Future of the KDE commit digest?

Every day I visit the dot, I’m sad to see no new commit digests. The last digest is one month old, and refers to two-month-old developments. I appreciate very much the work that Danny has done for the commit digest, but he also notes that the current method does not scale to the future. KDE is growing every day. We’re welcoming a new contributor nearly each day (according to SVN account numbers, not counting patch writers), and a new e.V. member about every two weeks.

Judging from the comments on earlier commit digests, many people like the commit digest. (The concept has also been adopted by the Gnome project, recently.) Still, nobody seems to really care about its future. I’m already fully loaded with “the future of …” projects (most notably “the future of Kolf” and “the future of my academic studies”), but here is what I would imagine for the future of the commit digest. Perhaps, I can inspire somebody to make up something, or just start a discussion about this.

The model of a commit digest made by one person does not scale well, as one can currently observe (of course, I understand that Danny’s normal life is more important than the commit digest). The most important point from Danny’s view (as he explains in the blog article linked above) is that nobody actively writes stories for the commit digest. Many developers tend to write extensively about new features on the planet, but nobody writes articles for the commit digest.

(Disclaimer: In this paragraph, “nobody” means “virtually nobody”. The exception proves the rule. I did write articles for the commit digest proactively, for example.)

As a developer, I might want to add the problem that one person never knows how to judge commits properly, one single man does simply not know what is important to note in the digest, or whether some given commit fixes a bug or is an optimization or a new feature (unless one can conclude this immediately from the commit message).

I would like to have some community-driven site for preparing the commit digest. A developer (or an interested user) could rate commits on a scale between “ground-breaking new feature” and “uninteresting plumbing in internals”, and categorize them into features, bug fixes, optimizations, documentation updates, translation updates, move operations (from or to kdereview, for instance). If such metadata is available, it should be a trivial task to create even specialized digests. For example, some user from Bangkok might find a digest on updated Vietnamese translations very interesting. Or some student of computer science might want to filter all optimization commits to learn some useful tweaks for his C++ course.

It would also be nice if one could group commits together. For example, many developers like to distribute the several steps in implementing a feature into several commits:

• introducing some methods in related classes, or preparing the layout of related classes
• implement the new feature
• make the new feature appear in the user interface
• fix bugs in the feature and regressions introduced by the feature
• make it compile on Windows, again

One should be able to reflect this workflow in the commit digest.

To reduce the entry barrier to writing commit digest articles, there should be a simple option to insert blog posts into the commit digest. Many people are probably not reading the planet because there is too much noise. (There is more noise on other planets, but still.) It would be nice to find relevant blog posts, categorized by some topics such as “new features”, “community events”, or such.

Now I hear you asking when a normal developer should do all that. Rating commits, grouping commits, categorizing commits, adding blog posts. First, we have systems in place to integrate similar commit-related tasks with the normal coding workflow. (For instance, a KDE developer does not need to close a bug in Bugzilla manually after having commited a bugfix, he just appends some magic sequence to the commit message and have it closed automatically, with some commit description attached to the bug report.)

Second, such rating tasks do not take long. Again talking from my experience, I have moments when I’m simply not up for coding, when I do just do some smaller tasks that have piled up over the week. Rating the commits you did in one week should not take more than ten minutes, and it’s a great opportunity to recapitulate and reevaluate one’s design decisions and such.

Last but not least, the rating does not have to be done by the same developer. I for one could imagine to rate everything that is going on in kdegames on a regular basis. Other users might also be eager to contribute to KDE in an easy and productive manner, this could be a nice entry point. Of course, we would need some kind of validation for all ratings and such. The easiest way would be to prioritize developer ratings (their identities can be proven by the sysadmins), but I’m concerned what could be done to ensure the quality of input from non-developers.

Wow, that article has grown much too long. I hope that it fulfills its purpose to start something (at least a discussion).