[OpenStack-docs] Review guidelines compromise

Nick Chase nchase at mirantis.com
Thu Feb 26 15:34:27 UTC 2015


Today in the meeting we discussed the issue of how to handle issues with 
"nitpicks" to contributions.  We acknowledged the following concerns:

1)  We don't want to frustrate new (or old) contributors
2)  We want to encourage contributions
3)  We want to keep the docs "clean"
4)  We want to prevent a flood of additional bugs

To do that, we agreed on the following:

If you see something simple you can patch yourself, feel free to do 
that.  BEFORE doing that, leave a comment with some variation on the 
text here:  https://etherpad.openstack.org/p/docs-fixed-it-for-you

What we discussed, but didn't quite agree (because we didn't have time 
to discuss it properly) was what to do for changes that are too complex 
(or time consuming) for the reviewer to patch themselves.

In this situation, we need to balance contributor frustration and 
efficient use of their time with a desire to prevent the introduction of 
more new bugs than necessary.  To do that, I would propose that a 
reviewer should leave a comment explaining what needs to be fixed 
(something like this: 
https://etherpad.openstack.org/p/docs-please-fix-this), and offer the 
contributor the option to either fix it or file a new bug and paste the 
URL for that bug into a comment.

Now, before you have an allergic reaction to "file a new bug", please 
hear me out. :)

The purpose of this process is to make sure contributors know how to do 
this properly, and to keep things clean.  By doing it this way, the 
contributor will know how to do it correctly next time, and in most 
cases, filing a new bug will be more of a hassle than just fixing it 
(which is what we want).  Also, by offering them the option, we are 
using psychology to make them more willing to participate and do the 
right thing. :)

Undoubtedly there will be some reduced number of cases where the 
contributor chooses to just file a new bug.  We can use these for docs 
mentoring, and as "low-hanging-fruit", they will not remain unassigned 
for long.

OK, hopefully this is a good compromise, yes?

---  Nick





More information about the OpenStack-docs mailing list