There have been various discussions about assigning credit to contributors who help with a patch. This is done currently in CVS comments, but with limited visibility/searchability. In part the issue reflects limitations of CVS vs. some other versioning systems.

You can do an advanced issue search for e.g. 'closed' issues that have attachments, but there's no guarantee they were applied, or that the attachment authors' work was used.

A simple solution might be to add an interface to the project module. A rough idea:

When an issue is set to a given status (on drupal.org, 'fixed'), a set of checkboxes (maybe checked by default) appears for either (a) everyone who has commented on the issue, or, probably better, (b) everyone who has uploaded a patch. Maybe this appears only for users with CVS access rights, or maybe with 'assign credit' permission. Check who gets credit and submit. Then these data are visible on each project's page (a 'contributors' tab?) and on user pages.

Comments

dries’s picture

People can still read up on the issue history?

nedjo’s picture

Well, yes, just like they can read through CVS commit messages. But neither of these is an easy way of answering the questions (a) Who has contributed code to this project, or (b) What are the contributions of user x?

Right now on drupal.org we have a "Projects" section on user pages, generated by cvs.module, that displays project commit totals. This is a somewhat useful proxy indicator for these two questions, but of course it directly reflects just the task of applying patches, not the work of writing them. And, likely, it will be even less useful than it was before now that we have tightened CVS write access, and many fewer users are committing their patches directly to projects they don't maintain.

Assigning credit directly would enable us to give a direct account of who is contributing to what.

dww’s picture

+1 for the rough idea. i think i prefer having another symbol you can put in front of strings in the cvs message that link to users and can be tracked (there was an issue or development thread about this somewhere, can't find it right now). maybe even both (if you use "#nid" and "@user" in the same commit message, that counts as having the checkbox checked for that user on that issue). keep in mind, some (many?) issues end up having multiple commits, sometimes with patches from different people. closed issues are reopened and further fixed, etc. if the point is to track the changes in the code, what better place than the commit messages? then it's also visible in even more places (cvs log from cmd line, viewcvs, etc, in addition to profile/project pages and other drupal stuff.

nedjo’s picture

See this issue http://drupal.org/node/52285 for the idea of linking to users in CVS commit messages. The comment there from killes was "I think enforcing conventions on cvs committers is a bad idea."

sun’s picture

Why don't we create a action page for project maintainers which lists (fixed AND 'uncredited') issues. A project maintainer is able to choose one or more users for each issue, which will in turn receive (shared) credits for contributing. The userlist for each issue should only contain involved users of a specific issue.

I mean, if a project maintainer doesn't know who has done the work for an issue, I don't know who really does.

Another idea would be to let involved users vote for who should receive the credits.

sun’s picture

The more I think about this the more I tend to the voting way. Participating users should vote on issue comments (digg style) to measure the impact of each user on the resolution of an issue.
This way brain work can just as well be taken into account like development work and no human is left alone with the hard question of who should receive credits.

drumm’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)

#2340363: Add issue comment attribution and various followup issues added this concept to Drupal.org. I think our system of credit is unique to Drupal, and don't recommend pulling our custom code into the project* modules.