---

3.3.1 How to Track Tasks and Bugs Using Savannah

The team leader has to make sure that prospective translations are reviewed, that they do not contain obvious errors and confusing expressions and that they match the spirit and intention of the original essay. However, many teams tend to suffer from a specific problem: team members rely on the leader to make these extensive reviews. That is fine, as far as it goes, and the leader should always review translations before installing them in the repository—but it is nearly impossible (especially for a large team) to rely on a single person for such tasks. Team co-ordinators often do not manage to make such reviews in time, resulting in frustration among the team members and generally slowing the translation process.

A solution to this specific problem is to distribute the load among more people. For example: Member D makes a translation of foo.html and uploads foo.lang.po in the translation project’s repository at Savannah, marking the relevant task as “Ready For Test” (of course, the equivalent is sending a message with the attached translation to the team’s mailing list, or similar). Then Member A, B and C (or only A and B if C is currently busy) review it independently and post comments/suggestions/errors in the bug tracker. Discussion goes on between them and D, problems are rectified and finally the leader (who may happen to be one of A, B, C, D) makes a final review. It is easier to make the final review when most of the issues are already fixed in previous revisions. Finally, the translation is published. The result is better quality of the translation (since more people looked at it) and the whole burden does not fall solely on the shoulders of the leader. You can also set up an internal formal rule: If a member makes a translation, he has to review another one (or two) as well.

Some translations can take a fairly long time—the typical example is a complicated essay or a transcript of a speech. It is best to avoid duplicate work by indicating, or better—recording, that someone is working on this specific article. The ‘Tasks’ tracker is suitable for this purpose.

It is prudent to discuss the most convenient naming scheme and practice among team members, and publish the convention or rules at the team’s homepage. Note that you can create Custom Fields in the trackers, and resolved bugs can be searched based on these custom values.

Thus, a possible straightforward way to manage these tasks is:

• If someone starts working on a new translation, she creates a new task with a ‘Subject’ indicating the article, for example simply ‘philosophy/bsd.html’ and assigns it to herself.
• When the translation is finished and ready for review, the translator changes the ‘Status’ to “Ready For Test”.
• Other members review it, and open bugs relevant to one specific problem. It is usually better not to conflate two different issues together—it makes them harder to discuss, and hard to track them by severity. Some are grammatical errors, some are fundamental ones that change the whole meaning, some are simply suggestions for improvement. It helps if the project admin creates new Category fields for every article, for instance ‘gnu/gnu-history.lang.html’, ‘philosophy/microsoft.lang.html’—it would enable functionality like “Show me all bugs ever reported against this translation”, which is useful.
• Once the bugs (or at least the important bugs) are fixed, the team leader can make the final review and install the translation in the official repository, marking the task as ‘Done’. Bugs that are not resolved should remain open, naturally.

If there are compelling reasons, teams can choose to manage these things using external resources and eventually other bug (or issue) tracking systems. Whatever you decide, please make sure that bugs can be reported using free software only, and that the software providing that service is free. It makes an extremely bad impression if a reader has to report a problem about a gnu.org translation via nonfree hosting platforms like SourceForge.

If you use a certain facility (i.e. a bug tracking system) to manage bugs in translations, it is best to take advantage of generic.lang.html and advertise it on every page. See generic.html, for details.