I’m doing some casual research here, that I hope will help new contributors when they make proposals.
What are some of the existing consensus opinions that exist with in the community that may not be explicitly documented anywhere. What I’m trying to get at are the current decisions which shape proposals.
A few examples that I have seen:
Try the proposal in a third-party package (I know this one is documented)
Smaller changes could be a blog post or code snippet
Adding a new Setting should be avoided where possible
Performance improvements need to be demonstrated in numbers
Consider the maintenance burden for the Fellows and others going forward
I’m looking for others or corrections to my examples. What comes to mind for you?
Yes, I agree - my wording was intentionally brief. It could be expanded upon to say that for “contrib” modules, it would be 80% of those people using that contrib module.
@nanorepublica - I’m assuming with a fair degree of confidence that he was responding to me.
Django doesn’t aim for exhaustive protocol coverage. For example, there aren’t custom HTTP response classes for every possible status code but instead docs on making your own. Ditto for database functions.
(This principle is related to considering the maintenance burden.)