openinfra/four-opens
Code Issues Proposed changes

Added Open Development section

Browse Source
This commit is contained in:
Chris Hoge 2018-11-06 16:24:16 -08:00
parent bc8cc22e25
commit b07c46afb2
1 changed files with 46 additions and 0 deletions

46
docs/opendevelopment.rst Normal file

@ -0,0 +1,46 @@
================
Open Development
================
We maintain a publicly available source code repository through the entire
development process. We do public code reviews. We have public road maps.
This makes participation simpler, allows users to follow the development
process and participate in QA at an early stage.
"Open development" refers to the adoption of transparent and inclusive
development processes that enable everyone to participate as an equal on a
level playing field. Open development means that all patches are welcome for
consideration, whether that patch is from a project founder or a first time
contributor. A successful open source project will adopt a set of standards
that clearly states the metrics and standards that a contribution will be
evaluated against. By defining these standards we create an egalitarian process
in which contributions are evaluated on a level playing field. The metrics for
evaluating a patch can include:
- Correctness: does the code include tests of its functionality?
- Quality Assurance: does the code integrate with other projects and not introduce
regressions?
- Documentation: does a new feature include documentation on what
it does and how to properly configure it?
- Purpose: does the code implement a feature identified in the open design process?
Automation, like automated unit, integration, and style checking, can go a long
way to establishing a baseline standard for new code. Code review by trusted
community members is the additional critical layer on top of the automated
tooling?
This raises the question, how does one become a trusted community member?
Regular participation in code review and submitting patches builds reputation
and trust within a community. Aspects of the open development process must
include facilities for anyone (not just existing projects contributors and
leaders) to:
Discover current priorities and tasks. Report bugs and vulnerabilities. Leave
reviews on existing patches. Submit patches to a project.
There must also be a clearly defined process that describes how a contributor
can graduate to different levels of leadership within a project. The success of
Open Development relies not just on the availability and accessibility of
tooling in a project, but also upon the healthy governance of a community
(which we will discuss further in the next chapter on "Open Community").