author tags (was: The cash of our lives / Dvorak)

[Greg Stein <gs...@lyra.org>]

On Mon, Jun 09, 2003 at 06:06:54PM -0400, Noel J. Bergman wrote:
> > I don't know whether this was a symptom, a remedy, or a cause. Isn't the
> > fact these tags needed to be removed some telltale? I'm just wondering,
> > since you seem to advocate this as a good community pattern.
> 
> I fully admit that I suggested it after seeing what was going on in Avalon,

In Avalon, it was a remedy (IMO). In general, I believe it is a very good
thing to omit them.

>...
> Many (most?) @author tags, even in the Java distribution, have become
> nothing more than legacy markers.  Some of the people listed as the author
> of a class aren't even employed at Sun anymore.  Even if they are, they
> likely aren't the ones still maintaining or developing that code.  Perhaps
> we don't have access to the internal source control system for Java, but
> everyone can browse the CVS for an ASF project to see who has been doing
> what to any code for which an @author tag would matter.

Right. And people get visibility in CHANGES files, on the web site, or what
have you. But to identify people with a specific file? Hmm...

> Some negative aspects of @author would be the impression that the author
> "owns" the code, and reluctance on the part of others to make changes to
> "someone else's" code.

I've seen this more times than I care to count, over the years. It is an
especially bad thing at the ASF, where even a little of that isn't right.

Consider: the ASF is all about creating a community around a codebase so
that the code can survive the departure of any/all developers. If that is
the case, then why are their names in there? The code should be owned and
maintained indefinitely by the ASF and the community that has been
established as the caretakers of that code.

>From a legal standpoint, it is worrisome if your name is in the code. The
ASF is also built as a legal shield against (malicious) lawsuits. If your
name is in the code, then the plaintiff stands a very reasonable chance of
saying "you're name's in there, so you're at fault." If you leave the name
out, then the ASF has a *very* good chance of saying "so what if the made
the commit? they did it at the direction of the PMC, which is at the
direction of the ASF. thus, the ASF made the change. drop them from the
lawsuit."

> Positive aspects of @author are ... umm ... ?

People maintain that it is so you know who to talk to. I don't buy it. They
get out of date, or they don't include the right people, or the addresses
are wrong, or ...

Look at CVS. That'll tell you. But even better, pose the question on the
community's dev list.

So, yah... I haven't seen any real good reasons for author tags yet. Nor
have I over my years over professional development. And when you're talking
about a codebase that is intended to last for *decades* at the ASF, then I
*really* don't see the purpose of author tags or other types of in-code
credits.

Decades. Think about it... The ASF isn't fooling around here :-)

> Speaking of "good community pattern[s]" ... what are considered good and bad
> patterns?  That would be an interesting discussion, and perhaps something to
> record for incubator.  What problems have people encountered in their ASF
> communities?  What has worked/not worked?  What forms of behavior are
> acceptable/unacceptable?  Can technical debate go too far?  How do you
> resolve differences/conflict?

Within the httpd and APR communities, we studiously avoid author tags.
People have contributed patches, and we reject them until they remove their
name(s) from the patch. Within the dev community, we certainly know who
"knows best" about particular subjects, but there is zero "ownership" or
territorialism in the code.

The Subversion community operates the same. We rejected a number of patches
from a guy that wanted his name in there. After he kept pestering us, we
eventually told him flat out, "no." We haven't seen him since, so in
retrospect, I'm glad. It implies that he was seeking to have his name as
part of the project, more than he wanted to help the project.

Your question goes well beyond author tags, though, and is boundless. I'm
not going there right now.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

Re: author tags

[Steven Noels <st...@outerthought.org>]

On 10/06/2003 1:45 Greg Stein wrote:

> On Mon, Jun 09, 2003 at 06:06:54PM -0400, Noel J. Bergman wrote:
> 
>>>I don't know whether this was a symptom, a remedy, or a cause. Isn't the
>>>fact these tags needed to be removed some telltale? I'm just wondering,
>>>since you seem to advocate this as a good community pattern.
>>
>>I fully admit that I suggested it after seeing what was going on in Avalon,
> 
> 
> In Avalon, it was a remedy (IMO). In general, I believe it is a very good
> thing to omit them.

In the particular case of Avalon, it indeed was an appropriate action.

> I've seen this more times than I care to count, over the years. It is an
> especially bad thing at the ASF, where even a little of that isn't right.
> 
> Consider: the ASF is all about creating a community around a codebase so
> that the code can survive the departure of any/all developers. If that is
> the case, then why are their names in there? The code should be owned and
> maintained indefinitely by the ASF and the community that has been
> established as the caretakers of that code.

[snip]

> Look at CVS. That'll tell you. But even better, pose the question on the
> community's dev list.
> 
> So, yah... I haven't seen any real good reasons for author tags yet. Nor
> have I over my years over professional development. And when you're talking
> about a codebase that is intended to last for *decades* at the ASF, then I
> *really* don't see the purpose of author tags or other types of in-code
> credits.

I currently see a number of patterns wrt. @author tags:

1) as a way to credit non-committer code contributions

I think adding author tags for non-committer contributions builds up 
some sort of 'merit/credit points' system so that there's some 
measurable way of finding out when somebody is elligible for becoming a 
committer, based on track record. People also like it when their patches 
are marked with their authorship, since as a non-committer you are not 
listed on the whoweare pages. So I'd still be +0.5 on retaining such 
author tags. Over at Cocoon, we also typically add author attributes to 
user-submitted documentation, for the same reason. One might say we 
should use the commit message to credit such contributions, but these 
are less obvious to find out IMHO.

2) as an ongoing logbook for tracking who was involved with a particular 
piece of code. Like it or not, but sometimes it is easier to contact the 
dev-list notifying a particular guy his piece of code has gone awry, 
without having to look to CVSWeb or the like. Especially in the case 
where code patches originate from non-committers, who might not track 
the cvs commit messages or be deeply involved in the day-to-day life of 
a project.

Ideally, when someone becomes committer, his past and continued code 
contributions might be considered to be owned by the community-at-large, 
and author tags should be reflecting this. Then again, I believe some 
IDEs insert such tags automatically when someone touches a file.

I know people sometimes have troubles in finding out whether & where 
they should add/change author tags to existing code when they fix, patch 
or enhance. Maybe eradicating them might help.

Maybe the author tag should read "@author The Apache {$projectname} 
Developer Team", and add other tags for non-committer contributions, if any.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org