{"_id":"560e3d7ec1873e17005a26ca","githubsync":"","project":"56000f0d8c0c9d0d00dcad21","category":{"_id":"56000f0e8c0c9d0d00dcad25","pages":["56000f0f8c0c9d0d00dcad27","560e3d55c4e4ae0d00b42ed2","560e3d63c1873e17005a26c8","560e3d7ec1873e17005a26ca","560e3d8fcac9dc0d007af7b7","5613396904683b0d0087bd73","56240619d51d480d0064fcc9"],"project":"56000f0d8c0c9d0d00dcad21","version":"56000f0e8c0c9d0d00dcad24","__v":7,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-09-21T14:07:10.742Z","from_sync":false,"order":0,"slug":"prologue","title":"Prologue"},"version":{"_id":"56000f0e8c0c9d0d00dcad24","project":"56000f0d8c0c9d0d00dcad21","__v":13,"createdAt":"2015-09-21T14:07:10.176Z","releaseDate":"2015-09-21T14:07:10.176Z","categories":["56000f0e8c0c9d0d00dcad25","56008f2497f69f1700f21a36","560091601503430d007cc936","560e0d8054af2b0d005bbe92","560e3ce7ad6b200d00ff471c","560e3cf2c4e4ae0d00b42ed1","561c81d0e822e12b00e1fe00","561c81e9e822e12b00e1fe01","561c823d20b4a92b007d5147","56257f8951bf1c0d001f660a","562d5f165bd25e0d0054dbd4","562d68d5d38b650d0044472a","56421aebb0dc090d00f88438"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"__v":36,"user":"5600910981a9670d006d144f","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-10-02T08:17:02.988Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":3,"body":"We are crafting a collaborative development workflow to make it simple for people to get involved with _Space_ development, for the team to continuously improve the implementation experience, and expand the generic module offerings for faster app implementations.\n\nSlack is our base, with notifications from [GitHub](https://github.com/meteor-space/), [Trello](https://trello.com/meteorspace), CircleCI aggregated into three feeds for development of the _libraries_, _generic modules_, and _example apps_.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Join the team\"\n}\n[/block]\n1. Request Slack team access: Provide an email address via private message to either :::at:::rhyslbw or @DominikGuzei on [Gitter](https://gitter.im/meteor-space/general).\n2. Check out the [Trello](https://trello.com/meteorspace) boards to get up to speed on current development\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Style\"\n}\n[/block]\n- We use [git-flow](https://github.com/nvie/gitflow) so always branch from and target _develop_, which is the upcoming release of the package.\n\n[git-flow Cheat Sheet](http://danielkummer.github.io/git-flow-cheatsheet/)\n[A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/)\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Code quality tools in the future\",\n  \"body\": \"We'll be implementing tools to make this dead simple in the near future\"\n}\n[/block]\n- Keep to 80 characters or less per line of code, make the code expressive:\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Patching\"\n}\n[/block]\nFile an issue in the relevant repo on GitHub, fork it, create a [hot-fix branch](http://danielkummer.github.io/git-flow-cheatsheet/#hotfixes), ensure tests are passing, then submit a PR against the Meteor-Space develop branch with your fix.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Write a test to cover any overlooked scenarios\",\n  \"body\": \"While the packages have good test coverage and we only publish with a passing build, if you're submitting a patch it's likely that a scenario has been overlooked. If this is the case, adding a test that will initially fail that will then pass once the change is made is a great way to document the reason for the patch, and improves the test suite.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Test standards\"\n}\n[/block]\nThe library packages being closer to the metal are covered by unit tests, whereas the pattern packages are moving towards an exclusive focus on integration testing since we have a solid foundation with messaging. We feel unit tests here are mostly superfluous, can cause an information overload for a new user, and can be brittle which hampers refactoring efficiency. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Meteor Git Packages (MGP) for pre-release dependencies\"\n}\n[/block]\nIf you need to depend on a specific branch of another repo, for local development use a local package defined in _local-packages.json_ brought in via `mgp link`, and specify a commit hash in _git-packages.json_ to keep the build gree, as it's [not possible to specify a branch from a git repo](https://github.com/DispatchMe/mgp/issues/32). If anyone wants to take that on you'd be making a huge contribution!\n\n\n[Getting started](https://github.com/DispatchMe/mgp#getting-started) \n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Failing tests on local machine?\",\n  \"body\": \"Run `mgp` instead of 'mgp-link' to ensure you have the correct version checked out in your local environment.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"New git repositories checklist\"\n}\n[/block]\n- Add Repository to Slack integrations for GitHub and CircleCI\n- CircleCI configured, badge added to Readme \n- Package versions standard based on [SemVer](http://semver.org/), starting at 0.1.0\n- Add new label 'WIP' for PRs that are not yet ready for merging","excerpt":"Join us!","slug":"contribution-guide","type":"basic","title":"Contribution Guide"}

Contribution Guide

Join us!

We are crafting a collaborative development workflow to make it simple for people to get involved with _Space_ development, for the team to continuously improve the implementation experience, and expand the generic module offerings for faster app implementations. Slack is our base, with notifications from [GitHub](https://github.com/meteor-space/), [Trello](https://trello.com/meteorspace), CircleCI aggregated into three feeds for development of the _libraries_, _generic modules_, and _example apps_. [block:api-header] { "type": "basic", "title": "Join the team" } [/block] 1. Request Slack team access: Provide an email address via private message to either @rhyslbw or @DominikGuzei on [Gitter](https://gitter.im/meteor-space/general). 2. Check out the [Trello](https://trello.com/meteorspace) boards to get up to speed on current development [block:api-header] { "type": "basic", "title": "Style" } [/block] - We use [git-flow](https://github.com/nvie/gitflow) so always branch from and target _develop_, which is the upcoming release of the package. [git-flow Cheat Sheet](http://danielkummer.github.io/git-flow-cheatsheet/) [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/) [block:callout] { "type": "info", "title": "Code quality tools in the future", "body": "We'll be implementing tools to make this dead simple in the near future" } [/block] - Keep to 80 characters or less per line of code, make the code expressive: [block:api-header] { "type": "basic", "title": "Patching" } [/block] File an issue in the relevant repo on GitHub, fork it, create a [hot-fix branch](http://danielkummer.github.io/git-flow-cheatsheet/#hotfixes), ensure tests are passing, then submit a PR against the Meteor-Space develop branch with your fix. [block:callout] { "type": "info", "title": "Write a test to cover any overlooked scenarios", "body": "While the packages have good test coverage and we only publish with a passing build, if you're submitting a patch it's likely that a scenario has been overlooked. If this is the case, adding a test that will initially fail that will then pass once the change is made is a great way to document the reason for the patch, and improves the test suite." } [/block] [block:api-header] { "type": "basic", "title": "Test standards" } [/block] The library packages being closer to the metal are covered by unit tests, whereas the pattern packages are moving towards an exclusive focus on integration testing since we have a solid foundation with messaging. We feel unit tests here are mostly superfluous, can cause an information overload for a new user, and can be brittle which hampers refactoring efficiency. [block:api-header] { "type": "basic", "title": "Meteor Git Packages (MGP) for pre-release dependencies" } [/block] If you need to depend on a specific branch of another repo, for local development use a local package defined in _local-packages.json_ brought in via `mgp link`, and specify a commit hash in _git-packages.json_ to keep the build gree, as it's [not possible to specify a branch from a git repo](https://github.com/DispatchMe/mgp/issues/32). If anyone wants to take that on you'd be making a huge contribution! [Getting started](https://github.com/DispatchMe/mgp#getting-started) [block:callout] { "type": "warning", "title": "Failing tests on local machine?", "body": "Run `mgp` instead of 'mgp-link' to ensure you have the correct version checked out in your local environment." } [/block] [block:api-header] { "type": "basic", "title": "New git repositories checklist" } [/block] - Add Repository to Slack integrations for GitHub and CircleCI - CircleCI configured, badge added to Readme - Package versions standard based on [SemVer](http://semver.org/), starting at 0.1.0 - Add new label 'WIP' for PRs that are not yet ready for merging