CVSL10N access approval
runab at redhat.com
Fri Nov 7 04:51:02 UTC 2008
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 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 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.
runa on Red Hat
mishti or runa_b on Freenode, Gimpnet, Mozilla, LinuxChix
More information about the trans