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

[Martin Wuertele]

I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.

My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.

[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html

yours Martin

[John Goerzen]

Post by Martin Wuertele
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.

I don't get it.

You want to override a decision not because the decision is bad on its
face, but because of a *guess* as to the reason for it?

That makes no sense. What difference does the reason make? If it's a
good decision, then let it stand. If it's a bad decision, then let it
not.

Do you believe it's a bad decision, and if so, why?

-- John

[Martin Wuertele]

Post by John Goerzen
You want to override a decision not because the decision is bad on its
face, but because of a *guess* as to the reason for it?
That makes no sense. What difference does the reason make? If it's a
good decision, then let it stand. If it's a bad decision, then let it
not.
Do you believe it's a bad decision, and if so, why?

I belivie it is a baddecision because
- it looks to be based on personal differences on the way to interprete
the policy
- it prevents us to apply changes to the policy for an undefined time
- with a very week argument

If the rational behind the withdrawal was the lack of enough active
members removing inactive members and adding active ones would have been
the sane solution.

yours Martin

[Joerg Jaspert]

On 10818 March 1977, Martin Wuertele wrote:

Seconded. The whole quote below. Ie the full proposal.

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2]http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html

[Kalle Kivimaa]

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.

Actually, we really cannot vote on this as such, as the Secretary has
already ruled [1] that the DPL has no power to delegate the
responsibility for the policy manual, as that would contradict the
powers of the Technical Committee. So, AIUI any vote should first be
taken on the ruling on the constitution, as I don't think we can force
the DPL (or the ftpmasters) to take an unconstitutional action.

We can of course force the DPL to allow the TC members to have upload
access to debian-policy.

[1] http://lists.debian.org/debian-policy/2006/10/msg00164.html

[Debian Project Secretary]

Post by Kalle Kivimaa

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the
Debian constitution to delay the decision of the Debian Project
Leader keeping the Package Policy Committee as defined[2] in place
until the Debian Project Leader has found at least three people
"who'll be active in maintaining policy according to the policy
process"[3] and delegates them. Consequently the REJECT for uploads
of debian-policy must be removed.

Actually, we really cannot vote on this as such, as the Secretary
has already ruled [1] that the DPL has no power to delegate the
responsibility for the policy manual, as that would contradict the
powers of the Technical Committee. So, AIUI any vote should first be
taken on the ruling on the constitution, as I don't think we can
force the DPL (or the ftpmasters) to take an unconstitutional
action.

Sorry, that is not the intended ruling. The ruling was in
answer to a query about a random group of undelegated developers
changing policy, which would be unconstitutional.

Post by Kalle Kivimaa
We can of course force the DPL to allow the TC members to have
upload access to debian-policy.

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.

manoj

[Kalle Kivimaa]

Post by Debian Project Secretary
Sorry, that is not the intended ruling. The ruling was in
answer to a query about a random group of undelegated developers
changing policy, which would be unconstitutional.

OK, so the constitution allows the DPL to delegate any authority to a
delegate? Ie. the DPL could delegate somebody to overrule developers
on technical actions (6.1.4) or adjudicate disputes about
interpretation of the constitution (7.1.3). I did read the
constitution so that the DPL may not delegate authority that belongs
to somebody else according to the constitution.

I did think that you were referring to a future DPL delegation when
you answered to aj, but I guess you were referring to the REJECT.

Post by Debian Project Secretary
As per that interpretation, I've added a REJECT for uploads of
debian-policy. I won't be looking into formally creating a new
delegation 'til after etch has released, at which point I hope we
can find at least four people who'll be active in maintaining policy
according to the policy process we've had for quite some time.
This presupposes that you have either managed to change the
constitution, or replaced the secretary with one whose views are in
line with yours -- since under current wording of the constitution,
that would be unconstitutional.

[Ian Jackson]

Post by Debian Project Secretary
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.

Ian.

[Manoj Srivastava]

