Hi All,
since there has been some confusion about the new status pages, I feel
like I need to summarize what actually happened, and let me assure you,
it wasn't a step away from teams. Established language teams are well
considered by the new status pages, much more than previously. Yes, we
are still missing team pages, and we do apologise for not having had the
ressources to put them up yet, but it is our intention to do so. Things
are moving towards teams, and we'd like to encourage them, however, we
are reluctant to mandate things and tell you how things are going to be,
since that's not entirely up to us, but also up to you.
So, what is new?
First new thing is that a module can be assigned to a Translator and
there is a [Take]/[Release] mechanism in place. What exactly is a
Translator in this respect? A Translator is a person translating a file
at a given time (thanks, Josep ). What's it for? Two things. First, so
other people know who's currently doing what, and second, to minimise
conflicts because two translators are working on the same file at the
same time. You say that wouldn't happen if you'd have a group and one
coordinator to coordinate all translations of the group? For a small
group that might be feasible, but if you have one coordinator and 70+
translators, things can get quite difficult to manage this way. Also, we
would require the coordinator to be available at all time, we'd require
the coordinator to make a decision, or we'd require 70 people to
discuss about who's going to translate the file. Sometimes it is much
easier if, given the translator can do a good translation of the file,
whoever sees first that there is a file to be translated, that this
translator just does the job. Sometimes, there can be too much talking
about things, and it is, in fact, better to just do it. And there's
nothing that says that that's not how the group wants to do things. Not
all groups work in the same way. That might have an effect on
consistency? If the group has already agreed on a certain terminology,
and a person of that group simply does the job, without requiring too
much talking about it, how? As said, different groups work differently,
and I do not like the idea to build a system that is set to a certain
way, I rather build a system that can accommodate a large range of
behaviours of groups, or even of individuals. And yes, I am aware of the
disadvantages of this system, but IMO, groups should form because groups
want to form, and not because they have to form in order for the entire
system to work, groups should form in the way they want to form, and not
in one certain way, because that's the only way the system accommodates
for it.
How was the [Take]/[Release] mechanism intended to be used? A file
should be [Take]n before starting the translation, before doing a last
cvs up. Then the file should be worked on, and it should be commited
whenever you stop translating it. If you intend to keep working on it
soon, you keep the file, otherwise, you [Release] it. If you do commit a
finished file, it'll be released automatically.
This allows people to work independently, without requiring a group?
Yes, it does. It doesn't encourage groups? No, it doesn't. It is not the
job of a system to encourage groups, it is the job of people. People
encourage other people. I'd encourage anyone to join a group, everyone
should encourage everyone to join a group. If it is really the case that
most people ask for groups, and want to work in groups, why should it
even be necessary to mandate them? Shouldn't it then be the case that
most people actually do work in groups? It is up to every individual to
form a group, and to work in groups, it is, IMO, not up to one
individual to make groups happen.
What else is new?
The system allows for a module to have a maintainer. What exactly is a
Maintainer in this respect? A Maintainer is the person accountable for
the translation of a file. A Maintainer is the person commited to
providing a high-quality translation of that module to the
user-community. Yes, the maintainer is also the one who takes the blame
for a bad translation. As such, to compensate for the additional
responsibilities, the maintainer also has additional privileges. The
maintainer can manage who's translating the file. A maintainer is now
informed if someone takes the file (thanks, Josep ), and can chose to
release the module and take it herself/himself or to get someone else to
take it. A Maintainer is also informed of all commits to the file. If a
module has been finished, the module will automatically be set to QA and
the maintainer is now the only person with commit access to this file,
unless s/he [Approve]s it, or commits it, which we recognize as approval.
How do we support established translation teams? By making them
maintainers of modules, by letting them take over the responsibility
they've been carrying in the past, and by now providing them with a
mechanism to better manage the translation of a particular module, also
with informing them if somebody else is working on the file. Do we
support coordinators? Coordinators of small teams are invited to apply
for maintainership of all modules of a certain language. In general, and
if there are no objections from other members within the same language
group, this will be granted. For large teams, it may be better to split
maintainership to several individuals by coordinating/maintaining a
group of modules, however, we'd still, given there are no objections,
grant such request. If at any time, there are objections with regards to
a certain maintainer, everyone objecting is invited to make their case.
Every opinion will be heard, and we're happy to take concerns to a
maintainer directly.
That's about all. Again, apologies if the introduction of the new status
pages has been confusing, it wasn't our intention, and we will discuss
any further change on this list now. We'd also like to encourage people
to speak up, and not just if things aren't the way they want them to be.
After all, it is everyone's community.
Regards,
Bernd
--
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/