Skip to content

Latest commit

 

History

History
37 lines (27 loc) · 3.48 KB

CONTRIBUTING.md

File metadata and controls

37 lines (27 loc) · 3.48 KB
Raw

Commits

  • Follow the template of while creating issues and before making a PR.
  • Write clear meaningful git commit messages (Do read http://chris.beams.io/posts/git-commit/)
  • Make sure your PR's description contains GitHub's special keyword references that automatically close the related issue when the PR is merged. (More info at https://github.com/blog/1506-closing-issues-via-pull-requests )
  • When you make very very minor changes to a PR of yours (like for example fixing a failing travis build or some small style corrections or minor changes requested by reviewers) make sure you squash your commits afterwards so that you don't have an absurd number of commits for a very small fix. (Learn how to squash at https://davidwalsh.name/squash-commits-git )
  • When you're submitting a PR for a UI-related issue, it would be really awesome if you add a screenshot of your change or a link to a deployment where it can be tested out along with your PR. It makes it very easy for the reviewers and you'll also get reviews quicker.
  • Collective Code Construction Contract (https://rfc.zeromq.org/spec:42/C4/)

Feature Requests and Bug Reports

  • When you file a feature request or when you are submitting a bug report to the issue tracker, make sure you add steps to reproduce it. Especially if that bug is some weird/rare one.

Join the development

  • Before you join development, please set up the system on your local machine and go through the application completely. Press on any link/button you can find and see where it leads to. Explore. (Don't worry ... Nothing will happen to the app or to you due to the exploring 😉 Only thing that will happen is, you'll be more familiar with what is where and might even get some cool ideas on how to improve various aspects of the app.)
  • If you would like to work on an issue, drop in a comment at the issue. If it is already assigned to someone, but there is no sign of any work being done, please free to drop in a comment so that the issue can be assigned to you if the previous assignee has dropped it entirely.

Do read the Open Source Developer Guide and Best Practices at FOSSASIA.

Review Policy

Pull requests must be reviewed before merge. The goal is to have two people review the pull request. With this we want to spread the knowledge about the project and encourage positive feedback.

  • A pull-request with two positive reviews of contributors should be merged by the last reviewer and can be merged by anyone with write access.
  • A pull-request with one positive review of contributors can be merged after 24 hours by anyone with write access.
  • A pull-request with no positive review can be merged after three days by anyone with write access.

Merging Pull Requests

  • These MUST apply for your pull request to be merged:
    • you provide a screenshot of the working webapp or the link to the webapp.
    • the build passes
  • Your Pull request can be merged within 24 hours if you get a positive review.
  • Your Pull request can be merged after 24 hours of the last commit and last comment if no maintainer responded.

If the pull request creates a problem, the first person to recognize it should revert the pull requests as soon as possible.

Note that this does not clarify what to do if there a negative reviews. The goal is again to spread knowledge and feedback but also prevent frustration and stagnation of the project.