MAR
7
2004

How to highlight work in progress?

A common complaint I get from developers is that their work isn't showing up in the digest.

I'll explain how the whole thing is done, and then get to the question. I go through the 2000 or so commit emails from kde-cvs list, and select commits that are either bugfixes, new features, optimizations or security fixes. With bugfixes, any that have a bug number are selected. I then run a script that builds the html, statistics and other stuff, edit, add a few things here and there, then publish. This works reasonably well, although there are imo too many trivial bugfixes highlighted.

The format of the digest isn't conducive to highlighting work in progress. For a mature application, most of the commits are either maintenance/janitorial type fixes, or patches that introduce new features. Like KMail getting spam wizards. There was a patch inserting the basic functions, followed by a bunch that finished it up. Most of the time this work is highlighted appropriately. But when someone is working on building an application, they may have 15-20 patches that build the class hierarchy, some ui stuff, etc. This represents hours of important work, but no one or two patches give a decent idea of what is happening. The complaints usually arise from this situation.

So how would be a good way of representing this work? I encourage developers to email me summaries of their work. Any other ideas?

I am currently rewriting the scripts in php, and am close to being ready for some testing. My goal is to first match what we have now, move everything over to the new stuff, then add any neat stuff that comes to mind. The whole thing will still be based on selected commits.

Derek

Comments

Perhaps adding special human-readable tags like (case sensitive):

NEW FEATURE

or

IMPROVEMENT

or

(IMPORTANT) FIX

..to selected cvs messages could help?

At least within Kexi Project, Derek is right, that most bugfixing and feature improvements/additions comes from our irc discussions, regular schedule/todo docs, etc. rather than from bugs.kde.org system. Thus we cannot present any sensible issue numbers.


By Jarosław Staniek at Mon, 03/08/2004 - 15:19

Tags would help. But I don't expect developers to change their ways of working, unless they really want to see their name in print :)

One approach that may work is to make available a list of all the commits a developer has done in a module for a specific time period.

That way the viewer could see all that has gone into a project.

Derek


By dkite at Mon, 03/08/2004 - 16:23

You can do this pretty easily with cvs2cl.pl - I use this script to maintain the changelogs for a bunch of my apps and it works really well.


By Richard Moore at Tue, 03/09/2004 - 20:27

Would it be feasible to CCMAIL you on commits that might provide a new feature or finish what was started on a new feature? I know that's just more mail and bandwidth used by you, but it might be worth it.

Another idea that comes to mind is if developers want their work highlighted, could they just email you a quick synopsis along with the url's highlighting commits that add the relevant feature?


By mattr at Mon, 03/08/2004 - 17:59

Yes, good idea. Some developers have done that, and it works fine.

And a quick synopsis is the best. This is for situations where one or two commits don't give any real idea of what is being done.

Derek


By dkite at Mon, 03/08/2004 - 21:12

How about filtering by the length of the commit message? eg. I did a big update to the XPath code a few weeks ago that was probably worth a mention but didn't get one and it had a list of the added features which worked out quite long. This would of course miss some small but critical commits which would need another mechanism.

http://lists.kde.org/?l=kde-cvs&m=107727874211339&w=2


By Richard Moore at Tue, 03/09/2004 - 12:19