Ubuntu Translation bug handling process
sense at qense.nl
Mon Jan 4 17:06:30 GMT 2010
2010/1/4 David Planella <david.planella at ubuntu.com>:
> El ds 12 de 12 de 2009 a les 12:16 +0200, en/na Adi Roiban va escriure:
>> Just my 2 cents and I try to be brief and concise.... but I failed
>> I think that all Ubuntu Translators will be happy to make
>> ubuntu-translators less useful by not having to do bug triaging.
>> The bughandling wikipage was just a brainstorming page. I would be happy
>> to delete it and have all info on bugsquad wiki.
>> Ubuntu Translations bugs are something special from the following points
>> of view:
>> * They can be fixed without having someone patching and uploading a new
>> * Most of them can be fixed in less than 2 minutes, just from the web
>> UI. You only need to read the bug, to to Launchpad translation, fix the
>> translation and then come back and mark that bug as fixed.
>> * Many translators are not technical persons.
>> We can channel all bug to Ubuntu and make them use apport, but I think
>> that this will stop them from reporting bugs.
>> I like to keep things simple and this is why I went for a divide and
>> conquer approach for handling Ubuntu translations bugs.
>> I think that reporting a bug in Ubuntu is ok when you don't know exactly
>> what component is affected and who can fix it.
>> For translations bug we know they affect ubuntu-translation and they can
>> be fixed by the ubuntu-l10n-CC (replace CC with your language) team.
>> The triaging process can be done by the bug reporter at the time they
>> report the bug.
>> No need to add extra work to other persons.
>> My goal is to have ubuntu-translation bugs fixed. Fast. Without stepping
>> on others feet.
>> What are the drawbacks of the current process?
>> Right now, in Ubuntu we have 39668 new bugs. What do we gain if we put
>> Ubuntu Translation bugs together?
>> I think we should add this topic on the next team meeting agenda.
>> Next for translations is 7 Jan, bugsquad 12. I am available for both.
>> Kindest regards,
> Let's try to move this forward. I like Adi's suggestion to discuss it on
> a meeting, and I see that micahg has already added it to the next
> Bugsquad's meeting on the 12th of January, so we can talk about it
> I've summarised the main points at
> I think so far we agree that we can move that page to the bugsquad's
> wiki and let the bugsquad channel translation bugs to the
> ubuntu-translations project as appropriate.
> The main point for me is that I'm open to any suggestions for
> optimization. While I'd be prepared to sacrifice the pool of
> translations bugs the ubuntu-translations project offers by submitting
> them only to the source packages, though, I wouln't want to compromise
> the additional benefits it has provided so far: bugmail and the
> ubuntu-translations-coordinators team acting as a driver. I think these
> last points have made all the difference in comparison to the situation
> we already had, that is, having translation bugs reported only against
> the source packages.
> David Planella
> Ubuntu Translations Coordinator
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
If the separate 'ubuntu-translation' project helps the translations
team then of course it should stay. Reading your mails and the project
documentation made it clear to me that this project has been a great
help for the translators.
I'll try to attend the meeting at January the 12th. Because I do think
that it would be good to define the roles of the Bug Squad and the
Translations team here. The meeting would be a good way to do so since
IRC allows direct communication and ensures the presence and attention
of the team leaders. You already have a workflow in place and of
course we shouldn't force our policies upon you, but there are
overlapping areas where both teams have to deal with the bug reports.
What we should do is to come up with a way to let the bugs show up in
such a way that they are useful to both teams and don't mess up the
statistics of either one of them.
Thank you for adding the explanation to the wiki page! Now I know
where to direct people to if they want to know more about the policy
More information about the Ubuntu-bugsquad