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

[Russ Allbery]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> Given these goals, what are the steps or stages to reach
>  there? Here is my take at the states of a state machine:

[...]

This proposal looks great to me.  I think using user tags is a good idea;
it's clearer than the current policy process, which occasionally uses tags
in non-intuitive ways (liked fixed) because user tags weren't available.

I like having a requirement for a clear language change up-front.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Manoj Srivastava]

On Sat, 28 Oct 2006 17:23:33 +1000, Anthony Towns
 said:  

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

I agree. And the place where people can here the arguments is
 the debian-policy mailing list; even under the old process, porposals
 were refined on the list, and areguments were put forth for and
 against alternate strategies that helped shape the final proposal;
 and the final proposal was what was put to the BTS, and seconded, and
 only the final polishing discussion ever made it to the BTS.

This is similar in nature to general resolutions: the
 arguments made on the debian-vote list are not what makes it to the
 vote.debian.org mailing list.


> 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 assume you can already think up a bunch of improvements to the
> above skeleton, but does the general shape match what you're
> thinking?

That is a good starting point. But if we are going to revamp
 the policy modification process, let us examine the goals, and the
 logical states of the state machine of a policy change use case.

Goals:
 1) The change should be technically correct, and consistent with the
rest of the policy document. This means no legislating the value
of Pi
 2) The change should not be too disruptive; if very many packages
become instantly buggy, then instead there should be a transition
plan.  There could be very rare exceptions to this rule, if the
current state is really untenable. In which case, though, the TC
should probably be involved.
 3) The change has to be reviewed in depth. The discussion should be
held in the open, where any one may contribute; a publicly
accessible, open mailing list which is archived should be fine.
 4) Any domain experts should be consulted, since not every policy
mailing list subscriber is an expert on everything, including
policy maintainers.
 5) The goal is rough consensus on the change, which should not be
hard if the matter is technical. Technical issues where there is
no agreement should be referred to the TC; non-technical issues
should be referred to the whole developer body, and perhaps
general resolutions lie down that path.
 6) Package maintainers whose packages may be impacted should have
access to policy change proposals, even if they do not subscribe
to policy.

This last bit is where I am slightly concerned -- we have
 never done a good job on early notification. However, with 15,000
 packages and climbing, putting the task of determining which packages
 are affected can be very burdensome on the active policy maintainers
 (heh).  I would suggest i

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

[Anthony Towns]

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 

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

[Manoj Srivastava]

On Sat, 28 Oct 2006 10:58:09 +1000, Anthony Towns  
said: 

> On Fri, Oct 27, 2006 at 07:57:20AM -0500, Manoj Srivastava wrote:
>> > 10:23  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  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 m

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

[Manoj Srivastava]

