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.
