Spelling and grammar corrections

Change-Id: I38ba5a9145764357f0416b5c6f42e1204332ba5a
Signed-off-by: Kyle Mestery <mestery@mestery.com>

diff --git a/doc/source/policies/bugs.rst b/doc/source/policies/bugs.rst
index 0c3b4fc3f20c227832434f74d255e53647e54f52..95032bb9ddc6e20043e301d35b37006d31aecc43 100644 (file)
--- a/doc/source/policies/bugs.rst
+++ b/doc/source/policies/bugs.rst
@@ -67,10 +67,10 @@ the plugin/driver repo should not have Neutron in the affected projects section.
 However, you should add Neutron (Or any other project) to that list only if you
 expect that a patch is needed to that repo in order to solve the bug.
 
-It also worth adding that that some of these projects are part of the so
+It's also worth adding that some of these projects are part of the so
 called Neutron `stadium <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
 Because of that, their release is managed centrally by the Neutron
-release team; requests for releases need to funnelled and screened
+release team; requests for releases need to be funnelled and screened
 properly before they can happen. To this aim, the process to request a release
 is as follows:
 
@@ -105,7 +105,7 @@ Bug Report Template
 ~~~~~~~~~~~~~~~~~~~
 
 The more information you provide, the higher the chance of speedy triaging and
-resolution: identifing the problem is half the solution. To this aim, when
+resolution: identifying the problem is half the solution. To this aim, when
 writing a bug report, please consider supplying the following details and
 following these suggestions:
 
@@ -158,7 +158,7 @@ following these suggestions:
   This does not mean you are gonna get the backport, as the stable team needs
   to follow the `stable branch policy <https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy>`_
   for merging fixes to stable branches.
-* Attachments: consider attaching logs, truncated log snippets are seldomly
+* Attachments: consider attaching logs, truncated log snippets are rarely
   useful. Be proactive, and consider attaching redacted configuration files
   if you can, as that will speed up the resolution process greatly.
 
@@ -175,7 +175,7 @@ The process of bug triaging consists of the following steps:
   as a duplicate of the previous bug.
 * Check if the bug meets the requirements of a good bug report, by checking
   that the guidelines_ are being followed. Omitted information is still
-  acceptable if the issue is clear nonethless; use your good judgement and
+  acceptable if the issue is clear nonetheless; use your good judgement and
   your experience. Consult another core member/PTL if in doubt. If the bug
   report needs some love, mark the bug as 'Incomplete', point the submitter
   to this document and hope he/she turns around quickly with the missing