add better contribution guidelines + pr template

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,45 @@
+## Before Submitting This PR
+
+**Please confirm you have done the following:**
+
+- [ ] I have searched [existing issues](https://github.com/cjpais/Handy/issues) and [pull requests](https://github.com/cjpais/Handy/pulls) (including closed ones) to ensure this isn't a duplicate
+- [ ] I have read [CONTRIBUTING.md](../CONTRIBUTING.md)
+
+**If this is a feature or change that was previously closed/rejected:**
+
+- [ ] I have explained in the description below why this should be reconsidered
+- [ ] I have gathered community feedback (link to discussion below)
+
+## Description
+
+<!-- Describe your changes clearly and concisely -->
+
+## Related Issues/Discussions
+
+<!-- Link to related issues, discussions, or previous PRs -->
+<!-- If reopening something previously closed, explain why this should be reconsidered -->
+
+Fixes #
+Discussion:
+
+## Community Feedback
+
+<!--
+PRs with community support are much more likely to be merged.
+
+For features: Link to a discussion where community members have expressed interest.
+For bug fixes: Link to the issue where others have confirmed the bug.
+
+If you haven't gathered feedback yet, consider starting a discussion first:
+https://github.com/cjpais/Handy/discussions
+
+It is not explicitly required to gather feedback, but it certainly helps your PR get merged.
+-->
+
+## Testing
+
+<!-- Describe how you tested your changes and if you need help getting additional testing -->
+
+## Screenshots/Videos (if applicable)
+
+<!-- Add screenshots or videos demonstrating the change -->

CONTRIBUTING.md

@@ -137,6 +137,25 @@ We use GitHub Discussions for feature requests rather than issues. This keeps is
 
 ## 🔧 Making Code Contributions
 
+### Before You Start
+
+**This is critical:** Before writing any code, please do the following:
+
+1. **Search existing issues and PRs** - Check both open AND closed issues and pull requests. Someone may have already addressed this, or there may be a reason it was closed.
+   - [Open issues](https://github.com/cjpais/Handy/issues)
+   - [Closed issues](https://github.com/cjpais/Handy/issues?q=is%3Aissue+is%3Aclosed)
+   - [Open PRs](https://github.com/cjpais/Handy/pulls)
+   - [Closed PRs](https://github.com/cjpais/Handy/pulls?q=is%3Apr+is%3Aclosed)
+
+2. **If something was previously closed** - If you want to revisit a closed issue or PR, you need to:
+   - Provide a strong argument for why it should be reconsidered
+   - Gather community feedback first via [Discussions](https://github.com/cjpais/Handy/discussions)
+   - Link to that discussion in your PR
+
+3. **Get community feedback for features** - PRs with demonstrated community interest are **much more likely to be merged**. Start a discussion, get feedback, and link to it in your PR. This helps ensure Handy stays focused and useful for the most people without becoming bloated.
+
+Community feedback is essential to keeping Handy the best it can be for everyone. It helps prioritize what matters most and prevents feature creep.
+
 ### Development Workflow
 
 1. **Create a feature branch**:
@@ -193,12 +212,15 @@ We use GitHub Discussions for feature requests rather than issues. This keeps is
    - Go to the [Handy repository](https://github.com/cjpais/Handy)
    - Click "New Pull Request"
    - Select your fork and branch
-   - Fill out the PR template with:
+   - Fill out the PR template completely, including:
      - Clear description of changes
-     - Related issues or discussions
+     - Links to related issues or discussions
+     - **Community feedback** (especially important for features)
      - How you tested the changes
      - Screenshots/videos if applicable
      - Breaking changes (if any)
+     
+   **Remember:** PRs with community support are prioritized. If you haven't already, start a [discussion](https://github.com/cjpais/Handy/discussions) to gather feedback before or alongside your PR. It is not explicitly required to gather feedback, but it certainly helps your PR get merged faster.
 
 ### Code Style Guidelines