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

Re: About the new Status Pages



Thanks Bernd for taking the time to write this explanatory letter. It
definately helps having the points summarized.

There is a lot in your mail that I think everyone agrees with,
especially the good intentions. But I believe some of your arguments
you're making for the policy you appearantly have already decided upon
are very skewed and not based on reality. More on that below.


tor 2004-07-01 klockan 03.13 skrev Bernd Groh:
[ snip things about intentions that everyone agrees with ]
> 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.

The first thing that struck me was the claim that there will be 70+
translators for any single language. Believe me, the largest language
translation teams I know of aren't more than, say, a dozen to twenty
people for any project. And then that's still an exceptionally huge
team; almost all of them are much smaller, like one to five people. So
giving an example of "70+ people" doesn't really look like it's even
remotely connected to reality. It looks like the figure is intentionally
blown out of proportion.

Second, teams in practice usually annotate who is responsible for what
themselves, sometimes only with a simple spoken agreement, sometimes
with a list on a static web page, and sometimes even with more advanced
systems, similar to the current Fedora status pages. It usually depends
on the team's size and their structure what sort of method they want to
use and feel comfortable with.
Thus, there's really not an argument to be made that just because the
current Fedora status pages implement this, it's automatically superior
to what a team does for assignment (who's working on what) control, or
even that there is a benefit for larger teams, because larger teams
usually already have this in place. This is not new. The reason you got
requests for this is probably because you haven't had a team policy in
the past, so team agreement didn't always apply. That's fine, but don't
make it sound like evidence of team agreement not working.

Third, you make it sound like who's in charge of what usually changes
every day. In fact, it's usually quite a static thing. When a person
starts to translate a module, he usually keeps maintaining it, unless
some unforeseen issue arises. Of course people do sometimes exchange
modules, but that's almost always the exception. If you study teams
empirically you'll find that almost all translators keep maintaining the
same modules they've done previously. So requests for changing module
maintainership is usually a rare thing.

Fourth, you claim that all members of the team would fight for
translating a new module, thus making the life of the coordinator
difficult. This is almost never the case. It's difficult to get
volunteers, and every volunteer can usually get all what they want in
terms of getting their hands dirty without stepping on someone else's
toes. The problem is almost always the opposite -- to get volunteers to
work on a new module at all. Hence, the situation you describe with all
members of a team fighting for a particular module isn't the common case
at all.

Fifth, you make it sound like saying "I will be working on this
translation" in advance to the team would be as difficult as ending
world hunger or something like that. Trust me, it really isn't. Most
translators seem to be happy with and familiar enough to email
communication to be able to send short mails in their native tounge for
this to be a total non-issue. And, the assignments are almost always
non-controversial, so there is rarely the big discussions you try to
make a point of. Almost all this communication is a two-piece, really
short one: "I will translate XYZ" and the reply "OK, noted". Again, you
blow the issue out of proportion, and the argument doesn't seem to be
based on reality.

And last but not least, you fail to answer the question why you think
translation is different enough from other forms of contributions, like
software patches, where this anarchistic, no-prior-review-needed policy
is definately not used. If you believe a mandated review and cooperation
policy is bad for contributions, then why does every other form of
significant contribution to a project require this?


Given all of this, it sounds like you're making up arguments out of thin
air to defend your policy, instead of arguments based on experience. I'm
sorry to say that, but nevertheless that is the impression I get.

Granted, you're willing to change minor details in how the translation
system works according to feedback, but the most fundamental and
pressing issue that almost all experienced translators complain about is
the one you appearantly simply don't want to consider. Instead you make
up fictive arguments to defend your stance, unwilling to take note of
the massive complaints, or even the fact that one of the most wellknown
volunteer translator groups have recently left the project because of
this.

I don't speak Arabic, but I know Arabeyes has been extremely efficient
in producing close to complete translation coverage in virtually no time
at all for almost all major open source software projects out there, and
in having done so they are virtually one of a kind in translation
experience, so what they have to say should at least be considered. The
fact that they cite this flawed policy and the unwillingness to change
it as the prime reason for leaving the Fedora project should at least
ring a warning bell somewhere.

Appearantly it doesn't, but you decide that the Fedora translation
project should continue full steam ahead with an anarchistic policy that
no other major translation project uses, unwilling to consider why this
is the case, and a policy for which no good defensive arguments based on
conditions in reality can be made.

I would urge you to stop and reconsider before more teams lose their
faith in the reasonability of mankind, and decide to leave the sinking
ship.


Christian



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