Problem/Motivation
There are too many issues that are not actionable by the original issue participants or a Core Maintainer.
You can see the gigantic list at - https://drupal.org/project/issues/drupal?status=8 - when this issue was first opened the count was 2388.
It's near impossible to get a timely review for most issues outside of IRC.
It's not unusual for issues that might only need trivial feedback to be waiting in the "Needs review" list for multiple years.
A large number of stagnant CNR issues represents a lot of wasted volunteer effort.
Active, Postponed and "Needs work" patches usually have some known further action that can be taken by the thread participants to progress the issue, whether it's discussion or code. "Needs review" can be hard for a patch to break through as often a commitment is required from a community member who had no prior engagement with the issue.
Proposed Resolution
Adapt a simplified version of the "PAReview Bonus" Program from the Project Application queue to the Core issue queue to promote and focus the patch review process.
You can read all about the PAReview Bonus project at https://drupal.org/node/1975228.
Proposed core review bonus process:
Important: Only choose an issue that you feel you can do a good job reviewing. Don't feel obliged to be pushed way outside your comfort zone.
We want to prioritise reviewing issues that other people have tagged, so start by trying to pick an issue from the Core review bonus list (you can ignore issues you tagged yourself).
If the bonus list is empty (or you can't find anything there you feel comfortable reviewing), pick any issue you like from the normal "needs review" list.
If there are no issues in the normal review list, come back tomorrow!
Are you new to contributing? Don't worry, that's what the "Novice" tag is for!
Novice, Core Review Bonus issues can be found here: https://drupal.org/project/issues/search/drupal?status%5B%5D=8&issue_tag...
Normal Novice issues that need review can be found here: https://drupal.org/project/issues/search/drupal?status%5B%5D=8&issue_tag...
Here's a collection of links to existing docs to help you understand the Core development process.
A review does not have to be long but it should be as thoughtful as possible, within your personal ability.
A good quality review will usually take at least 15 minutes and could take as long as an hour or more if the patch is very large or involves a complex testing process.
Once you've left a comment on an issue, if the issue has made some progress (see below) then you've earned a tag and can remove the "Core Review Bonus" tag from the issue you just reviewed (if it's there).
Other people need to be able to see what is going on, so this is a two-step process. Leave a note on or just under your review comment like this:
🌱
[policy, no patch] Core review bonus
Closed: outdated
for [#12345]
Then go to your issue #12345 and tag it with "Core Review Bonus", with a link back to your review comment at the same time. This way your issue will turn up in the Core Review Bonus issue queue automatically and other people will be able to see why it was tagged.
Because other people participating in the Core Review Bonus are working through tagged issues first, this ensures that the issues you need feedback for are given a little more attention by the community than other issues of the same priority.
"Progress" on an issue could be:
- The issue has moved to a new status (most often back to "Needs Work" with your feedback)
- The issue summary has been updated to match the standard template (linked to above), or the documentation for the patch has been improved.
- Performance profiling has been done
- Manual testing has been performed and steps to reproduce have been provided in the issue summary for others to verify the testing results
Automated reviews are useful (keep doing them until
#1299710: [meta] Automate the coding-standards part of patch review →
lands!), but people appreciate it most when you take the effort to do a manual review alongside a scripted one. A review that is purely automated and no human has read over the patch or tried to understand the problem that the patch solves, while useful, should not be used as part of the Core Review Bonus - See comment #30 in this thread.
Remaining tasks
- Refine this process until people like using it
- Trial using this process at a Core sprint
User interface changes
Adding a new "Core Review Bonus" tag for core issues.
API Changes
None.