Re: PROPOSAL: A mechanism for updating Debian Policy documents
In general, I liked the technical aspects of the proposal. I don't
like the "voice" of the proposal, however. To me, it reads like a
mixture of technical details, personal opinion, and rationale for the
changes. I would prefer it if the technical content was decidedly
separate from the non-technical content. I would also prefer it if the
language used for the procedures were more "determinate" -- "A policy
maintainers team _will_ [or _shall_] be selected who will have
access..." rather than "I propose we select/install a group of
people..."
Unfortunately, this would require a massive amendment, equivilant to
rewriting the whole thing. Unless requested, I don't feel confident to
suggest such a massive amendment at this time.
I do have some technical questions, however:
> 3.2. Deadlines for Tabling Discussions
> --------------------------------------
>
...
>
> If a consensus is reached by the policy group, then the maintainers
> shall enter the amendment into the Policy document, announce the
> inclusion in the periodic report, and release a new version.
How will consensus be determined? Will one opposing developer be able
to force a deadlock? If not, how many?
> 3.2.1. Extensions to Deadlines?
> -------------------------------
>
> If a deadline is approaching, and the discussion s almost concluded
> (in other words, it has not reached an impasse), and the consensus on
> the policy group is that an extension of a week would resolve the
> issues better, a one-time extension could be granted. Care should be
> taken in exercising this option, since abusing this would merely
> postpone closures.
Again, how will consensus be determined?
For an exceedingly contentious issue where it looks like progress is
being made, is the recommended procedure to extend debate for a week,
then formally table the proposal while continuing "informal" debate
until the proposal can formally be remade?
> 3.3.1. Impasse on Technical Issues
> ----------------------------------
>
> 3.3.2. Non Technical and Subjective Disagreements
> -------------------------------------------------
This is a possibly stupid question, but what distinguishes a technical
and non-technical issue? In particular, it is possible that a proposal
would consist of both technical and non-technical parts, not
necessarily distinct. I think this proposal is in itself an example of
this. If a consensus cannot be reached on such a proposal, which if
the two deadlock resolution strategies should be used?
> PROPOSAL: A mechanism for updating Debian Policy documents
> Manoj Srivastava<srivasta@debian.org> $Revision: 1.5 $
There are several things that should be addressed that aren't, like how
proposals are amended, if developers (although I would prefer
"sponsors") withdraw their seconds or sponsorship, if proposers can
withdraw proposals, etc.
Right now, it implies that proposals are all-or-nothing, no amendments
possible. If it were being proposed under it's own rules (which it
implicitly is), it doesn't allow for changes. However, since it is
obvious that there are technical details (like the necessary number of
seconds) that Manoj hasn't fully address, I'd have to oppose it, since
I think that sort of thing should be concrete in a proposal.
I hope I've been clear.
--
Buddha Buck bmbuck@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: