On Fri, Oct 27, 2006 at 10:01:26PM -0500, Manoj Srivastava wrote:
> > The technical committee charter and the policy process both adopt
> > the principle that the people making the change [..] only act in an
> > editorial capacity -- reviewing changes and committing them
> > appropriately, but not do actual design work in their formal hats.
> But they also take the lead in discussions, and can and do
> decide if there are opposing opinions as to which opinion carries
> the day. Part of taking lead in the discussion is having the ability
> to say "Stop, we have heard all arguments on this already, based on
> the current positions of people on the list, this option is what we
> shall decide to do.".
Agreed absolutely.
The only point I'm emphasising is that you don't just have to hear the
arguments, you have to ensure they're made somewhere that others can
hear them too.
> Understand this: the old policy process proposal was written
> in this atmosphere. If you read back in the archives, you'll find
> that I did mention back in those days (and often later as well) that
> we had to walk softly, since we had no real constitutional authority
> to be changing at all.
Okay, that seems pretty clearly an untenable situation.
> Since there was no authority for a moderator, the process was
> overly bureaucratic.
My assumption had always been that the maintainers of debian-policy
would act as moderators.
> > You said on IRC yesterday that you'd consider treating the current
> > discussion as pre-proposal stuff, and follow the proper process once
> > a conclusion was reached -- that sounds fine to me, but continually
> > reserving the right not to do the "BTS dance" doesn't. If the
> > process isn't suitable for the policy editors, it should be changed
> > for everyone, rather than a short cut setup for the
> > delegates/editors/ctte.
> The old process, meant for pre delegation days, really should
> be revised. It is not really followed in practice a whole lot, to be
> honest.
It was followed while bugs were actively incorporated into policy; iirc
that stopped for a while, and never really resumed. I couldn't say what
the correct process for getting a change into policy would be now (well,
two weeks ago), beyond "post to -policy, and talk to Manoj".
> The stress should be on review, rough consensus, input from
> domain experts, sane, _contained_ discussion, and technical
> correctness being the goal, not popularity of opinion. The old
> process did not really ensure any of this (apart from a nebulous
> consensus as a goal.)
Absolutely, though consensus should still be a goal, of course.
> I never said there will be no review. Indeed, since I am
> conducting this process, the review has to be even more strict -- I
> dare not abridge discussion nor decide what is expert testimony as
> readily as I would in a discussion I was not involved in.
I don't think that's a desirable situation either; if a policy delegate
wishes to put forward a change, a different delegate should be around
to moderate discussion appropriately.
> In the old days, I had no authority to overrule even a single
> objection. Now I think that Debian has changed -- no matter what the
> issue, you can probably find a handful of very vocal people to block
> it.
Heh.
So does something like the following sound plausible?
1. Trivial policy updates that don't change the substance of policy
(markup changes, fixing typos) will be made by the policy maintainers
as they see fit.
2. Other changes will have a patch submitted against a bug assigned
to the debian-policy package in the BTS, and forwarded on to any
developers specifically affected by the proposed changes.
3. Once three developers or one of the policy maintainers (other than
the proposer) have indicated they support the proposed change,
the bug can be tagged "confirmed", and will then be reviewed by
the policy maintainers as a group.
4. If the policy maintainers are satisfied with the proposed change, the
patch will be committed to the policy revision control system and
the bug will be tagged "pending".
5. If at any point the policy maintainers are not satisfied with
the proposed change or the reasoning behind it, they may make
suggestions tag the bug "wontfix", and/or close the bug.
6. Policy should be designed to meet the concerns of all developers, and
all suggestions should be taken into account as far as possible.
That has a single process that applies to everybody, seems reasonably
quick for changes the maintainers propose, works even if there's only
one active policy maintainer, and requires at least one person other than
the proposer to review every change.
I'd suggest closing bugs that have been open for too long or seen too
much discussion with a message like "If this change is still desired,
please open a new bug with a brief summary of discussion to date and the
latest proposal". I'd be inclined to count every bug older than 90 days
or a year or so under that, personally.
I assume you can already think up a bunch of improvements to the above
skeleton, but does the general shape match what you're thinking?
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature