public-offering
/
pad.pub0.org
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Clarify instructions in PULL_REQUEST_TEMPLATE.md 

This change
- removes instructions about commit headers that nobody follows,
- links to useful resources for first-time contributors,
- simplifies some text, and
- hides all text inside <!--  -->.
pull/5256/head
Peter VandeHaar 2021-10-20 17:34:16 -04:00 committed by Richard Hansen
parent 9aaf781548
commit 9987834b15
1 changed files with 8 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
.github/PULL_REQUEST_TEMPLATE.md vendored
View File

@ -1,29 +1,13 @@
<!-- <!--
Some key notes before you open a PR: 1. If you haven't already, please read https://github.com/ether/etherpad-lite/blob/master/CONTRIBUTING.md#pull-requests .
2. Run all the tests, both front-end and back-end. (see https://github.com/ether/etherpad-lite/blob/master/CONTRIBUTING.md#testing)
3. Keep business logic and validation on the server-side.
4. Update documentation.
5. Write `fixes #XXXX` in your comment to auto-close an issue.
1. Select which branch should this PR be merged in? By default, you should always merge to the develop branch. If you're making a big change, please explain what problem it solves:
2. PR name follows [convention](http://karma-runner.github.io/4.0/dev/git-commit-msg.html) - Explain the purpose of the change. When adding a way to do X, explain why it is important to be able to do X.
3. All tests pass locally, UI and Unit tests - Show the current vs desired behavior with screenshots/GIFs.
4. All business logic and validations must be on the server-side
5. Update necessary Documentation
6. Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes
Also, if you're new here
- Contribution Guide => https://github.com/ether/etherpad-lite/blob/master/CONTRIBUTING.md
--> -->
> Please provide enough information so that others can review your pull request:
<!-- You can skip this if you're fixing a typo or updating existing documentation -->
> Explain the **details** for making this change. What existing problem does the pull request solve?
<!-- Example: When "Adding a function to do X", explain why it is necessary to have a way to do X. -->
> Screenshots/GIFs
<!-- Add images/recordings to better visualize the change: expected/current behviour -->