|
|
(21 intermediate revisions by 9 users not shown) |
Line 1: |
Line 1: |
− | __NOTOC__
| + | This page is now maintained as a guide at: https://docs.openstack.org/project-team-guide/ptl.html |
− | = 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.
| |