I find two problems with Manoj's proposal.
Unlike before, when the policy editor gathered in issues which, in his
view, were candidates for inclusion in policy, I propose that issues
are brought up in the policy group, and, if the initial discussion
warrants it, any developer, with at least two(?) seconds can formally
propose as a policy amendment.
You mention "any developer" or "developers" here, but I think you
should say "registered Debian developer". That is to say, you must be
a registered Debian developer to sponsor an issue (you could sponsor
an issue raised by a non-developer, however), and the seconds must
also be Debian developers.
AFAIK, the debian-policy email list is open to developers or
non-developers. But I think it's important that sponsors and
seconders be official Debian develoeprs. I'm not trying to be elite,
I just think this is a good way to enforce some level of quality in
proposed amendments.
A fascinating sub proposal has been that we use the bug tracking
system to track policy amendments in progress. If this is used, we may
initiate discussions in the policy group by filing wish-list bugs
(note: this should be open to anyone at all)
Formal proposals should be treated as normal bugs, and after the
discussion period are either closed (when incorporated in policy, or
roundly rejected as undesirable), or are demoted to (forwarded?) wish
list bugs. I like them being demoted to forwarded status, since the
upstream authors (the policy mailing list) has already had a stab at
them, and they have been shelved until further notice.
I think that the Policy is critical enough for the project that any
real flaws in the policy be automatically be deemed important bugs,
unless they affect release management.
Well I think we need to make a determination of whether or not to
completely include this in your proposal or not. It makes a
difference in the way that status reports are done. As the person who
originally raised this idea on IRC, Manoj, I think we should do it
this way, since I think it simplies how me manage and track open
amendments and issues. I think both retitling and the severity of the
bugs can and should be used (and outlined) in this document.
Issue raised: wishlist bug opened in BTS, with a subject of
"[PROPOSED] ..."
Seconds: developers may second the issue by emailing "seconded" to
the BTS.
Amendment: when a propsed issue becomes a formal amendment, the bug
severity is raised to "normal" and the bug is retitled to
"[AMENDMENT DD/MM/YYY] ...". Actually it might be
better to close the proposal and reopen so the bug date
reflects when the clock starts ticking on the bug; in which
case the bug could simply be retitled "[AMENDMENT] ...".
Accepted: if the amendment is accepted, the bug is marked forwarded,
until it is actually integrated into Policy and uploaded
and moved into the archive, at which time the bug is closed.
Rejected: if the amendment is closed, it is retitled as
"[REJECTED] ..." and marked as closed
Deadlocked: if the amendment is deadlocked, it is marked as
"[DEADLOCKED] ..."
--
.....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/>