Debian Project Secretary writes ("Re: Proposal to delay the decition
of the DPL of the withdrawal of the Package Policy Committee

Post by Debian Project Secretary
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

[Ian Jackson]

Post by Manoj Srivastava

Post by Ian Jackson
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.

Post by Manoj Srivastava
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.

[Manoj Srivastava]

Manoj Srivastava writes ("Re: Proposal to delay the decition of the

On Thu, 26 Oct 2006 12:28:51 +0100, Ian Jackson

Post by Ian Jackson
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
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

[Ian Jackson]

Manoj, your conflict of interest here is too severe, I think.

Would you please formally delegate the interpretation of the
constitution with respect to maintenance of policy to someone else ?

I don't think you've been grinding your own axe here but, I would like
to ask you to do us a favour and present the appearance of propriety
as well as the fact of it.

Ian.

[Manoj Srivastava]

Manoj, your conflict of interest here is too severe, I think. Would
you please formally delegate the interpretation of the constitution
with respect to maintenance of policy to someone else ?
I don't think you've been grinding your own axe here but, I would
like to ask you to do us a favour and present the appearance of
propriety as well as the fact of it.

Duly noted. But since the secretary's job routinely involves
running votes and DPL elections in which I have strong opinions, and
interpreting the constitution is an integral part of the process, I
would not be secretary if I did not think I could do my job
impartially despite that.

If it appears to me that my judgement as secretary is being
affected, I shall immediately recuse myself and delegate the power.

manoj

[Sven Luther]

Post by Manoj Srivastava

Manoj, your conflict of interest here is too severe, I think. Would
you please formally delegate the interpretation of the constitution
with respect to maintenance of policy to someone else ?
I don't think you've been grinding your own axe here but, I would
like to ask you to do us a favour and present the appearance of
propriety as well as the fact of it.

Duly noted. But since the secretary's job routinely involves
running votes and DPL elections in which I have strong opinions, and
interpreting the constitution is an integral part of the process, I
would not be secretary if I did not think I could do my job
impartially despite that.
If it appears to me that my judgement as secretary is being
affected, I shall immediately recuse myself and delegate the power.

I fear that your judgement to notice such conflict of interest is not so good
as you think, since this is already the second time in a few weeks you are at
the extreme limit of this boundary.

Sven Luther

[Steve Langasek]

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.

So you think it's wrong for the DPL to overrule the policy delegate because
of a disagreement, and therefore in your disagreement you wish to overrule
the DPL?

Two wrongs don't make a consensus.

[Martin Schulze]

Post by Steve Langasek

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.

So you think it's wrong for the DPL to overrule the policy delegate because
of a disagreement, and therefore in your disagreement you wish to overrule
the DPL?

I'd rather interpret the proposal as:

s/overrule/postpone the decision of/
until new CTTE people have been assigned.

Regards,

Joey

[Martin Schulze]

Seconded.

Regards,

Joey

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html
yours Martin

[Frank Küster]

Dear Anthony, dear all,

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader [...]

Could we all please stop this? I feel that this slowly turns into a
feud between nobody knows which groups and is eating up Debian and the
fun to work on it. It is going to harm Debian, and also the current
release process..

I have not seen an explanation by the DPL why he withdrew the policy
delegation. But even if I had, I don't think it would change much.

Anthony, I ask you as the DPL, please delay that decision yourself, thus
making this "stupid" voting process unnecessary.

Regards, Frank

[Anthony Towns]

Post by Frank Küster
I have not seen an explanation by the DPL why he withdrew the policy
delegation. But even if I had, I don't think it would change much.

You didn't see much explanation when the delegation was announced either;
nor any effect as a result of it -- Manoj continued editing policy, the
previous co-editors continued not contributing, and the new co-delegates
participated a little on the mailing list, then more or less vanished.

What has happened since is that the delegation has apparently been taken
as a mandate for the policy editors to set policy according to their own
opinion without any obligation to consult each other, or the developers
as a whole. I'm not willing to have delegations exist in that way.

Post by Frank Küster
Anthony, I ask you as the DPL, please delay that decision yourself, thus
making this "stupid" voting process unnecessary.

The process is already unnecessary, Manoj can continue to maintain policy
through his membership in the technical committee, and the only reason he
can't revert to the process that's was used since mid '98 until mid last
year is that he's put his secretary hat on and read a new interpretation
into the constitution that retroactively disallows that.

Cheers,
aj

[Ian Jackson]

Post by Anthony Towns
The process is already unnecessary, Manoj can continue to maintain policy
through his membership in the technical committee,

This is unfortunately not true. We'd have to discuss and vote on
every change and I don't think we want to do that. If it comes to
that we will probably delegate someone ourselves.

Post by Anthony Towns
and the only reason he can't revert to the process that's was used
since mid '98 until mid last year is that he's put his secretary hat
on and read a new interpretation into the constitution that
retroactively disallows that.

I agree that this situation is unfortunate.

Post by Anthony Towns
What has happened since is that the delegation has apparently been taken
as a mandate for the policy editors to set policy according to their own
opinion without any obligation to consult each other, or the developers
as a whole. I'm not willing to have delegations exist in that way.

Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

Ian.

[Manoj Srivastava]

On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

manoj

[Anthony Towns]

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to comments
from the technical committee".

Cheers,
aj

[Frank Küster]

Post by Anthony Towns

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to comments
from the technical committee".

Manoj sometimes gives the impression of not listening, because he
doesn't "nod" and say "yes, hm" by e-mail. But if you assert that he is
in fact not listening and not taking into consideration what he hears,
you should back up this claim with some references. I have the opposite
impression: The bugs that get no answer in the BTS are fixed soon, only
those that he discusses might be tricky, or he reluctant to fix them.

Regards, Frank

[Anthony Towns]

Post by Anthony Towns

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to comments
from the technical committee".

Manoj sometimes gives the impression of not listening [...]

Err, I mean Ian meant "(take on board) (comments)", and Manoj appears to
have misinterpreted that as "(take on) (Board comments)". Nothing more.

Cheers,
aj

[Frank Küster]

Post by Anthony Towns

Post by Anthony Towns

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to comments
from the technical committee".

Manoj sometimes gives the impression of not listening [...]

Err, I mean Ian meant "(take on board) (comments)", and Manoj appears to
have misinterpreted that as "(take on) (Board comments)". Nothing more.

I'm not familiar with the expression "take on board", but according to
dict.leo.org you are still asserting that he does not take into
consideration comments by others. I repeat what I wrote:

,----
| But if you assert that he is in fact [...] not taking into
| consideration what he hears, you should back up this claim with some
| references. I have the opposite impression
`----

Regards, Frank

[Anthony Towns]

Post by Frank Küster

Post by Anthony Towns

Post by Anthony Towns

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to comments
from the technical committee".

Manoj sometimes gives the impression of not listening [...]

Err, I mean Ian meant "(take on board) (comments)", and Manoj appears to
have misinterpreted that as "(take on) (Board comments)". Nothing more.

I'm not familiar with the expression "take on board", but according to
dict.leo.org you are still asserting that he does not take into

I'm asserting nothing of the kind. Ian might be, but I'm not.

Cheers,
aj

[Frank Küster]

Post by Anthony Towns

Post by Frank Küster

Post by Anthony Towns

Post by Anthony Towns

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone who
was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have
been disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to comments
from the technical committee".

Manoj sometimes gives the impression of not listening [...]

Err, I mean Ian meant "(take on board) (comments)", and Manoj appears to
have misinterpreted that as "(take on) (Board comments)". Nothing more.

I'm not familiar with the expression "take on board", but according to
dict.leo.org you are still asserting that he does not take into

I'm asserting nothing of the kind. Ian might be, but I'm not.

Sorry, I was confused because you answered as if you could read Ian's
mind, so I must have concluded you were the same person.

Regards, Frank

[Manoj Srivastava]

Post by Anthony Towns

Post by Manoj Srivastava
On Thu, 26 Oct 2006 16:17:05 +0100, Ian Jackson

Post by Ian Jackson
Perhaps it would be better if the policy maintainer were someone
who was more willing to listen and take on board comments ?

This sounds like a canard. What official Board comments have been
disregarded by the current set of policy maintainers? Or do you
mean "Ian wants a Yes Man"?

Ian meant "take comments under consideration", not "listen to
comments from the technical committee".

I always take all comments under consideration.

manoj

[Manoj Srivastava]

Post by Anthony Towns
What has happened since is that the delegation has apparently been
taken as a mandate for the policy editors to set policy according to
their own opinion without any obligation to consult each other, or
the developers as a whole. I'm not willing to have delegations exist
in that way.

Can you cite any instance that his has actually happened? Or
is this a proactive action based on speculation of the future? Has
there ever been any change acecepted into policy that was not
reviewed?

Post by Anthony Towns

Post by Frank Küster
Anthony, I ask you as the DPL, please delay that decision yourself,
thus making this "stupid" voting process unnecessary.

The process is already unnecessary, Manoj can continue to maintain
policy through his membership in the technical committee, and the
only reason he can't revert to the process that's was used since mid
'98 until mid last year is that he's put his secretary hat on and
read a new interpretation into the constitution that retroactively
disallows that.

I do not think there was a new interpretation. I The old
policy process was continuing since despite my appeals, no DPL ever
delegated policy editing powers away, and policy desperately needed
fixing.

I decided to do something that was constitutionally untenable
because I deemed not modifying policy as being worse for the
project. Lesser of two evils and all that. If policy bit rots again
as itdid when Christian left, I suppose I'll countenance breaking the
constitution again, in order to get policy fixed.

But then, _anyone_ could just NMU the policyu package, I
suppose, if the constitutional violation does not bother them.

manoj

[Anthony Towns]

Post by Manoj Srivastava

Post by Anthony Towns
What has happened since is that the delegation has apparently been
taken as a mandate for the policy editors to set policy according to
their own opinion without any obligation to consult each other, or
the developers as a whole. I'm not willing to have delegations exist
in that way.

Can you cite any instance that his has actually happened?

Yes, you claimed that you didn't need any review because you were a
delegate on IRC. You went on to ask for comments on IRC anyway, and you
might well have done so on the lists anyway, but that's not enough:
getting review from other developers is a requirement for acting in
the name of the project, whether that be in documenting the project's
technical policies or in any other way.

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.
10:25 <Manoj> policy delegates can make changes to policy, that is their
jurosdiction

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.

Cheers,
aj

[Frank Küster]

Post by Anthony Towns

Post by Manoj Srivastava

Post by Anthony Towns
What has happened since is that the delegation has apparently been
taken as a mandate for the policy editors to set policy according to
their own opinion without any obligation to consult each other, or
the developers as a whole. I'm not willing to have delegations exist
in that way.

Can you cite any instance that his has actually happened?

Yes, you claimed that you didn't need any review because you were a
delegate on IRC.

I think that basing a decision with the DPL hat on just on what someone
says on IRC is a bad idea. And of course you've been told multiple
times that this didn't mean "no public review", but instead "no review
through the normal review process".

Post by Anthony Towns
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 were acting in anger. You did not wait and talk with your delegate
again the other day. I think a leader should not act in anger, but
should take the time for talking.

Regards, Frank

[Anthony Towns]

Post by Frank Küster

Post by Anthony Towns
Yes, you claimed that you didn't need any review because you were a
delegate on IRC.

I think that basing a decision with the DPL hat on just on what someone
says on IRC is a bad idea.

IRC channels are used for official project business; the only difference
between them and mailing lists is technical.

Cheers,
aj

[Frank Küster]

Post by Anthony Towns

Post by Frank Küster

Post by Anthony Towns
Yes, you claimed that you didn't need any review because you were a
delegate on IRC.

I think that basing a decision with the DPL hat on just on what someone
says on IRC is a bad idea.

IRC channels are used for official project business; the only difference
between them and mailing lists is technical.

I am not in IRC very frequently, but I have been there often enough to
be convinced that this is very wrong. There's a big social difference
between mailing lists and IRC. And both are different to meeting in
person or talking on the phone.

Should we found a group that collects money to pay the DPL's phone bill
if he needs to give certain fellow DDs a call?

Regards, Frank

[MJ Ray]

Post by Anthony Towns
IRC channels are used for official project business; the only difference
between them and mailing lists is technical.

such as ease of access, archival, peer review...

[Raul Miller]

I just want to say that I am deeply dismayed by the turn events
have been taking.

I have a lot of respect for both A.J. and Manoj.

But I don't see a reasonable basis for this disagreement -- this
feels more like venting under high pressure (mostly the Etch
release, I think).

In that context, if I might take some liberties with each of their
earlier position statements:

AJ: 'decisions specific to this release should be thought about
before they're applied to future releases.'

Manoj: 'decisions specific to this release have relevance both
now and in the context of future releases'

Of course, more is involved here than just position
statements. In addition to talking past each other,
each seems to be taking action as he sees fit. [Which,
frankly, is how we are supposed to approach problems.]

Both statements are correct. Potential decisions made
incorrectly under the aegis of either position are survivable.
Albeit, painfully -- this entire process seems painful.

I'm not going to recommend anything here -- I think that this
whole situation is the rather inevitable fallout which tends
to follow in the wake of mis-communication. And,
recommendations do not solve mis-communication.

[Manoj Srivastava]

Post by Anthony Towns

On Thu, 26 Oct 2006 23:40:52 +1000, Anthony Towns

Post by Anthony Towns
What has happened since is that the delegation has apparently
been taken as a mandate for the policy editors to set policy
according to their own opinion without any obligation to consult
each other, or the developers as a whole. I'm not willing to have
delegations exist in that way.

Can you cite any instance that his has actually happened?

Yes, you claimed that you didn't need any review because you were a
delegate on IRC.

This is a mischaracterization of what was actually said, as
you have been informed about several times. Look, I am not going to
argue with you the merits of your delegations; they are your
decisions to make. I shall, however, now that you bring this up,
point to what I consider are lacunae in your rationale.

Post by Anthony Towns
You went on to ask for comments on IRC anyway, and you might well
have done so on the lists anyway, but that's not enough: getting
review from other developers is a requirement for acting in the name
of the project, whether that be in documenting the project's
technical policies or in any other way.

Dude, if you think all I have done is ask on IRC for review of
proposed policy changes, then you have selective amnesia: you even
responded to the threads on -policy and on -devel that I opened for
the review process.

Post by Anthony Towns
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.

Post by Anthony Towns
10:25 <Manoj> policy delegates can make changes to policy, that is their
jurosdiction

Right. The changes have always been up for public review, but
the final act is the policy delagate taking the changes discussed and
making changes to the technical policy manual. People contributing
on -policy and proposing, modifying, and reviewing proposals do not,
on their own, have the right to modify technical policy -- that used
to lie in the realm of policy delegates.

Post by Anthony Towns
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:
"where are the etch rc directives url again? I have some time;
I'll loboitomize policy to follow those directives exactly."
"policy is being degraded down to match the rc criteria"

Note that the stated goal was to make policy match the release
criteria: and the commentary was more a reflection of my opinion of
the release policy than anything else. (I should apologize to ABA and
Steve; on closer inspection, the release policy is quite sane).

I now realize that this must also have angered you, since the
release policy has its genesis in something you created. So I
apologize to you, too, for denigrating something you created.

I think the rest of the fiasco proceeded from your feeling of
anger (this is speculation on my part, of course). I do question the
judgement of basing you decisions on what was obvious to everyone as
"jus Manoj blowing off steam, he'll calm down in an hour"; you have
been around on previous occassions where I have ranted at length on
IRC (though perhaps not on things you might have been invvolved in
creating).

manij

[Anthony Towns]

Post by Manoj Srivastava

Post by Anthony Towns
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.

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.

Post by Manoj Srivastava

Post by Anthony Towns
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

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.

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.

(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)

Post by Manoj Srivastava
Note that the stated goal was to make policy match the release
criteria: and the commentary was more a reflection of my opinion of
the release policy than anything else. (I should apologize to ABA and
Steve; on closer inspection, the release policy is quite sane).
I now realize that this must also have angered you, since the
release policy has its genesis in something you created. So I
apologize to you, too, for denigrating something you created.

Thankyou, that's very gentlemanly.

I said this on IRC yesterday, but I'll repeat it here: in spite of any
disagreements we have, I think you do a good job both as secretary and
policy maintainer -- and in particular in removing the delegation I'd
expected you to be able to continue working on it in the same way you
had done prior to the delegation. Your weird perl one-liners on IRC
were one of the things that attracted me to Debian in the first place,
and while I certainly put you in the "crusty, irascible, cantankerous
old person full of stubborn ideas" box, I *like* Debian's curmudgeons...

Cheers,
aj

[Manoj Srivastava]

Post by Anthony Towns

Post by Anthony Towns
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.

Post by Anthony Towns
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.)

Post by Anthony Towns

Post by Anthony Towns
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

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.

Post by Anthony Towns
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 :)

Post by Anthony Towns
(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

[Anthony Towns]

Post by Manoj Srivastava

Post by Anthony Towns
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.

Post by Manoj Srivastava
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.

Post by Manoj Srivastava
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.

Post by Manoj Srivastava

Post by Anthony Towns
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".

Post by Manoj Srivastava
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.

Post by Manoj Srivastava
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.

Post by Manoj Srivastava
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

[Manoj Srivastava]

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

Post by Anthony Towns

Post by Anthony Towns
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.

Post by Anthony Towns
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 instead a Weekly Policy News, or the Policy
Monthly Gazette, or something, that people may subscribe to for a low
volume announcement list. Indeed, it can be an announce only list,
and a synopsis of the proposal and a rationale can be posted to it
when we reach the stage where the proposal is nearing the final form.

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

State A: There is a gap in current policy. For example, if there are
potentially several technically viable options that can be
taken, and it would help integration if all packages
affected can rely on one solution, it would help
integration.
Any user or developer should be able to point to such a deficiency,
and this can be an injection point of a policy change into the
system. There is a decision point here: some issues raised might not
be in the purvue of a policy change (I do not like the name
iceweasel, policy should prevent ice and a rodent in the name of any
package). This state is optional, some proposals can go right to
stage B

State B: Initial suggestions for a policy to address some such
need. This may not have formal policy language yet, or a
diff against current policy.

This is when discussion happens, alternate proposals are floated, and
the nitty-gritty details of policy creation are done. Policy
delegates, if any, should guide, but not control, this discussion;
they can help nudge the process along if the discussion has reached
an impasse, suggesting one alternative or the other. The guidance
could stop a circular discussion in which no new arguments are
forthcoming and decide in favour of the majority opinion, for
instance, to prevent a vocal minority from derailing the
process. Much care has to be exercised here, and we should probably
come up with a means for appealing any thing -- to another policy
delegate, perhaps?

If there is an arcane technical area involved, and there are domain
experts for that area, we may optionally go to:

Stage C: Solicit domain expert input. In most cases, it is easy to
determine who the domain experts are; usually the maintainer
of related packages either are domain experts or can point
to domain experts. This state is optional, and has two exit
points: either we get the domain expert testimony, and
perhaps a dialogue ensues, or we time out (I mean, domain
experts need not pay attention to us, etc)

At this point, there should either be the case where we have a fair
idea of what change is required, or have come to the conclusion we
can't agree. There should be support from three developers at this
point, before we proceed to the next phase (or a developer and a
delegate -- dunno if we should really special case the delegate here)

State D: Formal change language is created for the policy change, any
transition plans are sketched in, a rationale is attached as
a footnote, if appropriate, for future reference. At this
point, the policy change goes to the Policy Gazette, so
other people affected may join the discussion, if they
please.

State E: The proposal is sponsored by three developers.

States D and E may happen in any order, but both are required before
we move to the next state.

Final discussions happen here. There should be ample time for people
who are affected by this change to have read the Gazette and come in
to voice their inputs; final refinements to the language happen now.
This is again a decision point; either we have a rough consensus, or
we need to send the initial problem, and the fact we can't agree, off
to the TC or the developer body at large.

State F: the change is accepted, and is waiting for the next policy
update (which may not happen for a while, for example, if
policy is frozen fro a release).

State G: Not policy decision
Stage H: Time out, no formal policy language ever proposed
State I: referred to TC
State J: referred to debian-devel
State K: Rejected by delegates

Now, coming back to procedures. Should all states in the above
state machine be tracked in the BTS? From past experience, even
though the old policy process had state tracking via the BTS, most
people never did track state B -> state D changes in the BTS. Things
like state C tracking in the BTS seem like a lot of red tape.

User tags would be great for tracking flow of a change through
the state machine, though. We can leave severities well enough alone:
the severity can reflect a consensus of how critical a policy change
is, in the eyes of the proposer and debian-policy regulars, and
unrelated to the progress the proposal has made, which is tracked by
usertags and user categories.


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. Flaws/Defects in policy should have a normal or important bug
filed against policy in the BTS. The usertag is the one reserved
for "State A", unless 4. applies.

3. Gaps in policy should be filed with a wishlist priority. Usertag
is still the one reserved for "State A", unless 4. applies.

4. If a solution for the gap or flaw is also proposed initially, the
usertag is the one related to "State B", skip to 6.

5. Discussion on the gap/defect happens, and a tentative solution is
proposed. the usertag is the one related to "State B".

6. Input is solicited from domain experts, as needed. Time is
allowed for such experts to provide input.

7. Once three developers or one of the policy maintainers (other than
the proposer) have indicated they support the proposed change,
usertag corresponding to stage E is added.

8. Formal policy language is specified for the bug. usertag
corresponding to stage D is added. At this point, this Bug gets
sent to the policy-announce mailing list. Final reviews and
discussions start.

9. Policy should be designed to meet the concerns of all developers,
and all suggestions should be taken into account as far as
possible. If the policy maintainers are satisfied with the
proposed change, the patch will be committed to the policy
revision control system. The usertag corresponding to "State F"
is added.

10. If policy maintainers think that the proposed change does not
meet the concerns of all maintainers, or no formal language or
solution can be agreed upon, the may forward the issue to the TC or
the developer body; usertags for States H, I, or J may be added.

11. 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. The
usertag for state K is added.


manoj

[Josselin Mouette]

Hurray for another vote. Or how stupid management decisions bring us in
endless discussion loops.

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html

Seconded.

[Mike Hommey]

Seconded

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html
yours Martin

[Julien BLACHE]

Martin Wuertele <***@debian.org> wrote:

Hi,

I hereby second the proposal quoted below.

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html

JB.

[Bas Zoetekouw]

Hi Martin!

Seconded.

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html
yours Martin

[Alexander Wirt]

Martin Wuertele schrieb am Mittwoch, den 25. Oktober 2006:

I second the quoted proposal

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html
yours Martin

Alex

[Gerfried Fuchs]

Seconed.

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html

So long,
Alfie

[Benjamin Seidenberg]

I second this proposal (quoted below).

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html
yours Martin

[Martin Zobel-Helas]

*seconded*

Post by Martin Wuertele
I disagree with the Policy delegation decision of our DPL [1] and
therefore propose a resolution as defined in section 4.2.2 of the Debian
constitution to delay the decision of the Debian Project Leader keeping
the Package Policy Committee as defined[2] in place until the Debian
Project Leader has found at least three people "who'll be active in
maintaining policy according to the policy process"[3] and delegates
them. Consequently the REJECT for uploads of debian-policy must be
removed.
My reason for this proposal is the impression the revocation of the
delegation is based on the disagreement of the interpretation of the
policy between the chair of the Package Policy Committee and the Debian
Project Leader.
[1] http://lists.debian.org/debian-project/2006/10/msg00233.html
[2] http://lists.debian.org/debian-devel-announce/2005/06/msg00017.html
[3] http://lists.debian.org/debian-project/2006/10/msg00238.html

Greetings
Martin

[Debian Project Secretary]

Hi,

As I count, this resolution to delay the decition of the DPL
of the withdrawal of the Package Policy Committee delegation has
received 2K sponsors, which means that § 4.2.2.2 of the constitution
to be called into action.

,----
| 4. The Developers by way of General Resolution or election
| 4.1. Powers
| 3. Override any decision by the Project Leader or a Delegate.
| 4.2. Procedure
| 2. Delaying a decision by the Project Leader or their Delegate:
| 1. If the Project Leader or their Delegate, or the Technical
| Committee, has made a decision, then Developers can override
| them by passing a resolution to do so; see s4.1(3).
| 2. If such a resolution is sponsored by at least 2K Developers,
| or if it is proposed by the Technical Committee, the
| resolution puts the decision immediately on hold (provided
| that resolution itself says so).
| 4. If the decision is put on hold, an immediate vote is held to
| determine whether the decision will stand until the full vote
| on the decision is made or whether the implementation of the
| original decision will be delayed until then. There is no
| quorum for this immediate procedural vote.
`----

So, an immediate procedural vote has to be held to determine
whether the decision will stand until the full vote, on the decision
is made or whether the implementation of the original decision
(i.e. withdrawl of delegation from the policy delegates) will be
delayed until then.

I am proposing the following draft ballot for this immediate
vote, while I go about setting up the voting infrastructure. The
vote page containing the details of this general resolution is not
yet up, but as soon as it is it would be found at:
http://www.debian.org/vote/2006/vote_008



manoj

`This is a DRAFT ballot. Voting is not yet open.
======================================================================

Voting period starts 00:00:01 UTC on Friday, 28 Oct 2006
Votes must be received by 23:59:59 UTC on Friday, 10 Nov 2006

The following DRAFT ballot is for voting on a immediate procedural vote to
determine if the Debian project Leaders decision to un-delegate policy
delegates remain on hold until the full vote is called, in accordance
with section 4.2.2.4 of the Debian constitution. The vote is being
conducted in accordance with the policy delineated in Section A,
Standard Resolution Procedure, of the Debian Constitution.

You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions contact ***@debian.org.

HOW TO VOTE

Please read the debian-***@lists.debian.org mailing lists for details
on why this procedural vote is being called.

Do not erase anything between the lines below and do not change the
choice names.

In the brackets next to your preferred choice, place a 1. Place a 2 in
the brackets next to your next choice. Do not enter a number smaller
than 1 or larger than 2. You may skip numbers. You may rank options
equally (as long as all choices X you make fall in the range 1<= X <=
2).

To vote "no, no matter what" rank "Further discussion" as more
desirable than the unacceptable choices, or You may rank the "Further
discussion" choice, and leave choices you consider unacceptable
blank. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices. (Note: if the Further
Discussion choice is unranked, then it is equal to all other unranked
choices, if any -- no special consideration is given to the Further
discussion choice by the voting software).

Then mail the ballot to: ***@vote.debian.org. Don't worry
about spacing of the columns or any quote characters (">") that your
reply inserts. NOTE: The vote must be GPG signed (or PGP signed) (or
encrypted) with your key that is in the Debian keyring.

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
2808c3bb-6d17-49b6-98c8-c6a0a24bc686
[ ] Choice 1: The DPLs decision remains on hold until the full vote
[ ] Choice 2: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


----------------------------------------------------------------------

The responses to a valid vote shall be signed Devotee (DEbian VOTe
EnginE) using by the vote key created for this vote. The public key
for the vote, signed by the Project secretary, is appended below.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.5 (GNU/Linux)

mQGiBEVBK6wRBACsbjlsanpIl1F4IT6sWiML/khpUQjqtywggKt9hG0k4XpCIvsZ
YzioNdJyzODLCTCZWmmUEA1P5mSPKPosvqopp967wpF0fyu2TLoTNJnCsDCnSz3q
aofhlAF1LaOwfLDRpNFCW2J7bE+ELWBUhbPCN86T0D0ElelIvJvlR+maSwCgicvT
ClbqL2WuiYkLSLhnIk6BmI0D/Rd2ZO1/wXuWmYHacD1rOxKVxk8Zn5/1zDE+VaL1
K2ZYMdDCZMojxjncEtEQU3oKDuKwggSn/lYfXsNNEaeqafNnIDMpNlYT86IQiTnl
979uKKiEuRYA3t6GtoquPX0g3BoRwgeDrNUmyWD+a+FWop/YqkkBJfz+mcdx/coq
XIQEA/9ywGlON9hUSXa11t/p7ZuNd8IszEOA3MidQLHJEUGKCuv2Tb5LF41/kJ/1
2qljQTgRbxeEJ2plE2mz5tKelifKU4GWxz2EkOs7RnhrrqWNcx9betncsqKdoSvC
ADpm9BCA/SkfkgO8QqRuzv49HdNi68mkVVbq19EnIodjq+gjR7RQVGhlIGltbWVk
aWF0ZSBwcm9jZWR1cmFsIHZvdGUga2V5IChFcGhlbWVyYWwgS2V5KSA8Z3JfaW1t
ZWRpYXRlQHZvdGUuZGViaWFuLm9yZz6IZgQTEQIAJgUCRUErrAIbAwUJABuvgAYL
CQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEEMP13Z94uS6d1IAn1ar9cN/FvhbIYux
qC9tF8cyQtJGAJ9WBnWVpGCQOYPFOCHvVwgkXSg4xIhGBBARAgAGBQJFQSx5AAoJ
ECG62ru/JEJM4v8An3Vc4wGJT4VA+AYeBW5k0Ntn8UHRAJ9x+eQZTfXkkC+2L8WV
tCoNwzcIebkCDQRFQSu9EAgAq1DQFKA2DASw++dQEmxG1gC2dz11CNfVJ/nKPBqQ
SFVTwB4XndyrbOUJUwm1RsYbRIo+krresbBV977r6sCyunr3KmQ6hsySYjmzJK5t
xgmJ3OpAnMisOaVxsf3YXhOUD1CSxLZImqcR1DkJiuDngZNR60517rtO1w8Z1cxk
XGRqSZLQm/3ArQPe7lTn/4NQS/xdeTVoCtoIaQb2hbs2uuP132ndxR3HsaELdX65
/KEvod0zKlh9OrY1mdQhlJPUbV60JLiFXe+Lj1gB4+7mqePAUpGPg3fy8+bOiYZF
QDZXan9Xfz8pfrbTfo5jNdH3LJ/UuqzxMmMBnXItAAtjWwADBQf6AhTIounlq95b
AVHEE1JdeIBgw7FM9QXlU5F3pqc7G6Cri/ZUS/0vZRr/qg33kSbWH3goauMEOWoq
RGc5b/CkRf8DSD9MYZxrC+5VGDE1kuPW5khaf3MWe+WUTy4cJcqFjCk5Ft2rRTdf
6UhSgRT35XrQEFmrK19nb83ohjsbMhPLXkSbSNcQMcr0s7htACHHC719gINEayUP
k+oG7TdLrOKWjopziRGS/GGe69HQk+zx570S5U92+6Wbitf+VDtYvixCWYQgEtsD
j8B1+KN6XCO1aMOkEw7rVvgvjAfQSQvEguMjzpEGIYbnVks5TFkBL4o4lKPyjM4+
ANq5MEKPwYhPBBgRAgAPBQJFQSu9AhsMBQkAG6+AAAoJEEMP13Z94uS6/VgAoIkj
sP6tSN+jXDq2rLxzkDXjz5D8AJ9jxwI8fE+nkQd19FxfbRR9Owwkeg==
=6S3R
-----END PGP PUBLIC KEY BLOCK-----


arch-tag: 1c14135a-7b23-45f7-b0d5-78e68b24d4f8

[Peter Samuelson]

[Debian Project Secretary]

Post by Debian Project Secretary
`This is a DRAFT ballot. Voting is not yet open.
======================================================================
Voting period starts 00:00:01 UTC on Friday, 28 Oct 2006
Votes must be received by 23:59:59 UTC on Friday, 10 Nov 2006

Did you mean Saturday, 28 Oct? Friday is the 27th.

Post by Debian Project Secretary
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
2808c3bb-6d17-49b6-98c8-c6a0a24bc686
[ ] Choice 1: The DPLs decision remains on hold until the full vote
[ ] Choice 2: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

I suppose it doesn't matter, but "Further discussion" is not really
accurate. This vote is not one that can be deferred, discussed, then
taken again.

Post by Debian Project Secretary
The responses to a valid vote shall be signed Devotee (DEbian VOTe
EnginE)

I think "DEbian VOTE Engine" looks better. Plus, the bike shed should
be green.

[Sven Luther]

Post by Debian Project Secretary
Hi,
As I count, this resolution to delay the decition of the DPL
of the withdrawal of the Package Policy Committee delegation has
received 2K sponsors, which means that § 4.2.2.2 of the constitution
to be called into action.
,----
| 4. The Developers by way of General Resolution or election
| 4.1. Powers
| 3. Override any decision by the Project Leader or a Delegate.
| 4.2. Procedure
| 1. If the Project Leader or their Delegate, or the Technical
| Committee, has made a decision, then Developers can override
| them by passing a resolution to do so; see s4.1(3).
| 2. If such a resolution is sponsored by at least 2K Developers,
| or if it is proposed by the Technical Committee, the
| resolution puts the decision immediately on hold (provided
| that resolution itself says so).
| 4. If the decision is put on hold, an immediate vote is held to
| determine whether the decision will stand until the full vote
| on the decision is made or whether the implementation of the
| original decision will be delayed until then. There is no
| quorum for this immediate procedural vote.
`----
So, an immediate procedural vote has to be held to determine
whether the decision will stand until the full vote, on the decision
is made or whether the implementation of the original decision
(i.e. withdrawl of delegation from the policy delegates) will be
delayed until then.
I am proposing the following draft ballot for this immediate
vote, while I go about setting up the voting infrastructure. The
vote page containing the details of this general resolution is not
http://www.debian.org/vote/2006/vote_008

Manoj, ...

You are overpassing your rights as secretary, it is not for you as secretary
to call for a vote, or take any such actions, but it is only the proposer and
the seconders who can do such.

This action of yours right now, casts more light to your abysmal behaviour on
the non-free firmware vote, where you first let the issue wait until you where
able to propose a proposal of your liking, and then hurried in to get the vote
down, thus rejecting other proposals which where better and more in line of
what debian needed, and which you didn't want.

In light of this and your actions here, i strongly propose that on issues you
have a strong interest or opinion, that someone else than you is in charge of
doing the day-to-day work of the secretary, maybe the DPL or TC would be
adequate on this here, or maybe some kind of assistant secretary either
permanent or delegated for the occasion.

Anthony, can you comment on this ?

Friendly,

Sven Luther

[Martin Wuertele]

Post by Sven Luther

Post by Debian Project Secretary
Hi,
As I count, this resolution to delay the decition of the DPL
of the withdrawal of the Package Policy Committee delegation has
received 2K sponsors, which means that § 4.2.2.2 of the constitution
to be called into action.
,----
| 4. The Developers by way of General Resolution or election
| 4.1. Powers
| 3. Override any decision by the Project Leader or a Delegate.
| 4.2. Procedure
| 1. If the Project Leader or their Delegate, or the Technical
| Committee, has made a decision, then Developers can override
| them by passing a resolution to do so; see s4.1(3).
| 2. If such a resolution is sponsored by at least 2K Developers,
| or if it is proposed by the Technical Committee, the
| resolution puts the decision immediately on hold (provided
| that resolution itself says so).
| 4. If the decision is put on hold, an immediate vote is held to
| determine whether the decision will stand until the full vote
| on the decision is made or whether the implementation of the
| original decision will be delayed until then. There is no
| quorum for this immediate procedural vote.
`----
So, an immediate procedural vote has to be held to determine
whether the decision will stand until the full vote, on the decision
is made or whether the implementation of the original decision
(i.e. withdrawl of delegation from the policy delegates) will be
delayed until then.
I am proposing the following draft ballot for this immediate
vote, while I go about setting up the voting infrastructure. The
vote page containing the details of this general resolution is not
http://www.debian.org/vote/2006/vote_008

You are overpassing your rights as secretary, it is not for you as secretary
to call for a vote, or take any such actions, but it is only the proposer and
the seconders who can do such.

I completely disagree with you. The constitution states "an immediate
vote is held" and I don't see that only the proposer can call for a vote
in this case. The way I read it it's not necessary that the proposer
needs to call for a vote in this case.

I very much appreciate the secretarys work.

If you and several others still feel that it is necessary for me as
proposer to call for a vote I will send out a signed mail later today.

yours Martin

[Jurij Smakov]

On Fri, Oct 27, 2006 at 08:46:21AM +0200, Sven Luther wrote:
[...]

Post by Sven Luther
You are overpassing your rights as secretary, it is not for you as secretary
to call for a vote, or take any such actions, but it is only the proposer and
the seconders who can do such.

Did you actually read this passage from constitution which was quoted
in Secretary's message? Section 4.2.2 describes in detail the
procedure for delaying a decision by DPL, and I believe that
everything is done in accordance with it.

Best regards,

[Sven Luther]

Post by Jurij Smakov
[...]

Post by Sven Luther
You are overpassing your rights as secretary, it is not for you as secretary
to call for a vote, or take any such actions, but it is only the proposer and
the seconders who can do such.

Did you actually read this passage from constitution which was quoted
in Secretary's message? Section 4.2.2 describes in detail the
procedure for delaying a decision by DPL, and I believe that
everything is done in accordance with it.

Not really, but i read the way resolution votes where handled (Annex A.),
which says :

A.2.1 The proposer or a sponsor of a motion or an amendment may call for
a vote, providing that the minimum discussion period (if any) has elapsed.

It may indeed have missed the point about reverting decisions :

4.2.4 If the decision is put on hold, an immediate vote is held to determine
whether the decision will stand until the full vote on the decision is made
or whether the implementation of the original decision will be delayed until
then. There is no quorum for this immediate procedural vote.

But nowhere in section 4.2 does it speak about who issues the call for vote,
while A.4.2 isvery clear about this.

In any case, independent of the actual text, there is evident conflict of
interest, both here as ian jackson pointed ou, and in the non-free vote, and
we need to engage in some reflection as to not see this happen again. Do you
have anything constructive to say about this ?

Friendly,

Sven Luther

[Jurij Smakov]

Post by Sven Luther
Not really, but i read the way resolution votes where handled (Annex A.),
A.2.1 The proposer or a sponsor of a motion or an amendment may call for
a vote, providing that the minimum discussion period (if any) has elapsed.
4.2.4 If the decision is put on hold, an immediate vote is held to determine
whether the decision will stand until the full vote on the decision is made
or whether the implementation of the original decision will be delayed until
then. There is no quorum for this immediate procedural vote.
But nowhere in section 4.2 does it speak about who issues the call for vote,
while A.4.2 isvery clear about this.

It does not matter, since in this special situation the vote is
supposed to be 'immediate'.

Post by Sven Luther
In any case, independent of the actual text, there is evident conflict of
interest, both here as ian jackson pointed ou, and in the non-free vote, and
we need to engage in some reflection as to not see this happen again. Do you
have anything constructive to say about this ?

This is completely irrelevant for the question about whether the
current vote is being called in violation of constitution.

[Don Armstrong]

[Stripping out the cross posting since it's annoying]

Post by Sven Luther

| 4. If the decision is put on hold, an immediate vote is held to
| determine whether the decision will stand until the full vote
| on the decision is made or whether the implementation of the
| original decision will be delayed until then. There is no
| quorum for this immediate procedural vote.

You are overpassing your rights as secretary, it is not for you as
secretary to call for a vote, or take any such actions, but it is
only the proposer and the seconders who can do such.

What part of "immediate vote" isn't clear? All this does is determine
whether the decision of the DPL is put on hold or stands for the
course of the discussion/resolution period.

Even if Manoj were to delegate the running of this vote to another
developer,[1] that developer would have to conduct an immediate vote
as well.


Don Armstrong

1: I don't see an issue with suggesting this just to avoid any
possibility of this kind of accusation, but it's not like running the
vote has any special power in this regards; everything is pretty well
spelled out by the constitution. [This is why jurists recuse
themselves, of course... not that they aren't capable of being even
handed, but just to preserve the appearance of the same.]

[Martin Wuertele]

Post by Sven Luther
You are overpassing your rights as secretary, it is not for you as secretary
to call for a vote, or take any such actions, but it is only the proposer and
the seconders who can do such.

As you insist - which I still think isn't necessary - I call for a vote
on my proposal and kindly ask our secretary to go ahead.

yours Martin

[Hubert Chan]

Post by Martin Wuertele

Post by Sven Luther
You are overpassing your rights as secretary, it is not for you as
secretary to call for a vote, or take any such actions, but it is
only the proposer and the seconders who can do such.

As you insist - which I still think isn't necessary - I call for a
vote on my proposal and kindly ask our secretary to go ahead.

FWIW, you can't call an immediate vote on your proposal. Your proposal
still has the normal minimum discussion period. (Unless the DPL varies
it by a week.)

The immediate vote that Manoj is calling is a separate ballot, to
determine whether or not Aj's decision will be put on hold until the
vote on your proposal is complete.

So you'll have to do another call for vote on your own proposal in about
two weeks.

[Martin Wuertele]

Post by Hubert Chan
FWIW, you can't call an immediate vote on your proposal. Your proposal
still has the normal minimum discussion period. (Unless the DPL varies
it by a week.)
The immediate vote that Manoj is calling is a separate ballot, to
determine whether or not Aj's decision will be put on hold until the
vote on your proposal is complete.
So you'll have to do another call for vote on your own proposal in about
two weeks.

I know, I just wanted to stop the complains regarding our secretarys
immediate call for votes.

yours Martin

[Anthony Towns]

Post by Debian Project Secretary
As I count, this resolution to delay the decition of the DPL
of the withdrawal of the Package Policy Committee delegation has
received 2K sponsors, which means that ? 4.2.2.2 of the constitution
to be called into action.
| 4.2. Procedure
| 2. If such a resolution is sponsored by at least 2K Developers,
| or if it is proposed by the Technical Committee, the
| resolution puts the decision immediately on hold (provided
| that resolution itself says so).

I can't see anywhere in the resolution it claims to invoke 4.2.2.2, so afaics
that doesn't apply.

Post by Debian Project Secretary
I am proposing the following draft ballot for this immediate
vote, while I go about setting up the voting infrastructure. The
vote page containing the details of this general resolution is not
http://www.debian.org/vote/2006/vote_008
Voting period starts 00:00:01 UTC on Friday, 28 Oct 2006
Votes must be received by 23:59:59 UTC on Friday, 10 Nov 2006

If this immediate vote is compliant with the constitutional requirements
(which afaics it's not), please consider the voting period varied to
one week.

Post by Debian Project Secretary
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
2808c3bb-6d17-49b6-98c8-c6a0a24bc686
[ ] Choice 1: The DPLs decision remains on hold until the full vote
[ ] Choice 2: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

I believe the options should be:

Choice 1: The DPL's withdrawal of the delegation remains on hold pending a vote
Choice 2: The DPL's withdrawal of the delegation stands until a vote

with no default option (or, since there is no quorum, Choice 2 being
treated as the default option, which is equivalent).

I'm not sure what all this is aiming to achieve beyond being a different
attempt to effectively prevent me from exercising any DPL powers, and
to further discourage people from having any faith in our constitutional
processes.

Cheers,
aj

[Martin Wuertele]

Post by Anthony Towns
I'm not sure what all this is aiming to achieve beyond being a different
attempt to effectively prevent me from exercising any DPL powers, and
to further discourage people from having any faith in our constitutional
processes.

You are actually encouraged to exercise your DPL powers and establish a
working policy delegation. The main difference between the text in your
mails and the proposal is to do it now as opposed to do so after the
release.

yours Martin

[Don Armstrong]

Post by Anthony Towns
I can't see anywhere in the resolution it claims to invoke 4.2.2.2,
so afaics that doesn't apply.

Since the resolution itself is about putting a decision on hold, 4.2
seems to apply; the "resolution must say so" verbiage seems to be
there to avoid putting a decision on hold by an amended resolution
seconded by 2K developers which affirms a decision. [Although, the
alternative supposition is tenable, even if it differs from my initial
reading. Clarification by the proposer would resolve this issue.]

I should note as well that 4.2.5 conflicts slightly with the current
powers granted under 4.1.{3,4} to developers... but that's not all
that big of a deal.

Post by Anthony Towns
I'm not sure what all this is aiming to achieve beyond being a
different attempt to effectively prevent me from exercising any DPL
powers, and to further discourage people from having any faith in
our constitutional processes.

This part of the process is there to make sure that what those in
vested positions in Debian do don't overstep the bounds set by the
larger project; being able to overrule any constitutional delegate is
an important part of the constitutional process, as hurtful as it may
be to those who are threatened with being overruled.

In any event, it'd be nice to just resolve the after effects if that's
even possible, as it seems that the initial cause of this current
fracas was just heated discussion, the feared consequences of which
have failed to materialize at all.


Don Armstrong

[Manoj Srivastava]

Post by Don Armstrong

Post by Anthony Towns
I can't see anywhere in the resolution it claims to invoke 4.2.2.2,
so afaics that doesn't apply.

Since the resolution itself is about putting a decision on hold, 4.2
seems to apply; the "resolution must say so" verbiage seems to be
there to avoid putting a decision on hold by an amended resolution
seconded by 2K developers which affirms a decision. [Although, the
alternative supposition is tenable, even if it differs from my
initial reading. Clarification by the proposer would resolve this
issue.]

Also, from the resolution itself:
] I disagree with the Policy delegation decision of our DPL [1] and
] therefore propose a resolution as defined in section 4.2.2 of the Debian
] constitution to delay the decision of the Debian Project Leader keeping
] the Package Policy Committee as defined[2] in place

