Re: Ubuntu Translation bug handling process
The Bugsquad meeting was postponed to Jan 19th at 1600 UTC -- FYI On 01/04/2010 11:06 AM, Sense Hofstede wrote: > 2010/1/4 David Planella: >> 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 >>> package >>> >>> * 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 >> there. >> >> I've summarised the main points at >> >> https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background >> https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming >> >> 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. >> >> Thanks. >> >> Regards, >> David. >> >> -- >> David Planella >> Ubuntu Translations Coordinator >> david(dot)planella(at)ubuntu(dot)com >> www.ubuntu.com >> >> >> >> >> -- >> Ubuntu-bugsquad mailing list >> ubuntu-bugsq...@lists.ubuntu.com >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> >> > Hello, > > 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 > of Translations. > > Regards, -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Translation bug handling process
2010/1/4 David Planella : > 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 >> package >> >> * 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 > there. > > I've summarised the main points at > > https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background > https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming > > 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. > > Thanks. > > Regards, > David. > > -- > David Planella > Ubuntu Translations Coordinator > david(dot)planella(at)ubuntu(dot)com > www.ubuntu.com > > > > > -- > Ubuntu-bugsquad mailing list > ubuntu-bugsq...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad > > Hello, 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 of Translations. Regards, -- Sense Hofstede [ˈsɛn.sə ˈɦɔf.steːdə] -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Translation bug handling process
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 > package > > * 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 there. I've summarised the main points at https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Background https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Brainstorming 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. Thanks. Regards, David. -- David Planella Ubuntu Translations Coordinator david(dot)planella(at)ubuntu(dot)com www.ubuntu.com signature.asc Description: Això és una part d'un missatge signada digitalment -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Translation bug handling process
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 package * 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, -- Adi Roiban -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
Re: Ubuntu Translation bug handling process
2009/12/7 David Planella : > 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 > disadvantage
Re: Ubuntu Translation bug handling process
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 t
Ubuntu Translation bug handling process
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. 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. 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. 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. 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. 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. 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. 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. 6. Use the Triaged status for the source package when the Bugsquad doesn't need to do any work on it anymore! 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. [1] https://wiki.ubuntu.com/UbuntuBugDay/20091203 Regards, -- Sense Hofstede /ˈsen.sɜː ˈhɒf.steɪdɜː/ -- ubuntu-translators mailing list ubuntu-translators@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
