development-practices/overview.md

 # Development Practices
 
+## Typical development process
+
 The typical development process on Samba looks like this:
 
 * A developer has a problem to solve. This might be fixing a [bug](https://bugzilla.samba.org),
@@ -11,11 +13,11 @@ There are a couple of benefits to this approach:
 	* It's standard practice in [Test-Driven Development (TDD)](https://en.wikipedia.org/wiki/Test-driven_development)
 to help prove that the new test-case works correctly. 
 	* It means `git bisect` can be run over the codebase, which can help to identify any degradations introduced to Samba.
-After any given commit, the Samba code will always compile, and always pass all tests.
+After any given commit, the Samba code will always compile, and will always pass all tests.
 * The developer then writes the code to fix the bug or implement the desired functionality.
 The _known failure_ status for the new tests is removed, the new tests are re-run, and this time they should all pass.
-* The developer should then run the full Continuous Integration (CI) test suites over their changes, to verify they haven't broken any existing functionality.
-The [Gitlab CI](https://gitlab.com/samba-team/devel/samba/pipelines) provides a convenient way to do this, although there are several other ways to do this.
+* The developer should then run the full Continuous Integration (CI) test suite over their changes, to verify they haven't broken any existing functionality.
+The [Gitlab CI](https://gitlab.com/samba-team/devel/samba/pipelines) provides a convenient way to do this, although there are several other approaches.
 * The developer should end up with a coherent set of patches that add the new functionality, along with tests that prove the new functionality works correctly.
 They then send the patch-set to the [samba-technical mailing-list](https://lists.samba.org/mailman/listinfo/samba-technical) for review.
 * The code is reviewed by a [Samba Team members](https://www.samba.org/samba/team). 
@@ -72,7 +74,7 @@ A bot runs on `sn-devel` four times per day and e-mails the [samba-cvs](https://
 This allows developers to see which tests, perhaps newly introduced, caused the failure.
 
 Tests can be marked as 'flapping' (either in [selftest/flapping](https://git.samba.org/?p=samba.git;a=blob;f=selftest/flapping) or [selftest/flapping.d](https://git.samba.org/?p=samba.git;a=tree;f=selftest/flapping.d)), which means the test case still gets run, but the test result is essentially ignored.
-Obviously, this practiced is discouraged as it reduces the usefulness of the test.
+Obviously, this practice is discouraged as it reduces the usefulness of the test.
 
 More work could be done to investigate these intermittent test failures and fix them.
 
@@ -87,7 +89,7 @@ Samba has a [guide for new developers](https://wiki.samba.org/index.php/Contribu
 which includes things like:
 * Each patch should be as small as possible, i.e. changes only one thing. This makes review easier.
 * The patch should have an appropriate commit description.
-* Patches that fix a bug contain an appropriate `BUG` tag.
+* Patches that fix a bug should contain an appropriate `BUG` tag.
 
 Samba has formal coding guidelines, as well as informal practices that Samba Team Members tend to enforce during review.
 
@@ -121,9 +123,9 @@ mandatory `Signed-off-by:` tags on every git commit.
 
 ### Informal coding guidelines
 
-As well as the formal coding standard, Samba Tema Members tend to enforce informal, common sense practices during review. 
+As well as the formal coding standard, Samba Team Members tend to enforce informal, common sense practices during review. 
 For example, the coding guidelines don't dictate specific naming conventions, but most Samba Team reviewers would suggest existing naming conventions are followed.
-For example, some commonly-used variables often just use an abbreviated from of the structure name:
+The general convention is that commonly-used variables just use an abbreviated form of the structure name, such as:
 
 ```c
 	struct ldb_result *res = NULL;