[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: CVSL10N access approval

Noriko Mizumoto wrote:

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.


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.

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.

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

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.



[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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]