docs: strengthen contributing guidelines

- Require issues for all PRs (except trivial fixes like typos)
- Add requirement to wait for maintainer buy-in before starting work
- Add "SDK is opinionated" section for maintainer discretion
- Restructure with clearer "What Needs Discussion" section
- Add welcoming opening to balance strict rules

Author: maxisbey

CONTRIBUTING.md

@@ -4,26 +4,34 @@ Thank you for your interest in contributing to the MCP Python SDK! This document
 
 ## Before You Start
 
-### Bug Fixes
+We welcome contributions! These guidelines exist to save everyone time, yours included. Following them means your work is more likely to be accepted.
 
-Bug fixes are welcome! For straightforward bugs, feel free to open a PR directly. For complex bugs that require significant changes, consider opening an issue first to discuss the approach.
+**All pull requests require a corresponding issue.** Unless your change is trivial (typo, docs tweak, broken link), create an issue first. PRs without a linked issue will be closed.
 
-### New Features and Enhancements
+Having an issue doesn't guarantee acceptance. Wait for maintainer feedback or a `ready for work` label before starting. PRs for issues without buy-in may also be closed.
 
-**Please open an issue before starting work on new features or significant enhancements.** We will often close pull requests for new features that were not previously discussed. This isn't because we don't appreciate the contribution—it's because adding features creates long-term maintenance burden and requires alignment with the SDK's direction.
+Use issues to validate your idea before investing time in code. PRs are for execution, not exploration.
 
-What counts as "significant"?
+### The SDK is Opinionated
+
+Not every contribution will be accepted, even with a working implementation. We prioritize maintainability and consistency over adding capabilities. This is at maintainers' discretion.
+
+### What Needs Discussion
+
+These always require an issue first:
 
 - New public APIs or decorators
 - Architectural changes or refactoring
 - Changes that touch multiple modules
 - Features that might require spec changes (these need a [SEP](https://github.com/modelcontextprotocol/modelcontextprotocol) first)
 
+Bug fixes for clear, reproducible issues are welcome—but still create an issue to track the fix.
+
 ### Good Candidates for Contribution
 
-Issues labeled [`good first issue`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) or [`help wanted`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) are great places to start. Issues labeled [`ready for work`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22ready+for+work%22) have been triaged and are ready for implementation.
+Issues labeled [`good first issue`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) or [`help wanted`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) are great starting points. Issues labeled [`ready for work`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22ready+for+work%22) have been triaged and are ready for implementation.
 
-Issues labeled `needs confirmation` or `needs maintainer action` are **not** good candidates—please wait for maintainer input before starting work on these.
+Issues labeled `needs confirmation` or `needs maintainer action` are **not** good candidates—wait for maintainer input before starting work.
 
 ## Development Setup