From aba68b114beead9c11aa939d3098774718af597c Mon Sep 17 00:00:00 2001
From: Helium314 <helium314@mailbox.org>
Date: Mon, 17 Jul 2023 08:47:20 +0200
Subject: [PATCH] update PR template

---
 .github/PULL_REQUEST_TEMPLATE.md | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 5cbfdf7a9..464977034 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,6 +1,13 @@
 <!--
 * Describe briefly what your pull request proposes to fix or improve.
-* If it's not completely obvious, describe what the PR does to achieve the desired result. Do no waste the maintainers' or anyone elses time by making them find out instead.
-* If you use someone else's code (e.g. from another AOSP fork), please mention the source.
-* Which device / Android version did you test the PR on?
+* If it's not completely obvious, describe what the PR does to achieve the desired result. This can help avoiding time consuming discussions.
+* If you use someone else's code (e.g. from another AOSP fork), please mention the source. Or even better link to the commit, as this may provide additional context.
+* Which device / Android version did you test the PR on? The keyboard may behave differently on different devices, e.g. due to Android version or screen size.
+
+If you're not familiar with pull requests, some essentials:
+* A pull request should contain only one feature. This way reviewing and discussion is much simpler than for a all-my-favorite-features PR.
+* Before investing a lot of time, make sure the feature you want to contribute is actually wanted, e.g. by checking issues or opening an issue (and possibly offering to work on it).
+* If you intend to do large changes, it might be good to start with a draft PR and discuss your approch. It may turn out your initial approach will need changes, so by discussing early you can avoid wasting time on re-writing code.
+* You should be able and willing to explain the changes you did, as well as your reasoning. This is especially relevant for changes that at first glance seem unrelated to the goals of your PR.
+* If you want to spend the time, you can read more detailed guides on "good PRs", e.g. https://betterprogramming.pub/how-to-create-a-good-pull-request-and-how-to-review-one-c30a13f61fd2
 -->