Skip to content

Latest commit

 

History

History
86 lines (54 loc) · 5.24 KB

CONTRIBUTING.md

File metadata and controls

86 lines (54 loc) · 5.24 KB
Raw

Contributing

We expect contributors to abide by our underlying code of conduct. All conversations and discussions on GitHub (issues, pull requests) must be respectful and harassment-free.

If you feel another member of the community has violated our Code of Conduct, you may anonymously contact the team https://twimbit.typeform.com/to/M4MlG5uy.

Remember that communication is the lifeblood of any Open Source project. We are all working on this together, and we are all benefiting from this software. It's very easy to misunderstand one another over asynchronous, text-based conversations: When in doubt, assume everyone within this project has the best intentions.

We are all humans trying to work together to improve the community. Always be kind and appreciate the need for trade-offs. ❤️

Before making your first pull request or issue, give our this a full read:

Contributing to Monday Wordpress integration project

We expect contributors to abide by our underlying code of conduct. All discussions about this project must be respectful and harassment-free.

Remember that communication is the lifeblood of any Open Source project. We are all working on this together, and we are all benefiting from this software.

It's very easy to misunderstand one another in asynchronous, text-based conversations. When in doubt, assume everyone has the best intentions.

If you feel anyone has violated our Code of Conduct, you should anonymously contact the team with our abuse report form.

Where to contribute

All issues.

PRs without an associated issue may still be merged, but the core team will focus on changes that solve existing issues. We strongly encourage creating an issue before working on a PR!

When in doubt, ask a core team member by mentioning us on the issue.

How to contribute

  • Fork the project and clone it to your local machine. Follow the installation guide!
  • Create a branch with your GitHub username and the ID of the issue, for example: git checkout -b USERNAME/some-new-feature-1234
  • Code and commit your changes. Bonus points if you write a good commit message: git commit -m 'Add some feature'
  • Push to the branch: git push -u origin USERNAME/some-new-feature-1234
  • Create a pull request for your branch. 🎉

Contribution guidelines

Create an issue

Nobody's perfect. Something doesn't work? Something could be better? Check to see if the issue already exists, and if it does, leave a comment to get our attention! If the issue doesn't already exist, feel free to create a new one. A core team member will triage incoming issues.

Please note: core team members may update the title of an issue to reflect the discussion.

Create a pull request

  • Try to keep the pull requests small. A pull request should try its very best to address only a single concern.
  • For work in progress pull requests, please use the Draft PR feature.
  • Make sure all tests pass and add additional tests for the code you submit.
  • Document your reasoning behind the changes. Explain why you wrote the code in the way you did. The code should explain what it does.
  • If there's an existing issue, reference to it by adding something like References/Closes/Fixes/Resolves #123, where 123 is the issue number. More info here.
  • Please fill out the PR Template when making a PR.
  • All commits in a pull request will be squashed when merged. Please note: a core team member may close your PR if it has gone stale or if we don't plan to merge the code.

Pull request reviews

All community pull requests are reviewed by our core team.

  • All contributors must sign the CLA.
  • All required checks are expected to pass on each PR.
    • In the case of flaky or unrelated test failures, a core team member will restart CI.
  • We require 2 approvals from core team members for each PR.
  • Requested Changes must be resolved (with code or discussion) before merging.
  • If you make changes to a PR, be sure to re-request a review.
  • Style discussions are generally discouraged in PR reviews; make a PR to the linter configurations instead.
  • Your code will be deployed shortly after it is merged.

A note on "force pushing"

After you submit your pull request, one of the members of the core team will review your code.

Please avoid force pushing unless you need to rebase with the master branch.

If feedback is provided, any changes should be contained in new commits. Please don't force push or worry about squashing your commits.

Force pushing (despite being useful) has some drawbacks. GitHub doesn't always keep the review history, which results in lost context for the reviewers.

We squash every PR before merging, so there is no need to force push!

The bottom line

We are all humans trying to work together to improve the community. Always be kind and appreciate the need for tradeoffs. ❤️