Ubuntu Translation bug handling process

Mon Dec 7 10:21:37 GMT 2009

Hi Sense,

First of all, thanks a lot for the feedback. We really appreciate this,
since bug handling is a new process for the translations team and any
comments, especially from experienced bug squad members, are really
useful to us.

Let me give some background on the purpose of the ubuntu-translations
project for translations bug reporting. As you probably know, unlike
other teams (e.g. kernel), translations cannot be reported against a
single package (not even language packs (*)). This, and the facts that
a) knowledge on how to handle or fix translations is currently scarce
and b) translations has been an aspect traditionally not too well looked
after, lead to the situation that many translations bugs were simply
forgotten in the past, although many members of the translations
community would have been willing to actively triage them and in some
cases also fix them.

In the past, the i18n or l10n tags had been used on an occasional basis,
but as in Launchpad you cannot subscribe to a tag, it was not possible
for those interested in monitoring and acting upon translations bugs to
have an overview of the whole picture.

With the ubuntu-translations project we've now got a hub for
translations bugs: this allows those interested in them to get an
overview of currently open bugs, having a team (the Ubuntu Translations
Coordinators) behind it -both actively triaging and fixing them and
acting as a point of contact- and permitting further community
participation subscribing to bug mail. Another compelling reason for
using it was to decouple bugs related to Ubuntu translations from bugs
in the Launchpad Translations component. Very often bugs in the distro
were reported against Rosetta, and there was not a clear path for the
Rosetta developers to bring them back to the distro. Now they only have
to move them to ubuntu-translations, and if necessary we open tasks for
the appropriate packages.

We are still learning about the bug triaging process for translations,
and in that respect we've been documenting it and asking for feedback
from the bugs team:

https://help.ubuntu.com/community/ReportingBugs#Filing%20translation%
20bugs
https://wiki.ubuntu.com/Translations/KnowledgeBase/ReportingBugs
https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs

Note that this is still work in progress, e.g. the last two documents
should probably be merged into HandlingBugs, which is currently a
brainstorm page for defining the process.

That's one of the reasons (not having a defined process) we hadn't
widely announced the project yet, but after the experience from the last
cycle and your original suggestion on a Hug Day on language packs, I
thought it might be time to move this forward, give it a road test
during the Hug Day and get some more feedback. 

Needless to say, we are open to suggestions and willing to follow the
standard practices of the bug squad.

I feel that this has worked extremely well for the Karmic cycle. I do
not have statistics at hand other than [1], but judging by the number of
bugs we've processed and the status of the release (also comparing it to
previous ones), I think this has been one of the main achievements of
last cycle in terms of better translations QA.

El dj 03 de 12 de 2009 a les 20:27 +0100, en/na Sense Hofstede va
escriure:
> Hello,
> 
> Browsing the BugDay of this day[1] I can't help but feel that a lot of
> these bugs have appeared on the list because the ubuntu-translators
> project doesn't want to use or cannot set importance and the Triaged
> status. I suspect the latest.

Neither of those, it's because we (well, at least me) didn't quite know
the difference between Confirmed and Triaged. I'd be more than happy to
use the same convention from

https://wiki.ubuntu.com/Bugs/Status

for the ubuntu-translations project, and start marking the current
Confirmed bugs to Triaged as appropriate.

> This means that the status of the bug reports that are mainly handled
> by Ubuntu Translators will continue to pop up on search results like
> the one used for the lists of this BugDay.
> 

Another thing I noticed in the Hug Day is that only members of the
ubuntu-translations-coordinators team can change the status to triaged -
is there a way we could give this ability to the bugsquad team as well?
Would that be desirable?

> The triaging process for translation bugs is further complicated by
> the requirement to report it both against the source package of the
> affected application and the ubuntu-translations project. This forces
> us to maintain two sets of statuses, each subject to the rule of a
> different team. This causes confusion.
> 

Although we do not make it a requirement, it is true that in most of the
cases there is a separate task for the package. While I see some of the
disadvantages in that, I cannot think of any other way of keeping track
of translation bugs as a whole and at the same time have the bugs
reported or fixed in the package.

> Then there is the problem of the difference between translations made
> at Launchpad and translations made upstream. Some bugs have to be
> fixed here, some have to be forwarded upstream.
> 

If there is a fix in a particular translation to be forwarded upstream,
it should be the responsibility of the local Ubuntu translation team
subscribed to the bug to do that. While the
ubuntu-translations-coordinators team encourages that, we do not have
the resources for forwarding these particular fixes ourselves.

> I suggest to make the process of reporting more clear by implementing
> the following changes:
> 
> 1. The starting point of all translation bugs -- unless you know
> better already -- can still be the source package of the affected
> application.

Ideally, it should work like this, but experience has shown that such
bugs never make it to the translations team or those
interested/knowledgeable in translations, so they tend to remain open.

> 2. No extra tasks for bugs in upstream translations, this only adds
> extra clutter to the overview, generates extra mail noise and
> generates more work and confusion.

I'm still in favour of using the ubuntu-translations project for the
reasons stated above, but I (and I believe I can speak for the rest of
team members) am open to any suggestions or improvements.

> 3. Bugs in translations done at Launchpad should be reported against
> ubuntu-translations and keep the source package task, because:
> 4. The source package task is for maintaining the status of the bug
> concerning the system -- i.e. if the bug has been Triaged(=reported
> properly upstream or at ubuntu-translations) or if the Fix is Released
> -- the ubuntu-translations task should be for the status of the fix in
> Rosetta or the team only
> 4b. This means that translation bugs always need to be 'forwarded
> upstream', be it to real upstreams or to ubuntu-translations. This is
> what the triagers should focus on when triaging these bugs.

While I basically agree on this, I think you are talking of the process
of forwarding translations upstream in general, and not translation bug
fixes, which is a task that has never been done through bug reports. I
think 

> 5. Responsible for setting the status in ubuntu-translations are their
> (appointed?) members, responsible for the source package task is Bug
> Control (and the Bugsquad). Some members of ubuntu-translations that
> are very active on Launchpad/Malone could be granted membership of
> Ubuntu Bugcontrol -- if they don't already are a member -- to make it
> easier for them to manage the source package tasks.

That's a very good point, and might address the question I was asking
above about bugsquad members not being able to change the
ubuntu-translations statuses to Triaged.

> 6. Use the Triaged status for the source package when the Bugsquad
> doesn't need to do any work on it anymore!
> 

We'll do it for ubuntu-translations from now on! :)

> These points don't add a lot of new stuff, but things would be a bit
> clearer if both teams would agree on them and integrate them into the
> documentation.

Again, thanks a lot for the feedback, which is really appreciated. I
hope this generates further discussion and helps us improving the
quality in native language support in Ubuntu.

Regards,
David.

(*) Language pack packages are usually not a good target for bug
reports. Unless the bug is localized to a particular language pack, in
which case it is valid to report it there and then assign it to the
local translation team if necessary, there are lots of translation
issues which have nothing to do with language packs (e.g. untranslated
strings in an application, translations not loaded, etc.). Furthermore,
the Ubuntu Translations Coordinators team is not the bug contact for
language packs, so unless actively searching for reports against
language packs, these usually fall out of the translations team radar.

[1]
https://bugs.launchpad.net/ubuntu-translations/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY&search=Search

-- 
David Planella
Ubuntu Translations Coordinator
david(dot)planella(at)ubuntu(dot)com
www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part
 d'un missatge signada digitalment
Url : https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20091207/455334e1/attachment.pgp 