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
Show Stats 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 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.
Planning Artifacts:

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

@ -118,7 +118,7 @@ Projects with Unit Tests Voting
* aodh
* barbican
* ceilomter
* ceilometer
* cinder
* cliff
* 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.
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
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.
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
your mission into community, or you find the current structure can't fullfill
your goal, we engourage you to encounter with these committees that might be
your mission into community, or you find the current structure can't fulfill
your goal, we encourage you to encounter with these committees that might be
able to help:
* 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
: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.
Finally, while most conflicts should be resolved at the project team level,
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
vulnerability reports. The review, audit, or threat analysis may
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
validated by a third party. The VMT doesn't stipulate which
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
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
expertise can help minimize disruption to downstream products and
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
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
debt. These goals are selected from a `backlog of potential goals`_
based on feedback from deployers, users, contributors, and PTLs and