[openstack-dev] [nova] the bugs team needs (more) members

Markus Zoeller mzoeller at de.ibm.com
Fri Apr 1 10:46:39 UTC 2016

TL;DR: * The Nova bugs team needs more members
       * Tasks: https://wiki.openstack.org/wiki/BugTriage
       * Cleanup:
       * Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
       * Etherpad: https://etherpad.openstack.org/p/nova-bugs-team

The Nova project has a large backlog of open bug reports. Around 5 new
bug reports get created everyday. It is not possible to make a 
reasonable progress with the current number of people. The nova bugs
team needs to play a more active role and it needs more people for that.

What's in for you?
As bugs are in every software in every place, you will get around a lot.
Having a specific issue makes it also easier to ping other folks to
discuss this issue. Bug fixes also don't have the hard deadlines 
imposed on feature patches. Being once on the bug triage side will
improve the quality of your future bug reports which will make them
more likely to get solved.

Current Status
The main issue which slows down all following steps are bug reports
without the essential informations [1]:
    * versions (nova, hypervisor, database, ...) 
    * steps-to-reproduce (with actual data)
    * expected behavior 
    * actual observed behavior
    * logs (in debug mode)
    * topology (for example: nova-network vs. neutron)
Although this gets asked for when creating a bug report, the vast
majority of bug reports lack this information. Usually it takes one
to three roundtrips to get this information from the reporter. This
is time consuming. As we focus less on new features in Newton [2] I 
have the hope that the bug list will get more attention.

The tasks are listed in the wiki [3]. They "just" need to be done.
Repeatedly. Some on a daily basis, some less frequently. The cleanup
dashboard [4] is a tool I use personally but can be used by you too.

The Neutron folks introduced a weekly rotating bug skimming duty and
they've made good experiences with it. This involves 1-3 people who
check new bugs reports if they are valid and provide the essential
information. We should adapt that [5].

In general we should aim for:
* respond to new bugs in a timely manner to get high quality reports
* clean up the "old stuff" (>= 1.5 years)
* spread the effort to multiple shoulders
* rotate the different efforts to prevent exhaustion and tunnel vision

There is an ongoing effort to move the RFEs (request for feature 
enhancements) away from the bug list [6] to allow us to be more
focused on faulty behavior of existing features people already rely on.

* The nova bugs team has an IRC meeting [7] which allows us to sync
  with each other.
* The cleanup dashboard [4] shows bug reports which need a check
  based on the tasks [3].
* The etherpad [8] can be used to avoid an overlap of efforts of
  different people.

It's possible to use the nova bugs team IRC meeting for education 
sessions if this helps you.
I will also attend the summit in Austin in a few weeks. We can do an
unofficial "bugs mgmt process" crash course there if you like. Just
talk to me there (or beforehand in IRC) and we will find the time 
and space.
At last I can offer a Google Hangout session if some are interested
in that.

How to Join?
* Join the nova-bugs Launchpad group [9]
* Familiarize with the process [10]
* Attend the bugs meeting [7]

With a few people who are willing to spent a few hours per week we
can create a well maintained bug list where issues get addressed
in a timely manner to consistently improve the quality of Nova.

[1] "working on bug reports; what blocks you?": 
[2] "No spec approvals for new things until after the summit": 
[3] https://wiki.openstack.org/wiki/BugTriage
[6] "Wishlist bugs == (trivial) blueprint?": 
[7] https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
[8] https://etherpad.openstack.org/p/nova-bugs-team
[9] https://launchpad.net/~nova-bugs
[10] http://markuszoeller.github.io/posts/2015/12/01/openstack-bugs/

Regards, Markus Zoeller (markus_z) 

More information about the OpenStack-dev mailing list