(debian-policy.info)Change Goals

---

Next: Current Process Prev: Introduction<3> Up: Debian Policy changes process

---

Enter node , (file) or (file)node

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