Masayuki Igawa <masayuki.ig...@gmail.com> wrote on 10/16/2014 03:41:24 PM:
> From: Masayuki Igawa <masayuki.ig...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 10/16/2014 03:44 PM > Subject: Re: [openstack-dev] [QA] Proposal: A launchpad bug > description template > > Hi Markus, > > Thank you for bringing up this. > > On Thu, Oct 16, 2014 at 9:13 PM, Markus Zoeller <mzoel...@de.ibm.com> wrote: > > TL;DR: A proposal for a template for launchpad bug entries which asks > > for the minimal needed data to work on a bug. > > > > > > Hi, > > > > As a new guy in OpenStack I find myself often in the situation that I'm > > not able to work on a bug because I don't understand the problem itself. > > If I don't understand the problem I'm not able to locate the source of > > the issue and to provide an appropriate patch. > > > > As the new guy I don't want to flood the bug entry with questions what > > it should do which might be obvious to other members. And so, wrt > > Igawas comment in the mail thread "[openstack-dev] [qa] Tempest Bug > > triage" (http://openstack.markmail.org/thread/jcwgdcjxylqw2vyk) I'd > > like to propose a template for bug entries in launchpad (see below). > > > > Even if I'm not able to solve a bug due to the lack of knowledge, > > reading the bug description written according to this template could > > help me build up knowledge in this area. > > > > Maybe this or a similar template can be preloaded into the description > > panel of launchpad when creating a bug entry. > > > > What are your thoughts about this? > > > > Regards, > > Markus Zoeller > > IRC: markus_z > > > > > > -------------------------- template start ----------------------------- > > > > Problem description: > > ====================== > > # Summarize the issue in as few words as possible and as much words as > > # necessary. A reader should have the chance to decide if this is in his > > # expertise without reading the following sections. > > > > Steps to reproduce: > > ====================== > > # Explain where you start and under which conditions. > > # List every input you gave and every action you made. > > > > # E.g.: > > # Prereqs: Installed devstack on x86 machine with icehouse release > > # 1) In Horizon, launch an instance with name "test" an flavor "m1.tiny" > > # from image "cirros-0.3.1-x86_64-uec" > > # 2) Launch 2 other instances with different names but with the same > > # flavor and image. > > > > Expected behavior: > > ====================== > > # Describe what you thought what should happen. If applicable provide > > # sources (e.g. wiki pages, manuals or similar) why to expected this. > > # E.g.: > > # Each instance should be launched successfully. > > > > Observed behavior: > > ====================== > > # Describe the observed behavior and how it differs from the expected > > # one. List the error messages you get. Link to debug data. > > # E.g.: > > # The third instance was not launched. It went to an error state. The > > # error message was "host not found". > > > > Reproducibility: > > ====================== > > # How often will the "steps to reproduce" result in the described > > # observed behavior? > > # This could give a hint if the bug is related to race conditions > > # Try to give a good estimate. > > # E.g. "4/5" (read "four times out of five tries") > > # 5/5 > > > > Environment: > > ====================== > > # Which version/branch did you use? > > # Details of the machine? > > > > Additional data: > > ====================== > > # Links to http://paste.openstack.org/ with content of log files. > > # Links to possible related bugs. > > # Things which might be helpful to debug this but doesn't fit into the > > # other sections. > > > > -------------------------- template end ----------------------------- > > +1! > > I think many of bug descriptions don't have enough information for > debugging now. So we should have enough information like this as > possible. > However, one thing I'm concerned about this template is a little heavy > process for submitting an easy bug. We might have some templates for > depending on the situation. > > Thanks, > -- > Masayuki Igawa > I'm not quite sure if it would be good to omit a proper bug description even if the author of the bug considers this an "easy" bug. If it is an easy one it could be tagged with the "low-hanging-fruit" tag and left for a new contributor. Sure, it is easier for the *author* to make a quick description in a bug entry but I assume that this time saving has to be paid in the later steps of the lifecycle of the bug. A bug seems easy to an author because he has already the knowledge to debug this. Another person will not profit from a short description and will not increase his knowledge and help in other (more complicated) bugs. If a section is irrelevant for this bug (e.g. Environment), than a short "N/A" could save time for author and reader. Regards, Markus Zoeller IRC: markus_z _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev