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+
>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
translators.
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
ago.
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 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.
I'm sure you can count. So can I. The key point is the relevance of
those numbers.
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
best.
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
the discussions.
>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
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 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.
>Third, you make it sound like who's in charge of what usually
changes
>every day.
How? 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.
> 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?
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.
>Fourth, you claim that all members of the team would fight for
>translating a new module, thus making the life of the coordinator
>difficult.
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.
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.
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
>toes
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
>at all.
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.
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. :-)
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.
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
groups.
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.
> 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.
You should leave it up to the language team to decide. No solution fits
every language team, as even you have pointed out.
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.
>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?
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.
My opinion is that it should be optional, and only used if there's an
explicit request to use it by the team.
>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?
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.
Christian