Future of the KDE commit digest?

April 17, 2009

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).


6 Responses to “Future of the KDE commit digest?”

  1. friesoft Says:

    those are absolutely amazing ideas imho 🙂

    I also really miss the digests.. still I fully understand danny not having enough time.. I’m more or less in the same situation.. real life is just too demanding 😀
    that said I want to thank danny again for his great work in the past 🙂

    I haven’t had the time yet to get into action by writing code but I’d love to help rating and categorizing the commits.. I’m having many lessons at school which are perfect for such activities ^^

  2. vvaz Says:

    Some time ago there was proposition for additional tags for commits. With this tags developers themselves could provide first filtering of commits. It wouldn’t be done on separate site but with commit itself. For example when you add new feature to Palapeli you add tag to commit – CD-FEATURE and this commit is magically added to digest. Other two tags could be CD-OPTIMISATION and CD-BUGFIX.

    I think that with a bit of work (not that I am able to do that) 90% of digest could be made automatically. Human work would be to add short introduction and post thing on dot.

    For not abusing system like developers marking all commits with CD* tags simple filters could be employed: commit comment not shorter than eg. 100 non-whitespace characters and/or in some way set limit of CD* tags per week per application.

    If you want community angle add voting for users and regulate those limits with results.

  3. Hans Says:

    Did I hear someone saying “commit plasmoid”? Personally I like to kill time in other ways, but seeing how people like to tag and comment on each others’ photos on Facebook etc., I’m sure there’ll be people who would enjoy tagging/rating for commits. Especially if it’s easily accessible, for example from your desktop.

  4. Digger Says:

    yeap, commit plasmoid which allows real time taging could by nice

  5. InvisibleSmiley Says:

    “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).”

    Or unless that person has a deep understanding of the platform and invests a significant extra amount of time into gathering the required information (understanding the actual changes made by reading the commit/diff, bug comments etc.). That’s what I do for the SeaMonkey Trunk Tracker. But I have to agree that it doesn’t scale. I only managed to keep up with the commit flood by limiting the scope (concentrating on major changes and ones that can be perceived) and posting more seldom (first weekly, then biweekly, now only prior to new releases of the software).

    That said I’m curious to see what will happen to the KDE Commit Digest. I always enjoyed reading it but I can also imagine how much work it is and how much time it takes to prepare it. I still think such work requires some degree of insight so maybe it’s and idea to distribute the work among several people, each watching a different set of modules/applications, something like a product stewardship.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s