[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: About the new Status Pages
- From: Bernd Groh <bgroh redhat com>
- To: Fedora Translation Project List <fedora-trans-list redhat com>
- Subject: Re: About the new Status Pages
- Date: Tue, 06 Jul 2004 15:03:55 +1000
Christian Rose schrieb:
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.
As said, and that's why I am a little surprised by your email, I am
actually in favour of not just giving anyone cvs access for a certain
language, if 1) the group wants it, and 2) somebody makes
herself/himself accountable for such decision. If a language group
wouldn't want to restrict cvs access to "newcomers", nobody of that
language group would actually be willing to be accountable for such
decision, or there isn't any language team in place yet, I do not see
why I should not give someone of that language group cvs access. What is
wrong with that model? If 1) the group wants it, and 2) somebody makes
herself/himself accountable for such decision, I do agree completely
that cvs access should be restricted, and the group should decide
when/if it is time to give a "newcomer" cvs access. I've said the
exactly same before, and I say it here again, just in case it wasn't
entirely clear where I stand, though it should be.
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
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.
I can only go by how many people sign up to be a translator for a
certain language, and we have language groups with well above 70
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.
Well, it's not, and it certainly shouldn't look that way. My apologies
if it appeared as if I'd intentionally blow things out of proportion, I
simply did a count.
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
Christian, please, you know as well as I, that I never called any system
to be superior to another, neither I made an argument for it, I simply
said that there are different ways of doing things.
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.
Neither I said there is a benefit for larger teams, I simply said there
could be, depending on how the team handles things. And yes, the reason
for the requests might as well be because there wasn't a team policy in
the past, however, even if, I cannot change the past, all I can do is to
try and better things from how they are now.
Third, you make it sound like who's in charge of what usually changes
How? By introducing a Maintainer and stating that a maintainer should be
a "permanent" entity?
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.
That's how it should be, and that's why I've said a Maintainer should be
something "permanent". However, in our current reality, we do have to
deal with more than one person working on one and the same module at the
same time. Simply saying that it shouldn't be that way doesn't make it
go away. Saying that it's because there aren't any teams and we
shouldn't have done a, b, and c in the past, doesn't make it go away
either. As said, I cannot change the past, all I can do is to try and
better things from how they are now. All we did was adding visibility to
what's going on, what was so wrong about that?
Fourth, you claim that all members of the team would fight for
translating a new module, thus making the life of the coordinator
No, I don't. I can kind of see how you could get there, given I've said:
"or we'd require 70 people to discuss about who's going to translate the
file", but with this, I did not intend to say that members of a team
would actually fight for translations, neither I was making any kind of
claim, I simply meant to illustrate the responsibility a coordinator
has, and the difficulties s/he could, in addition, face in a large team.
All that was part of me making the point that, even though we'd like to
have coordinators for every team, we'd like such role to be entirely
voluntary, and not mandatory in order for the entire system to work.
That's all. Again, I didn't mean to say the coordinator model doesn't
work, neither that our model is better, not even that we do not want to
have coordinators, all I meant is that I do not wish to build a system
that is dependent on a coordinator or a team of a certain structure
being in place, but supports it iff that should be the case.
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
I'd say this depends on the language and the people involved in that
particular language, in general, I'd tend to agree with you, though.
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
Christian, in fact, I do agree with you that it is hard to get good
people taking on certain responsibilities, and this isn't just limited
to translations, but even more so to maintaining modules and
coordinating a language, or would you now disagree? Do you believe it is
hard to get people working on a module, but actually easy to find
maintainers, or even coordinators? I actually do agree with you, that,
in general, it is hard to find either, and that exactly is why I don't
want to build a system that is dependent on it. Why would you build a
system that is dependent on something that, apparently, is hard to
find? Why not simply support it if a given structure is in place or
forms naturally, and voluntarily? Maybe it is just my opinion, but if
nobody wants to be the coordinator of an entire language, I don't think
the language should have one, though I'd hope it would be the case.
Maybe I am wrong, but that's simply how I see things.
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.
And you're telling me I blow things out of proportion?
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
We do have quite active mailing lists for some languages, and yes, with
70+ subscribers (just to stick with that number, I could easily blow it
even more out of proportion), and I doubt communicating via email in
large and active mailing lists is an ideal situation. Again, I don't say
it can't be done this way, neither I say our way is superior, I simply
say that I prefer our way for mere reasons of scalability. That may as
well be a non-issue, but not one I'd like to count on.
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.
In my experience, it's a short email "I will translate abc", "I will
translate bcd", no "Noted" then replies "is anyone translating def"? or
"who is translating bgr", maybe "I have translated xrt", then "sorry,
xrt is finished now", maybe "what is available?", "what can I
translate?", and just scale that out a bit now, and make a good argument
of why I should use email communication to manage who's doing what? You
say this is not based on reality? Sorry, but this is the reality I am
facing. Yes, true, assignment is most of the time non-controversial, and
if you read what I wrote, you'll see that I never said otherwise. Given
everyone knows what everyone else is doing, why translate what someone
else is translating already? But, if I don't know, I don't know, and an
email is easily missed too, especially if you get many. Of course, that
is all blown out of proportion and not based on reality, right? Or is
your reality the only reality and every other "reality" is just made up
and blown out of proportion?
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?
Well, naturally, the most important thing is that the system is stable
and works properly, and not reviewing software patches couldn't ensure
that. Of course, it is most important that the systems works, and be it
only in english. Or would you rather have a swedish system that crashes
regularly, than an english one that works properly? I am not the only
one who would agree that the software working properly is more important
than the translation being perfect, or do you really want to say that
this isn't so in reality?
Now, I don't really believe a mandated review and cooperation policy is
bad for contributions, I merely think that nobody should have to be a
maintainer or coordinator for a language if nobody really wants to. I do
think that review and coorporation is good, I simply don't think anyone
should be made to do it.
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.
Well, maybe you simply got the wrong impression, but I don't know why? :(
I've made it clear where we want to head to, but it seems like you're
still more concerned with what we've done before. But as said, I cannot
change the past. We haven't changed or introduced any new policy, we've
simply added a layer of visibility to how things are. I still fail to
see what was so incredibly bad about this step, and that is a question
you haven't answered yet.
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.
First, how can I know that almost all experienced translators complain?
It was only a handful of people who said anything on this list. If
people don't speak up on this list, what am I supposed to do? Secondly,
what fundamental issue am I not willing 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
First, it was the same handful of people who complained, and given the
number of subscriptions, I can hardly call it massive. Secondly, I still
don't know what stance you are talking about? What exactly is that
stance of mine that is so massively criticised? All I did was adding a
layer of visibility to our current system, and I still think it was an
improvement to how things were. On a side note, the translator group you
are referring to had their very own reasons for leaving. But, since
we're at it, what am I supposed to do? Let's say, you, and you alone,
take on all swedish modules. You do a good job, but now I have 11
translators signed up, of 2 I don't hear anything and the 8 others are
complaining about you? Do you want me to just go, yes, he did all of the
translations so far, and everyone else should just deal with it? What
kind of policy is that? Yes, this is an exaggeration, simply to
illustrate the problem of where to draw the line. Out of the arabic
language group I had more people not in support of that group taking
over maintainership than I had in favour. Tell me, what am I supposed to
do? IMO, it is not up to me to make policy, the individuals of that
language group should just come up with a solution by themselves, I
cannot possibly be the judge, especially not given I don't speak the
[snip] 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.
What exactly are you talking about? Are you sure you didn't simply
misunderstand the situation?
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
Christian, I don't know what to say? I do listen to what the community
is saying, and I do consider everything coming to my eyes or ears, the
only problem I have is that I haven't got unlimited ressources. I don't
know why you'd think otherwise, but as it seems, there is nothing I can
do about it, and that's a shame.
Fedora-trans-list mailing list
Fedora-trans-list redhat com
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
[Date Prev][Date Next] [Thread Prev][Thread Next]