CVSL10N access approval

[Runa Bhattacharjee]

Noriko Mizumoto wrote:
> Hi
> 
> As per FLP meeting today, I like to propose the idea of the approver
> procedure. At the moment there are only handful members giving approval
> and we should have more team coordinators to involve this process,
> because sponsoring allows the user to commit.

[snip]

Well, right amidst this discussion Igor has sent in a mail[1] highlighting a real incident that 
pointedly shows the flaw in the current system.

<quote>
...
I think we really should rethink how members are approved for cvsl10n
group. Anybody could have committed a translation file full of errors,
bad words or even a malicious file replacing the actual .PO.
...
</quote>

The current system of approval lacks to implement the following basic checks as mandatory ones:

1. Language team/maintainer knows the existence of the  new member
2. Language team/maintainer wishes to include the new member in his/her team
3. Language team/maintainer wishes to allow the new member to have commit rights

Due to reasons (or past history) best known to a language team/maintainer, a new member for a 
language may or may not be allowed a freehand to make commits rightaway.

> 
> Also we may be able to approach more automate way in FAS, such as;
> 1. The account requester selects language team to join
> 2. Auto approval request mail is sent to the selected language coordinator
> 3. The coordinator can approves/rejects
> 4. Only if approved, it is notified to the cvsl10n group to sponsor that
> person
> 

The above is the model currently followed by Gnome account system[2] and is a good way to ensure 
that the language maintainer's nod is taken into account before granting a new entrant commit 
rights. Due to the large number of language teams (>~75) in FLP, granting cvsl10n approval rights to 
the maintainers for each language team is not a scalable model (imho). Rather, the introduction of 
an additional step - "approval from the language maintainer" - would ensure that the the process 
does not lose its streamline.

The current setup is also compounded by the fact that the language coordinators *do not* get 
notified of any commits made to the <lang>.po files. Like the incident around the pt_BR files, there 
could be more similar incidents that are currently unknown. The additional step (mentioned above) 
would somewhat restrict the entry-process into the L10n process, but compromising with the content 
is not something desirable either.

I am sure there are some better suggestions hiding out there.  Additionally, there could be more 
unreported  problems that have been faced by language teams/maintainers due to the current model of 
cvsl10n approval. Perhaps bringing them out into the open would be helpful at this time to chalk out 
a more balanced model for the FLP.

hth

regards
Runa



[1] https://www.redhat.com/archives/fedora-trans-list/2008-November/msg00030.html

[2] http://live.gnome.org/TranslationProject/RequestingAnAccount
-- 
blog: http://runab.livejournal.com

irc:
runa on Red Hat
mishti or runa_b on Freenode, Gimpnet, Mozilla, LinuxChix