Updating our project guidelines to minimise churn.

[lovelydinosaur]

My perspective is that Django REST framework is feature complete and has been for a while now.
Despite this, there's still a lot of issue/pr churn which isn't providing any value.
I'm opening this discussion because I'd suggest figure out what changes we need to make in order to communicate the project status clearly.

I strongly feel that only changes that we should be seeing in REST framework at this point in the project lifecycle are:

• Tracking any changes required by updates in Django versions.
• Tracking any changes required by updates in Python versions.
• Security updates.

What changes would we need to make to the project to communicate this as clearly as possible, and reduce the ongoing churn that the project is currently seeing?

[jathanism]

I think it would be valuable to display this at the top of the README, in the contributors guide for the docs, and also in the issue templates.

Consider what the maintainers of requests have in their docs here:

https://requests.readthedocs.io/en/latest/dev/contributing/?highlight=feature%20complete#feature-requests

Requests is in a perpetual feature freeze, only the BDFL can add or approve of new features. The maintainers believe that Requests is a feature-complete piece of software at this time.

One of the most important skills to have while maintaining a largely-used open source project is learning the ability to say “no” to suggested changes, while keeping an open ear and mind.

If you believe there is a feature missing, feel free to raise a feature request, but please do be aware that the overwhelming likelihood is that your feature request will not be accepted

[lovelydinosaur]

I would be up for reviewing a pull request effecting this change.

[auvipy]

I would be happy to start a draft PR. any pointer where to put them?

[auvipy]

I want to add few points explicitly with what Tom mentioned:

1. Bug fixes
2. Long standing design limitations / implementation detail improvement for better dev exp without breaking much
3. Not exposing any new API surface unless needed for any existing features support: explicitly decided only by Old and new maintainers. But community inputs are welcome.
4. Improving test and CI infra.