openstack/governance
Code Issues Proposed changes

Fix some typos

Browse Source 
This is to fix the following typos:
  fullfill
  engourage
  reponsible
  peforms
  conisistency
  decsion
  ceilomter
  evalation
  does't

Change-Id: I31684292f69fdd157c14d06ea1d6b1b31eb0cfb5
This commit is contained in:
zhufl
2020-01-08 09:02:33 +08:00
parent 188abad633
commit 3ea2ec0cd4
7 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
goals/selected/ocata/remove-incubated-oslo-code.rst
View File

@@ -829,7 +829,7 @@ None
tricircle tricircle
--------- ---------
Tricircle does't rely on oslo-incubator or any openstack/common modules, Tricircle doesn't rely on oslo-incubator or any openstack/common modules,
it is consuming the oslo.* libraries. it is consuming the oslo.* libraries.
Planning Artifacts: Planning Artifacts:

2
goals/selected/pike/python35.rst
View File

@@ -118,7 +118,7 @@ Projects with Unit Tests Voting
* aodh * aodh
* barbican * barbican
* ceilomter * ceilometer
* cinder * cinder
* cliff * cliff
* congress * congress

2
goals/selected/stein/upgrade-checkers.rst
View File

@@ -15,7 +15,7 @@ should be documented today in the upgrade release notes would be a good
candidate for an upgrade checker to validate. candidate for an upgrade checker to validate.
These checks should perform any upgrade validation that can be automated. There These checks should perform any upgrade validation that can be automated. There
may always be some things that need some subjective evalation, but for those may always be some things that need some subjective evaluation, but for those
things that can be automated to determine if there is an issue that could things that can be automated to determine if there is an issue that could
impact upgrade success, a validation check should be created to automate it. impact upgrade success, a validation check should be created to automate it.

4
reference/comparison-of-official-group-structures.rst
View File

@@ -163,8 +163,8 @@ Governance
Committees exist to help `govern`_ the community and provide leadership. Committees exist to help `govern`_ the community and provide leadership.
You can self-nominate for the below committees and become a committee member, You can self-nominate for the below committees and become a committee member,
or provide feedback to committee. If you find it's hard or confusing to push or provide feedback to committee. If you find it's hard or confusing to push
your mission into community, or you find the current structure can't fullfill your mission into community, or you find the current structure can't fulfill
your goal, we engourage you to encounter with these committees that might be your goal, we encourage you to encounter with these committees that might be
able to help: able to help:
* Technical Committee (TC) * Technical Committee (TC)

2
reference/role-of-the-tc.rst
View File

@@ -45,7 +45,7 @@ in other TC-maintained documents.
The current governance model institutes a two-level structure with The current governance model institutes a two-level structure with
:doc:`project teams <projects/index>` in charge of specific sets of git :doc:`project teams <projects/index>` in charge of specific sets of git
repositories or tasks. The TC is reponsible for making sure the model repositories or tasks. The TC is responsible for making sure the model
is followed, and fair elections are held for every project team. is followed, and fair elections are held for every project team.
Finally, while most conflicts should be resolved at the project team level, Finally, while most conflicts should be resolved at the project team level,
the TC remains ultimately responsible in case issues cannot be solved at the TC remains ultimately responsible in case issues cannot be solved at

2
reference/tags/vulnerability_managed.rst
View File

@@ -88,7 +88,7 @@ Requirements
implementation which could imply a large number of future implementation which could imply a large number of future
vulnerability reports. The review, audit, or threat analysis may vulnerability reports. The review, audit, or threat analysis may
be done by the project team itself or an impartial third party. be done by the project team itself or an impartial third party.
In the event the project team involved in the tagging peforms In the event the project team involved in the tagging performs
the review, audit, or threat analysis, the results must be the review, audit, or threat analysis, the results must be
validated by a third party. The VMT doesn't stipulate which validated by a third party. The VMT doesn't stipulate which
third party would perform this review or validation; for example third party would perform this review or validation; for example

4
reference/upstream-investment-opportunities/2019/goal-champions.rst
View File

@@ -12,7 +12,7 @@ Business Case
------------- -------------
Organizations who sponsor Goal Champions Organizations who sponsor Goal Champions
have someone in-house who understands the upstream decsion making and have someone in-house who understands the upstream decision making and
implementation work across services and projects. This in-house implementation work across services and projects. This in-house
expertise can help minimize disruption to downstream products and expertise can help minimize disruption to downstream products and
services and help position timely communications and expectations with services and help position timely communications and expectations with
@@ -39,7 +39,7 @@ Technical Details
Each release series, the OpenStack Technical Committee selects a set Each release series, the OpenStack Technical Committee selects a set
of shared objectives to be fulfilled in that release cycle, that of shared objectives to be fulfilled in that release cycle, that
provide value across Openstack projects by e.g. advancing conisistency provide value across Openstack projects by e.g. advancing consistency
and user experience across OpenStack or addressing shared technical and user experience across OpenStack or addressing shared technical
debt. These goals are selected from a `backlog of potential goals`_ debt. These goals are selected from a `backlog of potential goals`_
based on feedback from deployers, users, contributors, and PTLs and based on feedback from deployers, users, contributors, and PTLs and