5db7e933c2
This change restructures the body of the book to add an additional chapter about actions and processes. It also edits the chapters to create a more cohesive flow and voice through the whole. Change-Id: I31690e21ecc801e6c62cce57c5ed4174335bdc61 Signed-off-by: Ildiko Vancsa <ildiko.vancsa@gmail.com>
73 lines
3.9 KiB
ReStructuredText
73 lines
3.9 KiB
ReStructuredText
================
|
|
Open Development
|
|
================
|
|
|
|
Open Development is the next pillar as well as the next step after establishing
|
|
the Open Design principle. Similarly to the former steps, you also need a
|
|
transparent and inclusive development process that enables everyone to
|
|
participate as equals on a level playing field.
|
|
|
|
The contributors of your community need to have access to every step of the
|
|
process. This means that the process needs to be documented and accessible for
|
|
everyone including established contributors and newcomers. You need to use
|
|
tools and services that are also available to all participants to use in order
|
|
to perform the required steps of the process.
|
|
|
|
The community should not differentiate between contributions depending on the
|
|
affiliation of the person who authored or committed that change. The review
|
|
process needs to be open with history so requests and decisions can be accessed
|
|
later. While accepting contributions can look subjective you need to put all
|
|
the effort into documenting criteria, guidelines - to write code or
|
|
documentation - and processes to ensure the most objective process possible.
|
|
In addition, you can also put a lot of emphasis on automation, such as testing
|
|
- unit, functional, integration tests and more - in case of source code.
|
|
|
|
Reviewing contributions should be available, and encouraged, to everyone who is
|
|
interested in the project, even if the final decision can be made only by a
|
|
subset of contributors. These contributors -called core reviewers, committers,
|
|
etc-, should be members of the project leadership and elected by the fellow
|
|
community members based on merit.
|
|
|
|
The open development process opens up the avenue for newcomers to become
|
|
seasoned contributors and then take on leadership positions, if that is
|
|
something that they desire. Besides contributing new ideas and functionality,
|
|
it is very important to demonstrate how much one cares about the project,
|
|
including the quality of the software as well as the processes used to create
|
|
and maintain it. You can become part of the community by reviewing
|
|
contributions, propose new ideas, fix issues and participate in the community's
|
|
communication channels, like mailing lists, meetings, and so forth.
|
|
|
|
|
|
Open Development Process Examples
|
|
---------------------------------
|
|
|
|
The OpenStack community is a large group of contributors with multiple project
|
|
teams who've been actively practicing and evolving their development processes
|
|
to make it more efficient and inclusive.
|
|
|
|
The community is following a set of metrics and guiding principles to evaluate
|
|
a code or documentation change:
|
|
|
|
- Correctness: code changes need to have corresponding tests to ensure it works
|
|
as specified
|
|
- Quality Assurance: the code has test cases to ensure smooth integration with
|
|
other services and does not introduce regression
|
|
- Documentation: a new feature needs to be properly documented, including
|
|
API documentation and configuration options
|
|
- Purpose: the code change should implement a bug fix or new functionality as
|
|
previously identified and discussed as part of the open design process
|
|
|
|
The OpenStack community prioritized automation from the beginning to ensure the
|
|
quality of the code as well as an open development process. Code changes go
|
|
through multiple rounds of automated testing where a change cannot be approved
|
|
without a successful test run. Once a change is approved by the core reviewers
|
|
it goes through one more round of testing. If that is successful, the change
|
|
gets merged into the project's code base. It is very important to note, that
|
|
the last entity who votes on the change is the tool that executes all the
|
|
applicable test cases.
|
|
|
|
The community is actively working on their contributor focused documentation
|
|
that captures the development processes and tools that are used throughout all
|
|
the phases. This ensures that everyone can gain the knowledge to be able to
|
|
contribute and follow the same guidelines to ensure a level playing field.
|