72a20ab455
As discussed in Yoga PTG TC+PTL interaction sessions[1], adding goal checklist to know if goal is ready or not. Also, remove the goal schedule which was needed when goal were coupled with development cycle. [1] https://etherpad.opendev.org/p/tc-ptl-interaction Change-Id: I91c21233673c75f37461094dcf1fbb9ef4ca2e5e
259 lines
12 KiB
ReStructuredText
259 lines
12 KiB
ReStructuredText
.. _release-cycle-goals:
|
|
|
|
======================
|
|
OpenStack-wide Goals
|
|
======================
|
|
|
|
The pages in this part of the governance documentation describe
|
|
OpenStack-wide goals.
|
|
|
|
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.
|
|
|
|
The first step in the process is to build a `backlog of potential goals`_.
|
|
This helps us coalesce feedback received from deployers, users, contributors,
|
|
and PTLs. It is the reference used as a base for goal discussion during
|
|
Forum events. Finally, it serves as inspiration for prospective goal
|
|
champions.
|
|
|
|
.. _`backlog of potential goals`: https://etherpad.openstack.org/p/community-goals
|
|
|
|
Defining Goals
|
|
--------------
|
|
|
|
Goals are defined here in the governance documentation to ensure that
|
|
we establish a common understanding of the expectations being set.
|
|
|
|
Once champions have volunteered to propose and drive a specific goal, they
|
|
should iterate through goal definition in the ``/goals/proposed/`` directory.
|
|
This allows to keep the goal selection process separate from the goal
|
|
definition process. Goal proposals should have the ``goal-proposal`` gerrit
|
|
topic, whose voting rules are specified in the `house rules`_.
|
|
|
|
.. _`house rules`: https://governance.openstack.org/tc/reference/house-rules.html
|
|
|
|
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.
|
|
|
|
This separates the discussion for each goal, and allows authors to gradually
|
|
refine and improve their proposal through multiple incremental changes.
|
|
Goals should be discussed on the mailing list to collect feedback on their
|
|
feasibility, and consensus on whether they have been completely and clearly
|
|
described. Below checklist will help to know if goal is ready to be selected
|
|
or need more pre-work.
|
|
|
|
Goal Checklist
|
|
~~~~~~~~~~~~~~
|
|
|
|
Below checklist provide a high-level view for goal readiness and the same is
|
|
mandatory to fill while proposing the goal.
|
|
|
|
+-------------------+-------------------------------------+------------+
|
|
| Item | Requirements | Catagory |
|
|
+===================+=====================================+============+
|
|
| | | |
|
|
| Design | * Is design finalized? | Mandatory |
|
|
| | | |
|
|
+-------------------+-------------------------------------+------------+
|
|
| | | |
|
|
| Implementation | * Are implementation details | Mandatory |
|
|
| | finalized? | |
|
|
| | | |
|
|
+-------------------+-------------------------------------+------------+
|
|
| | | |
|
|
| Dependency & | * Is there any dependency or blocker| Mandatory |
|
|
| Blocker | in OpenStack or External software?| |
|
|
| | | |
|
|
+-------------------+-------------------------------------+------------+
|
|
| | | |
|
|
| Current state | * Any project completed this goal? | Optional |
|
|
| | | |
|
|
+-------------------+-------------------------------------+------------+
|
|
| | | |
|
|
| Meeting & | * Is there any regular meeting or | Optional |
|
|
| discussion | discussion planned where projects | |
|
|
| | can ask questions and get help? | |
|
|
+-------------------+-------------------------------------+------------+
|
|
|
|
Selecting goals
|
|
---------------
|
|
|
|
The TC will consider proposed goals from the ``/goals/proposed/`` directory
|
|
and select a set of OpenStack-wide goals to allow planning and other
|
|
discussion at the PTG event at the start of each cycle.
|
|
|
|
OpenStack-wide goals are not tied to any release, and they can have target
|
|
dates which can be a particular cycle release date or multi-cycle or even
|
|
in between a release cycle. Goal completion target dates will be selected by
|
|
considering the amount of work needed and the community (project and
|
|
champions) bandwidth. If a goal requires a large amount of work, it can be
|
|
divided into different milestones, with each milestone targetting a set of
|
|
things to complete. For example, if goal 'A' needs two big things to do, it
|
|
can be divided into two milestones, say Milestone 1: Yoga cycle release,
|
|
Milestone 2: Z cycle release.
|
|
|
|
There is no minimum or maximum limit on the number of goals to be selected at
|
|
a time. It can be zero or more depends on the complexity and work required per
|
|
goal. For example, if three groups of contributors would like to start
|
|
three different goals and projects are also ok with that, then it is fine to
|
|
select all three goals at a time and implement those in parallel. Also, it is
|
|
completely fine to have no goal for a particular time with a valid reason,
|
|
for example, if any previous OpenStack-wide goal is still pending and needs
|
|
more time to complete, or project team has less bandwidth and working on
|
|
other priority items like popup team work etc.
|
|
|
|
To select a goal, a TC member can pick one or more goals from the
|
|
``/goals/proposed/`` directory and move them to the ``/goals/selected/``
|
|
directory.
|
|
|
|
This allows to consider the proposed series goals as a group, and take
|
|
into account how feasible they are together, considering the timing and
|
|
amount of work required. Champions for selected goals should +1 this patch to
|
|
confirm they are ready to work on their goal.
|
|
|
|
|
|
Tracking Goal Progress
|
|
----------------------
|
|
|
|
After goals are approved, the goal champions can create one story per
|
|
goal and one task per project per goal or setup an etherpad 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 progress on their tracking item
|
|
(etherpad, story, or blueprint). A status indicating progress is being made
|
|
should include a link to a planning artifact (such as a spec). 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 or etherpad 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 deadline of the goal.
|
|
|
|
If a goal is not completed, that information should be added, along
|
|
with any references needed to track when that work will be completed.
|
|
|
|
Champion or TC member needs to move the completed goal from
|
|
``/goals/selected/`` directory to ``/goals/completed/`` directory.
|
|
|
|
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.
|
|
|
|
Goal Selection Schedule
|
|
=======================
|
|
|
|
During the PTG of every cycle, TC has to make sure some goals are selected
|
|
and in progress. If none are selected, then the TC should investigate possible
|
|
candidates to select as goals. There is no requirement of a minimum or maximum
|
|
number of selected goals; there can be zero or more based on the community and
|
|
champion bandwidth.
|
|
|
|
Community goals
|
|
===============
|
|
|
|
It's not required to define community goals every time. The TC can
|
|
decide to not set any actionable community-wide goal for a specific
|
|
release/time, leaving the projects to focus on whatever is most important
|
|
in their scope.
|
|
|
|
.. toctree::
|
|
:maxdepth: 2
|
|
|
|
selected/index
|
|
proposed/index
|
|
|
|
.. toctree::
|
|
:maxdepth: 3
|
|
|
|
completed/index
|