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
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
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
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
that the language maintainer's nod is taken into account before granting a new entrant
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
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*
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
would somewhat restrict the entry-process into the L10n process, but compromising with the
is not something desirable either.
I am sure there are some better suggestions hiding out there. Additionally, there could
unreported problems that have been faced by language teams/maintainers due to the current
cvsl10n approval. Perhaps bringing them out into the open would be helpful at this time to
a more balanced model for the FLP.
runa on Red Hat
mishti or runa_b on Freenode, Gimpnet, Mozilla, LinuxChix