incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Code ownership (was Re: whoweare.html)
Date Wed, 06 Nov 2002 14:56:17 GMT

B. W. Fitzpatrick wrote:
> David Shane Holden <> writes:
>>B. W. Fitzpatrick wrote:
>>>Are you serious? Quite frankly, I find that behavior reprehensible--It
>>>reeks of strange fraternity initiation rites.
>>>If I write, test, and commit a piece of good solid code and someone
>>>else goes pissing in it just to leave their scent and to show me that
>>>I don't 'own' the code, I am *not* going to be amused by it.
>>>Ownership of code shouldn't be taught by this kind of negative
>>>reinforcement, and I would suggest that the quality of the code
>>>suffers as a result.
>>So you're saying it's ok for you to brag to everybody that you wrote the 
>>'good' code, that sounds pretty lame.  
> I'm not looking for bragging rights or an ego stroke--my initial
> understanding of Ken's post was that people were changing code just
> for the sake of changing it.  Ken noted that he was talking mostly
> about stylistic changes.

Errr, sorry, I wasn't clear probably, don't remember talking about style 
in particular.

I hope I explained better on the mail sent Wed, 06 Nov 2002 07:32:11 
+0100 (

> It turns out that we're talking about the fundamental differences of
> having a low barrier to commit access as opposed to high barrier to
> commit access.  When you only give commit access to people who have
> shown that they grok the project guidelines and the code style, you
> find that you *rarely* have to tweak someone else's commit. 

My "use case" is a bit different.

The committer committed new files/code.
The committer didn't commit bad stuff.
The committer followed the guidelines.

But the committer still hasn't *felt* what it's like to see the code he 
has written, that usually developers feel as theirs initially, worked on 
by other developers. First commits on one's code can really feel strange.

By starting to work *actively* on that part of code, making it better, 
it's just a way of making him understand how it's supposed to work, and 
that he should not feel bad about it.

If someone makes changes, and not only style stuff, it's because we are 
all part of the same project, all giving a hand, all trying to make the 
best stuff.

> The other part of the discussion here is the manner by which new
> committers are 'taught' code ownership and project styles. Ken noted
> that by fixing someone else's off-style commit, you teach them how to
> live in the project.  Justin pointed out the merits of telling the
> committer what they did wrong and letting them fix it.  Neither way is
> necessarily wrong--people just have different preferences.  I for one
> strongly prefer a high bar to become a committer and the "tell them
> and let them fix it" attitude.

Actually, what happened to me is that I had a quite high barrier before 
entering, it took me *years* of help, discussions and patches.

But being inside has been a *totally* different thing, and I /still/ had 
to get accustomed to it.
I've seen this happen lots of times; once one becomes a committer he 
still has to learn a lot.

I'm not saying that either way is good or bad, both have their place and 
it's up to the sensibility of the committers, just that it's a 
possibility that works. Heck, it has worked for me!

>>How would you show someone that the code they _donated_ isn't
>>theirs, its the communities?
> It's noted in the copyright license at the top of every file.  How
> much more explicit can you be?

Telling people something, or writing it will _not_ make them understand 
anything, at least not deeply.

Only real interaction and things that happened actually teach.

If it weren't so, we wouldn't need teachers, nor the incubator project 

>>>>One thing that *could* be a problem is that @author tags can give the 
>>>>impression that a cretain piece of code is "maintained" by the authors, 
>>>>or that they are responsible for it, and this can reduce peer review.
>>>Yes.  Also, I think that placing author credit in every file
>>>encourages territoriality and individualism while discouraging people
>>>from thinking and acting as a team.
>>But showing people that the 'good' code you wrote isnt?
>>Sounds somewhat hypocritical...
> This is not the point.  See above. 

I lost you both on this one...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message