From 3ea2ec0cd49eadfa1dac1c503d707fdbc57d136f Mon Sep 17 00:00:00 2001 From: zhufl Date: Wed, 8 Jan 2020 09:02:33 +0800 Subject: [PATCH] Fix some typos This is to fix the following typos: fullfill engourage reponsible peforms conisistency decsion ceilomter evalation does't Change-Id: I31684292f69fdd157c14d06ea1d6b1b31eb0cfb5 --- goals/selected/ocata/remove-incubated-oslo-code.rst | 2 +- goals/selected/pike/python35.rst | 2 +- goals/selected/stein/upgrade-checkers.rst | 2 +- reference/comparison-of-official-group-structures.rst | 4 ++-- reference/role-of-the-tc.rst | 2 +- reference/tags/vulnerability_managed.rst | 2 +- .../upstream-investment-opportunities/2019/goal-champions.rst | 4 ++-- 7 files changed, 9 insertions(+), 9 deletions(-) diff --git a/goals/selected/ocata/remove-incubated-oslo-code.rst b/goals/selected/ocata/remove-incubated-oslo-code.rst index b4828f81f..ab8ed6076 100644 --- a/goals/selected/ocata/remove-incubated-oslo-code.rst +++ b/goals/selected/ocata/remove-incubated-oslo-code.rst @@ -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: diff --git a/goals/selected/pike/python35.rst b/goals/selected/pike/python35.rst index de3f6857e..39ddb8d08 100644 --- a/goals/selected/pike/python35.rst +++ b/goals/selected/pike/python35.rst @@ -118,7 +118,7 @@ Projects with Unit Tests Voting * aodh * barbican -* ceilomter +* ceilometer * cinder * cliff * congress diff --git a/goals/selected/stein/upgrade-checkers.rst b/goals/selected/stein/upgrade-checkers.rst index 8b4b4078a..a79e99fd8 100644 --- a/goals/selected/stein/upgrade-checkers.rst +++ b/goals/selected/stein/upgrade-checkers.rst @@ -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. diff --git a/reference/comparison-of-official-group-structures.rst b/reference/comparison-of-official-group-structures.rst index cfa28719b..160b73880 100644 --- a/reference/comparison-of-official-group-structures.rst +++ b/reference/comparison-of-official-group-structures.rst @@ -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) diff --git a/reference/role-of-the-tc.rst b/reference/role-of-the-tc.rst index 8386baebd..e38905161 100644 --- a/reference/role-of-the-tc.rst +++ b/reference/role-of-the-tc.rst @@ -45,7 +45,7 @@ in other TC-maintained documents. The current governance model institutes a two-level structure with :doc:`project teams ` 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 diff --git a/reference/tags/vulnerability_managed.rst b/reference/tags/vulnerability_managed.rst index 6c2b1c0cc..b28931c53 100644 --- a/reference/tags/vulnerability_managed.rst +++ b/reference/tags/vulnerability_managed.rst @@ -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 diff --git a/reference/upstream-investment-opportunities/2019/goal-champions.rst b/reference/upstream-investment-opportunities/2019/goal-champions.rst index 7118f1a29..a312ac85f 100644 --- a/reference/upstream-investment-opportunities/2019/goal-champions.rst +++ b/reference/upstream-investment-opportunities/2019/goal-champions.rst @@ -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