[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: Thu, 08 Jul 2004 12:46:23 +1000
I'll just address some points here.
Christian Rose schrieb:
tis 2004-07-06 klockan 07.03 skrev Bernd Groh:
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.
Ok. You still base your argument though on that it's difficult to be a
coordinator or find someone to be one. That's not my experience at all.
More on that below.
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.
The first thing that struck me was the claim that there will be 70+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
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.
Ok, you count teams different than I do. Given your explanation above,
you count a team as everyone who has ever explained interest in a
particular language and/or subscribed to a mailing list.
I count a team as roughly the group of active translators. By active I
meant those who have actually produced or updated at least one
translation in recent time, ie. not someone only lurking on a mailing
list, and not people that did their last translation update two years
There can, and usually is, a big difference in numbers.
For practical purposes, I consider the way of counting the active
contributors much more useful. Contribution counts. It's difficult to
get a qualified opinion from people that are silently lurking on a
mailing list, or (even worse) perhaps only posting noise to the list but
not actively contributing, be it in translations or reviews.
And then that's still an exceptionally hugeWell, 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.
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.
I'm sure you can count. So can I. The key point is the relevance of
For Swedish Fedora translations, there are two active contributors:
Göran and me. On the translation mailing list we use, there are on the
other hand 55 subscribers. I counted them. Granted, many of them I've
never seen posting to the list, and some are only contributing to other
projects, such as the TP and GNOME/KDE etc.
The people who are actively doing reviews are only a handful, a dozen at
And I know for a fact that this situation is not unique. On the
contrary, it's the common case to have a majority of silent bystanders
and lurkers on a public mailing list, who hardly have any effect
whatsoever on the daily actions and contributions, and often not even
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.
even that there is a benefit for larger teams, because larger teamsNeither I said there is a benefit for larger teams, I simply said there
could be, depending on how the team handles things.
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.
And for some teams it could be that there is no benefit at all, but
rather a drawback, since instead of handling this on their own they must
now have this system imposed on them, and keep having to ask you
whenever it doesn't suit them, and hope that you will both agree to the
change and have the time to do it.
Ok, noted. And since I'd like to avoid this, I'd like to know what these
drawbacks are. Since I believe the page, in general, is helpful. If
there are groups that have an established way of doing things, and the
page really does keep them from doing it how they've been doing a good
job in the past, then let's talk about it. I want to hear all these
cases, in details.
Third, you make it sound like who's in charge of what usually changesHow? By introducing a Maintainer and stating that a maintainer should be
a "permanent" entity?
You made an argument by claiming it was difficult for a dingle
coordinator to keep track of assignment changes, something I don't agree
with is necessarily true, except for the biggest teams.
No, I didn't. I said exactly what you've just said.
In fact, it's usually quite a static thing. When a personThat'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?
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.
Because you used this opportunity not to try to rectify the lack of
teams, but rather try to ensuring the lack of teams could be maintained
for the future, by not changing the policy but rather have the new
translation status pages make the policy even more prominent.
And you're still not prepared to change the policy.
It's not up to me to change any policy, though I'm still not entirely
sure what policy you are referring to. Could you please, and I do
apologise for not having understood it yet, be more explicit. Is it true
that you are referring to me not mandating teams and a coordinator for
each language? Is that the policy you are referring to? It's an honest
Fourth, you claim that all members of the team would fight forNo, 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.
translating a new module, thus making the life of the coordinator
Hypotethical speculations at best.
I could also claim any organization shouldn't have a responsible person,
because there could be a danger of the members of the organization
disagreeing with eachother. How novel.
In organizations, on a voluntary base, responsible people are usually
responsible, because they want to be responsible, or because other
people in the organization have encouraged them to be responsible, and I
do welcome that. I didn't say language groups shouldn't have a
coordinator, or did I? In fact, I said I'd like every language group to
have a coordinator , and maintainers, iff there is someone who wants to
be a coordinator, or a maintainer. So, in how is that statement of yours
even closely related to what I said?
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 getI'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.
volunteers, and every volunteer can usually get all what they want in
terms of getting their hands dirty without stepping on someone else's
The problem is almost always the opposite -- to get volunteers toChristian, 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.
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
You're still basing your argument on that it is difficult to find
coordinators. My experience is that it simply isn't. In my experience
it's sometimes even easier to find a coordinator, than someone willing
to do the actual work of translating modules, because the latter is
often much more work. :-)
Ok, you've said you'd come to that, so I'll keep listening. :-)
But, there are a lot of people who'd prefer more work over more
Or is it the case that coordinators are simply unaware of their
For a one person team, being the coordinator is no extra work at all.
For a small team (2 to 4 people), being a coordinator is basically just
a title. There's not much for the coordinator to do, other than noting
who does what, which usually doesn't change that often.
So, you wouldn't say the coordinator has to coordinate the review
process and make sure all work actually gets reviewed? If coordinator is
nothing but a title, what exactly was it for again?
For a bigger team, the noting of who does what is of course a bigger
challenge, and it grows further with the team size.
But here comes the beauty: When the team size grows, the more likely you
are to find someone who is willing to step up to do the work of
coordinating. Pick any group of ten people, and count the number of
times you'll get a group where not *anyone* would find it acceptable to
be the one who keeps note of who maintains what, and occasionally be the
one who has the final say on things. You're unlikely to get many such
Well, that's great! But again, who is accountable for the quality of the
translations? Surely, everyone is responsible, but who is accountable?
Whom can I blame if the translations aren't good or not done? It sounds
like the coordinator, apart from sometimes having the last say, does
nothing but keeping track of who does what. Well, that part our new
system can do too. Wouldn't it make a great coordinator on its own? Or
is there more to a coordinator than you let on here?
There's also another thing with bigger groups. Having an official
coordinator doesn't rule out the possibilities of delegating some of the
work to others, and the bigger the group is, you're then again more
likely to find people who can do those responsibilities.
Given this and my own experience, I don't agree with it being hard to
find coordinators, and I agree even less with taking this claim to be
the foundation of a policy where you don't even *try* to have a
coordinator by default.
That's fine, we don't all have to agree. And, btw, I don't take anything
for the foundation of any policy, I simply don't have enough reason to
support a change in policy to what you consider the best policy. But, I
do listen to what you're saying, and you may just convince me one day.
You haven't yet though. And, about us not trying to have a coordinator
by default, we've only just started, and our apologies if it'll take a
little longer than you'd like, but our ressources are limited, and
there's nothing I can do about it.
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.
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
You should leave it up to the language team to decide. No solution fits
every language team, as even you have pointed out.
Well, I had some really good feedback so far, so let's just see what
happens. And, btw, I've addressed that very issue before. :)
And the team keeping track of the assignment coordination themselves
without having to bother you or anyone else in charge of the status
pages works *especially* well for smaller teams, so there's no reason it
shouldn't be the default.
Let the teams who want it have the status pages assignment control, and
leave the rest of the teams to coordinate their work in whatever way
fits them best.
I believe that's a fair suggestion, and one I myself made before, on
this very list. And I'm happy to open it up for discussion.
non-controversial, so there is rarely the big discussions you try toIn 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?
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.
No, I base my view on my six years of experience with translation and
translation coordination, both with smaller and bigger teams, and then
the coordination a whole translation project.
If there's something single important thing I've learned then that's
that there is no single organizational structure and assignment policy
that fits every team. Some teams are large, some very small, and some
work for common, big languages spoken by hundreds of millions of people,
while others for smaller, perhaps even minority languages.
The reality you describe is the one for a big team for a big language,
where there are many people involved and loosely organized, and many new
volunteers joining at the same time. This is certainly a truth, but only
one part of the truth.
There are many teams aswell where the situation is almost *completely*
the opposite, and where for example mail communication works just fine.
The assignment control on the new translation status pages probably
works well for such a team you describe, but it probably at the same
time won't work very well for others, where it gets in the way of the
already established and efficient procedure.
Yet you want to squeeze all teams into using this by default.
No. I've even made the suggestion on this very list to put certain teams
on exclude lists, so they don't have to go through the newly implemented
process. I've made that suggestion as soon as I realised that the new
system might actually conflict with the way some smaller teams are
My opinion is that it should be optional, and only used if there's an
explicit request to use it by the team.
Noted. What do others think?
And last but not least, you fail to answer the question why you thinkWell, 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?
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?
This statement that anything that builds and doesn't crash is just fine
is so absurd from a QA point of view I won't even bother to respond. I
trust you have no prior experience with any QA or the real implications
and considerations of such processes, so I'll rest my case.
What statement that anything that builds and doesn't crash is just fine?
Where did I say that? Well, maybe I need to illustrate what I meant.
Let's say you've got a certain package, translated into 32 different
languages. Now, a not reviewed software patch gets in, and it's so bad
that it effects the entire package. As a result, it becomes unusable.
Now, the package itself, and all 32 different translations of the
package become useless. Same thing, for one particular translation.
Let's say a translation for a particular language is all bad. Result?
The package becomes unusable for that particular language, but, the
package still works, does what it's supposed to do, and supports 31
different languages. Tell me, same thing? One just as bad as the other?
Of course, I want to have all 32 languages usable, but if I've got
limited ressources, I wouldn't think twice where to put them. Then
again, it's prolly all because I haven't got any prior experience with
QA, or the real implications and considerations of such processes, right?
Yes, I rest my case too.
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]