Re: Bugzilla and localizations components/products
Axel Hecht
here's the proposal coming out of the thread in .governance. Quick recap
for .l10n: We'd like to re-arrange how we do bugzilla components for
l10n, to achieve a few things:
- get a better at exposing work items for people to pick up
- get a better grip on the web bugs, and not spam the websites folks
with all l10n bugs there
- better track what bugs are open, both within a particular localization
and across localizations.
There has been a good deal of back and forth, but l10n-drivers and Gerv
came up with the following that we'd like to do:
- create a new categorization (like "Client Software") for l10n bugs,
called "Mozilla in Your Language".
- within that classification, have a "product" (bugzilla term) per
locale, named
l10n: Afrikaans (af)
l10n: Arabic (ar)
....
- within each product, have a bunch of components.
Firefox
Fennec
Thunderbird
SeaMonkey
Calendar
Toolkit
Websites
Other
Those are created as needed, i.e., locales without Fennec don't have
that component set up.
Each of those components has a QA contact like
"firef...@localization.bugs" and a default-CC of
"a...@localization.bugs, firef...@localization.bugs", default assignee
is nob...@mozilla.org.
The existing locale-bugs will be migrated into the new components (with
some community help), and the old components will be removed. The
components for Registration and Infrastructure will stay where they are.
Ricardo, what to do with MT?
All components will have their QA contacts and default assignee per
scheme, and we'll need to get all localizers to move over to watch the
new aliases (we can probably rename the current ones to ease that a
bit). This is a change for some locales, but it's going to make it
easier for new contributors to just go in and watch the bugzilla
component they're interested in.It'll also be easier for us to CC
aliases if we're interested in feedback from particular locales on
non-l10n bugs etc.
The new bug templates will be adjusted to expose "Mozilla in Your
Language" as fits.
The whole thing should make bugzilla a more powerful tool for all of us,
and make it easier to join existing localization efforts, too.
Known drawback: When moving a bug from one component to the other, all
products independent of classification are shown. We'll make that list
longer, sorry. The good news is, all l10n products are prefixed with
"l10n:" so it's easy to skip, and, only experienced bugzilla users with
added bugzilla priviledges can even do that, so we're not hitting
unexperienced bugzilla users. Nor is it an action that happens *that*
frequently.
We hope you like it, and if there are no blockers discovered, we'll move
forward with this scheme soon.
Axel
Pavel Cvrcek
> We hope you like it, and if there are no blockers discovered, we'll move
> forward with this scheme soon.
What about Mozilla Communities? Will be moved to new location too?
Classification: Other
Product: Mozilla Communities
Component: cs or es-MX
See Bug 520454.
--
Pavel Cvrček <pcv...@mozilla.cz>
http://www.mozilla.cz/
Axel Hecht
> Dne 16.3.2010 11:28, Axel Hecht napsal(a):
>> We hope you like it, and if there are no blockers discovered, we'll move
>> forward with this scheme soon.
>
> What about Mozilla Communities? Will be moved to new location too?
>
> Classification: Other
> Product: Mozilla Communities
> Component: cs or es-MX
>
> See Bug 520454.
>
I'm not sure yet, I'm open for opinions. It's not something we need to
decide ad-hoc, either, IMHO. There don't seem to be any bugs in the
es-MX component to begin with, so the practical impact of that being
"available" across locales seems to be low.
Might be worth to get some feedback from you guys on how that component
is doing for cs. Found 77 bugs in there, but can't read a single one of
them ;-)
Axel
Pavel Cvrcek
> Might be worth to get some feedback from you guys on how that component
> is doing for cs. Found 77 bugs in there, but can't read a single one of
> them ;-)
Yes, it's in czech because it's better for some part of our community.
This component is used for tracking bugs which are related to our
community and our websites (for example: http://www.mozilla.cz/).
I agree that this isn't something whan we need decide at this moment.
Just for info. We don't have problem to stay in this component.
Ricardo Palomares Martínez
> The existing locale-bugs will be migrated into the new components (with
> some community help), and the old components will be removed. The
> components for Registration and Infrastructure will stay where they are.
> Ricardo, what to do with MT?
Sorry, I've been somewhat offline these days. I browsed your post and
inmediately thought of MT, yes.
Regarding your question, most modern bugs filed on MT were created by
myself to track changes in the application, so it seems that not a lot
of people will miss if MT component disappears from bmo. In fact, I'll
be releasing a new version RSN and I was too lazy to file bugs for
every change in this new version.
I've been reviewing my permissions on Sourceforge.net where the
project has its code (https://sourceforge.net/projects/moztrans/) but
I can't assign myself filed bugs in it (why I don't have full
permissions there is a long story).
So I could create a new project on either Sourceforge.net or other
place and migrate both the code and the bug system there, starting
with the new version of MT. Since that moment, MT bugs should be filed
in the new project site.
What would happen to MT old bugs? Will they still exist and be
searchable? Or should we just forget them?
TIA
Axel Hecht
> Axel Hecht escribi�:
There's a Graveyard category on bugzilla, with a "Mozilla Localizations
Graveyard" you should be able to still search those bugs.
If sourceforge isn't cool for you, I'd suggest looking into alternative
things like github or bitbucket, or google code. They all have
lightweight bug trackers and their dvcs nature helped other projects a
lot in actually getting contributions in. Seems that sf isn't at the top
of the game there these days.
Axel
PS: Taking off of governance on purpose.
Axel Hecht
http://blog.mozilla.com/axel/2010/07/26/looking-at-a-l10n-bugzilla-classification/.
Comments welcome.
Axel
Mark Banner
> I've blogged with some screenshots on how this setup looks locally at
> http://blog.mozilla.com/axel/2010/07/26/looking-at-a-l10n-bugzilla-classification/.
>
> Comments welcome.
For changing bugs, I think moving a bug to one side of the "l10n" to
another (e.g. Thunderbird -> Core) would be more difficult, because its
not just one or two simple scrolls with the wheel. However, that's a
rare operation, so maybe it isn't too bad.
The search page is also another potential problem, but I guess at least
we have the classification there to filter out the L10n products should
we not want to scroll through them.
Just some thoughts.
Standard8
Axel Hecht
> On 26/07/2010 21:52, Axel Hecht wrote:
>> I've blogged with some screenshots on how this setup looks locally at
>> http://blog.mozilla.com/axel/2010/07/26/looking-at-a-l10n-bugzilla-classification/.
>>
>>
>> Comments welcome.
>
> For changing bugs, I think moving a bug to one side of the "l10n" to
> another (e.g. Thunderbird -> Core) would be more difficult, because its
> not just one or two simple scrolls with the wheel. However, that's a
> rare operation, so maybe it isn't too bad.
Yeah, we've discussed this in this thread on .governance before. The
outcome was that this is OK, as it's both rare, and the current list is
tough already. Also, it's hitting experienced bugzilla users only.
> The search page is also another potential problem, but I guess at least
> we have the classification there to filter out the L10n products should
> we not want to scroll through them.
>
> Just some thoughts.
To quote shaver from elsewhere in this thread,
> Yes, we may have reached a local minimum for taxonomy usability. :-/
Axel
Axel Hecht
of making the products be "l10n:ab-CD Language Name (Region)"
If you want to take part in the planning of how to implement this,
please make sure you're CCed on
https://bugzilla.mozilla.org/show_bug.cgi?id=556236.
Axel