8.2. Change Goals

• The change should be technically correct, and consistent with the rest of the policy document. This means no legislating the value of π. This also means that the proposed solution be known to work; iterative design processes do not belong in policy.

• The change should not be too disruptive; if very many packages become instantly buggy, then instead there should be a transition plan. Exceptions should be rare (only if the current state is really untenable), and probably blessed by the TC.

• The change has to be reviewed in depth, in the open, where any one may contribute; a publicly accessible, archived, open mailing list.

• Proposal should be addressed in a timely fashion.

• Any domain experts should be consulted, since not every policy mailing list subscriber is an expert on everything, including policy maintainers.

• The goal is rough consensus on the change, which should not be hard if the matter is technical. Technical issues where there is no agreement should be referred to the TC; non-technical issues should be referred to the whole developer body, and perhaps general resolutions lie down that path.

• Package maintainers whose packages may be impacted should have access to policy change proposals, even if they do not subscribe to policy mailing lists (policy gazette?).