Typos/articles.

ContributorGuidelines.md

@@ -16,13 +16,13 @@ We write MicroPython in C not to keep writing code in C. We write it to let us a
 
 So, while we cannot achieve full CPython compatibility in MicroPython, we want to have as complete as possible, CPython-compatible standard library written in Python, there's a separate project for that: https://github.com/micropython/micropython-lib .
 
-But note that even micropython-lib has its pretty well defined scope: it's for Python standard library modules, plus, as an exception, to modules we consider to be part of "standard MicroPython library". micropython-lib is not intended to become the single destination (or an outright dump) of all modules MicroPython. Instead, we would like to achieve the same model as used by Python in general: there's a wide community, with multitude of modules maintained by individual members of it.
+But note that even micropython-lib has its pretty well defined scope: it's for Python standard library modules, plus, as an exception, for modules we consider to be a part of "standard MicroPython library". micropython-lib is not intended to become the single destination (or an outright dump) of all modules MicroPython. Instead, we would like to achieve the same model as used by Python in general: there's a wide community, with a multitude of modules maintained by individual members of it.
 
 Summing up, you have 3 choices where to contribute with MicroPython development:
 
 * MicroPython core
 * micropython-lib
-* Maintain your own module or port, as part of the general MicroPython community  
+* Maintain your own module or port, as a part of the general MicroPython community  
 
 So, it is worth considering where some change fits better. It may be not immediately obvious either, so may take some discussion, as described in the following section. 
 
@@ -35,11 +35,11 @@ If you're not sure if some change would go along with MicroPython approach, plea
 * [Project tickets](https://github.com/micropython/micropython/issues)
 * [Development forum](http://forum.micropython.org/viewforum.php?f=3)
 
-You may not agree with us on interpretation of a specific feature, so please share your point of view, and be prepared to elaborate and argue it - we're here to listen, and discussion is the way to run projects. But at the same time please keep in mind that we necessarily have to be conservative to achieve (and not lose on the way) project aims as stated in "What to contribute" section, so we may suggest better destination to apply your change/effort to, per "Where to contribute" section.
+You may not agree with us on interpretation of a specific feature, so please share your point of view, and be prepared to elaborate and argue it - we're here to listen, and discussion is the way to run projects. But at the same time please keep in mind that we necessarily have to be conservative to achieve (and not lose on the way) the project aims as stated in the "What to contribute" section, so we may suggest better destination to apply your change/effort to, per the "Where to contribute" section.
 
-We accept changes using Github pull requests, as the most seamless way for both ourselves and contributors. When you make commits for a change, please follow format of existing commit messages (use "git log" to review them). For considerable changes, we expect a detailed, yet formal and concise description of the change in commit message. If you make 2 or more considerable changes, they should go in separate commits. The same applies to unrelated changes - for example, don't put formatting changes and actual code changes in one commit. 
+We accept changes using Github pull requests, as the most seamless way for both ourselves and contributors. When you make commits for a change, please follow the format of existing commit messages (use "git log" to review them). For considerable changes, we expect a detailed, yet formal and concise description of the change in the commit message. If you make 2 or more considerable changes, they should go in separate commits. The same applies to unrelated changes - for example, don't put formatting changes and actual code changes in one commit. 
 
-When you submit a pull request, please make sure that it's understood why you propose this change: what problem it addresses, how it improves MicroPython (and at the same time, not deteriorates it, taking into account stringent constraints of "What to contribute" section). Good, detailed commit messages are an easy way to achieve this, and yet sometimes it's better to put informal points, colloquial arguments and big examples in comments to a pull request instead, to keep commit messages concise and focused.
+When you submit a pull request, please make sure that it's understood why you propose this change: what problem it addresses, how it improves MicroPython (and at the same time, not deteriorates it, taking into account stringent constraints of the "What to contribute" section). Good, detailed commit messages are an easy way to achieve this, and yet sometimes it's better to put informal points, colloquial arguments and big examples in comments to a pull request instead, to keep commit messages concise and focused.
 
 
 # "Django criteria"