openstack/project-team-guide
Code Issues Proposed changes

Update Design Summit -> Forum + PTG

Browse Source 
Update language around Design Summit, and mention Forum and PTGs
instead. This also affects timelines which were based on Summit - n
weeks and which were therefore removed.

Change-Id: Ieb6990c993d0eec78a17464374f84c1eb0606d12
This commit is contained in:
Thierry Carrez 2017-05-30 15:30:56 +02:00
parent 1623412a8f
commit 271d35ae74
6 changed files with 124 additions and 186 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
doc/source/glossary.rst
View File

@ -6,9 +6,16 @@
Design Summit Design Summit
Design Summits are periodic, in-person, meetings for the entire The 'Design Summit' is the previous name for the developer-oriented event
OpenStack community used to finalize plans for a development that used to happen concurrently with the OpenStack Summit. Design
cycle. See :ref:`design-summit` for details. Summits have been split into two separtate events: the :ref:`forum` at the
OpenStack Summit, and the :ref:`ptg`.
Forum
The 'Forum' is one of the pillars of the OpenStack Summit event. It is
where the community gets together to discuss the future of OpenStack.
See :ref:`forum` for details.
IRC IRC
@ -18,11 +25,18 @@
https://wiki.openstack.org/wiki/IRC for tips for setting up a https://wiki.openstack.org/wiki/IRC for tips for setting up a
client. client.
Mid-cycle sprints/meetups Mid-cycle sprints
Midcycle sprints or meetups are optional in-person gatherings Midcycle sprints or meetups are optional in-person gatherings
focused around a project team or a specific initiative within the focused around a project team or a specific initiative within the
community. See :ref:`midcycles` for details. community. See :ref:`sprints` for details.
Project Teams Gathering ('PTG')
The 'Project Teams Gathering' is an event for upstream project team
members to get together to bootstrap a new development cycle and
organize the work for the remainder of the cycle. See :ref:`ptg`
for details.
PTL PTL
@ -34,4 +48,4 @@
The OpenStack Technical Committee is responsible for governance The OpenStack Technical Committee is responsible for governance
of the technical contributors to the project. See of the technical contributors to the project. See
http://governance.openstack.org for more details. https://governance.openstack.org/tc/ for more details.

38
doc/source/open-community.rst
View File

@ -132,7 +132,8 @@ a default ambassador of the project team in communications with other teams.
The PTL is expected to have sufficient time available to dedicate to running The PTL is expected to have sufficient time available to dedicate to running
the project. Responsibilities of the PTL include the following tasks: the project. Responsibilities of the PTL include the following tasks:
* Organizing the content of the project team track in our Design Summits * Organizing the team participation to events like the Forum or Project Teams
Gatherings
* Interacting with the release team in the #openstack-release IRC channel * Interacting with the release team in the #openstack-release IRC channel
* By default participating in the weekly `Cross Project meeting`_ and watching * By default participating in the weekly `Cross Project meeting`_ and watching
the `cross project repository`_, unless a `Cross Project Specification the `cross project repository`_, unless a `Cross Project Specification
@ -179,37 +180,10 @@ wiki page on `tie breaking`_.
Election Schedule Election Schedule
----------------- -----------------
The election schedule is based on the release cycle and summit dates, The `Technical Committee charter
so the following timeline is expressed as the number of weeks leading <https://governance.openstack.org/tc/reference/charter.html>`__
up to the summit. defines the rules for the election schedule. Dates are generally based on the
release cycle (for PTL elections) and summit dates (for the TC elections).
Summit -6
~~~~~~~~~
Nominations open for PTL elections for the next cycle begin the week
before the election.
Summit -5
~~~~~~~~~
PTL elections for the next cycle are held 5 weeks before the design
summit. Refer to `the TC charter
<http://governance.openstack.org/reference/charter.html#election-for-ptl-seats>`__
for more details about PTL elections.
Summit -4
~~~~~~~~~
Nominations for the Technical Committee election begin the week before
the election.
Summit -3
~~~~~~~~~
The Technical Committee election is held 3 weeks before the design
summit. Refer to `the TC charter
<http://governance.openstack.org/reference/charter.html#election-for-tc-seats>`__
for more details about TC elections.
.. _should be logged: http://governance.openstack.org/reference/irc.html .. _should be logged: http://governance.openstack.org/reference/irc.html

163
doc/source/open-design.rst
View File

