Difference between revisions of "PTL Guide"
(Fix and complete content, point to reference documents) |
|||
Line 3: | Line 3: | ||
This is intended to be a living document sharing the common conventions and | This is intended to be a living document sharing the common conventions and | ||
− | mechanisms used in managing projects within the | + | mechanisms used in managing core projects within the OpenStack foundation. |
− | + | This document assumes 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 | This is intended to expand into how to use Launchpad and the general processes | ||
of managing the projects. | of managing the projects. | ||
Line 18: | Line 18: | ||
* links to Code, Documentation and Community pages | * links to Code, Documentation and Community pages | ||
* references to bugs, blueprints, and answers | * references to bugs, blueprints, and answers | ||
+ | * shows series, milestones, and links to corresponding release deliverables | ||
− | Each project typically has multiple groups associated with it: | + | Each project typically has multiple groups associated with it (the same person : |
* <projectname>-core (https://launchpad.net/~projectname-core) | * <projectname>-core (https://launchpad.net/~projectname-core) | ||
− | - folks | + | - folks responsible for code reviews (have +2 code approval) |
− | |||
− | |||
* <projectname>-drivers (https://launchpad.net/~projectname-drivers) | * <projectname>-drivers (https://launchpad.net/~projectname-drivers) | ||
− | - can manage blueprints and blueprint settings | + | - folks responsible for maintaining the roadmap and objectives |
− | - | + | - can manage milestones, blueprints and blueprint settings |
+ | - includes the PTL and anybody the PTL delegate this authority to | ||
* <projectname>-bugs (https://launchpad.net/~projectname-bugs) | * <projectname>-bugs (https://launchpad.net/~projectname-bugs) | ||
− | - can | + | - can set importance and specific statuses to bugs |
+ | - -core and -drivers teams are generally part of it | ||
− | + | There is also a generic ~projectname team (https://launchpad.net/~projectname) but it's not really used for anything. | |
− | |||
− | |||
− | |||
− | https:// | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Bugs === | === Bugs === | ||
Line 57: | Line 39: | ||
Receiving bug reports and specific, (ideally reproducible) problems from the | Receiving bug reports and specific, (ideally reproducible) problems from the | ||
community. Anyone can open a bug report against a project. | community. Anyone can open a bug report against a project. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
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. | 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. | ||
− | + | A single bug in Launchpad can have multiple '''bug tasks''', which can be project tasks or series tasks. '''Project tasks''' are used to track tasks necessary to fix the bug across several projects (so you can have a single bug affecting multiple OpenStack projects). '''Series tasks''' are also used to track backport work: you can nominate the bug for a given past series to track the completion of the backport of a bug to a stable/* branch. See [https://bugs.launchpad.net/nova/+bug/985184 here] for an example. | |
− | Bugs | + | Bugs are generally completely open. A special case of bug report is a security vulnerability. In general, these bugs |
− | + | are submitted as ''embargoed security'' bugs and only the reporter and the OpenStack [[VulnerabilityManagement]] team see | |
− | + | these bugs initially. Access is controlled through bug "subscription". The PTL of the affected project is quickly added to the access list, and additional folks can be subscribed from any of the people currently able to see the issue. As soon as possible, embargoed security issues are unembargoed and accessible by everyone. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | '''Please learn the meaning of the different fields in a bug (status, importance...) at: [[Bugs]]''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
By default, bugs sort of importance, and then status - so setting the | By default, bugs sort of importance, and then status - so setting the | ||
importance higher implies that they're more important to get solved. | importance higher implies that they're more important to get solved. | ||
− | Bugs ( | + | Bugs (unlike blueprints) can be tagged with ad-hoc '''tags''' as well, and then those |
− | tags searched or filtered on. | + | tags searched or filtered on. You can see official tags at: [[BugTags]]. |
− | + | Another important field is the '''milestone''' associated with the bug. Bugs associated with a | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
milestone mean that they're intended to be closed in that milestone. Later in 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 | release cycle, a milestone "cut" will be blocked by open bugs associated with | ||
Line 131: | Line 79: | ||
be associated with a series and/or milestone. | be associated with a series and/or milestone. | ||
− | + | '''Please learn the meaning of the different fields in a blueprint at: [[Blueprints]]''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | the | ||
− | |||
− | |||
− | |||
A blueprint is also used to propose features, and are typically used as discussion | A blueprint is also used to propose features, and are typically used as discussion | ||
− | points for future features in | + | points for future features in OpenStack Design Summits. To propose a feature, an |
individual should create a blueprint, assign themselves (Assignee) to the | individual should create a blueprint, assign themselves (Assignee) to the | ||
blueprint, and then be prepared to discuss or develop how the feature may be | blueprint, and then be prepared to discuss or develop how the feature may be | ||
Line 161: | Line 96: | ||
delivery progress as well as update milestone settings if a blueprint is going | delivery progress as well as update milestone settings if a blueprint is going | ||
to slip. | to slip. | ||
+ | |||
+ | === 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 somewhat 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 | ||
== Weekly IRC [[OpenStack]] Meetings == | == Weekly IRC [[OpenStack]] Meetings == | ||
The release manager will typically review the state of the project against | The release manager will typically review the state of the project against | ||
− | the current milestone in the weekly | + | the current milestone in the weekly OpenStack meeting. |
For example: | For example: |
Revision as of 14:39, 15 June 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 core projects within the OpenStack foundation.
This document assumes 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
- shows series, milestones, and links to corresponding release deliverables
Each project typically has multiple groups associated with it (the same person :
- <projectname>-core (https://launchpad.net/~projectname-core)
- folks responsible for code reviews (have +2 code approval)
- <projectname>-drivers (https://launchpad.net/~projectname-drivers)
- folks responsible for maintaining the roadmap and objectives - can manage milestones, blueprints and blueprint settings - includes the PTL and anybody the PTL delegate this authority to
- <projectname>-bugs (https://launchpad.net/~projectname-bugs)
- can set importance and specific statuses to bugs - -core and -drivers teams are generally part of it
There is also a generic ~projectname team (https://launchpad.net/~projectname) but it's not really used for anything.
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.
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.
A single bug in Launchpad can have multiple bug tasks, which can be project tasks or series tasks. Project tasks are used to track tasks necessary to fix the bug across several projects (so you can have a single bug affecting multiple OpenStack projects). Series tasks are also used to track backport work: you can nominate the bug for a given past series to track the completion of the backport of a bug to a stable/* branch. See here for an example.
Bugs are generally completely open. A special case of bug report is a security vulnerability. In general, these bugs are submitted as embargoed security bugs and only the reporter and the OpenStack VulnerabilityManagement team see these bugs initially. Access is controlled through bug "subscription". The PTL of the affected project is quickly added to the access list, and additional folks can be subscribed from any of the people currently able to see the issue. As soon as possible, embargoed security issues are unembargoed and accessible by everyone.
Please learn the meaning of the different fields in a bug (status, importance...) at: Bugs
By default, bugs sort of importance, and then status - so setting the importance higher implies that they're more important to get solved.
Bugs (unlike blueprints) can be tagged with ad-hoc tags as well, and then those tags searched or filtered on. You can see official tags at: BugTags.
Another important field is the milestone associated with the bug. 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:
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.
Please learn the meaning of the different fields in a blueprint at: Blueprints
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.
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 somewhat 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:
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:
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.