openstack-doc-core team mailing list archive

[Alexandra Settle <alexandra.settle@xxxxxxxxxxxxx>]

One case study amongst many, I’m afraid, I have commented on at least one
patch a day for the last two weeks.
Everyone is trying to go by the book, but the book is not all too clear
for new contributors.

Summit session would be a great idea, there is no one answer to this
unfortunately complex problem.

I had an idea, and I want to float it by the core team. We could separate
half the core team into a triaging team, and the rest into reviews/patches
- we definitely have enough cores now. Every time the core team is
reviewed (quarterly), we mix it back up again.
Those that were triaging, move into the review/patch team, and vica versa.
It does mean that your stats will ebb and flow, but we can monitor that
appropriately if we keep track of who on the core team is doing what.

What do we think?



On 30/09/2015 1:42 pm, "Tom Fifield" <tom@xxxxxxxxxxxxx> wrote:

>On 29/09/15 14:44, Lana Brindley wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 29/09/15 16:30, Andreas Jaeger wrote:
>>> On 2015-09-29 07:20, Alexandra Settle wrote:
>>>> Hi everyone,
>>>>
>>>> I�ve been noticing in the last few months (and I�m sure it�s been a
>>>> problem before) that we have contributors submitting bug reports, and
>>>> then immediately fixing before triage,  or there are patches without
>>>> bugs (or blueprints) and it�s becoming quite confusing.
>>>>
>>>> I am finding that this is a problem because some of these bugs are
>>>> personal issues they�re finding with their individual builds, or on
>>>> occasion it is a bug that needs to be fixed and individuals are offer
>> ing
>>>> the wrong solutions and immediately trying to patch it up in the
>>>> documentation.
>>>>
>>>> Personally, I�m unsure how to solve this issue, and wondering if we c
>> an
>>>> get a think tank going on how to solve this.
>>>>
>>>> So far all I�ve been able to do is to remind contributors to wait for
>>   a
>>>> second individual to triage, or the patch is eventually abandoned due
>>   to
>>>> several negative reviews (which, ultimately encourages said contribut
>> or
>>>> not to come back because we look like a very negative community).
>>>>
>>>> We can do more �bug triaging days�, but not everyone is to give the t
>> ime
>>>> to this exercise.
>>>>
>>>> Thoughts? Suggestions? Comments? Questions?
>>>
>>> This is not a simple topic, thanks for raising it!
>>>
>>> Some OpenStack projects encourage this behaviour - if you send a patch
>>> without a bug, they often ask for a bug that you create and assign
>>> directly to you...
>>
>> Normally, this works, and we can trust people to use their best
>> judgement. I certainly don't want to enforce this for everyone, because
>> finding a typo or something trivial really doesn't need this level of
>> process. Recently, though, there's been a flurry of people finding and
>> 'fixing' things that are actually bugs, and I've had a few different
>> core team members point it out to me that we need to try and remind
>> people about triage for things like that.
>>
>>>
>>> Also, we have Documentation like
>>>   http://docs.openstack.org/infra/manual/developers.html#working-on-bug
>> s
>>>   https://wiki.openstack.org/wiki/BugTriage
>>>
>>> Neither asks for an independent review.
>>
>> No, and neither should they, I think. I actually suspect the better way
>> to handle this is for our core team to be ever-vigilant, and make sure
>> we're checking for independent review on patches that require it. Most
>> of the culprits aren't regular committers, anyway, and I don't want to
>> alienate any of our regular group.
>>
>> I suspect this is a people problem, which we shouldn't try and fix
>> through extra processes, but by conversation and education.
>>
>>>
>>> I acknowledge the problems we have and I think this might be a broader
>>> topic to discuss - not on this limited list but perhaps together with
>>> developers on openstack-dev? Or in some cross-project meeting?
>>
>> Let's bring it up at Summit. I've applied for a cross-project session,
>> so if that gets approved, it might be a good place.
>>
>
>
>Case study: https://review.openstack.org/#/c/228186
>
>Someone identifies and sends in a patch that fixes a technical problem,
>some outdated text - a one sentence change. Though the wording could
>perhaps be tweaked, their fix is technically accurate.
>
>Our current response: 6 reviewers marking the patch down because the bug
>wasn't confirmed.
>
>
>
>Regards,
>
>
>Tom
>
>
>
>
>--
>Mailing list: https://launchpad.net/~openstack-doc-core
>Post to     : openstack-doc-core@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack-doc-core
>More help   : https://help.launchpad.net/ListHelp


________________________________
Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Level 1, 37 Pitt Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@xxxxxxxxxxxxx and delete the original message. Your cooperation is appreciated.