New Policy change process
The Policy change process documented in the current debian-policy package
as policy-process.* is obsolete. Please disregard the current documents;
they will be dropped in the next Policy release. We're switching to a new
process based on Manoj's proposal from some time ago.
I have taken the liberty of starting with Manoj's process and my original
bug triage and tagging and writing up a new process. This should not be
set in stone, and in particular it's not yet been reviewed by any of the
other Policy delegates. I don't mind if we change it. I just want (and
need) something to start from so that I can try to organize the otherwise
daunting task of reducing the current Policy bug list.
The new process is documented at:
http://wiki.debian.org/PolicyChangesProcess
and is basically a streamlined version of Manoj's process. I've made the
following changes:
* Only normative issues follow the full process. The same tags are used
for convenience for informative issues (changes to wording,
non-normative footnotes, and the like that don't affect the Policy
dictates), but the same process need not be used and those bugs can be
resolved at the discretion of policy maintainers. Packaging issues are
also kept separate with their own tag and don't follow the regular
process for obvious reasons.
* There is no explicit state for requesting input from domain experts.
This is a minor streamlining to try to cut down on the number of states
and doesn't mean this isn't part of the process. This should be part of
the discussion process. If we end up needing an explicit step with its
own tag, we can add it back in, but I wanted to start with a set of tags
that I was already working with.
* I'm currently not bothering to tag the reason for rejecting proposals.
We can do that if we end up seeing a need, but my intention is to be
fairly active about closing rejected issues. I want to get the bug
count down and I don't see a need to keep a lot of things lingering in
the BTS. We can always unarchive and reopen as need be.
* Rather than using usertags for every step of the process, I'm using the
standard patch, pending, and wontfix tags for the closing stages of the
process since the usertags basically meant the same thing. This lets
standard BTS-wide queries and tools still get an accurate impression of
the state of Policy bugs.
I welcome any comments on this process, including anything that isn't
clear. I've tried to document what's needed at each stage for a given
Policy bug to advance through the process.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: