[openstack-dev] [all][bugs] Developers Guide: Who's mergingthat?
John Garbutt
john at johngarbutt.com
Fri Nov 6 14:14:32 UTC 2015
On 6 November 2015 at 13:38, Markus Zoeller <mzoeller at de.ibm.com> wrote:
> Jeremy Stanley <fungi at yuggoth.org> wrote on 11/05/2015 07:11:37 PM:
>
>> From: Jeremy Stanley <fungi at yuggoth.org>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: 11/05/2015 07:17 PM
>> Subject: Re: [openstack-dev] [all][bugs] Developers Guide: Who's merging
> that?
>>
>> On 2015-11-05 16:23:56 +0100 (+0100), Markus Zoeller wrote:
>> > some months ago I wrote down all the things a developer should know
>> > about the bug handling process in general [1]. It is written as a
>> > project agnostic thing and got some +1s but it isn't merged yet.
>> > It would be helpful when I could use it to give this as a pointer
>> > to new contributors as I'm under the impression that the mental image
>> > differs a lot among the contributors. So, my questions are:
>> >
>> > 1) Who's in charge of merging such non-project-specific things?
>> [...]
>>
>> This is a big part of the problem your addition is facing, in my
>> opinion. The OpenStack Infrastructure Manual is an attempt at a
>> technical manual for interfacing with the systems written and
>> maintained by the OpenStack Project Infrastructure team. It has,
>> unfortunately, also grown some sections which contain cultural
>> background and related recommendations because until recently there
>> was no better venue for those topics, but we're going to be ripping
>> those out and proposing them to documents maintained by more
>> appropriate teams at the earliest opportunity.
>
> I've written this for the Nova docs originally but got sent to the
> infra-manual as the "project agnostic thing".
>
>> Bug management falls into a grey area currently, where a lot of the
>> information contributors need is cultural background mixed with
>> workflow information on using Launchpad (which is not really managed
>> by the Infra team). [...]
>
> True, that's what I try to contribute here. I'm aware of the intended
> change in our issue tracker and tried to write the text so it needs
> only a few changes when this transition is done.
>
>> Cultural content about the lifecycle of bugs, standard practices for
>> triage, et cetera are likely better suited to the newly created
>> Project Team Guide;[...]
>
> The Project Team Guide was news to me, I'm going to have a look if
> it would fit.
+1 for trying to see how this fits into the Project Team Guide.
Possibly somewhere in here, add about having an open bug tracker?
http://docs.openstack.org/project-team-guide/open-development.html#specifications
You can see the summit discussions on the project team guide here:
https://etherpad.openstack.org/p/mitaka-crossproject-doc-the-way
Thanks,
johnthetubaguy
>> So anyway, to my main point, topics in collaboratively-maintained
>> documentation are going to end up being closely tied to the
>> expertise of the review team for the document being targeted. In the
>> case of the Infra Manual that's the systems administrators who
>> configure and maintain our community infrastructure. I won't speak
>> for others on the team, but I don't personally feel comfortable
>> deciding what details a user should include in a bug report for
>> python-novaclient, or how the Cinder team should triage their bug
>> reports.
>>
>> I expect that the lack of core reviews are due to:
>>
>> 1. Few of the core reviewers feel they can accurately judge much of
>> the content you've proposed in that change.
>>
>> 2. Nobody feels empowered to tell you that this large and
>> well-written piece of documentation you've spent a lot of time
>> putting together is a poor fit and should be split up and much of it
>> put somewhere else more suitable (especially without a suggestion as
>> to where that might be).
>>
>> 3. The core review team for this is the core review team for all our
>> infrastructure systems, and we're all unfortunately very behind in
>> handling the current review volume.
>
> Maybe the time has come for me to think about starting a blog...
> Thanks Stanley, for your time and feedback.
>
> Regards, Markus Zoeller (markus_z)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list