Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
On Sat, 28 Oct 2006 10:58:09 +1000, Anthony Towns <firstname.lastname@example.org> said:
> On Fri, Oct 27, 2006 at 07:57:20AM -0500, Manoj Srivastava wrote:
>> > 10:23 <aj> Manoj: will you be following the policy change
>> > procedure you created
>> > years ago? (file a bug marked wishlist with the
>> > changes you want, get a second on the -policy list,
>> > answer any comments, etc)
>> > 10:23 <Manoj> aj: nope. that is for others to tell me what to do.
>> Quite so. As I have explained already in another mailing list, the
>> policy process document is to ensure that the policy delegates do
>> not miss out on a proopsal or the discussion around it; it ensures
>> that I do not drop anything. Since I am driving thids review, there
>> is no need for me to do the BTS dance.
> The technical committee charter and the policy process both adopt
> the principle that the people making the change (the committee
> members and the policy editors respectively) 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.".
It is also nice to be able to give weight to domain expert
opinions. If we are discussing, say, policy about some aspect related
to the debian installer, and joeyh or frans pop provide input, and
even if fifty random people who never worked on the installer jump up
saying that that's not how the installer works, or, if it does, that
is not how it is supposed to work and, anyway , frans only said that
to hurt them -- it is nice to able to do more than just count up the
numbers of opinions voiced.
Why is this relevant? Well, the before the delegation, I had
no authority to abridge discussion even after we started going around
in circles. There was no way to give some opinions more weight than
others. That is why for years anything remotely controversial could
not be included in policy -- there was no way to do anything without
a near consensus.
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.
Since there was no authority for a moderator, the process was
After the delegation, the process followed changed -- people
have gotten changes into policy without doing the BTS dance, usually
for non-controversial and obvious changes that were no brainers.
Even no-trivial changes, if there is no controversy, have
gone in, since there is no reason to remain so bureaucratic. I
suppose I should have modified the document, but well, things were
working all right, and it is not on the top of the heap of the TODO
> That doesn't mean they can't do design work, just that if/when they
> do, they're expected to follow the same process anyone else would.
> AFAICS, that's got multiple benefits -- it means that the priveleges
> those people get over other developers are minor, it makes it easy
> for anyone to follow changes because all changes go through the same
> process, and it provides a consistent process which makes it simpler
> for everyone to deal with.
> 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
The old process, meant for pre delegation days, really should
be revised. It is not really followed in practice a whole lot, to be
This is not to say there is no review of content, for any
proposal. The actual review process happens on the mailing list.
Often, not all discussion makes it to the BTS, even for issues being
tracked by the BTS (which is why I have a full archive for policy in
What do we use the BTS for? Well, we use the BTS as a book
mark. Once an issue has gone beyond initial discussion, I ask
people to file a bug at wishlist so it does not get off my radar.
I often can't follow all the discussion in real time, and so
lose track of what status the proposal is at -- I'll get to
all of them when I catch up, but if someone figures out we have
consensus, and so marks up the bug on the BTS, it helps me prioritize
what I work on.
The getting three people to agree on something is just to cut
down on zany proposals that would otherwise accrue -- and again,
that is part of that document that we need to rethink in light of
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.)
>> > I'm not willing to let a delegation stand while if it's being
>> > used as a justification to not talk to other people; even if
>> > that's happening only hypothetically.
>> You do not have to justify your decisions to me, but I think it is
>> evident to anyone who reads the orc log that has been floating
>> around that I came into that discussion ranting about the release
>> policy, and said:
> Sure. But seriously, even ranting on IRC, having delegates
> repeatedly claim special priveleges to not need to consult with
> anyone else is beyond the pale for me. Even if you only talk about
> it but don't act on it, it sets up a precedent for other people to
> say "well it was okay for him, why not for me?" later.
This is not actually the case, as I have explained. The
review process is the critical issue here -- and the review is
carried out on the mailing list. This is not unique in Debian (no
BTS for legal that I am aware of).
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.
The old process of proposers and seconds is also something is
deem necessary -- if I do not have most developers on -policy
behind it, including the release team leads, the policy changes are
dead in the water. Formally asking two people to second this process
when we clearly need a heck of a lot more seems ... red tape.
The old document also sates that the whole process could be
stopped dead in its tracks by a single formal objection. And then we
deferred to the TC or took a vote. I think that is a flaw -- if
there are serious objections from a significant minority of active
members of the mailing list, sure, we should punt to the TC or a GR,
but not if there is one lone objection.
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. I think we need to re-examine when we should take the discussion
out of the mailing list and let more developers or the TC in, but I
do know the number ought to be greater than one.
Indeed, if I can't get at least a dozen people to sign off on
the final version, this process is dead.
> If that's not your view -- and I would have thought it wasn't -- I'd
> be happy to renew the delegation, but so far you haven't clearly
> said that.
You never so clearly asked :)
> (Personally, I'd rather have an additional three-seven people to
> delegate too; but I'm afraid I don't have any brilliant ideas on who
> that could be)
Good luck. I have been trying for 8 years to get help on
policy, but counting the changelog updates, I have had an abysmal
"But what we need to know is, do people want nasally-insertable
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C