|
|
| (22 intermediate revisions by 10 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.
| |
| − | | |
| − | 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.
| |
