20240426 docs

.github/ISSUE_TEMPLATE/1-issue.md

@@ -5,6 +5,13 @@ about: Please only raise an issue if you've been advised to do so after discussi
 
 ## Checklist
 
+<!--
+Note: REST framework is considered feature-complete. New functionality should be implemented outside the core REST framework. For details, please check the docs: https://www.django-rest-framework.org/community/third-party-packages/#about-third-party-packages
+-->
+
 - [ ] Raised initially as discussion #...
-- [ ] This cannot be dealt with as a third party library. (We prefer new functionality to be [in the form of third party libraries](https://www.django-rest-framework.org/community/third-party-packages/#about-third-party-packages) where possible.)
+- [ ] This is not a feature request suitable for implementation outside this project. Please elaborate what it is:
+  - [ ] compatibility fix for new Django/Python version ...
+  - [ ] other type of bug fix
+  - [ ] other type of improvement that does not touch existing code or change existing behavior (e.g. wrapper for new Django field)
 - [ ] I have reduced the issue to the simplest possible case.

PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,4 @@
-*Note*: Before submitting this pull request, please review our [contributing guidelines](https://www.django-rest-framework.org/community/contributing/#pull-requests).
+*Note*: Before submitting a code change, please review our [contributing guidelines](https://www.django-rest-framework.org/community/contributing/#pull-requests).
 
 ## Description
 

docs/api-guide/serializers.md

@@ -845,8 +845,6 @@ Here's an example of how you might choose to implement multiple updates:
         class Meta:
             list_serializer_class = BookListSerializer
 
-It is possible that a third party package may be included alongside the 3.1 release that provides some automatic support for multiple update operations, similar to the `allow_add_remove` behavior that was present in REST framework 2.
-
 #### Customizing ListSerializer initialization
 
 When a serializer with `many=True` is instantiated, we need to determine which arguments and keyword arguments should be passed to the `.__init__()` method for both the child `Serializer` class, and for the parent `ListSerializer` class.

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.
-* 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.
+* 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.
 
 ## 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 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 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 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/project-management.md

@@ -13,55 +13,13 @@ The aim is to ensure that the project has a high
 
 ## Maintenance team
 
-We have a quarterly maintenance cycle where new members may join the maintenance team. We currently cap the size of the team at 5 members, and may encourage folks to step out of the team for a cycle to allow new members to participate.
+[Participating actively in the REST framework project](contributing.md) **does not require being part of the maintenance team**. Almost every important part of issue triage and project improvement can be actively worked on regardless of your collaborator status on the repository.
 
-#### Current team
+#### Composition
 
-The [maintenance team for Q4 2015](https://github.com/encode/django-rest-framework/issues/2190):
+The composition of the maintenance team is handled by [@tomchristie](https://github.com/encode/). Team members will be added as collaborators to the repository.
 
-* [@tomchristie](https://github.com/encode/)
-* [@xordoquy](https://github.com/xordoquy/) (Release manager.)
-* [@carltongibson](https://github.com/carltongibson/)
-* [@kevin-brown](https://github.com/kevin-brown/)
-* [@jpadilla](https://github.com/jpadilla/)
-
-#### Maintenance cycles
-
-Each maintenance cycle is initiated by an issue being opened with the `Process` label.
-
-* To be considered for a maintainer role simply comment against the issue.
-* Existing members must explicitly opt-in to the next cycle by check-marking their name.
-* The final decision on the incoming team will be made by `@tomchristie`.
-
-Members of the maintenance team will be added as collaborators to the repository.
-
-The following template should be used for the description of the issue, and serves as the formal process for selecting the team.
-
-    This issue is for determining the maintenance team for the *** period.
-
-    Please see the [Project management](https://www.django-rest-framework.org/topics/project-management/) section of our documentation for more details.
-
-    ---
-
-    #### Renewing existing members.
-
-    The following people are the current maintenance team. Please checkmark your name if you wish to continue to have write permission on the repository for the *** period.
-
-    - [ ] @***
-    - [ ] @***
-    - [ ] @***
-    - [ ] @***
-    - [ ] @***
-
-    ---
-
-    #### New members.
-
-    If you wish to be considered for this or a future date, please comment against this or subsequent issues.
-
-    To modify this process for future maintenance cycles make a pull request to the [project management](https://www.django-rest-framework.org/topics/project-management/) documentation.
-
-#### Responsibilities of team members
+#### Responsibilities
 
 Team members have the following responsibilities.
 
@@ -78,16 +36,12 @@ Further notes for maintainers:
 * Each issue/pull request should have exactly one label once triaged.
 * Search for un-triaged issues with [is:open no:label][un-triaged].
 
-It should be noted that participating actively in the REST framework project clearly **does not require being part of the maintenance team**. Almost every import part of issue triage and project improvement can be actively worked on regardless of your collaborator status on the repository.
-
 ---
 
 ## Release process
 
-The release manager is selected on every quarterly maintenance cycle.
-
-* The manager should be selected by `@tomchristie`.
-* The manager will then have the maintainer role added to PyPI package.
+* The release manager is selected by `@tomchristie`.
+* The release manager will then have the maintainer role added to PyPI package.
 * The previous manager will then have the maintainer role removed from the PyPI package.
 
 Our PyPI releases will be handled by either the current release manager, or by `@tomchristie`. Every release should have an open issue tagged with the `Release` label and marked against the appropriate milestone.
@@ -198,7 +152,7 @@ If `@tomchristie` ceases to participate in the project then `@j4mie` has respons
 
 The following issues still need to be addressed:
 
-* Ensure `@jamie` has back-up access to the `django-rest-framework.org` domain setup and admin.
+* Ensure `@j4mie` has back-up access to the `django-rest-framework.org` domain setup and admin.
 * Document ownership of the [mailing list][mailing-list] and IRC channel.
 * Document ownership and management of the security mailing list.
 

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