About the new Status Pages

Thu Jul 1 09:54:16 UTC 2004

Bernd Groh,

    Thank you very much for your hard work and good job! :D

    I've just tried the updated status system, it really works well.

    Thank you.

======= 2004-07-01 09:13:50 Quote from your mail =======

>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/
>
>
>
>--
>Fedora-trans-list mailing list
>Fedora-trans-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-trans-list
>

==================================================

hutuworm