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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
