At the risk of adding fuel to an unproductive discussion, I thought I'd throw in my comments:

Legal:

   * IANAL, however, it strikes me that there is at least some small
     legal exposure in the @author tags.  As a "contributor" of sorts,
     but not an official committer, there are certain documents that
     I/my company need not sign with respect to my "contributions" to
     ASF.  The @author tag, unfortunately, adds some ambiguity back
     into the equation, insofar as I *could* appear to be a significant
     contributor even though the same level of paperwork may not be
     associatiated with my "contributions."
   * Based on what I've read, it would appear that certain unnamed
     three letter companies are creating allegations based on the most
     superficial of analyses of code.  May this be ASFs way of
     protecting the "innocent" from spurious supeonas?  I'll grant that
     it is a very narrow margin of defense, nothing more, although one
     that apparently would defeat said unnamed three letter companies.

Social:

* Some people contribute merely by monitoring the mailing list and
perhaps testing, sending in a wire log that helps to find a bug. Do we want to recognize those people as well?
* Some "contributions" have been in the form of one-line "patches"
that are not in unidiff format, and do not have an associated
Bugzilla entry. Do we recognize them?
* Since the @author tag is certainly at the moment somewhat
arbitrary in its actual recognition, its continued use may
currently discourage contribution to the extent that people feel
like the community is short-changing their contribution.


Having noted some of the "social" issues, I do have to say that this mailing list has been very friendly and welcoming, and my compliments to everyone for keeping it that way.

While not an entirely accurate measure, I have an urge to suggest a mathematical and statistical recognition metric, combining:

   * # of emails written to developer list
   * # of patches submitted
   * # of responses to bugzilla issues, wherein said person is not the
     reporter of the particular issue.
   * # of bugzilla issues reported, wherein reporting does not result
     in an INVALID categorization
   * negative points for each INVALID Bugzilla report (people wasting
     time and energy on behalf of the group)
   * Other contributions?

My gut instinct is that some of these contributions should be weighted more than others, but seeing as this is a quagmire, I'm not sure I'd want to suggest what that weighting would be - at least not yet. The resulting number could be used to generate a ranking, and possibly a weighting of each contributor.

With each release, the tally should be accumulated for some time period prior to that release (6 months?), and those people should be recognized in the release notes, and perhaps also on the web site.

Such a metric would at least be an improvement over what we have now. It would at least recognize people who do "nothing more" than track down bugs. It would also give us some visibility into the size and involvement of the HttpClient community.

Darts welcome!

-Eric.

Michael Becke wrote:

The ASF has recently recommended that we discontinue use of @author tags. When first starting out I always enjoyed seeing my name in "lights", though I do agree with the ASF's opinion on this matter. If we come to a consensus to remove @authors I suggest that we remove them from all existing code, as well as leave them out of new additions. Any comments?

Mike


Begin forwarded message: ASF Board Summary for February 18, 2004


<snip>

- author tags are officially discouraged. these create difficulties in
establishing the proper ownership and the protection of our
committers. there are other social issues dealing with collaborative
development, but the Board is concerned about the legal ramifications
around the use of author tags


- it is quite acceptable and encouraged to recognize developers' efforts
in a CHANGES file, or some other descriptive file which is associated
with the overall PMC or release rather than individual files.

<snip>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to