Update Design Summit -> Forum + PTG
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
parent
1623412a8f
commit
271d35ae74
|
|
@ -6,9 +6,16 @@
|
|||
|
||||
Design Summit
|
||||
|
||||
Design Summits are periodic, in-person, meetings for the entire
|
||||
OpenStack community used to finalize plans for a development
|
||||
cycle. See :ref:`design-summit` for details.
|
||||
The 'Design Summit' is the previous name for the developer-oriented event
|
||||
that used to happen concurrently with the OpenStack Summit. Design
|
||||
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
|
||||
|
||||
|
|
@ -18,11 +25,18 @@
|
|||
https://wiki.openstack.org/wiki/IRC for tips for setting up a
|
||||
client.
|
||||
|
||||
Mid-cycle sprints/meetups
|
||||
Mid-cycle sprints
|
||||
|
||||
Midcycle sprints or meetups are optional in-person gatherings
|
||||
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
|
||||
|
||||
|
|
@ -34,4 +48,4 @@
|
|||
|
||||
The OpenStack Technical Committee is responsible for governance
|
||||
of the technical contributors to the project. See
|
||||
http://governance.openstack.org for more details.
|
||||
https://governance.openstack.org/tc/ for more details.
|
||||
|
|
|
|||
|
|
@ -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 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
|
||||
* By default participating in the weekly `Cross Project meeting`_ and watching
|
||||
the `cross project repository`_, unless a `Cross Project Specification
|
||||
|
|
@ -179,37 +180,10 @@ wiki page on `tie breaking`_.
|
|||
Election Schedule
|
||||
-----------------
|
||||
|
||||
The election schedule is based on the release cycle and summit dates,
|
||||
so the following timeline is expressed as the number of weeks leading
|
||||
up to the summit.
|
||||
|
||||
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.
|
||||
The `Technical Committee charter
|
||||
<https://governance.openstack.org/tc/reference/charter.html>`__
|
||||
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).
|
||||
|
||||
|
||||
.. _should be logged: http://governance.openstack.org/reference/irc.html
|
||||
|
|
|
|||
|
|
@ -12,119 +12,54 @@ all, however, is our common 6-month development cycle.
|
|||
|
||||
OpenStack development cycles are named alphabetically (Austin, Bexar, Cactus,
|
||||
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
|
||||
6 months. They are a key part of the "Open Design" promise: they are open to
|
||||
the public, and recent contributors are sponsored by the OpenStack Foundation
|
||||
to attend free of charge. They were modeled after Ubuntu Developers Summits,
|
||||
which are now discontinued.
|
||||
The Forum is an event held during the OpenStack Summits, every 6 months.
|
||||
They are a key part of the "Open Design" promise: it is where the various
|
||||
constituents of our community get together to bring feedback and discuss the
|
||||
future of OpenStack.
|
||||
|
||||
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
|
||||
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
|
||||
topic. Therefore, usage of slides or microphones is discouraged, to reduce
|
||||
the distance between the session proposer/moderator and the rest of the
|
||||
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
|
||||
-----------------------
|
||||
|
||||
A few months before the event, every PTL is contacted by the event organizers
|
||||
to get an idea of the session needs for their project team track. After
|
||||
conferring with their teams, they should answer with a number of fishbowl
|
||||
sessions and working sessions desired.
|
||||
The list of topics being discussed is selected by a selection committee
|
||||
including User Committee members, Technical Committee members and Foundation
|
||||
staff, based on input from the community.
|
||||
|
||||
The organizing staff at the Foundation will gather all requirements and
|
||||
allocate slots based on project requests and availability in the venue,
|
||||
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.
|
||||
Topics are first brainstormed by each group on separate etherpads, then
|
||||
formally submitted for committee review.
|
||||
|
||||
During the summit
|
||||
-----------------
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
necessary.
|
||||
|
||||
.. _midcycles:
|
||||
.. _ptg:
|
||||
|
||||
Midcycle sprints
|
||||
================
|
||||
Project Teams Gathering
|
||||
=======================
|
||||
|
||||
Midcycle sprints (also named *midcycle meetups*) are optional project team
|
||||
gatherings that happen between Design Summits. They should be announced on the
|
||||
openstack-dev mailing-list and listed on:
|
||||
https://wiki.openstack.org/wiki/Sprints
|
||||
The Project Teams Gathering (or PTG) is an event held every 6 months,
|
||||
at the beginning of each development cycle. Attendance is key to the
|
||||
developer productivity during the rest of the cycle.
|
||||
|
||||
Those are freely organized by project teams, usually using space donated by
|
||||
Foundation member companies. Travel costs are the responsibility of the
|
||||
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.
|
||||
Each room at the PTG is freely organized by each project team or
|
||||
workgroup.
|
||||
|
||||
Multiple sprints may be co-located, especially when there are good
|
||||
cross-pollination opportunities between the involved teams. However,
|
||||
productivity also lies in the small, quiet environment, and social bonding
|
||||
is easier in smaller groups.
|
||||
Goals
|
||||
-----
|
||||
|
||||
Note that the Design Summit should be the first choice for gathering the
|
||||
whole team for decisions and roadmap alignment. Attendance to the midcycle
|
||||
sprints should never be mandatory. It is therefore better to have a specific
|
||||
objective for the sprint and use it to get things done. Any feeling of
|
||||
"required" attendance (social or actual) may cause hard feelings, especially
|
||||
marginalizing contributors without a corporate sponsor, family caretakers,
|
||||
and people who need Visas to travel.
|
||||
* Bootstrap the upcoming development cycle, get alignment on the team
|
||||
priorities, define common objectives, assign tasks
|
||||
* 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, address social issues, spend time
|
||||
together during the evening, reset relationships after heated online
|
||||
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
|
||||
factoring in the monetary and life cost of travel, we also support Virtual
|
||||
|
|
|
|||
|
|
@ -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 at the summit design sessions?
|
||||
#. Does the person participate in the forum discussions?
|
||||
|
||||
#. 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
|
||||
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
|
||||
=======================
|
||||
|
|
@ -166,28 +191,23 @@ At the end of the cycle
|
|||
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:
|
||||
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg49312.html
|
||||
#. Decide if your team will hold a team meeting at the PTG, and communicate
|
||||
with the events organizers
|
||||
|
||||
#. Create an etherpad for every design session, prime the content. List these
|
||||
etherpads in the Wiki and send out a note to mailing list. For example:
|
||||
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076283.html
|
||||
#. If your team gathers at the PTG, create an etherpad to dynamically build
|
||||
the room agenda, and list it on the event wiki page.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
#. 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)
|
||||
#. Keep the event schedule up to date on what the current topics of discussion
|
||||
in your team room is.
|
||||
|
||||
|
||||
Stable
|
||||
|
|
|
|||
|
|
@ -296,22 +296,22 @@ Typical Development Cycle Schedule
|
|||
|
||||
The development cycles follow a repeating pattern, which is described
|
||||
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
|
||||
current cycle. The cycles follow a repeating pattern, which is
|
||||
described more generally here.
|
||||
|
||||
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
|
||||
week following the feature freeze).
|
||||
|
||||
.. note::
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Weeks Leading to Milestone 1
|
||||
|
|
@ -412,19 +412,6 @@ Release 0
|
|||
Thursday of this week
|
||||
- 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
|
||||
======================
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
The exact length of any given stable branch life support is discussed amongst
|
||||
stable branch maintainers and QA/infrastructure teams at every Design Summit.
|
||||
It is generally between 9 and 15 months, at which point the value of the
|
||||
stable branch is clearly outweighed by the cost in maintaining it in our
|
||||
continuous integration systems.
|
||||
stable branch maintainers and QA/infrastructure teams at the start of every
|
||||
release cycle. It is generally between 9 and 15 months, at which point the
|
||||
value of the stable branch is clearly outweighed by the cost in maintaining
|
||||
it in our continuous integration systems.
|
||||
|
||||
|
||||
Appropriate Fixes
|
||||
|
|
|
|||
Loading…
Reference in New Issue