Skip to content

Latest commit

 

History

History
32 lines (27 loc) · 3.94 KB

PR_GUIDELINES.md

File metadata and controls

32 lines (27 loc) · 3.94 KB
Raw

Pull Request Guidelines

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

In order to give everyone a chance to submit a pull request and contribute to the Talawa project, we have put restrictions in place. This section outlines the guidelines that should be imposed upon pull requests in the Talawa project.

Pull Requests and Issues

  1. Do not start working on any open issue and raise a PR unless the issue is assigned to you. PRs that don't meet these guidelines will be closed.
  2. Pull requests must be based on open issues available.
  3. Use this method to automatically close the issue when the PR is completed.

Testing

  1. All pull requests must have test units. If, for some reason, it is not possible to add tests, please let us know and explain why. In that case, you'll need to tell us what steps you followed to manually test your changes.
  2. Please read our CONTRIBUTING.md document for details on our testing policy.

Pull Request Processing

These are key guidelines for the procedure:

  1. We do not accept draft Pull Requests. They will be closed if submitted. We focus on work that is ready for immediate review.
  2. Removing assigned reviewers from your Pull Request will cause it to be closed. The quality of our code is very important to us. Therefore we make experienced maintainers of our code base review your code. Removing these assigned persons is not in the best interest of this goal.
  3. If you have not done so already, please read the Pull Requests and Issues and Testing sections above.
  4. Each contributor may only create one pull request at a time. We have this rule in place due to our limited resources - if everyone was allowed to post multiple pull requests, we would not be able to review them properly. It is also better for contributors because you can focus on creating one quality PR - so spend time making sure it is as good as it can be.
  5. Upon successful push to the fork, check if all tests are passing; if not, fix the issues and then create a pull request.
  6. If the pull request's code quality is not up to par, or it would break the app, it will more likely be closed. So please be careful when creating a PR.
  7. Please follow the PR template provided. Ensure the PR title clearly describes the problem it is solving. In the description, include the relevant issue number, snapshots, and videos after changes are added.
  8. If you are borrowing a code, please disclose it. It is fine and sometimes even recommended to borrow code, but we need to know about it to assess your work. If we find out that your pull request contains a lot of code copied from elsewhere, we will close the pull request.
  9. No Work In Progress. ONLY completed and working pull requests and with respective test units will be accepted. A WIP would fall under rule 4 and be closed immediately.
  10. Please do not @mention contributors and mentors. Sometimes it takes time before we can review your pull request or answer your questions, but we'll get to it sooner or later. @mentioning someone just adds to the pile of notifications we get and it won't make us look at your issue faster.
  11. Do not force push. If you make changes to your pull request, please simply add a new commit, as that makes it easy for us to review your new changes. If you force push, we'll have to review everything from the beginning.
  12. PR should be small, easy to review and should follow standard coding styles.
  13. If PR has conflicts because of recently added changes to the same file, resolve issues, test new changes, and submit PR again for review.
  14. PRs should be atomic. That is, they should address one item (issue or feature)
  15. After submitting PR, if you are not replying within 48 hours, then in that case, we may need to assign the issue to other contributors based on the priority of the issue.