From 9987834b15332badc4c6d7b547bcf8e9cc535bb8 Mon Sep 17 00:00:00 2001
From: Peter VandeHaar <pjvandehaar@users.noreply.github.com>
Date: Wed, 20 Oct 2021 17:34:16 -0400
Subject: [PATCH] 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 <!--  -->.
---
 .github/PULL_REQUEST_TEMPLATE.md | 32 ++++++++------------------------
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index d745034b..d9f66090 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -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.
- 2. PR name follows [convention](http://karma-runner.github.io/4.0/dev/git-commit-msg.html)
- 3. All tests pass locally, UI and Unit tests
- 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
+If you're making a big change, please explain what problem it solves:
+- Explain the purpose of the change.  When adding a way to do X, explain why it is important to be able to do X.
+- Show the current vs desired behavior with screenshots/GIFs.
 
 -->
-
-> 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 -->