Author Tags (was: JUnit test for...)

[Dain Sundstrom <da...@coredevelopers.net>]

On Monday, August 11, 2003, at 06:04 PM, Ed Letifov wrote:

> Also,  for  the  future, should the @author tags be specified? I don't
> mind  an  impersonal  collective  ownership  at all, but I can imagine
> someone  bugging  you  someday,  since  you  will  be the one actually
> performing commit.

I used to be strongly for @author tags, but Greg Stein convinced me 
otherwise.  Author tags are not really definitive,  if you really want 
to know who did something to a file you need to check the CVS log.  
Also, I think author tags are a way that code gets 'assigned' to 
someone, and I would like to avoid the problem of code ownership that I 
have seen in other open source project I have worked on.  Although, I 
think the Apache system is designed to reduce the impact of such 
problems, I think not having author tags will help.

Just my 2 cents,

-dain

(Hopefully Greg will post his feelings on this.) 
  

Re: Author Tags

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

Author tags in source code is a bad idea.  As many  have pointed out 
you can determine responsibility from cvs and give credit on a web 
page.  To me, its important that the entire community feels that they 
have ownership (responsibility and credit) for all the code. That's 
what open source is all about, after all.  Author tags serve no other 
purpose, IMO, than to give a developer bragging rights to some portion 
of the project.  A credits page would be a much more effective 
instrument for giving credit.

On Tuesday, August 12, 2003, at 02:17  AM, Jason Dillon wrote:

>> Code responsibility means that even though anyone may leap in and 
>> hack on
>> a piece, the long term future of a piece of code is the 
>> responsibility of
>> known people. Effectively code-ownership [bad] is implementation while
>> code responsibility [good] is design. Author tags signify code
>> responsibility.
>

Re: Author Tags

[Jason Dillon <ja...@coredevelopers.net>]

> Code responsibility means that even though anyone may leap in and hack 
> on
> a piece, the long term future of a piece of code is the responsibility 
> of
> known people. Effectively code-ownership [bad] is implementation while
> code responsibility [good] is design. Author tags signify code
> responsibility.

I agree.  Anyone who assumes ownership of such code simply needs a 
little reminder of how things work.

--jason

Re: Author Tags

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

On Tuesday, August 12, 2003, at 02:20  AM, Bruce Snyder wrote:
>
>
> This is already provided via the mavenized site temporarily available
> here:
>
>     http://www.apache.org/~jstrachan/geronimo/team-list.html
>
>

Why is my e-mail address richardmf? What does the "mf" part stand for? 
No, don't tell me ... I think I know.  Can someone change this to "mh"? 
  or just change the whole thing user id to "rmh". Thanks.

Re: Author Tags

[Bruce Snyder <fe...@frii.com>]

This one time, at band camp, Alex Blewitt said:

AB>> changelog files are a much better indication of whom to liase with than
AB>> historic @Author tags, particularly as the project matures and the 
AB>> people
AB>> change.
AB>>
AB>> James provides a page of credits where people can be publicly named and
AB>> thanked which I believe is also more appropriate than @Author tags.
AB>
AB>I think this is an excellent approach. Most people want to see their 
AB>name 'in print', and use @author tags to do it, but then the issues of 
AB>code ownership raise their ugly heads.

This is already provided via the mavenized site temporarily available
here:

    http://www.apache.org/~jstrachan/geronimo/team-list.html

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

Re: Author Tags

[Alex Blewitt <Al...@ioshq.com>]

> changelog files are a much better indication of whom to liase with than
> historic @Author tags, particularly as the project matures and the 
> people
> change.
>
> James provides a page of credits where people can be publicly named and
> thanked which I believe is also more appropriate than @Author tags.

I think this is an excellent approach. Most people want to see their 
name 'in print', and use @author tags to do it, but then the issues of 
code ownership raise their ugly heads.

Having a separate credits page will solve that issue, and then any 
code-responsibility questions can be directed to those in the 
changelogs.

> We have
> also discussed the use of CVS keyword replacement "$id$" (is that 
> right?) in
> the @Author tag to at least identify the last comitter to work on a 
> file.
> The jury is out on the merit of that one, as it is carried into the 
> released
> javadocs, which may be problematic as the comitter may not be the 
> actual
> author of the changes.

I think that with a project where there are many developers and only a 
few commiters, having the commiter's ID doesn't really add much, but 
may be useful for checking why particular patches went through.

> I would expect that any external (non-contributor) requests for help 
> would
> be better directed to the appropriate list and not the @Author, and 
> likewise
> I would also expect any responsible contributor to review the change 
> log and
> relevant commit logs for the code they are interested in if they want 
> to
> discuss issues with a specific previous author. Otherwise the normal 
> means
> of communication (dev- lists) can be used as normal.

