Alternative, concise PR template

.github/pull_request_template.md

@@ -1,65 +1,12 @@
 <!--
-    Possible security vulnerabilities: STOP here and contact [email protected] instead!
-
-    Please update the title of the PR with a meaningful message - do not leave it "empty" or "generated"
-    Please update this summary field:
-
-    The summary should cover these topics, if applicable:
-    * the motivation for the change
-    * a description of the status quo, for example the current behavior
-    * the desired behavior
-    * etc
-
-    PR checklist:
-    - Do a self-review of your code before opening a pull request
-    - Make sure that there's good test coverage for the changes included in this PR
-    - Run tests locally before pushing a PR (./gradlew check)
-    - Code should have comments where applicable. Particularly hard-to-understand
-      areas deserve good in-line documentation.
-    - Include changes and enhancements to the documentation (in site/content/in-dev/unreleased)
-    - For Work In Progress Pull Requests, please use the Draft PR feature.
-
-    Make sure to add the information BELOW this comment.
-    Everything in this comment will NOT be added to the PR description.
--->
-
-### What changes were proposed in this pull request?
-<!--
-Please clarify what changes you are proposing. The purpose of this section is to outline the changes and how this PR fixes the issue. 
-If possible, please consider writing useful notes for better and faster reviews in your PR. See the examples below.
-  1. If you refactor some codes with changing classes, showing the class hierarchy will help reviewers.
-  2. If you fix some IRC features, you can provide some references of other IRC implementations / IRC spec.
-  3. If there is design documentation, please add the link.
-  4. If there is a discussion in the mailing list, please add the link.
--->
-
-
-### Why are the changes needed?
-<!--
-Please clarify why the changes are needed. For instance,
-  1. If you propose a new API, clarify the use case for a new API.
-  2. If you fix a bug, you can clarify why it is a bug.
+📝 Describe what changes you're proposing, especially breaking or user-facing changes. 
+📖 See https://github.com/apache/polaris/blob/main/CONTRIBUTING.md for more.
 -->
 
-
-### Does this PR introduce _any_ user-facing change?
-<!--
-Note that it means *any* user-facing change including all aspects such as new features, bug fixes, or other behavior changes. Documentation-only updates are not considered user-facing changes.
-
-If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible.
-If possible, please also clarify if this is a user-facing change compared to the released Polaris versions or within the unreleased branches such as master.
-If no, write 'No'.
--->
-
-
-### How was this patch tested?
-<!--
-If tests were added, say they were added here. Please make sure to add some test cases that check the changes thoroughly including negative and positive cases if possible.
-If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future.
-If tests were not added, please describe why they were not added and/or why it was difficult to add.
--->
-
-### CHANGELOG.md
-<!--
-If the changes need to be included in CHANGELOG.md, please add a line here and in CHANGELOG.md.
--->
+## Checklist
+- [ ] 🛡️ Don't disclose security issues! (contact [email protected])
+- [ ] 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
+- [ ] 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
+- [ ] 💡 Added comments for complex logic
+- [ ] 🧾 Updated `CHANGELOG.md` (if needed)
+- [ ] 📚 Updated documentation in `site/content/in-dev/unreleased` (if needed)