DrupalCon Portland 2013: PATCH REVIEWS: GET GOOD REVIEWS, GIVE GOOD REVIEWS. FASTER.
There are over 2000 core issues waiting for reviews. We need more reviews faster. A shortage of timely reviews frustrates patch authors, leads to draining rerolls, and causes some would-be contributors to give up on core. Some reviews, like: "looks good", lack specific useful information. When core committers review issues, they sometimes point out missing core gates requirements that could have been addressed before RTBC. This drags out the time to commit.
GOALS:
Get more reviews.
Get faster reviews.
Get more useful reviews.
We will discuss ways accomplish those goals through:
Patch authors asking for reviews in a way that guides potential reviewers into giving just the right kind of feedback, like:
asking for needs architectural review, needs usability review, needs coding standards review, needs manual testing, etc.,
using links to meta issues with review instructions, and
linking to reusable Contributor Task documents.
More efficient reviews with tools like:
dreditor,
drush,
simplytest.me,
html (yes html),
screen capturing.
More informative reviews, where the reviewer:
gives steps to reproduce in a numbered list (or steps that show it is not reproducible),
lists which browsers versions and theme and when to include that information,
references d.o documents when appropriate like sections of the standards, or the core gate requirements,
checks previous comments to identify concerns and state if the patch addresses them and which still need to be addressed, and
points out what is blocking versus non-blocking, and suggests what is to be done in a follow-up.
We won't just provide lists of suggested things to do; we will discuss the motivation and benefits for the suggestions.
We can do these now. But dream: how can changes to Drupal.org embrace some of these concepts?
WHO'S IT FOR?
This conversation is to help developers who want their patches reviewed faster, and for any contributors who want to be more effective and efficient with their reviews. Come share your techniques for patch review, and help us "close the loop" on core's review process.
GOALS:
Get more reviews.
Get faster reviews.
Get more useful reviews.
We will discuss ways accomplish those goals through:
Patch authors asking for reviews in a way that guides potential reviewers into giving just the right kind of feedback, like:
asking for needs architectural review, needs usability review, needs coding standards review, needs manual testing, etc.,
using links to meta issues with review instructions, and
linking to reusable Contributor Task documents.
More efficient reviews with tools like:
dreditor,
drush,
simplytest.me,
html (yes html),
screen capturing.
More informative reviews, where the reviewer:
gives steps to reproduce in a numbered list (or steps that show it is not reproducible),
lists which browsers versions and theme and when to include that information,
references d.o documents when appropriate like sections of the standards, or the core gate requirements,
checks previous comments to identify concerns and state if the patch addresses them and which still need to be addressed, and
points out what is blocking versus non-blocking, and suggests what is to be done in a follow-up.
We won't just provide lists of suggested things to do; we will discuss the motivation and benefits for the suggestions.
We can do these now. But dream: how can changes to Drupal.org embrace some of these concepts?
WHO'S IT FOR?
This conversation is to help developers who want their patches reviewed faster, and for any contributors who want to be more effective and efficient with their reviews. Come share your techniques for patch review, and help us "close the loop" on core's review process.