Agree completely.

Alex.

RE: Author Tags

[Danny Angus <da...@apache.org>]

Henri wrote:

> Code responsibility means that even though anyone may leap in and hack on
> a piece, the long term future of a piece of code is the responsibility of
> known people. Effectively code-ownership [bad] is implementation while
> code responsibility [good] is design. Author tags signify code
> responsibility.

The James project recently removed @Author tags from all of our code, and
the world didn't end.

In a new project with many new contributors contributing large amounts of
code I would expect that the value of avoiding any notion of ownership and
the rise of fiefdoms would far outweigh the benefit of attribution *in the
code*. Particularly so if the codebase is expanding to such an extent that
only small teams with special interest are actually directly involved with
certain encapsulated (isolated?) packages.

In dynamic projects such as these (Apache) it is my opinion that status and
changelog files are a much better indication of whom to liase with than
historic @Author tags, particularly as the project matures and the people
change.

James provides a page of credits where people can be publicly named and
thanked which I believe is also more appropriate than @Author tags. We have
also discussed the use of CVS keyword replacement "$id$" (is that right?) in
the @Author tag to at least identify the last comitter to work on a file.
The jury is out on the merit of that one, as it is carried into the released
javadocs, which may be problematic as the comitter may not be the actual
author of the changes.

I would expect that any external (non-contributor) requests for help would
be better directed to the appropriate list and not the @Author, and likewise
I would also expect any responsible contributor to review the change log and
relevant commit logs for the code they are interested in if they want to
discuss issues with a specific previous author. Otherwise the normal means
of communication (dev- lists) can be used as normal.

d.

Re: Author Tags

[Henri Yandell <ba...@generationjava.com>]

On Mon, 11 Aug 2003, Greg Stein wrote:

> Exactly. And even for the case where the change/commit came from somebody
> else, that will (should) be noted in the log message. You can always find
> out who wrote any particular change.

CVS change/commit logs don't go into the javadoc, which is often the major
way in which a user looks at the code.

> > Also, I think author tags are a way that code gets 'assigned' to
> > someone, and I would like to avoid the problem of code ownership that I
> > have seen in other open source project I have worked on.  Although, I
> > think the Apache system is designed to reduce the impact of such
> > problems, I think not having author tags will help.

Code ownership is bad. But only in terms of the old corporate concept that
only Mr X can change a piece of code. Code responsibility is important
however. I've found that when you throw away code ownership, you often end
up with no one caring.

Code responsibility means that even though anyone may leap in and hack on
a piece, the long term future of a piece of code is the responsibility of
known people. Effectively code-ownership [bad] is implementation while
code responsibility [good] is design. Author tags signify code
responsibility.

Hen

Re: Author Tags

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

On Mon, Aug 11, 2003 at 06:43:11PM -0500, Dain Sundstrom wrote:
>...
> I used to be strongly for @author tags, but Greg Stein convinced me 
> otherwise.  Author tags are not really definitive,  if you really want 
> to know who did something to a file you need to check the CVS log.

Exactly. And even for the case where the change/commit came from somebody
else, that will (should) be noted in the log message. You can always find
out who wrote any particular change.

> Also, I think author tags are a way that code gets 'assigned' to 
> someone, and I would like to avoid the problem of code ownership that I 
> have seen in other open source project I have worked on.  Although, I 
> think the Apache system is designed to reduce the impact of such 
> problems, I think not having author tags will help.

Agreed on both parts. While the Apache "system" as you call it (or "the
Apache Way" in other parts) disables fiefdoms ("you can't change that!
that's my code/responsibility!"), there can always be underlying notions of
"ownership". Eliminating author tags is yet another tool to avoid those
disruptive notions. Sure... if somebody is really gung ho on "owning" code,
then any tool you use isn't going to help. But the hope is that people like
that won't become committers in the first place. Further, every tool that
you use to get rid of the ownership concept is a bonus, and is very
necessary to establishing the most important part: a robust and healthy
community devoid of fractures and islands.

In June, I wrote a pretty long email about the topic:

    http://marc.theaimsgroup.com/?l=apache-community&m=105712356510449&w=2

And last year, I wrote some to the avalon-dev list (which spawned the thread
above):

    http://marc.theaimsgroup.com/?l=avalon-dev&m=103822961201266&w=2
    http://marc.theaimsgroup.com/?l=avalon-dev&m=103827529520851&w=2

    (also check out the rest of the avalon-dev thread)

Serge Knystautas defined a good policy for handling the recognition of
contributors:

    http://marc.theaimsgroup.com/?l=james-dev&m=103898649308900&w=2

> (Hopefully Greg will post his feelings on this.) 

Done :-)

Cheers,
-g

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