Grzegorz Adam Hankiewicz <gradha@titanium.sabren.com> writes:
> On 2004-11-20, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> > Count me in the camp that if a full committer vouches for a
> > translation (or the merits of the translator), then I'm perfectly
> > happy with it's provenance.
>
> Count me against.
>
> [...]
>
> Commit access to the Spanish translation is based on capability of
> speaking Spanish and accepting the project's rules. Commit access
> to the full tree doesn't go through this validation. Unless proven
> otherwise I don't consider any full commiter capable of modifying
> the translation.
>
> Surely this is obvious?
Well, yes, it is obvious. I don't disagree with what you're saying,
but I think there's a misunderstanding here about what "full
committer" means in practice.
When Daniel committed a mildly wrong change to the Spanish
translation, he made a mistake, but it was a minor, normal sort of
mistake. This sort of thing happens all the time, and not just in
translations: full committers also commit code bugs occasionally :-).
They are not expected to be perfect. What *is* expected is that they
will
a) React promptly and constructively to properly-delivered
criticisms
b) Learn from their mistakes, so as not to repeat them.
*These* are the traits that qualify people for full commit access.
Technical expertise is secondary, although of course it is still
relevant. There is a wide range of technical expertise among the full
committers; the main thing is that they are expected to be good judges
of their own limitations.
So what went wrong here?
When Daniel made the bogus change, you should have followed up to it
(publically) politely pointing out the problems, and inviting Daniel
to correct them. Daniel could then learn, and use his judgement about
whether or not to continue helping with the Spanish book translation.
Obviously, if Daniel didn't show any sign of learning, and continued
to make objectionable commits, then we'd have to try something new:
perhaps a new rule saying full committers can't automatically commit
to the translations, or perhaps breaking out book translations into
their own repository (perhaps even separating out the entire book).
But it is *highly* unlikely that we would have to resort to a new
rule. Daniel responds well to any friendly, constructive criticism.
The minor, one-time inconvenience to the other Spanish translators
would be compensated by gaining a new helper, if Daniel decided that
he could adjust to the translation's guidelines and continue
contributing.
So we don't need more talk about formal permissions and rules here.
The fact is, existing mechanisms were perfectly adequete to handle
this kind of bogus commit, just as they handle any other kind of bogus
commit.
Grzegorz, you didn't do anything wrong. The problem is that we said
"Please bring your translation into our tree!" without giving you any
guidance about what to do when someone makes a bogus commit. I'm
trying to make up for that now...
When an objectionable commit occurs, spend the five (or fifteen, or
whatever) minutes it takes to criticize & correct it, publically, so
that person can learn what they did wrong. They may realize that
they're not as able to contribute as they thought, and go away; or
they may get better and continue contributing. They or you may revert
the commit, or fix it. All of these are acceptable outcomes! There
is no crisis when someone makes a bad commit; this is why we have
version control :-).
Clearly, this method wouldn't work if you were getting several bogus
commits a day. But in practice, that's not going to happen. Very few
full committers know Spanish. Among those who do, you can rely on
them all to respond well to criticism, and to either improve or stop
committing. The additional time expenditure on your part is minimal,
but the potential benefit is high.
Now, there may be other reasons why the book should be broken out into
its own repository, as some people have mentioned. Those should be
discussed in a separate thread. All I'm saying here is that this
incident with Daniel is not one of those reasons -- it can be dealt
with in the usual way, and everything will work out fine.
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 22 18:45:59 2004