openinfra/four-opens
Code Issues Proposed changes

Fix typos

Browse Source 
Fix a couple of typos included in the initial upload.
This commit is contained in:
Thierry Carrez 2018-11-10 13:37:43 +01:00
parent 4a7f43b086
commit 0d901be790
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/opendesign.rst
View File

@ -16,9 +16,9 @@ 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
process, they 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
@ -40,7 +40,7 @@ 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
"how", and "where" of the design process. The "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

2
docs/opensource.rst
View File

@ -63,7 +63,7 @@ In practice, individual and corporate contributors need to understand the
consequences of contributing code to an Apache Licensed project, particularly
the granting of copyright and patent licenses to all users of the software. To
acknowledge this, many projects require that all contributors sign a
"Contributor License Agreements" (CLA) [#OSCLA]_ or "Developer Certification of
"Contributor License Agreement" (CLA) [#OSCLA]_ or "Developer Certificate of
Origin" (DCO). Typically, a CLA is a stronger statement, attesting that a
contributor has a right to submit work to the project and that they are
granting copyright and patent licenses in accordance with the Apache License