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, Trello, CircleCI aggregated into three feeds for development of the libraries, generic modules, and example apps.
Join the team
- Request Slack team access: Provide an email address via private message to either @rhyslbw or @DominikGuzei on Gitter.
- Check out the Trello boards to get up to speed on current development
Style
- We use git-flow so always branch from and target develop, which is the upcoming release of the package.
git-flow Cheat Sheet
A successful Git branching model
Code quality tools in the future
We'll be implementing tools to make this dead simple in the near future
- Keep to 80 characters or less per line of code, make the code expressive:
Patching
File an issue in the relevant repo on GitHub, fork it, create a hot-fix branch, ensure tests are passing, then submit a PR against the Meteor-Space develop branch with your fix.
Write a test to cover any overlooked scenarios
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.
Test standards
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.
Meteor Git Packages (MGP) for pre-release dependencies
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. If anyone wants to take that on you'd be making a huge contribution!
Failing tests on local machine?
Run
mgp
instead of 'mgp-link' to ensure you have the correct version checked out in your local environment.
New git repositories checklist
- Add Repository to Slack integrations for GitHub and CircleCI
- CircleCI configured, badge added to Readme
- Package versions standard based on SemVer, starting at 0.1.0
- Add new label 'WIP' for PRs that are not yet ready for merging
Updated less than a minute ago