@ -12,119 +12,54 @@ all, however, is our common 6-month development cycle.
OpenStack development cycles are named alphabetically (Austin, Bexar, Cactus, OpenStack development cycles are named alphabetically (Austin, Bexar, Cactus,
Diablo...) and may result in one or more releases. Stable branches (see the Diablo...) and may result in one or more releases. Stable branches (see the
chapter on :doc:`Stable Branches </stable-branches>`) are only cut once though, from the last release of a given deliverable for that development cycle. chapter on :doc:`Stable Branches </stable-branches>`) are only cut once
though, from the last release of a given deliverable for that development
cycle.
.. _design-summit: .. _forum:
Design Summit Forum
============= =====
Design Summits are events held at the beginning of a development cycle, every The Forum is an event held during the OpenStack Summits, every 6 months.
6 months. They are a key part of the "Open Design" promise: they are open to They are a key part of the "Open Design" promise: it is where the various
the public, and recent contributors are sponsored by the OpenStack Foundation constituents of our community get together to bring feedback and discuss the
to attend free of charge. They were modeled after Ubuntu Developers Summits, future of OpenStack.
which are now discontinued.
Goals Goals
----- -----
OpenStack Design Summits have several goals: The Forum has several goals:
* Close the feedback loop, by getting developers, operators and end users
of OpenStack in the same room
* Get feedback on the last release
* Get priorities for the next development cycle
* For features at the early design stages, get feedback on early direction * For features at the early design stages, get feedback on early direction
and quick convergence across a broad range of attendees and quick convergence across a broad range of attendees
* For features that are being implemented, get it through the final
implementation stages and engage with potential contributors and testers
* Get alignment on project team priorities for the upcoming development cycle
* Make quick progress on issues that are difficult to solve otherwise, by
getting the right set of people working on it together at the same time
* Meet in person with fellow contributors, socialize in the hallway track or
evening events, reset relationships after heated online discussions
The OpenStack Design Summits are not for traditional speaker-to-audience The Forum is not for traditional speaker-to-audience
presentations. They should all be open discussions about a specific technical presentations. They should all be open discussions about a specific technical
topic. Therefore, usage of slides or microphones is discouraged, to reduce topic. Therefore, usage of slides or microphones is discouraged, to reduce
the distance between the session proposer/moderator and the rest of the the distance between the session proposer/moderator and the rest of the
audience. audience.
Event structure
---------------
The event lasts for 4 days and is organized in tracks.
* The first day is usually dedicated to the "cross-project workshops" track.
This track is meant to provide a forum to discuss and address issues that
span more than just one project team. Sessions are generally 40-min long
or 90-min long.
* The second and third days are usually dedicated to project team tracks (one
per project team). Sessions are generally 40-min long.
* The "Ops" track is spread across those first three days. Originally a
separate event (the "Ops Summit"), the operators feedback and discussions
are now an integral part of our design process. Sessions are generally 40-min
or 90-min long.
* The last day is generally organized as "contributors meetups": half a day or
a full day of open discussion between project team members. The agenda is
generally decided on the spot based on the result of the previous sessions,
and the amount of energy left at that stage.
Session types
-------------
There are two types of rooms available for sessions, which condition the type
of session you can hold in them.
*Fishbowl* sessions happen in large rooms that can hold between 100 and 300
people. Those rooms are equipped with a projector and whiteboards, and are
organized in fishbowl style (concentric circles of chairs, people who want
to engage in the discussion should move to the center of the fishbowl)
Those sessions are for open discussions where a lot of participation and
feedback is desirable. They generally have catchy titles and appear prominently
on the Design Summit schedule.
*Working* sessions happen in smaller rooms that can hold between 20 and 40
people. Those rooms are equipped with a monitor and whiteboards, and are
organized in boardroom style (everyone around a large table).
Those sessions are for a smaller group of contributors to get specific
work done or prioritized. They generally have a blanket title (like "infra
team working session") and redirect to an etherpad for more precise and
current information about content, in an attempt to limit out-of-team
participation and avoid overcrowding the room.
Pre-summit organization Pre-summit organization
----------------------- -----------------------
A few months before the event, every PTL is contacted by the event organizers The list of topics being discussed is selected by a selection committee
to get an idea of the session needs for their project team track. After including User Committee members, Technical Committee members and Foundation
conferring with their teams, they should answer with a number of fishbowl staff, based on input from the community.
sessions and working sessions desired.
The organizing staff at the Foundation will gather all requirements and Topics are first brainstormed by each group on separate etherpads, then
allocate slots based on project requests and availability in the venue, formally submitted for committee review.
potentially arbitrating using metrics showing team development activity over
the past cycle.
With that allocation in mind, each project team should come up with a list of
topics to cover in fishbowl and working sessions. This is usually done through
collaborative tools like etherpad.openstack.org and multiple team meetings.
Approximately a month before summit, the draft slot / room allocation will be
proposed. It tries to minimize block conflicts (a project being prevented from
attending any session from another project), but comments are welcome before
it is made final.
A few weeks before summit, PTLs will be asked to push the proposed schedule
through tooling that will connect to the scheduling app used at the Summit.
During the summit During the summit
----------------- -----------------
We use etherpad.openstack.org to take notes during sessions. It is generally We use etherpad.openstack.org to take notes during sessions. It is generally
a good idea to prepare those etherpads in advance and list them on the a good idea to prepare those etherpads in advance and list them on the
common list of Design Summit etherpads. common list of Forum etherpads.
Each session should have a moderator to keep the discussion on track, and try Each session should have a moderator to keep the discussion on track, and try
to get to actionable outcomes before the end of the session. It is generally to get to actionable outcomes before the end of the session. It is generally
@ -135,34 +70,42 @@ your session on time, so that they can easily jump to another room. Vacate the
room at the end of the session, and continue the discussion in the hallway if room at the end of the session, and continue the discussion in the hallway if
necessary. necessary.
.. _midcycles: .. _ptg:
Midcycle sprints Project Teams Gathering
================ =======================
Midcycle sprints (also named *midcycle meetups*) are optional project team The Project Teams Gathering (or PTG) is an event held every 6 months,
gatherings that happen between Design Summits. They should be announced on the at the beginning of each development cycle. Attendance is key to the
openstack-dev mailing-list and listed on: developer productivity during the rest of the cycle.
https://wiki.openstack.org/wiki/Sprints
Those are freely organized by project teams, usually using space donated by Each room at the PTG is freely organized by each project team or
Foundation member companies. Travel costs are the responsibility of the workgroup.
individual attending (their employer most likely). Those are especially
useful in the early days of joining or forming a team, when social bonds
and trust need to be established.
Multiple sprints may be co-located, especially when there are good Goals
cross-pollination opportunities between the involved teams. However, -----
productivity also lies in the small, quiet environment, and social bonding
is easier in smaller groups.
Note that the Design Summit should be the first choice for gathering the * Bootstrap the upcoming development cycle, get alignment on the team
whole team for decisions and roadmap alignment. Attendance to the midcycle priorities, define common objectives, assign tasks
sprints should never be mandatory. It is therefore better to have a specific * Make quick progress on issues that are difficult to solve otherwise, by
objective for the sprint and use it to get things done. Any feeling of getting the right set of people working on it together at the same time
"required" attendance (social or actual) may cause hard feelings, especially * Meet in person with fellow contributors, address social issues, spend time
marginalizing contributors without a corporate sponsor, family caretakers, together during the evening, reset relationships after heated online
and people who need Visas to travel. discussions
* Take advantage of cross-pollination, by taking time to discuss
inter-project issues with members of other teams that will be present
during the same week
.. _sprints:
Sprints
=======
In addition to Forums and PTGs, teams may meet in-person or virtually in
specific sprints. For those, it is generally good to have a specific
objective for the sprint and use it to get a specific goal done. They
should be announced on the mailing-list and open to any contributor who
wants to join.
To enable people to focus on the same topic at the same time, without To enable people to focus on the same topic at the same time, without
factoring in the monetary and life cost of travel, we also support Virtual factoring in the monetary and life cost of travel, we also support Virtual

54
doc/source/ptl.rst
View File

@ -70,7 +70,7 @@ private messages on IRC or publicly through the openstack-dev mailing list.
#. Does the person participate in weekly meetings? #. Does the person participate in weekly meetings?
#. Does the person participate at the summit design sessions? #. Does the person participate in the forum discussions?
#. Does the person participate at the mid-cycle / project-team-gathering? #. Does the person participate at the mid-cycle / project-team-gathering?
@ -146,6 +146,31 @@ During the cycle
release after 4 weeks even if the changes are minor. *More often is release after 4 weeks even if the changes are minor. *More often is
better than less often.* better than less often.*
Before the Forum
================
#. Start an etherpad to brainstorm potential session topics. For example:
http://lists.openstack.org/pipermail/openstack-dev/2017-March/114123.html
#. Based on that brainstorming, propose sessions. Create an etherpad for
every session, prime the content. List these etherpads in the Wiki.
During the Forum
================
#. Reach out to potential new contributors to the project, participate in
project on-boarding sessions.
#. Attend as many cross-project sessions as possible.
#. In the discussion sessions you moderate:
* Take notes on the etherpad (or delegate a scribe)
* Act as a moderator rather than actively participate (or delegate a moderator)
#. After the discussion, post a summary of the session outcome to the ML, for the
benefit of those who could not be present.
At the end of the cycle At the end of the cycle
======================= =======================
@ -166,28 +191,23 @@ At the end of the cycle
install guide need to be updated? install guide need to be updated?
Before the Summit Before the PTG
================= ==============
#. Start an etherpad for the design session proposals mail it out. For example: #. Decide if your team will hold a team meeting at the PTG, and communicate
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg49312.html with the events organizers
#. Create an etherpad for every design session, prime the content. List these #. If your team gathers at the PTG, create an etherpad to dynamically build
etherpads in the Wiki and send out a note to mailing list. For example: the room agenda, and list it on the event wiki page.
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076283.html
During the summit During the PTG
================= ==============
#. Reach out to new contributors to the project at the design sessions. #. Be flexible, attend inter-project sessions as appropriate.
#. Attend as many cross-project sessions as possible. #. Keep the event schedule up to date on what the current topics of discussion
in your team room is.
#. At the project design sessions.
* Take notes on the etherpad (or delegate a scribe)
* Act as a moderator rather than actively participate (or delegate a moderator)
Stable Stable

21
doc/source/release-management.rst
View File

@ -296,22 +296,22 @@ Typical Development Cycle Schedule
The development cycles follow a repeating pattern, which is described The development cycles follow a repeating pattern, which is described
in general terms here. The length of time between milestones may in general terms here. The length of time between milestones may
change from cycle to cycle because of holidays, summit scheduling, and change from cycle to cycle because of holidays, event scheduling, and
other factors, so consult the wiki for the actual schedule for the other factors, so consult the wiki for the actual schedule for the
current cycle. The cycles follow a repeating pattern, which is current cycle. The cycles follow a repeating pattern, which is
described more generally here. described more generally here.
Weeks with negative numbers are counting down leading to the event Weeks with negative numbers are counting down leading to the event
("Summit -2" is 2 weeks before the summit). Weeks with positive ("Release -2" is 2 weeks before the release). Weeks with positive
numbers are counting up following an event ("Feature Freeze +1" is the numbers are counting up following an event ("Feature Freeze +1" is the
week following the feature freeze). week following the feature freeze).
.. note:: .. note::
Dates for elections are specified in the Technical Committee charter Dates for elections are specified in the Technical Committee charter
relative to the design summits, while most other dates are based on relative to events dates, while most other dates are based on
community consensus and expressed in terms of the release date. community consensus and expressed in terms of the release date.
Because the summit may move around in the cycle, the two scheduling Because the events may move around in the cycle, the two scheduling
systems may overlap differently in different cycles. systems may overlap differently in different cycles.
Weeks Leading to Milestone 1 Weeks Leading to Milestone 1
@ -412,19 +412,6 @@ Release 0
Thursday of this week Thursday of this week
- All library releases freeze on master ends - All library releases freeze on master ends
Summit -2
---------
Final summit planning and design session preparation.
Summit
------
The semi-annual Design Summit and Conference where contributors,
operators, and users meet in person to discuss the state of the
project and future work.
.. _Mitaka Release Schedule: https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
Managing Release Notes Managing Release Notes
====================== ======================

8
doc/source/stable-branches.rst
View File

@ -51,10 +51,10 @@ Phase II support. Depending on how long each branch is supported, there may be
one or more releases in Phase III support. one or more releases in Phase III support.
The exact length of any given stable branch life support is discussed amongst The exact length of any given stable branch life support is discussed amongst
stable branch maintainers and QA/infrastructure teams at every Design Summit. stable branch maintainers and QA/infrastructure teams at the start of every
It is generally between 9 and 15 months, at which point the value of the release cycle. It is generally between 9 and 15 months, at which point the
stable branch is clearly outweighed by the cost in maintaining it in our value of the stable branch is clearly outweighed by the cost in maintaining
continuous integration systems. it in our continuous integration systems.
Appropriate Fixes Appropriate Fixes