Re: PROPOSAL: A mechanism for updating Debian Policy documents
Hi,
>>"Buddha" == Buddha Buck <bmbuck@acsu.buffalo.edu> writes:
Buddha> In general, I liked the technical aspects of the proposal. I
Buddha> don't like the "voice" of the proposal, however. To me, it
Buddha> reads like a mixture of technical details, personal opinion,
Buddha> and rationale for the changes.
*Shrug*. And that is indeed what it is. I delibrately kep it
semi formal, since I do not think somethig like taking over the
policy documents needs be shrouded in legalese.
Buddha> I would prefer it if the technical content was decidedly
Buddha> separate from the non-technical content.
There si not that much technical content, IMHO, and I think
that though we need to move from the ad hoc process we had so far, I
did not want to make it that formal.
Buddha> I would also prefer it if the language used for the
Buddha> procedures were more "determinate" -- "A policy maintainers
Buddha> team _will_ [or _shall_] be selected who will have access..."
Buddha> rather than "I propose we select/install a group of
Buddha> people..."
What difference does it make?
Buddha> Unfortunately, this would require a massive amendment,
Buddha> equivilant to rewriting the whole thing. Unless requested, I
Buddha> don't feel confident to suggest such a massive amendment at
Buddha> this time.
Unless you provide a benefit gained from that process, I
propose you let it lie ... Do you have anything stronger than
preference driving this suggestion?
>> 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.
Buddha> How will consensus be determined? Will one opposing
Buddha> developer be able to force a deadlock? If not, how many?
Human judgement? Do we need formal methods, really? I trust we
have a modicum of common sense and decorum left. If people really are
in disagreement, they may formally voice an objection; the proposer
can then poll each objector and ask if their concerns have been
resolved. If not, we go to the vote. Yes, one opposing voice can ask
for formal deadlock resolution.
Shall I add this to the proposal?
Buddha> For an exceedingly contentious issue where it looks like
Buddha> progress is being made, is the recommended procedure to
Buddha> extend debate for a week, then formally table the proposal
Buddha> while continuing "informal" debate until the proposal can
Buddha> formally be remade?
I leave that up to the people on the policy list, to determine
on a case by case basis. Not everyhing need be codified.
Buddha> This is a possibly stupid question, but what distinguishes a
Buddha> technical and non-technical issue?
Judgement? Ask the technical committee, if they think this is
a non-technical issue, then it is so. I suspect we should be able to
tell them apart. If it involves programs, or standards conformance,
it is probably technical.
Buddha> In particular, it is possible that a proposal would consist
Buddha> of both technical and non-technical parts, not necessarily
Buddha> distinct.
Get the technical aspects resolved by the committee, than vote
on the rest.
Buddha> I think this proposal is in itself an example of this.
Umm, no. This is basically a procedural proposal, and it sets
policy. This is not the domain of the technical committee, this is
the domain of the policy group. We vote on this proposal.
Buddha> If a consensus cannot be reached on such a proposal, which if
Buddha> the two deadlock resolution strategies should be used?
See above. Ask the tech committee. They'll make a ruling.
>> PROPOSAL: A mechanism for updating Debian Policy documents
>> Manoj Srivastava<srivasta@debian.org> $Revision: 1.5 $
Buddha> There are several things that should be addressed that
Buddha> aren't, like how proposals are amended, if developers
Buddha> (although I would prefer "sponsors") withdraw their seconds
Buddha> or sponsorship, if proposers can withdraw proposals, etc.
This is way too heavy. This proposal is not meant to massively
change the way that the policy group has worked before. This merely
changes how things enter into the document. The policy group so far
has debated over the policy being proposed, and traded excerpts back
and forth, with the assumption that the originator of the idea merge
in changes.
I do not want to put the policy group in a straght jacket by
trying to codify and restrict how they work.
However, if we want to bring full parliamentary procedures
into the policy group, speak now. I think that anything that
convoluted should use the constitutional procedures anyway (which is
not defined by this document). The policy group has served well
without formal parliamentary procedures in place; and the
constitution already defines how one can go through parliamentary
procedures and get policy amended.
It would be nice to get the Project Leaders views on this
proposal.
Buddha> Right now, it implies that proposals are all-or-nothing, no
Buddha> amendments possible. If it were being proposed under it's
Buddha> own rules (which it implicitly is), it doesn't allow for
Buddha> changes. However, since it is obvious that there are
Buddha> technical details (like the necessary number of seconds) that
Buddha> Manoj hasn't fully address, I'd have to oppose it, since I
Buddha> think that sort of thing should be concrete in a proposal.
So propose your changes, and lets see what the others think
about it.
Do we formally need amendments? Would excessive bureaucracy
stifle the give and take of the policy group? Would not having formal
amendments require policy maintainers exercising editorial control?
Do we need more than two seconds? Personally, I think 3
proponets for an amendment is just right. Comments?
manoj
--
God is the tangential point between zero and infinity. Alfred Jarry
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: