Open Stack

Markus,

If you van connect me with someone who can tell me what needs the most
attention and how to get started, I'd be happy to help.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Fri, Apr 1, 2016 at 3:46 AM, Markus Zoeller <mzoeller at de.ibm.com> wrote:

> TL;DR: * The Nova bugs team needs more members
>        * Tasks: https://wiki.openstack.org/wiki/BugTriage
>        * Cleanup: http://45.55.105.55:8082/bugs-dashboard.html
>        * 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.
>
>
> Tasks
> -----
> 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.
>
>
> Organization
> ------------
> * 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.
>
>
> Education
> ---------
> 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.
>
>
> References
> ----------
> [1] "working on bug reports; what blocks you?":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089677.html
> [2] "No spec approvals for new things until after the summit":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html
> [3] https://wiki.openstack.org/wiki/BugTriage
> [4] http://45.55.105.55:8082/bugs-dashboard.html
> [5]
> https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
> [6] "Wishlist bugs == (trivial) blueprint?":
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html
> [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)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160401/efe3ae41/attachment.html>