6c46a48c40
Convert paragraph to a list, this looks like a formatting problem. Add reference to the opencommunity chapter. Change-Id: Ib342de96058a891a6e0999ee2e09a743b45001a3
53 lines
2.5 KiB
ReStructuredText
53 lines
2.5 KiB
ReStructuredText
================
|
|
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. Publicly-accessible services means that everyone can see
|
|
everything about development activities, without even needing to sign up to a
|
|
service. Open development also 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 :doc:`Open
|
|
Community <opencommunity>`).
|
|
|