Documenting existing prevailing consensus/trends within the community.

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? :smile:

2 Likes

Don’t break existing behavior unless absolutely necessary to implement an improvement.

Core changes should show value to a super-majority of the installed base. (Colloquially, the “80%” rule.)

1 Like

The last point seems not reasonable to me. Taken to the extreme it could be interpreted as not making any changes to geodjango ever again for example :stuck_out_tongue:

Ken’s last point or mine?

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.

2 Likes

If you are going to change existing behavior, just do it. (With a deprecation period.) Don’t try to support both old and new behavior indefinitely.

Also, with nearly all rules of thumb, PEP 20’s “practicality beats purity” exception applies.

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.)

2 Likes