Contributing

About

We use a forking pull request workflow. If you're unfamilar with this check out GitHub's guide on forking for more information. Contributing to Obojobo looks like this:

1. If you haven't done already, fork the repo
2. Create an issue branch off a dev branch to work on your issue
3. When completed, verify your issue branch is complete (all tests pass with 100% coverage and there are no linting errors)
4. Submit a Pull Request
5. If approved, your PR will be merged into a dev branch for an upcoming release

Branch Structure

We very loosely follow GitFlow's method of organization. We use master, dev branches, issue branches and hotfix branches.

Master branch

• This is the production-ready current release branch.
• In general you should never branch off of master.

Dev (release) branches

• These are development branches from which all issues are based off of. Each one constitutes a release. The naming convention is dev/NUMBER-CODENAME, for example dev/6-lapis-lazuli.
• Dev branches change often and may contain bugs or breaking features.
• When developing you'll branch off of a main dev branch.

Issue branches

• All work is handled on issue branches. The naming convention is issue/ISSUE_NUMBER-ISSUE_SUMMARY, for example issue/848-survey-nongraded-questions.
• The issue summary ideally should be succinct but give you enough information to have an idea what the issue is for without having to look up the issue number.

Hotfix branches

• Hotfix branches are reserved to update master if a bug or high-priority need is discovered. The naming convention is hotfix/ISSUE_NUMBER-HOTFIX_SUMMARY, for example hotfix/824-caliper-js-repo-moved.
• Note that the issue number may sometimes be left out.

Pull Requests

• When finished, submit a Pull Request on the main repo, targeting a dev branch.
• Note that the core team may target a different release depending on the needs of the project
• PRs must be reviewed by two core developers before it is approved and merged into a dev branch