Open Design chapter

This commit is contained in:
Chris Hoge 2018-11-06 16:10:53 -08:00
parent bb24181a8d
commit bc8cc22e25
1 changed files with 72 additions and 0 deletions

72
docs/opendesign.rst Normal file
View File

@ -0,0 +1,72 @@
===========
Open Design
===========
We are committed to an open design process. Every development cycle the
OpenStack community holds face-to-face events to gather requirements and
write specifications for the upcoming release. Those events, which are open
to anyone, include users, developers, and upstream projects. We gather
requirements, define priorities and flesh out technical design to guide
development for the next development cycle.
The community controls the design process. You can help make this software
meet your needs.
The Four Opens are all about the acceptance of letting go of control over an
open source project. One popular open source development model for an
organization to release it has developed under an open source license. While
most of them will also commit to a transparent and inclusive development
process, the still frequently maintain control of the software with most of the
design decisions being made by organization leaders and implemented by their
employees. The principle of "Open design" takes this one step beyond and
guarantees a transparent and open process for planning and designing the
software. It's about letting go of the control of the design of the software
and its feature road-map, and accepting that it should be driven by the
community.
This is not easy to do. Design is an opinionated process. Design by committee
can be inefficient. It's easier and faster to keep design and feature
development in the hands of a happy few, behind closed doors, than to get
consensus across a community around desired features and priorities. But that
would be choosing to go fast in the short term with a small group rather than
going far in the long term with a larger group. Community-agreed design will be
slow, but it will lead to a better product that better answers the need of the
users.
In this section we'll cover how to set up your project and your development
cycle in a way that enables and encourages Open Design.
The "Open Design" Principle in Practice
---------------------------------------
Open Design begins with the establishment of a structure to guide the "when",
"how", and "where" of the design process. Then "when" refers to the
release-cadence of the software, particularly if it is a feature-based or
time-based release. A feature-based release allows the community to reach a
consensus on required capabilities a release should have, then only deliver the
next version of the software when those features are complete. While there are
many processes that can help estimate the time and effort it will take to
deliver a set of requirements, feature-based releases often result in delays in
delivery. If you're encouraging a large community of diverse developers, these
delays can have differing and significant impacts, particularly on vendors who
rely on release schedules for delivering software. Release delays can create
tension in the community, and raise the barrier of entry for contributors by
creating an unknown cost.
Because of those disadvantages, time-based releases are strongly preferred for
healthy collaboration. With a time-based release, there's no single group that
decides what feature can or can't be included in a release. The features that
are complete at the release deadline are the features available in that
release. A time based release means that everybody who depends on the software
has a clear expectation of how to contribute to the software, and what to
expect at any given step in the software development process. An additional
benefit is the ability to schedule events around aspects of the development
cycle.
A time-based release cycle becomes critical for the success of "Open Design".
Once the schedule is set, contributors know exactly when they can add their
voice to the design process. Part of the OpenStack design process is to have
face-to-face events at the beginning of every release cycle to begin the design
process for the next release. This in-person meeting focuses the attention of
the community in a neutral environment. These events are open to anyone,
including developers, users, and vendors.