← Back to team overview

openstack-doc-core team mailing list archive

Re: Review Rigour

 

On 11/17/2016 03:55 AM, Anne Gentle wrote:
> [...]
> I suggest we try it and see what chaos ensues with these guidelines:
> 1. If it's technically accurate, merge it. If it fixes a bug correctly,
> merge it.
> 2. If it's accurate and correct but could be written better, edit, then
> merge it with a comment to coach the person how the writing could be better.
> 3. If it's not the kind of patch we want for the docs, explain that in
> the review and also follow up to make sure the person doesn't feel
> rejected outright. Take ownership of the coaching areas more than the
> "this is wrong and here's why" aspect. (I'm not saying your reviews are
> like that, mind you, I just want ownership of the growth of contributors
> and the accurate doc base, not ownership of "it meets our English
> standards.")
> 
> Do those written guidelines help?

They do - and they change what we expect from a core reviewer.

We have to have this discussion on the mailing list and coach reviewers
in this direction as well - lead by example.

Before electing new core reviewers, let's see whether they follow this
as well - or just +1.

Note that I would put this policy more on new comers. If there's a bug
in one of my changes, feel free to -1 it and I'll fix it myself. But if
you do fix it, it's perfectly fine as well.

Regarding reviews: When I review, I point out the problems - and if it's
only a small number of nits, I'll -1 and WIP the change and say "Let me
fix it for you". That way everybody knows what I plan to change
(coaching) and knows that I'll do that,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
       HRB 21284 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126



References