openstack-doc-core team mailing list archive
-
openstack-doc-core team
-
Mailing list archive
-
Message #00496
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