Hi,
This is going to be a long email. I am contemplating the
holiday festivities, and am getting into the zen mode for making
traditional egg nog. Where I live, traditional egg nog means
contemplating very old Kentucky straight bourbon whiskey, and single
cask Jamaican white rum, amongst other things. Making good egg nog
makes one inclined t wax long and lyrical.
You have been warned.
Oh, and please send responses to the debian-policy mailing list.
The genesis of this current development is in the discussion (if
I may call it that) that emerged around the un-delegation and
re-delegation of the policy team, which means circa October '06.
In the mail of:
http://lists.debian.org/debian-vote/2006/10/msg00397.html
I spell out some of the bits missing from the old policy change
process; for example, soliciting and paying special heed to domain
expert advice, leading and abridging discussion on policy changes, etc.
In
http://lists.debian.org/debian-vote/2006/10/msg00402.html
I talk about the goals of the policy change process, and the initial
draft of what the new process would look like.
Last DebConf, I gave a talk titled: "The Policy and RC bug
goulash", which can be found at
http://people.debian.org/~srivasta/talks/policy_change_process/policy_and_rc_bugs.pdf.
The talk deals with two things: the policy rewrite, and the changes to
the policy process itself. I have already broached the re-write in
another thread, here is my proposal to move to the new policy process,
and to further open up the policy change process.
So, to recap, here are the goals for the policy change process:
GOALS
* The change should be technically correct, and consistent with the
rest of the policy document. This means no legislating the value of
$\Pi$. 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?).
Here is the policy change process as a state machine:
SATE DIAGRAM
* State A: Issue raised. Detect need, like gaps/flaws in
current policy, or a new rule should be added. Any user or
developer may start this step. There is a decision point here,
not all issues are in scope of policy. [TAG: issue]
* State B:Discussion Discuss remedy. Alternate proposals. Discussion
guided by delegates. There should be a clear time limit to this
stage. [TAG: discussion]
* State C:Solicit advice [Optional] Solicit domain expert input
[TAG: opinion]
* State D:Proposal. A final proposal has emerged from the
discussion, and there is a rough consensus on how to proceed to
resolve the issue. [TAG: proposal]
* State E:Wording proposed Close to a working solution. Create
policy language, rationale, test, and publish. [TAG: wording]
* State F:Seconded The proposal is signed off on by N developers,
N=3? (stages D and E may be reversed) Final discussions start;
input from affected developers. [TAG: seconded]
* State G:Accepted Change accepted, will be in next upload.
[TAG: accepted]
* State H:Reject Rejected proposals. [TAG: rejected]
These can be one of:
H1:dubious Not a policy matter [TAG: dubious]
H2:Ctte Referred to TC [TAG: ctte]
H3:Devel Referred to developer body [TAG: devel]
H4:Delegate Rejected by delegates [TAG: delegate]
(sent by default to TC)
H4:Timeout Timed out, no policy created. [TAG: obsolete]
Hopefully, the timeout rejection of policy changes will not be
exercised very often; if it is, perhaps the process should be
revisited.
Russ Allbery took the above proposal and ran with it, creating a
user tag view of policy
http://lists.debian.org/debian-policy/2007/08/msg00018.html
This allows users to see what the policy delegates think is the state
of the process, and allows for a transparent mechanism for looking at
the state of the policy change proposals. It would also help people
interested in joining the policy team to help the process along;
propose policy wording for proposals at the end of discussion, help
determine if the wording proposed meets policy goals, etc.
I have since used that framework, and I am proposing expanding
the user tags and using the user [EMAIL PROTECTED] as the
default user. I have expanded on the scheme used by Russ, to better
match the proposals for the process (adding in seconds, etc).
Experimenting with these user categories, new proposals pop to the top,
helping me quickly see new proposals, and letting me categorize them.
Please look at
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&[EMAIL
PROTECTED]&ordering=policy
for a preview.
These user categories also help in making the process more
efficient, and predictable; it also help direct effort (for example, my
primary effort at the moment is to look at all the proposals
categorized as wording; with an eye to bringing them to
resolution. This is where seconds would help. The people seconding
shoul perhaps include any reasons they have for seconding, if they
think it would help others see the validity of the wording proposed.
In any case, either these proposals should be accepted, or
rejected, or sent back to discussion: perhaps we should discuss what a
time limit should be for each stage the proposal spends its time in?
I suggest that all the usertags for the policy, apart from the
second usertag, only be applied by the policy delegates, and that any
DD be allowed to add a usertag seconded to any report that already has
the wording usertag.
Additional usertags are:
* dubious, ctte, devel, delegate,timeout These are mostly used to add
reasons for rejection; or why the delegates are tending towards
rejection of a particular proposal.
* dpkg, security
Here is my current take on the user category and classification
of current bugs.
manoj
user [EMAIL PROTECTED]
usercategory issue-type [hidden]
* Issue Type [tag=]
+ Normative [normative]
+ Informative [informative]
+ Packaging [packaging]
+ Unclassified []
usercategory issue-status [hidden]
* Issue Status [tag=]
+ Issue Raised [issue]
+ Under Discussion [discussion]
+ Opinion Solicited [opinion]
+ Change Proposed [proposal]
+ Wording Proposed [wording]
+ Wording Seconded [seconded]
+ Wording Accepted [accepted]
+ Rejected [tag=rejected]
+ Unknown []
usercategory policy
* status
* issue-type
* issue-status
* severity
* classification
usercategory old
* status
* severity
* classification
usertag 452393 + issue, normative
usertag 89038 + issue, normative
usertag 120418 + issue, normative
usertag 122038 + issue, normative
usertag 161912 + issue, normative
usertag 186700 + issue, normative
usertag 192571 + issue, normative
usertag 215549 + issue, normative
usertag 228692 + issue, normative
usertag 263448 + issue, normative
usertag 276160 + issue, normative
usertag 291177 + issue, normative
usertag 375502 + issue, normative
usertag 392479 + issue, normative
usertag 400322 + issue, normative
usertag 402721 + issue, normative
usertag 408500 + issue, normative
usertag 412668 + issue, normative
usertag 425523 + issue, normative, dpkg
usertag 438492 + issue, normative, dubious
usertag 442070 + issue, normative
usertag 445203 + issue, normative
usertag 446712 + issue, normative
usertag 447231 + issue, normative
usertag 452105 + issue, normative
usertag 457364 + issue, normative
usertag 403391 + discussion, normative
usertag 374029 + discussion, normative
usertag 391240 + discussion, normative
usertag 99324 + discussion, normative, dubious
usertag 99933 + discussion, normative
usertag 160827 + discussion, normative
usertag 169600 + discussion, normative, dubious
usertag 181123 + discussion, normative
usertag 184064 + discussion, normative
usertag 188731 + discussion, normative
usertag 203650 + discussion, normative, dubious
usertag 212814 + discussion, normative
usertag 224509 + discussion, normative
usertag 232448 + discussion, normative
usertag 248809 + discussion, normative
usertag 253511 + discussion, normative, dubious
usertag 291148 + discussion, normative
usertag 291631 + discussion, normative
usertag 295006 + discussion, normative, dubious
usertag 299007 + discussion, normative, security, dubious
usertag 331532 + discussion, normative, dubious
usertag 338219 + discussion, normative
usertag 367650 + discussion, normative, dubious
usertag 381729 + discussion, normative, dubious
usertag 391841 + discussion, normative
usertag 397939 + discussion, normative
usertag 399913 + discussion, normative
usertag 400112 + discussion, normative
usertag 401452 + discussion, normative
usertag 403649 + discussion, normative, dpkg
usertag 411510 + discussion, normative
usertag 413353 + discussion, normative
usertag 430649 + discussion, normative
usertag 431109 + discussion, normative
usertag 434651 + discussion, normative, dubious
usertag 435476 + discussion, normative, dubious
usertag 436419 + discussion, normative
usertag 440420 + discussion, normative
usertag 104373 + normative, proposal
usertag 106073 + normative, proposal
usertag 122817 + normative, proposal, dubious
usertag 143941 + normative, proposal
usertag 152955 + normative, proposal
usertag 196367 + normative, proposal
usertag 206684 + normative, proposal
usertag 208010 + normative, proposal
usertag 208011 + normative, proposal
usertag 218893 + normative, proposal
usertag 241333 + normative, proposal
usertag 246016 + normative, proposal
usertag 267142 + normative, proposal
usertag 284340 + normative, proposal, dubious
usertag 291460 + normative, proposal
usertag 314808 + normative, proposal
usertag 345619 + normative, proposal, dubious
usertag 347581 + normative, proposal
usertag 348336 + normative, proposal
usertag 391836 + normative, proposal
usertag 416450 + normative, proposal
usertag 431813 + normative, proposal
usertag 436105 + normative, proposal
usertag 442134 + normative, proposal
usertag 443334 + normative, proposal
usertag 379150 + normative, wording, dpkg
usertag 392362 + normative, wording
usertag 65577 + normative, wording
usertag 114920 + normative, wording
usertag 172436 + normative, wording
usertag 209008 + normative, wording
usertag 250202 + normative, wording
usertag 367984 + normative, wording
usertag 455602 + informative, issue
usertag 422552 + informative, discussion
usertag 102213 + informative, discussion, dubious
usertag 163666 + informative, discussion
usertag 218897 + informative, discussion
usertag 328951 + informative, proposal
usertag 175202 + informative, proposal
usertag 186102 + informative, proposal
usertag 47438 + packaging
usertag 175064 + packaging
usertag 203098 + packaging
--
"If I ever get around to writing that language depompisifier, it will
change almost all occurences of the word "paradigm" into "example" or
"model." -- Herbie Blashtfalt
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
