About the new Status Pages

[Bernd Groh]

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/