Re: Complaint of the Slovak coordinator

[Marcel Telka <marcel telka sk>]

On Mon, May 17, 2010 at 09:54:16PM +0100, Laco Gubík wrote:
> On 13 May 2010 11:05, Marcel Telka <marcel telka sk> wrote:
> > After the Peter's proposal I started to discuss his ideas and we found
> > that these proposals fits to several categories:
> > - just do it. You do not need to be the coordinator to have these done
> >  (for example, to write some wiki articles)
> Just do it, but if coordinator argues with you in thread long several
> emails and does not see reason why your article should be added to the
> wiki, because this information already exists on Internet in English,
> you kind of lose interest and motivation to do anything like this.
> It is beyond my comprehension why coordinator would be so against
> other people trying something different and why he needs to be so
> dismotivational.

I think you are talking about this thread:
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00573.html

There are 6 emails total in the thread (3 from Peter, 3 from me).

1st mail from Peter is something like announce that he created a web
page with steps how to compile a gnome module from git. Peter requested
for comments and stated that when the comments are resolved we can
somehow incorporate this info into our team wiki page.

2nd mail is from me. I replied that there are at least two wiki pages
where the topic is somehow covered. I suggested to improve those two
wiki pages (at live.gnome.org) instead of creating new page.

3rd mail from Peter: He stated that people would prefer step-by-step
instructions in Slovak. He stated he is not willing to update those two
wiki pages. Finally, he stated if majority (of the team, I assume) will
state the manual for module compilation is not needed, he will leave the
manual at his private wiki page and he will not incorporate his page to
our team wiki page.

4th mail from me. I replied that it is true that the Jhbuild wiki page
is not in Slovak. I also stated that the Jhbuild *is* step by step. I
said that I understand that everybody might need something different.

5th email from Peter. He admitted the Jhbuild is step by step, but he
also stated that most of people does not want to build whole gnome to
get just one module.

6th email from me. I stated the Jhbuild page contains steps for building
just one module. I repeated that I understand that everybody might need
something different.

Here the thread ended.

Here are all of the emails:
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00573.html
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00579.html
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00580.html
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00584.html
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00586.html
http://mail.gnome.org/archives/gnome-sk-list/2010-February/msg00589.html

> 
> > - no change. After the detail explanation we found that the real change
> >  would be none or insignificant.
> Change would be significant - checked modules committed in some
> specified time, trust to the team, new members welcomed, if this is
> nothing for Marcel...

Peter proposed several different things, not only changes in translation
commits, etc.  You paired it wrongly here.

> 
> > - unclear change with potentially more overhead. For example the change
> >  with module assignments.
> Clear enough for me and some other guys who have reviewed and were
> happy with this proposal. Peter has shown repeatedly in the past that
> he has lot of time, more than anybody else in team including Marcel.
> Therefore i do not see this as issue, plus i do not think this would
> be so much of overhead.

This cannot be decided without knowing details (written in Slovak). For
example I do not understand here how the free time of the coordinator is
related to module assignment. I could write more words about this topic,
but I think it would be waste of time (but if really needed for those
outside our team, just ask, I'll provide details).

> 
> > - change with potential impact on quality. For example time limits for
> >  reviewers to do their job.
> Yeap quality might sligltly decrease, but instead of current 98-99%,
> I'm quite sure that it will not get worse than 95%. But we will cover
> much more, and any error might always be fixed afterwards.

IIRC I had comments for about 20 % of messages when a po file arrived
from reviewer to be commited. This is just one example.

> > The above is true. During that period (for long time till beginning of
> > 2009) the tam had 3 regular members with occasional help from some other
> > people. They often just sent a translation (sometimes bypassing the
> > team) and never returned back for the module translation maintenance or
> > updates. In that time the quality and quantity suffered. The quality
> > suffered because most of the translations and updates were not reviewed
> > by someone else.
> Here I would like to ask question why only 3 people were in team, were

Because there were no volunteers. Most of the people just translated in
launchpad, ignoring GNOME upstream, I think.

> > Yes. That's true. Because most of the team members are new to the team
> > we need to carefully reviewer their translations before commit to make
> > sure the translations are correct and consistent. Most of these
> > translations comes from members who joined the team about Christmas
> > 2009. 4 active members joined the team between November 2009 and
> > Februrary 2010. There are also some other inactive members joined during
> > that period, but I do not count them. So this generated somehow bigger
> > load of new translations in our queue.
> Like I have mentioned above, not all new members were inexperienced.
> On top of that, about 50% of modules committed in past year were
> translated by Marcel and 25% by Pavol Simo (older "member"), so only 6
> or 7 modules in past year were committed, which were translated by
> somebody else including new members. This does not give too much
> chance to new members, does it?

This is not about chances. This is about amount of work. If you update
an already translated module where just few messages are changed/added
it is much easier to review and commit it.

> > Because of this situation: a lot of new translations with not enough
> > quality after the review we have the bottleneck where many translations
> > are waiting for my review. To be honest, this is understandable. When
> > you have about 6 active translations with 4 reviewers the rate of new
> > translations income for my final review is really huge.
> Lot of team members have repeatedly asked Marcel to provide
> dictionary, and some of them even started discussing different
> possible implementations, but Marcel showed little interest and only
> said that he is busy right now but wants to do it in future.
> It is hard to do translation when you are not sure which of the
> correct possible translations you should use.

This is exactly the reason why I started the rules.

> I personally, from what I have seen, do not think that all these
> translations were so bad. There is difference between bad translation
> and not a perfect translation and also other people might use slightly
> different  style or synonyms, which does not make their translation
> necessarily bad.

> > These one time translators are big problem for quality. You cannot
> > achieve quality with random translators.
> Nothing prevents you to accept this and check it, or offer it to
> somebody else to check it. In worst case you can still add it into
> Vertimus and not commit it, somebody would eventualy pick it up and
> finish it.

There are plenty of such translations in Vertimus. I receive
translations off Vertimus really seldom.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   marcel telka sk  |
|                homepage: http://telka.sk/ |
|                jabber:   marcel jabber sk |
+-------------------------------------------+