Tweaks to "How to contribute"

master
pfalcon 2014-12-11 08:50:55 -08:00
rodzic d1e5bfafb7
commit 6c6812a855
1 zmienionych plików z 2 dodań i 2 usunięć

@ -18,14 +18,14 @@ Summing up, you have 3 choices where to contribute with MicroPython development:
# How to contribute
Please make sure you read previous sections to understand MicroPython philosophy and approach. We expect contributors will be aligned with them on general matters, because otherwise it would be hard to understand why specific change is proposed at all.
Please make sure you read previous sections to understand MicroPython philosophy and approach. We expect contributors will be aligned with them in general, because otherwise it would be hard to understand why specific change is proposed at all.
If you're not sure if some change would go along with MicroPython approach, please discuss this change first. We have 2 channels of communication:
* Project tickets
* [Development forum](http://forum.micropython.org/viewforum.php?f=3)
You may not agree with us on interpretation of specific feature, please share your point of view, and be prepared to elaborate and argue it. But 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.
You may not agree with us on interpretation of 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.
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 detailed, yet formal and concise description in of the change in commit messages. 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.