[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: About the new Status Pages



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]