Open Stack

HTML rendered version: http://www.openstack.org/blog/2016/02/openstack-developer-mailing-list-digest-20160226/

Audience for Release Notes
==========================
* We have 3 potential audiences for release notes:
  - Developers consuming libraries or other code directly.
  - Deployers and operators.
  - End-users.
* Two kinds of documentation being discussed:
  - Reno [1] for release notes [2]
    + Keep in mind the audience is *not* someone who is necessarily going to be
      looking at code or writing apps based on libraries we produce.
    + Highlight information that deployers and operators will need, like
      changes to configuration options or service behaviors.
    + Describe REST API changes that an end-user may need to know about.
  - In-tree developer documentation [3] for Developers.
    + Internal details, library API changes, etc. -- any changes the deployer
      is not going to see.

* The two sets of documentation are meant for different purposes, so we need to
  think about what information we publish in each.


A Proposal to Separate the Design Summit
========================================
* Today
  - Since the beginning, we've had face to face time at Design Summits to
    discuss development cycles to set goals and organize the work for the
    upcoming 6 months.
  - A more traditional conference took place at the same time to ensure
    interaction between upstream and downstream parts of our community.


* Current issues
  - For developers:
    + Difficult to focus on upstream work with so many distractions coming
      from the conference.
    + As a result the summit is less productive, and we form midcycles to fill
      our focus.
  - For companies:
    + Flying all their developers to expensive cities and conference hotels for
      the summit is pretty costly.  - The goals of the summit location reaching
      out to users everywhere does not necessarily align with the goals of the
      design summit location.
    + Not enough time to  build products on top of the recent release.
  - Not enough time for users to try out the new release to have feedback.
  -  Finding venues that can accommodate both events is becoming increasingly
     complicated.


* Proposal: Split up the events
  - The first event would be for upstream technical contributors of OpenStack.
    + Held in a simpler, scaled-back setting that would let all OpenStack
      project teams meet in separate rooms, but in a co-located event that
      would make it easy to have ad-hoc cross-project discussions.
    + It would be held in closer to the centers of mass of contributors, in
       less-expensive locations.
    + It would happen a couple of weeks /before/ the previous cycle release.
       There is a lot of overlap between cycles. Work on a cycle starts at the
       previous cycle feature freeze, while there is still 5 weeks to go.  Most
       people switch full-time to the next cycle by RC1.  Organizing the event
       just after that time lets us organize the work and kickstart the new
       cycle at the best moment. It also allows us to use our time together to
       quickly address last-minute release-critical issues if such issues
       arise.
  - The second event would be the main downstream business conference.
      + This includes high-end keynotes, marketplace, and break out sessions.
      + Organized two or three months /after/ the release, to give time
        downstream users to deploy and build products on top of the release.
      + This will better allow us to gather feedback on the recent release,
        a gather requirements for the next cycle.
      + A subset of contributors who would like to participate in sessions can
        collect and relay feedback to other team members (similar to the
        operators midcycle meetups).
* The split should reduce the number of midcycle events, however, if they're
  still needed, they could happen at the conference event (which is in the
  middle of the cycle).
* The split means that we need to stagger the events and cycles.  We have
  a long time between Barcelona and the Q1 Summit in the US, so the idea would
  be to use that long period to insert a smaller cycle (Ocata) with a release
  early March, 2017 and have the first specific contributors event at the start
  of the P cycle, mid-February, 2017. With the already-planned events in 2016
  and 2017 it is the earliest we can make the transition. We'd have a last,
  scaled-down design summit in Barcelona to plan the shorter cycle.
* Operators midcycle will still continue to happen.


* Voiced Concerns and Answers:
  - This creates two events instead of one.
  - Creates community split, with developers skipping the main and
    non-developers not providing any feedback to the contributor specific
    event.
    + There will still be a lot of strategic discussions at the main event. 
    + This is where we look at the N-1 release and start drawing plans and
      cross-project themes for the N+1 release.
    + We don't need every developer there, but we still need a significant
      chunk of them, with every team represented, so that we can have those
      strategic and cross-project discussions.  
    + Someone who wants to keep touch with development could still make only
      one trip, so it's not expected for the communities to be split. We'd
      still all be represented in the main event.
  - Losing the main summit as an excuse to fund developers' travel. Some
    developers are only sent to the Design summit because the main event is
    happening at the same time.
    + If you have to pretend to attend the Summit to be able to attend the
      Design Summit instead, there is deception involved.  You should a talk
      with your employer on where the most value lies for you in attending
      which event.
    + The Foundation also has the Travel support program to cover the gaps [4].
  - The fear of US-centricity (translating from "closer to the centers of mass
    of contributors"). This makes travel cost cheaper at the expense of making
    it more costly for non-US parts of our community.
    + The goal is "minimize and *balance* travel costs for existing
      contributors". There will still be some continent rotation involved, but
      we need to balance cost and fair.
  - The lost of midcycle spirit. Some people really like the midcycles as they
    stand: separated small events where only your small team is around. The
    split appears to reduce the likelihood, the need, or the funding for such
    events. 
    + While the hope is the proposed format will let us fulfill all our team
      socialization needs, it's true that there will be other people around,
      and it will feel a lot less exclusive and special.
    + The trade-off is that having people all together encourages cross-project
      work and breaks silos.

[1] - http://docs.openstack.org/developer/reno/
[2] - http://releases.openstack.org/
[3] - http://developer.openstack.org/
[4] - https://www.openstack.org/summit/austin-2016/austin-and-travel/#travel-support