Skip to content

Latest commit

 

History

History
68 lines (46 loc) · 3.58 KB

CONTRIBUTING.md

File metadata and controls

68 lines (46 loc) · 3.58 KB
Raw

CONTRIBUTING - Draft

This project has a Code of Conduct that we expect all of our contributors to abide by, please check it out before contributing.

Contributor license agreement

By submitting code as an individual or as an entity you agree that your code is licensed the same as the Digital Paper Edit.

Pull requests and branching

  1. Feel free to start by raising an issue so that others can be aware of areas where there is active development, and if needed we can synchronies the effort.

  2. Fork the repo

  3. Before working on a feature always create a new branch first. Createa a branch with a meaningful name.

  4. Branches should be short lived - consider doing multiple PR breaking down functionalities as opposed to one big change.

  5. If you've added code that should be tested, add tests, if you need help with automated testing, feel free to raise an issue.

  6. Ensure the test suite passes.

  7. Make sure your code lints.

  8. If you've changed APIs, consider updating the documentation and QA Testing docs.

  9. Once the work is complete push the branch up on to GitHub for review. Make sure your branch is up to date with master before making a pull request. eg use git merge origin/master or rebase

  10. Once a branch has been merged into master, delete it.

master is rarely committed to directly unless the change is quite trivial or a code review is unnecessary (code formatting or documentation updates for example).

Code Quality

  • Aim for solutions that are easy to explain and reason around so that others can contribute to it.
  • Use meaningfull descriptive variables and function names. eg avoid using x,y,z as variable names.
  • Keep lines short
  • Keep functions small and avoid side effects when possible.
  • etc..

See this blog post for more on this

Contributing checklist

  • Fork the repository
  • Create a branch with a meaningful name
  • Add automated tests where appropriate
  • Ensure test suite passes (npm run test)
  • Make sure your code lints. (npm run lint)
  • consider re-factoring for code quality and readability
  • Update documentation and QA docs where appropriate - see updating the documentation
  • Setup your PR for review

Releases

(for the Labs team)

  1. Once a PR has been merged that constitutes a new version release, ensure a commit labelling it (with semantic versioning)
  2. Create a new release on GitHub. Make sure there is a version tag (eg. v1.2.1) and a release title of the same.
  3. (If necessary, check the pre-release)
  4. Publish to NPM, via npm run publish:public.