Updated: Comment #14
Problem/Motivation
The current commit messages generated by Dreditor credit anyone who has uploaded a new version of a patch, even if they have just done an easy reroll. By contrast, reviewers are almost never credited, even if they have provided significant feedback across multiple reviews, because doing so requires special care on behalf of a committer to manually adjust the commit message by hand to include more people. This seems unfair. It also means reviewers don't share the responsibility for the patch when just looking at the commit log.
We want to be able to recognize more contributions than committed someone else's work, or touched a patch in an issue that eventually got committed somewhere.
Comments are sometimes more than one kind of thing, both a review of a previous thing, and a proposal for something different, and a patch.
We do not want to make more work for people. We do not want someone to feel like they should go through lots of comments on lots of issues an categorize them, or +1 it.
We do not want to introduce a change to the issue queue that makes the issue queues more combative (less collaborative).
Proposed resolution
General proposal:
Categorize comment as a review (and/or some other type of non-code contribution), so data about more contribution types can exist.
(This might later be able to be parsed for specific credit in auto-generated commit messages.)
Method of categorization proposal:
- owner manual categorization.
automatic. (Alternative to manual type categorization: automatically guess what type of contribution a comment had based on stats about the comment: if there was a status change, how long the comment was, what types of files were attached to the comment.)crowd sourced (non-comment owners could categorize other user's comments)
types
(what to have in the select list
- Research (how something is done currently in Drupal and why it's broken; how other projects accomplish something.)
- Proposal (new idea, specific architectural direction, etc.)
- Solution (a patch, code snippet or file that constitutes the solution or part of the solution to the problem in the issue summary)
- Review (feedback on another's work that pushes the issue forward in some way)
- Issue management (helping to set tags/priorities, updating issue summaries, etc. e.g. (mentors) prepping for a sprint)
Examples:
Maybe link to specific comments in other issues.
| Description | Type |
|---|---|
| Updating title, changing priority, adding tags | Issue management |
| Reading comments, identifying remaining tasks, updating the issue summary | Issue management |
| Attaching and embedding image showing a bug | Issue management |
| Attaching and embedding image showing before and after screenshots | Issue management |
| Commenting to evaluate after screenshots | Review |
| Commenting to evaluate a change (expressed via words, or mock up, or patch) to the UI | Review |
| Attaching and embedding image file of a UI mockup | Proposal |
| Patch which adds an image file | Patch |
| Comment with some code snip-its suggesting a way to do something | Proposal |
| Comment with some code snip-its pointing out a problem with a previous patch and making a suggestion of a better way | Review, Proposal |
| ? | ? |
| ? | ? |
Implementation ideas
- Multiple select,
- Default to something sane,
- goes to a value guessed based on status change/state
- takes into account the type of file uploaded
- like a default a user picks and is stored in their profile.
Remaining tasks
Discuss. Agree.
User interface changes
TBD
API changes
TBD