Josep,
If there were translation teams, and I was the coordinator of my
team...
Isn't that the case? Do you want to be the maintainer of all modules for
catalan now or not? I haven't heard any objections, so it's yours for
the taking. :)
* I would encourage all translators to have a CVS account and
commit
their changes, *provided* the file has been *reviewed* and *accepted* by
the rest of the members of the team.
I'd encourage them too. But sometimes you want to commit something
you're working on, even though you're not finished. And sometimes you'd
like to commit something cos your finished, even though nobody else had
time to review yet. If it's no good, you can always roll back. What our
system does... you take a module, you work on it, you commit. If it's
not finished, you have to release it if you don't want to work on it
anymore. If it's finished, you're auto-released. If there's no
maintainer, end of story. If there's a maintainer, module set to QA, all
commit access blocked for everyone but the maintainer. Maintainer has to
approve with either a commit or by clicking [Approve]. Maintainer can
chose to wait for feedback from other reviewers.
* I would encourage all translators to apply as maintainers for
those
files that they are familiar with, either because they have translated
them before, or because they use them often, or for whatever reason. I
would still give priority to the last translator to be the maintainer if
he/she would like to.
I'd encourage them too. And I'd give priority to someone who was active
translating the file.
* I would make sure that whenever a file is "taken" or
"released" the
team's mailing list, and specially the maintainer of a file, are
informed about it.
Yes, good point, I should add that feature. So far, only the translator
is informed if s/he has been released. The maintainer is informed of
commits, but informing the maintainer of take and release can indeed be
helpful. And nothing speaks against the maintainer being a group, really.
* I would have more time to translate, and I would have to spend
less
time coordinating the team, assigning files and keeping track of who's
doing what and for how long they have been doing it.
That's the aim.
Roles:
*** Translator: the person translating a file at a given time.
That's the intention.
*** Maintainer: is the person responsible to keep updated a file,
whenever it needs improvements. This person would be responsible for any
translation bugs on that file. He/she doesn't have to be the translator,
though. The translator might change over time, upon team member's
availability.
That's the intention.
A Maintainer should be informed about translators taking their files,
and maybe maintainers should be able to commit at any time independently
of who's taken the file... (if possible)
Currently informed of commits, but of takes would be good too, I agree.
And the maintainer can commit at any time, that was my main point for
adding a maintainer.
Briefly, a maintainer is the person to contact for a certain file,
and
it often happens to be its translator too.
That's the intention.
*** Coordinator (team): the person to contact about anything related
to
the translation of a certain language (as described in Christian Rose's
description of the GNOME ModelĀ¹). It is the maintainer of all those
files that have not yet a maintainer, or for whom s/he is the real
maintainer, of course. It will commit files and act as a maintainer on
behalf of translators that have no CVS account.
That's who I'd assign all modules to by default (as a maintainer). That
at least is the intention. When we have team pages up, we can formalize
that all a bit more.
The coordinator coaches new translators (could be done by maintainers
too).
Possibly the coordinator should have full CVS access to any file that
belongs to its language.
That is a valid point. So far, the coordinator has only full access to
the files that are "unmaintained" (by being their maintainer). But I
believe that's a good feature to add. And I believe everyone experienced
can coach anyone new.
The election of the coordinator is up to each team, any changes about
coordinator must be submitted to this mailing list.
The coordinator should be informed about changes in Maintainers.
Maybe there could be the role of the "translation project coordinator"
much like what Christian Rose is for the GNOME project, and which I
suppose falls into Sarah Wang right now.
Fedora translation page should have a description of the translation
process, teams, coordinators... you get the idea :)
Well, that's the plan, it'll just take a little longer. Sorry, if we
can't put it up all at once.
All that... of course, if there were translation teams...
Well, there are, we know that, don't we? :)
Briefly, combining teams with the new method have a lot of potential
that we should explote.
Again, this is only my view, and there might be flaws, if there are I
hope you can spot them and tell me :)
No, I didn't spot any flaws, a lot of your suggestions have already been
put in place with the new system. And that exactly is it what puzzles
me. Given you've just suggested a lot of things that we've just put in
place with the new status pages, why again is it that it is criticized
so much? Why even do people say it nullifies existing translation teams?
I don't have to get it, or do I? ;)
Best Regards,
Bernd
Best regards,
/Josep
Bernd: these might be the scriptures you were asking for :)
Nah, that's pretty much the path I am going, as said, and a lot has been
implemented with the new upgrade. I simply won't restrict anyone cvs
access until we're fully organized, that's all. :)
Note: not all members of a team have to be translators, there are also
proof readers, philologists, users, etc, and not all of them have to
have CVS access.
1)
http://www.redhat.com/archives/fedora-trans-list/2004-June/msg00148.html
--
Fedora-trans-list mailing list
Fedora-trans-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-trans-list
--
Dr. Bernd R. Groh Phone : +61 7 3514 8114
Software Engineer (Localization) Fax : +61 7 3514 8199
Red Hat Asia-Pacific Mobile: +61 403 851 269
Disclaimer:
http://apac.redhat.com/disclaimer/