So it explicitly mentions 4.2.2, which means the resolution is
about delaying decisions, not about affirming them; if the proposer
and sponsors do not think that they wanted the hold to apply, they
can now voice their opinions, and there would be no harm, no foul.

manoj

[Martin Zobel-Helas]

Post by Anthony Towns
If this immediate vote is compliant with the constitutional requirements
(which afaics it's not), please consider the voting period varied to
one week.

I don't see the reason here to reduce the time of the voting period. I
understand "immediate vote" as per constitution as "voting without prior
discussion period".

Please give a reasonable argument, why the voting period for this GR
should be reduced to one week.

Greetings
Martin

[Peter Samuelson]

[Martin Zobel-Helas]

Post by Martin Zobel-Helas
I don't see the reason here to reduce the time of the voting
period. I understand "immediate vote" as per constitution as "voting
without prior discussion period".
Please give a reasonable argument, why the voting period for this GR
should be reduced to one week.

4.2.3:
The voting period is 2 weeks, but may be varied by up to 1 week by
the Project Leader.

AJ is asking that the vote be varied from 2 weeks down to 1 week. I
assume this is supposed to get the nonsense out of the way sooner so
people can get back to arguing about dunc-tank, but that's just a
guess[1]. I don't see why AJ would have to justify this decision.

[1] To save AJ the trouble, IANADD.

[Lionel Elie Mamane]

Post by Peter Samuelson
[Martin Zobel-Helas]

Post by Martin Zobel-Helas
I don't see the reason here to reduce the time of the voting
period. I understand "immediate vote" as per constitution as
"voting without prior discussion period".
Please give a reasonable argument, why the voting period for this
GR should be reduced to one week.

I don't see why AJ would have to justify this decision.

Because he holds a mandate given to him by the DDs? Hold a mandate ->
explain your decisions made under that mandate to the electorate. No?

(I, for one, would consider "to get a speedy decision, in one
direction or the other" sufficient justification.)