[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

About the new Status Pages



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/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]