Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
123 lines (89 loc) · 3.67 KB

CONTRIBUTING.md

File metadata and controls

123 lines (89 loc) · 3.67 KB

Contributing to Polygon-Views

This document contains a set of guidelines to help you during the contribution process. Please review it in order to ensure a fast and effective response from the maintainers.

General questions

For general questions you can look the [documentation] to learn more about the library and find some examples. If you have questions which are not covered by the documentation, please contact one of the maintainers:

Submitting contributions

We are glad to receive code contributions in the form of patches, improvements and new features. Below you will find the process and workflow used to review and merge your changes.

Step 0: Preparing the contribution

If you want to contribute a new feature or code improvement, contact one of the maintainers first and discuss your approach.

Step 1: Branch

Create a new branch from develop and choose an name which describes your contribution.

git checkout -b contribution-name

Step 2: Code

  • Document your changes: Add or update the relevant entries for your change in the documentation to reflect your work and inform the users about it.

  • Add unit tests: If you add or modify functionality, it must include unit tests. Prefer snapshot-tests when no logic is included.

Step 3: Commit

Try to commit as often as you can, keeping your changes logically grouped within individual commits. Generally it's easier to review changes that are split across multiple commits.

git add changed-file-1 changed-file-2
git commit

A good commit message should describe what changed and why. Follow these guidelines when writing one:

  1. Use the imperative, present tense: "change" not "changed" nor "changes"
  2. The first line should contain a short description of the change in 50 characters or less.
  3. Do not end the description with a dot
  4. The description must be in lowercase
  5. Use the format <type>(<scope>): <subject>, where scope is optional and refers to the subsystem changed and type could be:
    • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
    • docs: Documentation only changes
    • feat: A new feature
    • fix: A bug fix
    • refactor: A code change that neither fixes a bug nor adds a feature
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    • test: Adding missing or correcting existing tests
  6. Keep the second line blank
  7. If necessary, use the rest of the message to explain the change in detail
  8. Wrap the message's body at 72 columns

Step 4: Rebase

Rebase your branch to include the latest work on your branch.

git fetch origin
git rebase -i origin/develop

In case a conflict occurs, please resolve it and then use the following command to continue with the rebase.

git rebase --continue

Step 5: Test

Bug fixes and features should have tests and not break tested code. Run the test suite and make sure all tests pass. Run the linter to verify your code follows the coding style and conventions. Please do not submit changes that fail either check.

npm run test
npm run lint

Step 6: Push

When your work is ready and complies with the project conventions, upload your changes to your fork:

git push origin <branch-name>

Step 7: Pull request

Open a new Pull Request from your working branch to develop. Write about the changes and add any relevant information to the reviewer.

Step 8: Review and approval

When the changes have been approved, you can merge the changes to develop. The release will be performed by the maintainers.