Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation

[Manoj Srivastava <srivasta@debian.org>]

On Sat, 28 Oct 2006 10:58:09 +1000, Anthony Towns <aj@azure.humbug.org.au> 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
 overly bureaucratic.

        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
 things. 

> 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
> 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.

        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
 Gnus).

        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
 delegation. 

        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
 track record.

        manoj
-- 
"But what we need to know is, do people want nasally-insertable
computers?"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C