Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Message-ID: <3DC8B76B.6020700@apache.org>
Date: Wed, 06 Nov 2002 07:32:11 +0100
From: Nicola Ken Barozzi <nicolaken@apache.org>
Reply-To: nicolaken@apache.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: Code ownership (was Re: whoweare.html)
References: <20021106030601.F13CD1083C@pantheon.red-bean.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


B. W. Fitzpatrick wrote:
> Nicola Ken Barozzi <nicolaken@apache.org> writes:
> 
>>I tend to ask all developers to add their name to the authors with any 
>>commit they make that has impacted on the code (ie not cosmetics), and 
>>this levels the credit system. You never know from the authors if a 
>>certain one has made 1000 lines of code or only one.
> 
> 
> IMO, if you want a list of everyone who has worked on a codebase, 

I'm talking about a lost of everyone who has worked on a file.

> make
> a top-level file like COMMITTERS and let people put their names in
> there.  ChangeLogs, if kept, are shipped with the code, and you can
> always run "cvs annotate" on the repository.  See
> http://svn.collab.net/repos/svn/trunk/COMMITTERS for an example of
> this.
>  
> 
>>I find code ownership a problem that can and must be prevented and 
>>resolved in the community. A trick that seasoned committers do on new 
>>committers is to change their first commits and work on them, to show 
>>that the code is of everyone. If they complain, it's time for a nice and 
>>bold explanation.
>> From my experience on this, it's not something one forgets easily ;-)
> 
> 
> Are you serious? 

Honest. Probably I should explain it a bit better though...

> Quite frankly, I find that behavior reprehensible--It
> reeks of strange fraternity initiation rites.

Naaaaa ;-P

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

Let me explain: usually new committers never commit "a piece of good 
solid code", that is 100% perfect... oh well, nobody usually ever does 
anyway, but they especially tend to make errors.

Anyway, it's *always* possible to make a piece of code better, even if 
it doesn't have errors.

Don't take this as "I change your stuff just to show you my scent", but 
as "I'm giving you a hand to make that code better still".

" work on them " was meant as a positive action, to co-work on the code.

Most times, as I have seen, new committers find it strange that someone 
is *working* on the code they committed, and I'm not talking about just 
treading on it, but *helping*.

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

Never seen it suffer, and I see it as *positive* reinforcement.

This is my expericene of course, both as a first-time committer and as a 
"seasoned" developer, if you pass me the auto-definition ;-)

>>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, as I said later on, it really doesn't happen really.

Territoriality is *human* and happens whatever you do and don't include 
in the files.

It's the people that make the community, not lack of credit.

Author tags are mostly about giving  and visibility.
Heck, we have it in the Apache license, "do what the heck you want but 
give us credit and don't sue us".

Giving credit is important. It has nothing to do with ownership, and 
that's the big fat license on the top of the file, not a @author line 
that nobody knows how much code it represents.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------