github/meteor
1
1
Fork 0
mirror of https://github.com/meteor/meteor.git synced 2026-05-02 03:01:46 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #7019 from abernix/spelling-typos

Browse Source 
[docs] Spelling corrections on Contributing.md
This commit is contained in:
Tom Coleman
2016-05-10 15:03:17 -07:00
parent 1b94e0fc46 0270d75b56
commit fac2809e33
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Contributing.md
View File

@@ -71,13 +71,13 @@ month. We use our [roadmap](Roadmap.md) to communicate the high level features
Every additional feature adds a maintenance cost in addition to its value. This
cost starts with the work of writing the feature or reviewing a community pull
request. In addition to the core code change, attention needs to be paid to
documentation, tests, maintability, how the feature interacts with existing and
documentation, tests, maintainability, how the feature interacts with existing and
speculative Meteor features, cross-browser/platform support, user experience/API
considerations, etc. Once the feature is shipped, it then becomes the community's responsibility to fix future bugs related to the feature. In case the original author disappears, it's important that the feature has good tests and is widely used in order to be maintainable by other contributors.
For these reasons, we strongly encourage features to be implemented as [Atmosphere or npm packages](http://guide.meteor.com/writing-packages.html) rather than changes to core. Try to re-work your feature request as a minimal set of hooks to core that enable the feature to be implemented as a package.
Feature requests should be well specified and un-ambigous to have the greatest chance of being worked on by a contributor.
Feature requests should be well specified and unambiguous to have the greatest chance of being worked on by a contributor.
Finally, you can show your support for features you would like by commenting with a +1 or up-voting the issue.
@@ -128,7 +128,7 @@ incredibly rewarding. We hope you come to feel the same way.
You'll have the best chance of getting a change into core if you can build consensus in the community for it. Start by creating a well specified feature request as a Github issue.
Help drive discussion and advocate for your feature on the Github ticket (and perhaps the forums). The higher the demand for the feature and the greater the clarity of it's specification will determine the likelyhood of a core contributor prioritizing your feature by flagging it with the `pull-requests-encouraged` label.
Help drive discussion and advocate for your feature on the Github ticket (and perhaps the forums). The higher the demand for the feature and the greater the clarity of it's specification will determine the likelihood of a core contributor prioritizing your feature by flagging it with the `pull-requests-encouraged` label.
Split features up into smaller, logically seperable chunks. It is unlikely that large and complicated PRs will be merged.