Governance revisited

[Troy Rollo]

On Monday 25 September 2006 13:16, Dimi Paun wrote:
> On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
> > Everyone who complaints about "problems" with patch acceptance policy
> > seem to claim that, but my impression is that complaints are going
> > from technically incompetent people, who just "feels" that the process
> > can be improved, but can't explain it in developer's language (i.e. in
> > technical words) how.

> One thing to be careful about is the ever growing trend of forming
> a very tightly coupled in-group. It is very easy to happen: most
> top developers work for the same company, they are extremely competent,
> and have the technical argument on their side.

Is it, or is it that the culture attracts "yes" men? Considering the text you 
quoted, who would want to work for CodeWeavers if they do differ in opinion 
(or, quite frankly, even if they don't)? People are more likely to go where 
they will be appreciated.

"We know we're right, because we're all very clever and we all agree".

> It is way too easy to feel righteous.

The text you quoted exhibits far more serious problems than that.

> This is a big problem, as it elevates the (already high) barrier to
> entry to a dangerous altitude. And the feedback is positive, as people
> are being put off, the in-group grows tighter, etc.

Indeed. Consider again the paragraph you quoted. Not only is it ad-hominem, it 
is a classic example of forestalling disagreement. Don't speak up to disagree 
or you'll be labelled incompetent. The accusation is far more likely to be 
more an indication of the maturity of its maker rather than a reflection of 
truth.

If I say I've been coding since I was 14 (in those days home computers had 
less than 1% penetration in Australia), in assembly language since shortly 
after that and raw machine code not long after, having memorised the 
instruction set, then was widely recognised as the most capable Comp Sci 
student at the top university for Computer Science in the state, and that I 
only employ people who are proven geniuses, would it make a difference? While 
true, it's all irrelevant to the argument at hand. The accusation made above 
is also irrelevant.

There is a valid point being made here - the black hole of patch submission 
*is* turning away developers. As one anecdote, one person currently on my 
staff - and note above - tried submitting patches to Wine in a personal 
capacity and would most likely still be submitting patches, but found the 
problems being discussed rendered it not worth his effort. I don't have to 
walk very far to find somebody else with the same opinion of Wine.

The present system turns people off even before you've had time to learn 
whether they are capable or not.

> To my mind, Alexandre is the Roger Federer and Michael Schumacher of
> software development. He is never wrong.

Everybody is wrong sometimes, although I have noticed that when somebody gets 
a sufficiently high reputation people stop noticing when they do get things 
wrong. I say this from the perspective of somebody who is sometimes in the 
situation of being the person with that reputation. As an example I have had 
people say to me "it's easy to speak up when you get everything right", to 
which I have responded that "I do get things wrong, you just don't notice 
when I do."

Actually, some people arguing in support of the status quo have pointed out 
that Alexandre sometimes accepts things he previously rejected after an 
argument being made successfully in favour of a change - in such a case if we 
are calling things black-and-white wrong or right, then either the first 
decision or the revised one must be wrong. A rejection cannot be an 
incontrovertible sign of the wrongness of the contribution.

Of course making an argument in favour of a particular contribution is 
somewhat challenging, if not impossible, when you're not being told why 
Alexandre perceives his solution to be better, which seems to be most of the 
time. Often the difference may be a mere matter of style - Alexandre seems to 
be more comfortable with copy-and-paste coding than I am, for example - but 
if it's more than a matter of style the rejection of the patch should give 
the reason. It saves no time to require people to chase up Alexandre for 
reasons unless by "saving time" you mean the person doesn't bother and so the 
change never gets in.

> This is
> even more difficult when you have to guess Alexandre's ideas about how
> you should properly solve the problem :)

Actually, this is probably 90%+ of the problem. If patch submission weren't a 
black hole in which it either gets through or you have to go begging for 
feedback like an errant schoolboy, you wouldn't see nearly the volume of 
complaints you do.

Worse are the times when you spend considerable time reworking a patch to his 
specifications and he still won't let it in. One of my staff had this 
problem, and the answer from Alexandre was that he wasn't going to let 
*anything* in covering that area no matter how it was implemented until it 
had been proven in the field (effectively forcing a branch). That's pretty 
soul-destroying stuff. That staff member resigned a short time later, and 
while he gave other reasons his frustration with dealing with Alexandre had 
been showing, and his whole job revolved around improving Wine.

> IOW, I think we're missing on an important human aspect of development:
> the need to compete, and show that you can do it better than the other
> guy.

This is something that abates with maturity... at least for people who don't 
get stuck in a One True View Of The World mind-set.

> Bottom line, I don't know. At most I can say that sometimes I wish
> Alexandre would be a bit more impulsive, and just let (a selected few)
> things in that people want.

I don't think this is necessary, at least 
-- 
Troy Rollo - wine at troy.rollo.name