The content below is taken from the original (OpenStack Developer Mailing List Digest Feb 20-26), to continue reading please visit the site. Remember to respect the Author & Copyright.

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.
• Full thread [4]

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.

How to 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 [5].
• 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.
• Full thread [6]