diff --git a/docs/opendesign.rst b/docs/opendesign.rst
new file mode 100644
index 0000000..f585055
--- /dev/null
+++ b/docs/opendesign.rst
@@ -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.