Abstract

This PEP outlines the python-dev voting guidelines. These guidelinesserve to provide feedback or gauge the “wind direction” on aparticular proposal, idea, or feature. They don’t have a bindingforce.

Rationale

When a new idea, feature, patch, etc. is floated in the Pythoncommunity, either through a PEP or on the mailing lists (most likelyon python-dev[1]), it is sometimes helpful to gauge the community’sgeneral sentiment. Sometimes people just want to register theiropinion of an idea. Sometimes the BDFL wants to take a straw poll.Whatever the reason, these guidelines have been adopted so as toprovide a common language for developers.

While opinions are (sometimes) useful, but they are never binding.Opinions that are accompanied by rationales are always valued higherthan bare scores (this is especially true with -1 votes).

Voting Scores

The scoring guidelines are loosely derived from the Apache votingprocedure[2], with of course our own spin on things. There are 4possible vote scores:

• +1 I like it
• +0 I don’t care, but go ahead
• -0 I don’t care, so why bother?
• -1 I hate it

You may occasionally see wild flashes of enthusiasm (either for oragainst) with vote scores like +2, +1000, or -1000. These aren’treally valued much beyond the above scores, but it’s nice to seepeople get excited about such geeky stuff.

References

Copyright

This document has been placed in the public domain.