docs: Try to steer people to better practices

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -8,7 +8,7 @@ body:
       options:
         - label: I have searched the [discussions](https://github.com/clap-rs/clap/discussions)
           required: true
-        - label: I have searched the existing issues
+        - label: I have searched the [open](https://github.com/clap-rs/clap/issues) and [rejected](https://github.com/clap-rs/clap/issues?q=is%3Aissue+label%3AS-wont-fix+is%3Aclosed) issues
           required: true
   - type: input
     attributes:

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -8,7 +8,7 @@ body:
       options:
         - label: I have searched the [discussions](https://github.com/clap-rs/clap/discussions)
           required: true
-        - label: I have searched the existing issues
+        - label: I have searched the [open](https://github.com/clap-rs/clap/issues) and [rejected](https://github.com/clap-rs/clap/issues?q=is%3Aissue+label%3AS-wont-fix+is%3Aclosed) issues
           required: true
   - type: input
     attributes:

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,9 @@
+<!--
+Thanks for helping out!
+
+Please link the appropriate issue from your PR.
+
+If you don't have an issue, we'd recommend starting with one first so the PR can focus on the
+implementation (unless its an obvious bug or documentation fix that will have
+little conversation).
+-->

CONTRIBUTING.md

@@ -22,6 +22,15 @@ There are a few goals of `clap` that I'd like to maintain throughout contributio
 
 ## General Overview
 
+### Where to Start
+
+- [Discussions](https://github.com/clap-rs/clap/discussions) can be useful for getting help and brainstorming
+- [Issues](https://github.com/clap-rs/clap/issues) work well discussing a need and how to solve it
+  - Focus: requirements gathering and design discussions
+  - Sometimes a branch or Draft PR might be used to demonstrate an idea
+- [PRs](https://github.com/clap-rs/clap/pulls) work well for when the solution has already been discussed as an Issue or there is little to no discussion (obvious bug or documentation fixes)
+  - Focus: implementation discussions
+
 ### Testing Code
 
 To test with all features both enabled and disabled, you can run this command:
@@ -71,6 +80,16 @@ $ cargo test --test <test_name> --features debug
 2. Push your changes back to your fork (`git push origin $your-branch`)
 3. Create a pull request against `master`! (You can also create the pull request first, and we'll merge when ready. This a good way to discuss proposed changes.)
 
+PR expectations:
+- PRs remain small and focused
+ - If needed, we can put changes behind feature flags as they evolve
+- Commits are atomic (i.e. do a single thing)
+- Commits are in [Conventional Commit](conventionalcommits.org/) style
+
+We recognize that these are ideals and we don't want lack of comfort with git
+to get in the way of contributing.  If you didn't do these, bring it up with
+the maintainers and we can help work around this.
+
 ## Conditions for fulfilling a bounty:
 
 1. You should make a pull request which fixes the issue the bounty was promised for