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

@@ -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:

goals/selected/pike/python35.rst

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

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.
 

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)

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 <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

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

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