On Thu, 26 Oct 2006 16:08:48 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Manoj Srivastava writes ("Re: Proposal to delay the decition of the
> DPL of the withdrawal of the Package Policy Committee delegation"):
>> On Thu, 26 Oct 2006 12:28:51 +0100, Ian Jackson
>> <[EMAIL PROTECTED]> said:
>> > The TC could decide to make a new person the maintainer of the
>> > policy package.
>> 
>> You are correct, the TC could delegate their powers to any one.

> No, I mean according to the constitution 6.1(2) the TC is empowered
> to

> Since the TC is empowered to transfer a package between developers,
> the DPL is _not_ empowered to do so unless it's urgent.  See s5.1.

That is only when there is a dispute between developers about
 who is the maintainer. Having the TC initiate such a process to strip
 away a package from a developer is over reachin itself.

>> However, the people who maintain the policy package are still the
>> maintainers -- and while they cannot make normative changes to
>> policy,

> The people who maintain the policy package _are_ empowered to make
> normative changes to policy.  I don't see how any other reading of
> 3.1(1) is possible, whether or not the policy maintainers are
> Delegates.

When changing policy, the technical decisions being made
 affect far more than their own work. So no, I don't think that it
 applies to the policy package, and that is an exception to the rule.

> You might say that only the TC has the power to make normative
> changes to policy (is that what you're saying?) but this is
> obviously absurd given 6.3(6):

>Technical Committee makes decisions only as last resort.

That, indeed, is true, as also borne out by experience. But
 unless the DPL or the TC delegate away modification of policy, policy
 will change only as a last resorrt, or if the issue is brought before
 them. So, in effect, the developers can, in a new policy process,
 bring each proposal before the TC, which can rule on it and elect
 change, or not change, the policy.

> So the TC's power to determine policy is to overrule the policy
> maintainers, not to stand in for them.  The TC is far too cumbersome
> for use as the first-line of decisionmaking.

That is not what the constitution says.

> Also, if you think that according to the constitution only the TC
> has the power to make normative changes to policy, what makes you
> think the defined `policy process' has any legitimacy ?

It has none. 

manoj
-- 
The difference between a career and a job is about 20 hours a week.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Ian Jackson]

Manoj Srivastava writes ("Re: Proposal to delay the decition of the DPL of the 
withdrawal of the Package Policy Committee delegation"):
> On Thu, 26 Oct 2006 12:28:51 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 
> > The TC could decide to make a new person the maintainer of the
> > policy package.
> 
> You are correct, the TC could delegate their powers to any
>  one.

No, I mean according to the constitution 6.1(2) the TC is empowered to

   Decide on any technical matter where Developers' jurisdictions
   overlap.

   In cases where Developers need to implement compatible ... stances
   (for example, if they disagree about ... who should be the
   maintainer for a package), the technical committee may decide the
   matter.

Since the TC is empowered to transfer a package between developers,
the DPL is _not_ empowered to do so unless it's urgent.  See s5.1.

> However, the people who maintain the policy package are still
>  the maintainers -- and while they cannot make normative changes to
>  policy,

The people who maintain the policy package _are_ empowered to make
normative changes to policy.  I don't see how any other reading of
3.1(1) is possible, whether or not the policy maintainers are
Delegates.

You might say that only the TC has the power to make normative changes
to policy (is that what you're saying?) but this is obviously absurd
given 6.3(6):

   Technical Committee makes decisions only as last resort.

So the TC's power to determine policy is to overrule the policy
maintainers, not to stand in for them.  The TC is far too cumbersome
for use as the first-line of decisionmaking.

Also, if you think that according to the constitution only the TC has
the power to make normative changes to policy, what makes you think
the defined `policy process' has any legitimacy ?

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Manoj Srivastava]

On Thu, 26 Oct 2006 12:28:51 +0100, Ian Jackson <[EMAIL PROTECTED]> said: 

> Debian Project Secretary writes ("Re: Proposal to delay the decition
> of the DPL of the withdrawal of the Package Policy Committee
> delegation"):
>> There are three ways policy can be changed:
>> a) The Technical ctte can do so
>> b) A group of developers can do so, via a GR, with a 2:1 super
>> majority (essentially, making the decision the tech ctte can make
>> -- think of it as over riding inaction)
>> c) The DPL can delegate people with the power to change policy.

> The TC could decide to make a new person the maintainer of the
> policy package.

You are correct, the TC could delegate their powers to any
 one.

However, the people who maintain the policy package are still
 the maintainers -- and while they cannot make normative changes to
 policy, they are still able to fix packaging bugs,  and fix
 typographical errors (which is why the FTP master decision to add
 REJECT rules is wrong, and over reaching).

Can you quote to me the section of the constitution under
 which you think the TC can strip a package away from a maintainer?
 Even overruling a maintainer requires the TC to act with 3:1
 majority, stripping away a package from a maintainer is a power I
 have not seen mentioned.

If you ask how the TC may delegate away it's powers to make
 policy changes, I can see the TC delegate making normative changes to
 the policy, and then the maintainers of the policy package can take
 that and upload the changed policy, as one scenario.

manoj
-- 
QOTD: "I used to go to UCLA, but then my Dad got a job."
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]