164 lines
6.7 KiB
ReStructuredText
164 lines
6.7 KiB
ReStructuredText
.. _release-cycle-goals:
|
|
|
|
======================
|
|
OpenStack-wide Goals
|
|
======================
|
|
|
|
The pages in this part of the governance documentation describe
|
|
OpenStack-wide goals for each release series.
|
|
|
|
We use these OpenStack-wide goals to achieve visible common changes,
|
|
push for basic levels of consistency and user experience, and efficiently
|
|
improve certain areas where technical debt payments have become too high
|
|
-- across all OpenStack projects. From a contributor perspective, the goals
|
|
help unify the community's work as a whole, with some shared objectives. We
|
|
know this work is worthwhile, because these goals are how we achieve the
|
|
OpenStack mission together. We will build these goals based on our shared
|
|
values.
|
|
|
|
We know this process is working when:
|
|
|
|
* Users and operators see OpenStack working well as a platform, rather
|
|
than a collection of loosely-related, different projects.
|
|
* We make progress on solving long-standing issues that would
|
|
otherwise have lingered indefinitely at different stages of
|
|
implementation in various projects.
|
|
* All contributors and projects know they are valued members of the
|
|
successful and thriving OpenStack community.
|
|
* We facilitate marketing communication around release time due to
|
|
successful completion of community-wide goals during the cycle.
|
|
|
|
Process Details
|
|
===============
|
|
|
|
Identifying Goals
|
|
-----------------
|
|
|
|
The goal process enables the community of OpenStack projects to
|
|
surface common concerns and work out specific technical strategies for
|
|
addressing these concerns. This community input enables the TC to
|
|
select specific community-wide goals for all projects to achieve
|
|
during a development cycle. We need to consider the timing, cycle
|
|
length, priority, and feasibility of the goals selected.
|
|
|
|
We will brainstorm goals before and at each summit, using feedback
|
|
received from deployers, users, contributors, and PTLs. Those goals
|
|
will be discussed on the mailing list to collect feedback about
|
|
whether each goal is achievable and described completely. The TC will
|
|
use that input to come to consensus and make the final decisions for
|
|
OpenStack-wide goals for each cycle in time to allow planning and
|
|
other discussion at the PTG event at the start of the cycle.
|
|
|
|
Defining Goals
|
|
--------------
|
|
|
|
Goals are defined here in the governance documentation to ensure that
|
|
we establish a common understanding of the expectations being set.
|
|
Goal definitions should use the provided template so they are all
|
|
formatted consistently. The goal definition does not take the place
|
|
of any blueprints, spec documents, or other planning tools used within
|
|
a project to track its work, but can be referenced from those
|
|
documents.
|
|
|
|
To define goals for a release cycle, a TC member should set up the
|
|
series directory in one patch, and then in follow-up patches TC
|
|
members can propose specific goals. This separates the discussion for
|
|
each goal onto its own review.
|
|
|
|
The actual goals shouldn't be completely new proposals (things no one
|
|
else in the community has seen before) because there will have been
|
|
discussion in the course of reaching consensus.
|
|
|
|
Tracking Goal Progress
|
|
----------------------
|
|
|
|
After goals are approved, the goal champions will create one story per
|
|
goal and one task per project per goal to track progress on
|
|
completion.
|
|
|
|
.. note::
|
|
|
|
It is expected that some projects may not always be able to complete a goal
|
|
within the targeted cycle. If this is the case, existing projects are
|
|
encouraged to continue to track their progress once they are able to further
|
|
work on the goals.
|
|
|
|
New projects do not need to retroactively track past goals as part of the
|
|
created stories or in pre-StoryBoard documentation, whether the goals were
|
|
completed before or after becoming an official project.
|
|
|
|
Team Acknowledgment of Goals
|
|
----------------------------
|
|
|
|
Each PTL is responsible for updating the storyboard task used to track the
|
|
goal progress for their project to set the status to "Progress" and to
|
|
include planning artifact links before the first milestone
|
|
deadline. The planning artifact is likely to be a link to a spec or
|
|
bug, and the completion artifact is likely to be a link to one or more
|
|
committed patches.
|
|
|
|
This step is also the indication that a project team is signing up as
|
|
agreeing to the goal and committing to do the work to complete the
|
|
goal, within their project. That commitment may mean doing it
|
|
themselves or may mean simply prioritizing reviews submitted by
|
|
others. Either way, the commitment is to have the goal completed, and
|
|
all teams are expected to commit the necessary resources to ensure
|
|
that it is finished.
|
|
|
|
All project teams are expected to prioritize these goals above other
|
|
work.
|
|
|
|
If the project has already met the goal, skip to the "Completing
|
|
Goals" step.
|
|
|
|
If the goal does not apply to a project, the PTL should explain why
|
|
that is the case, instead of linking to planning artifacts.
|
|
|
|
Completing Goals
|
|
----------------
|
|
|
|
After a goal is completed, each PTL is responsible for updating the
|
|
storyboard task used to track the goal progress for their project to
|
|
set the status to "Merged" and to add links to all completion
|
|
artifacts, before the final release date for the cycle.
|
|
|
|
If a goal is not completed, that information should be added, along
|
|
with any references needed to track when that work will be completed.
|
|
|
|
Goal Champion Responsibilities
|
|
------------------------------
|
|
|
|
The "goal champion" is responsible for guiding teams to implement a
|
|
goal, but is not responsible for doing the work themselves.
|
|
|
|
The champion is typically somewhat familiar with the technical issues
|
|
involved in a goal, at least enough to help teams find the information
|
|
they need. The champion does not need to be an expert with the tools
|
|
or libraries used for the goal, but some experience does help.
|
|
|
|
The champion is responsible for configuring StoryBoard to track
|
|
progress on their goal, and then ensuring that it is kept up to date
|
|
as work progresses.
|
|
|
|
The champion should check in with project teams regularly to ensure
|
|
they are able to make progress on the work and have not become stuck.
|
|
|
|
At the end of the release, there may be open tasks and these can remain open
|
|
in case someone comes along later and completes the task. As goal champion you
|
|
are not responsible for completing any incomplete tasks for which you are not
|
|
assigned, i.e. the project assigned to the task is responsible for completing
|
|
it. It is also encouraged to send a retrospective email to the
|
|
openstack-discuss mailing list with a summary of the goal including things
|
|
such as how many projects completed the goal, reasons behind some projects
|
|
that did not complete the goal, anything notable that came up during the goal
|
|
implementation phase, and next steps if there are any.
|
|
|
|
Release Cycles
|
|
==============
|
|
|
|
.. toctree::
|
|
:glob:
|
|
:maxdepth: 2
|
|
|
|
*/index
|