mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add link to project tracker

pfalcon 2014-12-21 14:45:19 -08:00
parent 25560b244f
commit e634c784a1
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ContributorGuidelines.md

@ -30,11 +30,11 @@ Please make sure you read previous sections to understand MicroPython philosophy
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
* [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 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 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.
When you submit 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 commit messages are easy way to achieve this, but sometimes it's better to put informal points, colloquial arguments and big examples in comments to pull request instead, to keep commit messages concise and focused.
When you submit 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 commit messages are easy way to achieve this, but sometimes it's better to put informal points, colloquial arguments and big examples in comments to pull request instead, to keep commit messages concise and focused.