Revision as of 18:42, 20 May 2012

New PTL's guide to managing an OpenStack Project

This is intended to be a living document sharing the common conventions and mechanisms used in managing projects within the OpenStack foundation.

In writing this, I'm assuming you're already familiar with contributing to openstack and tools related to making code updates and getting them in place. This is intended to expand into how to use Launchpad and the general processes of managing the projects.

Launchpad

Groups

Each core project has a project on launchpad:

• https://launchpad.net/projectname
• links to Code, Documentation and Community pages
• references to bugs, blueprints, and answers

Each project typically has multiple groups associated with it:

• <projectname>-core (https://launchpad.net/~projectname-core)

 - folks with +2 code approval
 - automatically included in ~devs

• <projectname>-devs (https://launchpad.net/~projectname)
• <projectname>-drivers (https://launchpad.net/~projectname-drivers)

 - can manage blueprints and blueprint settings
 - automatically included in ~bugs

• <projectname>-bugs (https://launchpad.net/~projectname-bugs)

 - can manage and triage bugs

Intended mechanisms for the tools:

Answers

https://answers.launchpad.net/projectname

General questions and a community support area for getting answers to those questions. Anyone can open a question, and anyone can answer a question.

Answers are used someone inconsistently in OpenStack, but would be an initial place for users to ask questions about how something works, or why something is working the way it is. Answers can be linked to an existing bug report, or a bug report can be created (and automatically linked). If the project team has some folks who are subject matter experts, and answer can be "assigned" to an individual with a launchpad account.

Actions

A PTL should plan to review open questions on a frequent basis - at least weekly:

• https://answers.launchpad.net/keystone/+questions?field.status=Open&field.actions.search=Search

Bugs

https://bugs.launchpad.net/projectname

Receiving bug reports and specific, (ideally reproducible) problems from the community. Anyone can open a bug report against a project.

A special case of bug report is a security vulnerability. In general, these bugs are private and only the reporter, the OpenStack security team, and the PTL see these bugs initially. Additional folks can be "subscribed" from any of the people currently able to see the issue.

Bugs can be used to indicate small-sized feature additions or work tasks as well. Since bugs can be tagged (where blueprints can't), bugs can be a useful medium for triaging and working against lists of issues to achieve a specific goal.

Other than security vulnerabilities, the bugs are completely open.

Bugs have the following "status" settings:

• new - just created
• triaged - generally means accepted as a bug.
• incomplete - missing information needed to reproduce the issue
• opinion - a differing opinion on what project should be doing (I don't really

use this)

• invald - no longer considered an active bug
• won't fix - yeah, what it says
• confirmed - a reproduced bug
• in progress - has a code review in play in gerrit to update the code to

resolve this bug

• fix committed - a fix has been commited to the master branch
• fix released - the committed fix has been released in an OpenStack release

Importance is orthogonal to status:

• critical - generally means that the bug needs to be resolved prior to the

next milestone

• high
• medium
• low
• wishlist - nice to have

By default, bugs sort of importance, and then status - so setting the importance higher implies that they're more important to get solved.

Bugs (unlink blueprints) can be tagged with ad-hoc tags as well, and then those tags searched or filtered on. A few common tags:

• low-hanging-fruit - generally meant to indicate 'easy' bugs that could be

solved by someone new to the project, or a good place to get started.

• docs - bugs related to project documentation
• releasename-backport-potential - indicates that bugs might be backported into

the previously released stable branch

• releasename-backport - indicates bug should be backported into previously

released stable branch

• blueprint - means that this bug is possibly a feature request and a blueprint

may or should be created in place of the bug.

Bugs also have a "milestone" associated with them. Bugs associated with a milestone mean that they're intended to be closed in that milestone. Later in a release cycle, a milestone "cut" will be blocked by open bugs associated with that milestone.

Actions

A PTL should plan to review all new bugs on a frequent basis - at least weekly:

• https://bugs.launchpad.net/keystone/+bugs?search=Search&field.status=New

Just prior to a milestone release, a PTL should go through all the bugs and associate any that are "in progress" and likely to be fully committed by the release, or in "fix committed" state to the milestone.

Blueprints

https://blueprints.launchpad.net/projectname

Intended to be feature requests or project efforts. A blueprint may require one or more code commits to complete. Anyone can propose a blueprint. Blueprints have a priority, a "design state", a delivery status, an assignee, and can be associated with a series and/or milestone.

Priority:

• essential - critical to the project, and reviewed in conjunction with

delivery status to get a sense of project progress.

• high
• medium
• low
• undefined
• not

Assignee is the person primarily responsible for implementing, or coordinating the implementation, of the feature described in the blueprint.

Milestone is used to indicate when a code feature is expected or hoped to land in the general release cycle.

A blueprint is also used to propose features, and are typically used as discussion points for future features in OpenStack Design Summits. To propose a feature, an individual should create a blueprint, assign themselves (Assignee) to the blueprint, and then be prepared to discuss or develop how the feature may be created and implemented.

Actions

A PTL should set importance and map to milestones on all blueprints at the beginning of a release cycle to make a map of how they expect the project to progress.

Just prior to a milestone, the PTL should review the blueprints and update delivery progress as well as update milestone settings if a blueprint is going to slip.

Weekly IRC OpenStack Meetings

The release manager will typically review the state of the project against the current milestone in the weekly OpenStack meeting.

For example:

• https://launchpad.net/keystone/+milestone/folsom-1

Actions

A PTL should be on the meeting, or have a delegate that can report on progress, make calls to action, and generally be prepared to answer questions about the project from the general community.