About the new Status Pages

[Christian Rose]

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