[OpenStack-docs] How to alienate contributors and tick off people

Andreas Jaeger aj at suse.com
Mon Feb 23 18:52:50 UTC 2015


On 02/23/2015 05:23 PM, Anne Gentle wrote:
> 
> 
> On Mon, Feb 23, 2015 at 10:18 AM, Nick Chase <nchase at mirantis.com
> <mailto:nchase at mirantis.com>> wrote:
> 
> 
>     Summarizing people's comments in one message, but if nothing else
>     please skip to the bottom (it's important):
> 
>         Though I do understand push back to fix larger standards
>         transgressions, for example some while ago I had a larger
>         section I submitted with lots of examples where the spacing the
>         the <screen> sections were all wrong so pointing out the error
>         in the first one and saying "please check and fix the others"
>         was completely appropriate.
> 
> 
>     For something like that, I completely agree; I mean, that's not what
>     I consider a "minor cosmetic issue".
> 
>         I tend to agree with Andreas that merging the change and oepning
>         another bug for style/syntax is likely to accumulate debt,
>         unless we get an influx of pre-summit people looking for cheap
>         commits to get ATC badges.
> 
> 
>     I don't see this as a problem.  As I said, we NEED a pool of these
>     for first time contributors.  If nothing else, these are the things
>     that are reeeeeally easy for someone to knock off in an afternoon if
>     they get out of control.  (If necessary to move things forward, I
>     will volunteer.)
> 
>         For my part I tend to scan bugs when I have time (infrequently)
>         for things that I have technical experience in actually doing,
>         grammar isn't going to catch my interest.
> 
> 
>     No, but there are lots of writers who don't have the technical
>     experience in a lot of what we do, but grammar they can handle.
> 
>         But we have to tell a contributor about our conventions to have high
>         quality standards - and I agree that we should do this in a nice
>         way.
> 
>     Agreed.  But we can do that with (as Diane suggested) a non-voting
>     comment, which can ask them to open a second bug if they can't get
>     to it to fix it.  And even if they don't, if this is something
>     that's truly a problem (rather than an irritation) somebody will
>     open another bug.
> 
>         Which patch is triggering that that has so important information
>         in it
>         that it needs to go out half way?
> 
> 
>     This didn't come from a specific patch, but more of a general
>     experience.  (This was more of a "That's it, I've got to say
>     something," kind of thing. :))
> 
>     I'm not looking to completely dismantle the way we ensure quality,
>     and I don't think that this will do that.  I'm simply looking to
>     create a friendlier environment for contributors as we attempt to
>     broaden our base.
> 
>     PLEASE READ THIS:  The reality is that I have had multiple people
>     tell me that they either dread submitting patches, or have stopped
>     contributing altogether because it's such an unpleasant experience.
>     We need to take this seriously and see what we can do to solve the
>     problem.
> 
>     If we find that making a policy like this causes more harm than
>     good, we can always change it back later.
> 
> 
> Thanks for bringing it up. We do have guidelines
> here: https://wiki.openstack.org/wiki/Documentation/ReviewGuidelines so
> feel free to enhance those to help solve the problem.

Before we do this, I suggest that we experiment a bit with the workflow.
Nick, could you show us a few examples how this would work, please?

> All our reviews are a judgement call and I'd like us all (core,
> regulars, everyone) to be mindful and show good judgement.

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




More information about the OpenStack-docs mailing list