Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

CONTRIBUTING: Advertise Git guide more clearly.

This commit is contained in:
Tim Abbott 2022-03-01 12:51:29 -08:00
parent 67870090f5
commit ee7f56724b
1 changed files with 18 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
CONTRIBUTING.md
View File

@ -189,11 +189,6 @@ below.
### Submitting a pull request ### Submitting a pull request
If it helps your workflow, you can make a pull request before your work is
ready for review, and we encourage you to do so. Simply prefix the title of
work in progress pull requests with `[WIP]`, and then remove the prefix when
you think it's time for someone else to review your work.
When you believe your code is ready, follow the [guide on how to review When you believe your code is ready, follow the [guide on how to review
code](https://zulip.readthedocs.io/en/latest/contributing/code-reviewing.html#how-to-review-code) code](https://zulip.readthedocs.io/en/latest/contributing/code-reviewing.html#how-to-review-code)
to review your own work. You can often find things you missed by taking a step to review your own work. You can often find things you missed by taking a step
@ -201,17 +196,29 @@ back to look over your work before asking others to do so. Catching mistakes
yourself will help your PRs be merged faster, and folks will appreciate the yourself will help your PRs be merged faster, and folks will appreciate the
quality and professionalism of your work. quality and professionalism of your work.
Once you are satisfied with the quality of your PR, follow the [guidelines on Then, submit your changes. Carefully reading our [Git guide][git-guide], and in
asking for a code particular the section on [making a pull request][git-guide-make-pr],
will help avoid many common mistakes.
Once you are satisfied with the quality of your PR, follow the
[guidelines on asking for a code
review](https://zulip.readthedocs.io/en/latest/contributing/code-reviewing.html#asking-for-a-code-review) review](https://zulip.readthedocs.io/en/latest/contributing/code-reviewing.html#asking-for-a-code-review)
to request a review. If you are not sure what's best, simply post a comment on to request a review. If you are not sure what's best, simply post a
the main GitHub thread for your PR clearly indicating that it is ready for comment on the main GitHub thread for your PR clearly indicating that
review, and the project maintainers will take a look and follow up with next it is ready for review, and the project maintainers will take a look
steps. and follow up with next steps.
It's OK if your first issue takes you a while; that's normal! You'll be It's OK if your first issue takes you a while; that's normal! You'll be
able to work a lot faster as you build experience. able to work a lot faster as you build experience.
If it helps your workflow, you can submit a work-in-progress pull
request before your work is ready for review. Simply prefix the title
of work in progress pull requests with `[WIP]`, and then remove the
prefix when you think it's time for someone else to review your work.
[git-guide]: https://zulip.readthedocs.io/en/latest/git/
[git-guide-make-pr]: https://zulip.readthedocs.io/en/latest/git/pull-requests.html
### Beyond the first issue ### Beyond the first issue
To find a second issue to work on, we recommend looking through issues with the same To find a second issue to work on, we recommend looking through issues with the same