Merge "Fix typos in governance"

goals/queens/split-tempest-plugins.rst

@@ -1,7 +1,7 @@
 .. -*- mode: rst -*-
 
 ==================================================
-Split Tempest Plugins into Seperate Repos/Projects
+Split Tempest Plugins into Separate Repos/Projects
 ==================================================
 
 Tempest plugins rely on setuptools entrypoints and therefore can be included
@@ -69,7 +69,7 @@ Completion Criteria
 
 For all projects with a bundled tempest plugin:
 
-#. Create a new seperate repo for the tempest plugin
+#. Create a new separate repo for the tempest plugin
 #. Migrate all the functionality from the bundled plugin to the new repo
 #. Switch gating jobs to use the new plugin project instead of the bundled one
 #. Delete the bundled tempest plugin from the project repo
@@ -85,7 +85,7 @@ https://etherpad.openstack.org/p/tempest-separate-plugin
 References
 ==========
 
-The tempest documentation elaborates on why seperate plugins are a better
+The tempest documentation elaborates on why separate plugins are a better
 pattern:
 
 http://docs.openstack.org/developer/tempest/plugin.html#standalone-plugin-vs-in-repo-plugin

reference/cti/golang_cti.rst

@@ -10,7 +10,7 @@ for Python repos is re-used here.
 A major criteria here is to not create an environment that is totally
 foreign to what developers are accustomed to in their respective
 communities.  Remember these are first OpenStack projects
-and they follow OpenStack processes where feasable.
+and they follow OpenStack processes where feasible.
 
 Each golang project must be able to do:
 

resolutions/20170329-golang-use-case.rst

@@ -86,7 +86,7 @@ The Rackspace cloud files team started experimenting with using Golang and from
 that the Hummingbird project was born. Today, Hummingbird serves as a very good
 proof of concept that we can solve all the problems that have been mentioned in
 a timely manner. Yes, the Swift team will still need to re-write the Object
-server, but a signficant amount of that work has already been done, plus it has
+server, but a significant amount of that work has already been done, plus it has
 been show to already work in production with excellent performance and
 scalability results [4]_.
 

resolutions/20170404-vision-2019.rst

@@ -8,7 +8,7 @@ March 2019, looking back at what the OpenStack Technical Committee has been
 involved with over the last few years. The aim is to describe an aspirational
 yet realistic end goal. It doesn't intend to list out all the tasks needed to
 reach the end goal, nor does it intend to stop evolving the direction as the
-enviroment changes between now and 2019.
+environment changes between now and 2019.
 
 .. note::
 

resolutions/20170425-drop-tc-weekly-meetings.rst

@@ -89,7 +89,7 @@ makes it clear when something will be debated so people can join in that
 debate, and the debate is clearly recorded in the meeting logs.
 
 Using the current meeting format and agendas for debate artificially limits the
-bandwidth to what can be agreed within one hour a week. Loosing this restriction
+bandwidth to what can be agreed within one hour a week. Losing this restriction
 should allow for much higher bandwidth, if we are successful.
 
 While email and gerrit conversations provide a good asynchronous mechanism to