|
|
| (20 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 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 [https://bugs.launchpad.net/nova/+bug/985184 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:
| |
| − | * 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.
| |
| − | | |
| − | '''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:
| |
| − | * https://answers.launchpad.net/keystone/+questions?field.status=Open&field.actions.search=Search
| |
| − | | |
| − | == 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.
| |
