958800 - Create aliases for Mozilla Localizations components

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Gordon P. Hemsley [:GPHemsley]]

Each component in the Mozilla Localizations product should have an associated alias, to be available for localizers to shadow for easy CCing of particular locales.

There was some concern in bug 474272 that this would be disruptive, but IIUC the mere creation of these aliases should affect anything else. They would merely serve as an extension point for localizers who would like to add such a feature to their workflow.

Based on discussion in bug 556236, which was conducted in the scope of a much bigger change, I recommend the following alias format guidelines:

(1) Use 'localization.bugs' for the domain.
(2) Use standard hyphenated-at-spaces usernames for the regular components (e.g. '[e-mail]', '[e-mail]').
(3) Use a 'locale.{locale code}@localization.bugs' format for locale components (e.g. '[e-mail]', '[e-mail]', '[e-mail]').

This creates a logical structure for the aliases and also allows for future expansion (e.g. '[e-mail]', '[e-mail]').

Once these aliases are created, they should be added as the default QA contact for any Mozilla Localizations component that does not already have one. (So as to avoid disrupting existing workflows, components with an existing QA contact would not be changed at this time.)

We might also want to consider doing the same for default assignees, though I suspect that the '[e-mail]' assignee might be serving an actual purpose in some workflows, so that likely warrants further discussion.

Axel, what do you think of this proposal? Does it sound reasonable to you?

Comment 1

[Gordon P. Hemsley [:GPHemsley]]

We should also consider adding each alias to the default CC list of its corresponding component.

Comment 2

[Axel Hecht [:Pike]]

The problem we have right now is that people contributing to l10n don't watch bugzilla. They don't watch their components, and many of them don't even have bugzilla accounts.

Using aliases instead of real people has two downsides: You don't actually know if anyone is getting bugmail, so it adds a false sense of security. And in the case of the needinfo flag, there's nobody actually checking the needinfo. The latter is already a practical problem with the [e-mail] account, which is needinfo'd, and there's just no contract that anyone will bother.

Thus, I'm resolving this as invalid. Sorry, sounds rude, like any of those "not fixed but fixed" descriptions. But I think this just isn't the problem we're facing, in particular based on my experience with the community alias.

Comment 3

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Axel Hecht [:Pike] from comment #2)
> The problem we have right now is that people contributing to l10n don't
> watch bugzilla. They don't watch their components, and many of them don't
> even have bugzilla accounts.

That sounds like a problem that deserves more attention, then.

> Using aliases instead of real people has two downsides: You don't actually
> know if anyone is getting bugmail, so it adds a false sense of security. And
> in the case of the needinfo flag, there's nobody actually checking the
> needinfo.

That's true, there is that risk. But it does at least provide a visible marker in a consistent place for whose attention is required.

> The latter is already a practical problem with the
> [e-mail] account, which is needinfo'd, and there's just
> no contract that anyone will bother.

I'm not familiar with with the '[e-mail]' alias or who its intended audience is.

> Thus, I'm resolving this as invalid. Sorry, sounds rude, like any of those
> "not fixed but fixed" descriptions. But I think this just isn't the problem
> we're facing, in particular based on my experience with the community alias.

I understand that the larger problem you're having with the l10n community is one of engagement, but this isn't intended to solve that straightaway. Rather, the intent is to provide an additional avenue for localizers to engage, should they so choose. There is a greater discussion to be had about how to improve engagement and encourage localizers to use the avenues available to them, but I don't think that should hinder the effort to increase the availability of avenues that have been shown to work for other groups of users.

The issue of a false sense of security is indeed an important one, and one that needs to be addressed, but I think it may be the only downside here, and I don't think it should be a showstopper to the creation of these aliases.

I don't like to get into open/close wars with you (and I know we have a particular history of doing that in this component), but I'm tentatively going to reopen this bug, because the fact remains that these aliases do not exist. If you feel strongly that they SHOULD not exist (an opinion that I would, naturally, disagree with), then I think this is better off as a WONTFIX.

Comment 4

[Axel Hecht [:Pike]]

I think the creation of those aliases doesn't serve any purpose.

Also, forcing QA contacts of components that you don't own isn't a good idea.

I don't intend to spend more time on this effort.

Comment 5

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Axel Hecht [:Pike] from comment #4)
> I think the creation of those aliases doesn't serve any purpose.

Duly noted. If it goes nowhere, so be it. At least we'll have tried.

> Also, forcing QA contacts of components that you don't own isn't a good idea.

As you've probably noticed, I prefer to ask for forgiveness rather than permission. :)

But as you've said, there has been trouble getting people to use Bugzilla and its many features, so it's dubious whether anyone will even notice, let along care.

I've been careful in my proposal to avoid disrupting any existing workflow; any component which already has a QA contact would be left alone. The only difference between this proposal and the status quo (which is a null QA contact) is that the QA contact could be shadowed. For all relevant intents and purposes, it may be interpreted as equivalent to a null QA contact if a component owner so desires.

> I don't intend to spend more time on this effort.

I'll take that to mean that you don't intend to WONTFIX this, then.

CCing non-null QA contacts to give them an opportunity to weigh in.

Comment 6

[Axel Hecht [:Pike]]

Oh damn, I'll WONTFIX this. We are not going to require l10n communities to cover up for this task.

As it should be said in various other discussions these days, don't ask people to work around your problem within the status quo, ask our bugzilla devs to fix it.

Comment 7

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Axel Hecht [:Pike] from comment #6)
> We are not going to require l10n communities to
> cover up for this task.

I don't understand what you mean by this.

> As it should be said in various other discussions these days, don't ask
> people to work around your problem within the status quo, ask our bugzilla
> devs to fix it.

We've tried that in the past, and it didn't go anywhere.

It's a lot easier to perform lots of little tasks to get us incrementally where we want to be than to try to coordinate a huge master plan all at once.