Adapt docs to reflect stability-focused contribution policy

docs/community/contributing.md

@@ -6,11 +6,9 @@
 
 There are many ways you can contribute to Django REST framework.  We'd like it to be a community-led project, so please get involved and help shape the future of the project.
 
----
+!!! note
 
-**Note**: At this point in it's lifespan we consider Django REST framework to be essentially feature-complete. We may accept pull requests that track the continued development of Django versions, but would prefer not to accept new features or code formatting changes.
+    At this point in its lifespan we consider Django REST framework to be feature-complete. We focus on pull requests that track the continued development of Django versions, and generally do not accept new features or code formatting changes.
-
----
 
 ## Community
 
@@ -36,10 +34,9 @@ Our contribution process is that the [GitHub discussions page](https://github.co
 
 Some tips on good potential issue reporting:
 
-* When describing issues try to phrase your ticket in terms of the *behavior* you think needs changing rather than the *code* you think need changing.
+* Django REST framework is considered feature-complete. Please do not file requests to change behavior, unless it is required for security reasons or to maintain compatibility with upcoming Django or Python versions.
 * Search the GitHub project page for related items, and make sure you're running the latest version of REST framework before reporting an issue.
-* Feature requests will often be closed with a recommendation that they be implemented outside of the core REST framework library.  Keeping new feature requests implemented as third party libraries allows us to keep down the maintenance overhead of REST framework, so that the focus can be on continued stability, bugfixes, and great documentation. At this point in it's lifespan we consider Django REST framework to be essentially feature-complete.
+* Feature requests will typically be closed with a recommendation that they be implemented outside the core REST framework library (e.g. as third-party libraries).  This approach allows us to keep down the maintenance overhead of REST framework, so that the focus can be on continued stability and great documentation.
-* Closing an issue doesn't necessarily mean the end of a discussion.  If you believe your issue has been closed incorrectly, explain why and we'll consider if it needs to be reopened.
 
 ## Triaging issues
 
@@ -48,8 +45,8 @@ Getting involved in triaging incoming issues is a good way to start contributing
 * Read through the ticket - does it make sense, is it missing any context that would help explain it better?
 * Is the ticket reported in the correct place, would it be better suited as a discussion on the discussion group?
 * If the ticket is a bug report, can you reproduce it? Are you able to write a failing test case that demonstrates the issue and that can be submitted as a pull request?
-* If the ticket is a feature request, do you agree with it, and could the feature request instead be implemented as a third party package?
+* If the ticket is a feature request, could the feature request instead be implemented as a third party package?
-* If a ticket hasn't had much activity and it addresses something you need, then comment on the ticket and try to find out what's needed to get it moving again.
+* If a ticket hasn't had much activity and addresses something you need, then comment on the ticket and try to find out what's needed to get it moving again.
 
 # Development
 

docs/community/release-notes.md

@@ -2,11 +2,13 @@
 
 ## Versioning
 
-Minor version numbers (0.0.x) are used for changes that are API compatible.  You should be able to upgrade between minor point releases without any other code changes.
+- **Minor** version numbers (0.0.x) are used for changes that are API compatible.  You should be able to upgrade between minor point releases without any other code changes.
 
-Medium version numbers (0.x.0) may include API changes, in line with the [deprecation policy][deprecation-policy].  You should read the release notes carefully before upgrading between medium point releases.
+- **Medium** version numbers (0.x.0) may include API changes, in line with the [deprecation policy][deprecation-policy].  You should read the release notes carefully before upgrading between medium point releases.
 
-Major version numbers (x.0.0) are reserved for substantial project milestones.
+- **Major** version numbers (x.0.0) are reserved for substantial project milestones.
+
+As REST Framework is considered feature-complete, most releases are expected to be minor releases.
 
 ## Deprecation policy
 

docs/index.md

@@ -184,7 +184,7 @@ Can't wait to get started? The [quickstart guide][quickstart] is the fastest way
 ## Development
 
 See the [Contribution guidelines][contributing] for information on how to clone
-the repository, run the test suite and contribute changes back to REST
+the repository, run the test suite and help maintain the code base of REST
 Framework.
 
 ## Support

docs_theme/css/default.css

@@ -439,3 +439,17 @@ ul.sponsor {
   display: inline-block !important;
 }
 
+/* admonition */
+.admonition {
+  border: .075rem solid #448aff;
+  border-radius: .2rem;
+  margin: 1.5625em 0;
+  padding: 0 .6rem;
+}
+.admonition-title {
+  background: #448aff1a;
+  font-weight: 700;
+  margin:  0 -.6rem 1em;
+  padding: 0.4rem 0.6rem;
+}
+

mkdocs.yml

@@ -9,6 +9,7 @@ theme:
     custom_dir: docs_theme
 
 markdown_extensions:
+ - admonition
  - toc:
     anchorlink: True