Open Stack

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.

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). Some of the material there is still a fit for
the Infra Manual insofar as we do intend to start maintaining a
defect and task tracker for the OpenStack community in the near
future, so information on how to use Launchpad is probably an
acceptable placeholder until that's ready (however much of it should
likely just link to Launchpad's own documentation for now).

Cultural content about the lifecycle of bugs, standard practices for
triage, et cetera are likely better suited to the newly created
Project Team Guide; and then there's another class of content in
your proposed addition, content which is primarily of interest to
people reporting bugs for the first time. The Developer Guide
audience doesn't, I think, have a lot of overlap with
users/deployers who need guidance on what sort of information to put
in a bug report. Unfortunately, I don't have any great suggestions
for another community-maintained document which aligns well with
that target audience either.

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.

-- 
Jeremy Stanley