Re: A proposal to revive the Policy document
Manoj Srivastava <srivasta@datasync.com> writes:
> >>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
>
> Ian> I disagree with Manoj wrt the level of formality required for
> Ian> maintaining the policy document.
>
> Then your is the first objection that I have seen regarding
> the proposal. If you wish to make this a formal objection, then under
> the proposal (which as yet has no standing) this would take the issue
> to a vote.
Woah woah woah. From reading Ian's comments, I'm more inclined to
think that Ian has misconstrued Manoj's proposal. Lets make sure we
all agree on exactly what that proposal says.
> Ian> I think we should have one or several policy editors who will produce
> Ian> a reasonable procedure to ensure that everyone is aware of discussions
> Ian> and their status. The editors would act as document editors do in the
> Ian> IETF, and make changes to the document when rough consensus was
> Ian> achieved.
Incidentally, it's instructive to compare the current flow of policy
topics with Manoj's propsed flow. Current flow:
* policy topic mentioned on debian-policy list
* ad hoc discussion
* policy maintainer may or may not pick up the topic as a proposed
bit of policy
* policy maintainer, once every 2 months or so, reformulates the
proposed topics as policy and summarizes them to the list
* more discussion ensues
* policy maintainer either shelfs it or puts it in policy, releases
a new version of the policy pkg
Manoj's flow (Manoj, I hope I got this right); note I didn't mark all
the states, I'm just looking to compare, not to exhaustively go over
every possible state transition:
* member of debian-policy list formulates a policy topic,
appropriately worded, and submits to BTS
* topic gets a second from the debian-policy list, or dies
* topic is discussed on the list, and amended as see fit by the
original proposer, with a limited time-to-live
* this dicussion should make apparent the validity of the topic; if
no compelling objections are made, and general agreement is reached,
the policy is "passed"
* a policy maintiainer updates policy in CVS, marks the topic as closed
* new policy package get snapshotted at some point
I just fail to see how Manoj's proposal is "formal" and the current
one is "informal". They are both quite informal. However, Manoj's
proposal is better:
* limits the discretionary power of a policy maintainer
* allows more than one policy maintainer
* provides "auditability" of policy topics (the old scheme was bad;
a lot of topics were just dropped, even with "seconds", for no
documented reason)
* audit trail (using the BTS)
* forces more focussed consideration of topics (time-limits)
As I see it, Manoj's proposal basically is devolving power back down
to the policy list, where it should be, without requiring a lot of
additional bureacracy or infrastructure or delay. Moreover, it
eliminates the "single point of failure" syndrome and debating society
aspects of this group.
> Ian> I don't think we need to have a formal process for ensuring that
> Ian> amendments are tracked etc. If the policy editors don't do a
> Ian> good job then the Technical Committee can overrule them, or in
> Ian> extremis decide in favour of someone else's request to take them
> Ian> over.
> I think I disagree. I think a process is indeed required,
> since designing a process is better than handling things ad hoc;
I would argue that we have always had a process, and that documenting
and agreeing on the process in the open is better than relying on the
judgement of a single party. And I fail to see how Manoj's proposal
is more "formal" than Christian's method. I would instead argue that
Manoj's proposal is explicit and open, whereas the former method was
opaque and cathedral-ish.
Mind you, Mssr Schwartz did do a great job. But why rely on
individual heroics? That doesn't seem robust nor scalable.
Even if we kept the old way, someone should still write out the
responsiblities and processes of the policy maintainer.
--
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
Reply to: