From 271d35ae74c89435c72209f8fe3718ea7c205015 Mon Sep 17 00:00:00 2001 From: Thierry Carrez Date: Tue, 30 May 2017 15:30:56 +0200 Subject: [PATCH] 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 --- doc/source/glossary.rst | 26 +++-- doc/source/open-community.rst | 38 ++----- doc/source/open-design.rst | 163 ++++++++++-------------------- doc/source/ptl.rst | 54 ++++++---- doc/source/release-management.rst | 21 +--- doc/source/stable-branches.rst | 8 +- 6 files changed, 124 insertions(+), 186 deletions(-) diff --git a/doc/source/glossary.rst b/doc/source/glossary.rst index 42fa1dd..b4aa52b 100644 --- a/doc/source/glossary.rst +++ b/doc/source/glossary.rst @@ -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. diff --git a/doc/source/open-community.rst b/doc/source/open-community.rst index f944d74..81fb75f 100644 --- a/doc/source/open-community.rst +++ b/doc/source/open-community.rst @@ -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 -`__ -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 -`__ -for more details about TC elections. +The `Technical Committee charter +`__ +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 diff --git a/doc/source/open-design.rst b/doc/source/open-design.rst index 8a9942a..c5f49c6 100644 --- a/doc/source/open-design.rst +++ b/doc/source/open-design.rst @@ -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 `) are only cut once though, from the last release of a given deliverable for that development cycle. +chapter on :doc:`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 diff --git a/doc/source/ptl.rst b/doc/source/ptl.rst index 97eb8bd..dea1e5b 100644 --- a/doc/source/ptl.rst +++ b/doc/source/ptl.rst @@ -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 diff --git a/doc/source/release-management.rst b/doc/source/release-management.rst index 83d29ee..f2e3394 100644 --- a/doc/source/release-management.rst +++ b/doc/source/release-management.rst @@ -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 ====================== diff --git a/doc/source/stable-branches.rst b/doc/source/stable-branches.rst index a05bb44..4f26dd2 100644 --- a/doc/source/stable-branches.rst +++ b/doc/source/stable-branches.rst @@ -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