With git, many developers tend to work on branches, even for longer time. Then they merge them into the ‘master’ branch when the functionality is finished, the freeze is over and so on.
In the Commit Digest we usually do not include commits outside of the master branch. Because of this, we can miss some of the interesting functionalities. Some developers have started putting DIGEST tag to their merge commits with information on the branch content. I really like the idea. If you develop a new function or some important refactoring during a longer period of time, make sure you include the DIGEST tag if you want to be sure the Commit Digest includes it.
This post is inspired by an Akademy discussion with a developer who likes the Commit Digest but didn’t know about the DIGEST tag 🙂
The KDE Commit Digest http://commit-digest.org/ provides weekly review of KDE developers activity. The reviewers of the Digest choose the commits to include based on the developer’s commit message and the commit content itself.
However, the change that is clear to the developer, may not be at all clear to someone with less knowledge of the project internals. There are two basic ways you can tell the Digest reviewers that your commit is important:
- Use the DIGEST tag in your commit message to mark the commit, normally at the end of your commit message. Use it as additional description of the general effect of your change. This can look like this: “DIGEST: This implements The New Great Function”.
- Write easy to read message that describes the function of the commit. Example: “With this change The Function Everyone Uses works 50% faster”).
Hint: Do not be afraid to use the DIGEST tag. The reviewers will make the decision and they generally prefer to have too many of those tags (this is a strictly theoretical situation at this moment) than not enough.
When translators and developers look at the same program, the see different things. For the developers, the code is clear. There is context around. For the translators, however, it is different. They just see the message text. It’s good to have a document that describes the two views.
Lasse Liehu has just finished a Techbase page about the subject. You can access is here: http://techbase.kde.org/Development/Tutorials/Localization/Message_Appearance .What I really like about this that it is full of illustrations. You can see the same situation from two viewpoints yourself. I recommend the example with “d/M/yyy”. That is a situation when
a context comment is really welcome.
I think this document is a must-read for both developers and translators. And if your program is not yet ready for translations, search Techbase for more documentation.
We had a BOF on translation issues on this year’s Akademy. Many people came up and we really didn’t have time to discuss everything. However, it was a very interesting meeting and a needed one. Sebastien made a summary on the translators’s list: http://lists.kde.org/?l=kde-i18n-doc&m=137413658517601&w=2
The common reservation system
The Google Summer of Code work is on the way. Up to this point different teams developed different solutions to handle the management of their teams, like the translation reservation. The GSoC work is going to provide a common tool. We were discussing mostly the details like authentication for translators and new people. The general agreement was that we’re going to try the new methods. The functionality will be optional and each team will decide if they’re going to use it or not.
Wiki translation workflow
Currently the wiki translations are somewhat apart from the main translation work. There is no information to the translation team if somebody joins the wiki translation, there is no automatic notification of the changes either. Most of the teams expressed concerns on the wiki translation quality and prefer the wiki translations to be linked more to the general ones.
Reporting a typo
It was a surprise to me to learn that most of the teams have problems getting user feedback, like typo reports. The Bugzilla system is not working well for such cases.
In the Polish translation we have a note to the user about this in the “About translations” window. It says to send a typo/clarification request to a mailing list. It was there since long ago and seems to work quite well.
We came with an idea to add a new window next/in the “Report a bug” one that allows to contact the translation team. I find it a good idea and it looks that it is also OK for kdelibs.
What we did not have time to discuss…
After my Akademy presentation, many translators told me that they also have a need for more promotion efforts. We did not have time to discuss it at the BoF, but we’ll use the mailing list for that.
I had a presentation at Akademy this year, talking about the way developers can use their commit messages to promote their projects further. The short version of the talk is: make the commit messages easy to understand and if you have an important new feature, add the DIGEST tag.
Slides the presentation are online. You can download them from:
my blog, Akademy site or my site.
KDE Commit-Digest provides an overview of the developers activity in KDE. However, bringing it to the readers every week requires significant number of people to review and classify the commits (thanks to developers!) on regular basis. That’s why we’re continously waiting for contributors!
Participation in the Commit-Digest offers an unique perspective on what is happening in the repos in real-time. Visit us and join as an editor, commit classifier or commit reviever, or any combination of those functions.