Open Stack

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.
 
> 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)