Articles, etc.

ContributorGuidelines.md

@@ -8,11 +8,11 @@ Here are more specific examples:
 
 2. It may seem that the "unix" port would not be affected by such stringent requirements, and yet it is, because one of the usecases is running MicroPython on truly minimal Linux systems with just 4 or even 2Mb of flash, half of which is taken by the kernel, remaining half by support utilities, and only mere hundreds of Ks are available for MicroPython, user apps, and data. So, every byte is still accounted for.
 
-3. MicroPython is not the only small, embeddable language, so we need to stay competitive in this niche. Well-known small language is Lua, and we take it as an assessment baseline. It's our belief that many people use Lua due to lack of a better choice. With MicroPython, there's now a good alternative. But we don't want people to reject MicroPython because it's "much bigger" than Lua. Note that it's necessarily bigger, because Python provides more standardized and well-defined functionality. But we want to stay at "somewhat bigger", and not "much bigger" mark. Actually, we want to maintain "minimal" MicroPython configuration, which achieves sizes comparable, or better, than typical non-fine-tuned Lua builds. 
+3. MicroPython is not the only small, embeddable language, so we need to stay competitive in this niche. Well-known small language is Lua, and we take it as an assessment baseline. It's our belief that many people use Lua due to lack of a better choice. With MicroPython, there's now a good alternative. But we don't want people to reject MicroPython because it's "much bigger" than Lua. Note that it's necessarily bigger, because Python provides more standardized and well-defined functionality. But we want to stay at "somewhat bigger", and not "much bigger" mark. Actually, we want to maintain "minimal" MicroPython configuration, which achieves sizes comparable, or better, than typical non fine-tuned Lua builds. 
 
 # Where to contribute
 
-We write MicroPython in C not to keep writing code in C. We write it to let us and everyone write code in Python. This should be good rule of thumb - anything which can be written in Python, should be written in Python, unless there're *really* good reasons to write it in C. 
+We write MicroPython in C not to keep writing code in C. We write it to let us and everyone write code in Python. This should be a good rule of thumb - anything which can be written in Python, should be written in Python, unless there're *really* good reasons to write it in C. 
 
 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 .
 
@@ -22,7 +22,7 @@ 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 general MicroPython community  
+* Maintain your own module or port, as 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.