diff --git a/HACKING.rst b/HACKING.rst
index fd63d64..8fbc9bb 100644
--- a/HACKING.rst
+++ b/HACKING.rst
@@ -36,11 +36,11 @@
 
 In most cases the very first issue is the most important information.
 
-Try to avoid using ``try`` blocks in the test cases, both the ``except``
-and ``finally`` block could replace the original exception,
+Try to avoid using ``try`` blocks in the test cases, as both the ``except``
+and ``finally`` blocks could replace the original exception,
 when the additional operations leads to another exception.
 
-Just letting an exception to propagate, is not bad idea in a test case,
+Just letting an exception to propagate, is not a bad idea in a test case,
 at all.
 
 Try to avoid using any exception handling construct which can hide the errors
@@ -54,10 +54,10 @@
 exceptions and still ensure resources are correctly cleaned up if the
 test fails part way through.
 
-Use the ``self.assert*`` methods provided by the unit test framework
-the signal failures early.
+Use the ``self.assert*`` methods provided by the unit test framework.
+This signals the failures early on.
 
-Avoid using the ``self.fail`` alone, it's stack trace will signal
+Avoid using the ``self.fail`` alone, its stack trace will signal
 the ``self.fail`` line as the origin of the error.
 
 Avoid constructing complex boolean expressions for assertion.
@@ -69,7 +69,7 @@
 Most other assert method can include more information by default.
 For example ``self.assertIn`` can include the whole set.
 
-Recommended to use testtools matcher for more tricky assertion.
+It is recommended to use testtools matcher for the more tricky assertions.
 `[doc] <http://testtools.readthedocs.org/en/latest/for-test-authors.html#matchers>`_
 
 You can implement your own specific matcher as well.
@@ -77,8 +77,8 @@
 
 If the test case fails you can see the related logs and the information
 carried by the exception (exception class, backtrack and exception info).
-This and the service logs are your only guide to find the root cause of flaky
-issue.
+This and the service logs are your only guide to finding the root cause of flaky
+issues.
 
 Test cases are independent
 --------------------------
@@ -87,7 +87,7 @@
 
 Test cases MAY depend on commonly initialized resources/facilities, like
 credentials management, testresources and so on. These facilities, MUST be able
-to work even if just one ``test_method`` selected for execution.
+to work even if just one ``test_method`` is selected for execution.
 
 Service Tagging
 ---------------