[proposal] Handling of contested changes near release finalization

Given the consensus-based nature of our development process, I propose
that something along the lines of the following be incorporated into
HACKING to streamline the decision making process near the end of a
release cycle (hopefully speeding up future release timelines):

  "Contested changes of non-critical functional severity should not be
  backported during a release candidate cycle which is likely to
  result in a final release. A change is "contested" not only by a -1
  veto in STATUS, but by negative feedback from a committer in any
  forum."

The stipulation of not porting non-critical changes is a best-practice
typically used by successful development projects.

The trust that committers extend to each other to freely make changes
to development branches should be reciprocated when there are
reservations about porting changes to a release branch. This is
especially imperative near the end of a release cycle.