About the new Status Pages

[Bernd Groh]

Christian,

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.
>

Ok.

>
>
>[...]
>  
>
>>>>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.
>

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 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.
>

No, I didn't. I said exactly what you've just said.

>>>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.
>

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 
question.

>>>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.
>

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 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. :-)
>

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 
responsibility. ;-)
Or is it the case that coordinators are simply unaware of their 
responsibilities?

>For a one person team, being the coordinator is no extra work at all.
>

Well, agree.

>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
>groups.
>

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.

>>>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.
>

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 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.
>

Well taken.

>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 
handling things.

>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 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.
>

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.

Regards,
Bernd

>Christian
>
>
>
>--
>Fedora-trans-list mailing list
>Fedora-trans-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-trans-list
>  
>


-- 
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
Disclaimer: http://apac.redhat.com/disclaimer/