Bug#741573: #741573: Menu Policy and Consensus

[Steve Langasek]

On Fri, Aug 28, 2015 at 02:38:50PM -0700, Nikolaus Rath wrote:
> Maybe discussion was the wrong word. What I mean is that for more than
> one year, any vote on this bug was prevented by the TC waiting for any
> one of its members to catch up on the discussion, articulate his
> concerns, write down a counter-proposal or refine their own
> proposal. What I'm saying is that here the perfect is the enemy of the
> good. You could have held a vote with three options (conses achieved +
> override Bill, consenus not achieved + agree with Bill, further
> discussion) within days of receiving this bug, and most likely would
> have been able to resolve it. 

Maybe I would have been overruled, but given those three options I would
always have voted "further discussion".  As we discussed early on in the TC
deliberations, neither of these options makes for good policy.  A policy
document telling maintainers "there are two menu systems, pick whichever one
you want" is bad policy.  A policy document telling maintainers to continue
using a menu system that's been superseded by events in the larger Free
Software ecosystem is bad policy.

The Technical Committee is never going to be a great way to write policy
because of the process involved, but the preferred method of using
debian-policy@lists for this didn't work either in this case.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#741573: #741573: Menu Policy and Consensus

[Nikolaus Rath]

On Aug 28 2015, Sam Hartman  wrote:
>> "Nikolaus" == Nikolaus Rath  writes:
>
> Nikolaus> On Aug 28 2015, Ian Jackson  
> wrote:
> Nikolaus> [ things about the menu system ]
>
> Nikolaus> This really has become a farce. This issue been open for
> Nikolaus> more than a year. Sam rephrased the entire issue earlier
> Nikolaus> this year in terms of consensus and has just finished his
> Nikolaus> analysis. And now it seems the discussion is restarting
> Nikolaus> again from the point where it started last year.
>
> My understanding is that we're going to make a minor revision to option
> D and vote.  Steve and Don wanted to see option D on the ballot, and
> Keith is incorporating some of my feedback.
>
> I don't think this discussion is what is blocking progress; I think
> we're just waiting on Keith at this point, and some other TC members
> including myself have agreed to help out if he gets busy.

Maybe discussion was the wrong word. What I mean is that for more than
one year, any vote on this bug was prevented by the TC waiting for any
one of its members to catch up on the discussion, articulate his
concerns, write down a counter-proposal or refine their own
proposal. What I'm saying is that here the perfect is the enemy of the
good. You could have held a vote with three options (conses achieved +
override Bill, consenus not achieved + agree with Bill, further
discussion) within days of receiving this bug, and most likely would
have been able to resolve it. 


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Nikolaus" == Nikolaus Rath  writes:

Nikolaus> On Aug 28 2015, Ian Jackson  
wrote:
Nikolaus> [ things about the menu system ]

Nikolaus> This really has become a farce. This issue been open for
Nikolaus> more than a year. Sam rephrased the entire issue earlier
Nikolaus> this year in terms of consensus and has just finished his
Nikolaus> analysis. And now it seems the discussion is restarting
Nikolaus> again from the point where it started last year.

My understanding is that we're going to make a minor revision to option
D and vote.  Steve and Don wanted to see option D on the ballot, and
Keith is incorporating some of my feedback.

I don't think this discussion is what is blocking progress; I think
we're just waiting on Keith at this point, and some other TC members
including myself have agreed to help out if he gets busy.

Bug#741573: #741573: Menu Policy and Consensus

[Nikolaus Rath]

On Aug 28 2015, Ian Jackson  wrote:
[ things about the menu system ]

This really has become a farce. This issue been open for more than a
year. Sam rephrased the entire issue earlier this year in terms of
consensus and has just finished his analysis. And now it seems the
discussion is restarting again from the point where it started last
year.

It seems to me that the TC members have become very hesitant to call for
a vote until there is internal conesus. I think this is a laudable goal
when it can be achieved. But in this case this doesn't seem possible, so
it just results in endless discussion.  Please just vote. Almost any
outcome (and certainly all the potential vote options that have been
proposed) are better than discussing something for more than a year.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
Ian> Consensus"):
>> Having such serious objections that have not been adequately
>> considered means you don't have rough consensus at least in the
>> ways I judge rough consensus.

Ian> Thanks for your thoughtful response and care when reading.

Ian> However, I'm afraid I think this is rather muddled thinking.
Ian> Consensus is a question about what proprtion of people hold
Ian> certain opinion.  It doesn't involve a value judgement.
Ian> Whereas, `adequately considered' involves a value judgement.

Ah, yes, we do not agree on what consensus is.
I think I understand your position well at this point and I thank you
for sharinge.
While I think your view on what consensus is differs from the consensus
view of consensus, I can certainly see where you are coming from.

If there are areas where you think additional discussion would be
valuable, I'd be happy to engage.  For this point though, I think I
understand our disagreement, and while I respect  where you are coming
from I'll need to do what I think is best.

--Sam

Bug#741573: #741573: Menu Policy and Consensus

[Ian Jackson]

Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and Consensus"):
> Having such serious objections that have not been adequately considered
> means you don't have rough consensus at least in the ways I judge rough
> consensus.

Thanks for your thoughtful response and care when reading.

However, I'm afraid I think this is rather muddled thinking.
Consensus is a question about what proprtion of people hold certain
opinion.  It doesn't involve a value judgement.  Whereas, `adequately
considered' involves a value judgement.

> Ian> For the TC to do the
> Ian> same would mean that - when the question is controversial and
> Ian> has a strong political element - the actual decision would be
> Ian> simply be based on which side has the most effort and best
> Ian> tactics in a mailing list flamewar.
> 
> I would urge you to read RFC 7282.  I understand this is not the IETF
> and even the IETF has not chosen to bind itself to that document.

I see references to the IETF as a repeated theme in your writings on
these subjuects.

I'm sorry to say that the I think the IETF is a poor model for
technical decisionmaking.  Indeed output from the IETF in many areas
has indeed suffered from precisely the kind of problems that one would
expect from an institution dominated by the people who have time and
willingness to argue on mailing lists. [1]

It may be difficult for the IETF to do better (because better
approaches may not scale well).

But Debian has a robust governance system and is small enough that we
can have difficult technical decisions made by a panel of highly
competent people - and that's what the TC is supposed to be.


So:

> However, I think the TC has very important roles beyond just judging
> consensus.

I think, in general, it should be no part of the TC's role to judge
consensus.  (There may be exceptions.)

Privileging consensus encourages all sorts of very dysfunctional
behaviours.  It encourages browbeating; wearing down of the
opposition; canvassing for supporters to come and join the fight;
asking the same question again; misrepresentation of others' views;
mailing list archeaology; arguments about who said what when; etc.

All of these are to a greater or lesser extent toxic.

> We need to decide what the policy is.  We can and in my opinion should
> factor in the opinions of others in doing that.

I certainly agree that the TC should take into account the opinions of
others.  But those opinions should be tested and evaluated on their
merits.

> Sam> I think the key area where we differ is that I would give preference
> Sam> other things being mostly equal to  upholding the work done in
> Sam> debian-policy.  As I understand it, you would vote for the option you
> Sam> thought technically best.  
> 
> You didn't confirm this, but it still sounds from what you've said  like
> that would be a fair summary.  I'm not trying to put words in your
> mouth, just confirm my understanding of your position.
> Additionally, it sounds like one of the reasons why may be that you're
> more skeptical of the technical quality of debian-policy than I am.

I'm sorry to say that I have very little confidence in the
debian-policy /process/, where it comes to controversial or difficult
questions.  This is not to say that I lack confidence in the policy
/editors/; in fact, I would like the policy /editors/ to use a process
which relies /more/ on their own judgement.

The current policy process works fine for easy questions - but for
easy questions, any process will do.

In practice, where technically complex questions are successfuly
resolved, this is usually done by the relevant experts communicating
elsewhere until they reach agreement, and then perhaps, or perhaps
not, writing up their conclusions as policy changes.

It is natural that policy will act as a lightning rod for
disagreement.  I think this is inevitable.  But at the moment, the
policy process is ill set up for dealing with such questions.


So with the policy process as currently constituted, and because I
think consensus is such a poor guide, I think that the TC should not
be heavily influenced by the outcome of the policy process.

If the policy editors were prepared to take a more definite line
themselves, and apply their own judgement, then the situation would be
very different.  But in that situation I think that for entirely
different reasons, the TC ought not to defer to the policy editors.

So either way, I think when it is deciding policy, the TC ought to be
making up its own mind on the merits.


> I think my job as a TC member is to come up with the best technical
> policy for Debian I can.  I think we disagree on how to accomplish that.

Yes.

Ian.


[1] Examples of IETF-generated nonsense that I'm aware of:
* A6, DNAME, bitstrin

Bug#741573: #741573: Menu Policy and Consensus

[Josh Triplett]

On Mon, 27 Jul 2015 15:05:03 -0700 Josh Triplett  wrote:
> On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette  wrote:
> > Sam Hartman  wrote: 
> > That seems very unlikely to me.  Diversity is an important part of
> > Debian.  I think it is likely that the TC is going to value the 
> > Debian
> > Menu as long as Bill or someone else is going to work on it.  I 
> > would
> > expect us to value the menu enough to enable those who want to
> > contribute to it to do so.
> > 
> > Given the state menu is in, reading this is… flabbergasting, to say the
> > least. I would answer tons of things, but fortunately they have already
> > been put together concisely: http://islinuxaboutchoice.com/ 
> > 
> > I think that's consistent with the consensus proposal that you 
> > asked us
> > to consider in this bug.
> > 
> > The consensus proposal was, in order to preserve some bits of Bill's
> > ego, to let menu die slowly by stopping to require mandatory entries for
> > a useless menu system that only a handful of obscure window managers are
> > still able to display. Now that Bill has made very clear, by completely
> > giving in to ridicule, that his ego should not be a problem, Charles is
> > merely proposing to accelerate that process and avoid pain for everyone.
> 
> Josselin, do you really believe that an inflammatory message like this is
> the right way to get your point across and get people to agree with you?
> 
> While I agree with the underlying arguments you're referring to, both
> about "choice" and about the (lack of) value of the old menu system,
> this kind of mail doesn't help anyone get past this issue, nor does it
> come across as reasonable.  It's worth noting that the old menu system
> provided a significant amount of value for many years, long before the
> XDG menu existed.  That it no longer holds as much importants as it once

s/importants/importance/; half-finished edit.

> did is no reason to denigrate people involved with it.
> 
> - Josh Triplett
> 
> 


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150727224513.GA4663@jtriplet-mobl1

Bug#741573: #741573: Menu Policy and Consensus

[Josh Triplett]

On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette  wrote:
> Sam Hartman  wrote: 
> That seems very unlikely to me.  Diversity is an important part of
> Debian.  I think it is likely that the TC is going to value the Debian
> Menu as long as Bill or someone else is going to work on it.  I would
> expect us to value the menu enough to enable those who want to
> contribute to it to do so.
> 
> Given the state menu is in, reading this is… flabbergasting, to say the
> least. I would answer tons of things, but fortunately they have already
> been put together concisely: http://islinuxaboutchoice.com/ 
> 
> I think that's consistent with the consensus proposal that you asked 
> us
> to consider in this bug.
> 
> The consensus proposal was, in order to preserve some bits of Bill's
> ego, to let menu die slowly by stopping to require mandatory entries for
> a useless menu system that only a handful of obscure window managers are
> still able to display. Now that Bill has made very clear, by completely
> giving in to ridicule, that his ego should not be a problem, Charles is
> merely proposing to accelerate that process and avoid pain for everyone.

Josselin, do you really believe that an inflamatory message like this is
the right way to get your point across and get people to agree with you?

While I agree with the underlying arguments you're referring to, both
about "choice" and about the (lack of) value of the old menu system,
this kind of mail doesn't help anyone get past this issue, nor does it
come across as reasonable.  It's worth noting that the old menu system
provided a significant amount of value for many years, long before the
XDG menu existed.  That it no longer holds as much importants as it once
did is no reason to denigrate people involved with it.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150727220416.GA3716@jtriplet-mobl1

Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Sam Hartman  wrote: 
That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

Given the state menu is in, reading this is… flabbergasting, to say the
least. I would answer tons of things, but fortunately they have already
been put together concisely: http://islinuxaboutchoice.com/ 

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.

The consensus proposal was, in order to preserve some bits of Bill’s
ego, to let menu die slowly by stopping to require mandatory entries for
a useless menu system that only a handful of obscure window managers are
still able to display. Now that Bill has made very clear, by completely
giving in to ridicule, that his ego should not be a problem, Charles is
merely proposing to accelerate that process and avoid pain for everyone.

-- 
Joss


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1437747652.13194.42.ca...@dsp0698014.postes.calibre.edf.fr

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> I made efforts to keep the wording mild, but I think that
Charles> it was an error.
>> From your attiude as the lead person behind the Debian Menu, it
>> is clear that
Charles> it has no future.  For one decade, you have taken no
Charles> leadership to build this future.  As a consequence, I think
Charles> that the next step is to plan its replacement and
Charles> deprecation.  Maybe the TC will come to this conclusion.

That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tsla8ulvhl4@mit.edu

Bug#741573: #741573: Menu Policy and Consensus

[Charles Plessy]

Le Thu, Jul 23, 2015 at 02:12:31PM +0200, Bill Allombert a écrit :
> 
> This is not the case. I made my position clear the first time in the bug log,
> but one year later Charles decided to restart the discussion while ignoring 
> all
> that was previously said. That made me angry and I have a policy not to post
> when I am angry.
> 
> Charles write with the undertone that his position will carry the day and that
> naysayer are a minority, which I find displeasing, especially when aiming for
> consensus, going as far as 'apologizing' to peope wanting to continue to 
> support
> Debian menu.

Bill, you are the only person complaining, and your position is not clear.

The original request is to "soften the wording recommending menu files" and
everybody except you agrees to do so.

The wording has been made without your input, because you did not participate
constructively to that part of the discussion.  You only were throwing in
vague arguments and taking other people as strawmen.

I made efforts to keep the wording mild, but I think that it was an error.
>From your attiude as the lead person behind the Debian Menu, it is clear that
it has no future.  For one decade, you have taken no leadership to build this
future.  As a consequence, I think that the next step is to plan its
replacement and deprecation.  Maybe the TC will come to this conclusion.

Cheers,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015072313.gc16...@falafel.plessy.net

Bug#741573: #741573: Menu Policy and Consensus

[Bill Allombert]

On Thu, Jul 23, 2015 at 08:45:53AM +0200, Wouter Verhelst wrote:
> Hi Sam,
> 
> [side note: while I joined the original discussion, I don't really have
> a stake in the outcome, other than the desire to have a working menu]
> 
> On Tue, Jul 21, 2015 at 09:06:08AM +, Sam Hartman wrote:
> > Should Bill have recused?
> > Your current process does not describe when policy editors should
> > recuse.
> > One thing we may learn here is that we need to be more clear about how
> > we handle recusals.
> 
> I'm not sure if the lack of a policy on recusals is a good excuse for
> the failure to do so. If Bill opposed the proposal (which certainly is
> his right), he *should* have actively partaken in the discussion,
> pointing out *why* he thought it a bad idea and asking for
> clarifications, improvements, etc. Instead, he mostly ignored the
> discussion while it was happening (not counting the occasional mails
> pointing out what he believed to be inaccuracies), and only making fully
> clear that he was going to oppose the proposal when he reverted the
> commit that implemented what others thought to be consensus.

This is not the case. I made my position clear the first time in the bug log,
but one year later Charles decided to restart the discussion while ignoring all
that was previously said. That made me angry and I have a policy not to post
when I am angry.

Charles write with the undertone that his position will carry the day and that
naysayer are a minority, which I find displeasing, especially when aiming for
consensus, going as far as 'apologizing' to peope wanting to continue to support
Debian menu.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150723121231.GB12811@yellowpig

Bug#741573: #741573: Menu Policy and Consensus

[Wouter Verhelst]

Hi Sam,

[side note: while I joined the original discussion, I don't really have
a stake in the outcome, other than the desire to have a working menu]

On Tue, Jul 21, 2015 at 09:06:08AM +, Sam Hartman wrote:
> Should Bill have recused?
> Your current process does not describe when policy editors should
> recuse.
> One thing we may learn here is that we need to be more clear about how
> we handle recusals.

I'm not sure if the lack of a policy on recusals is a good excuse for
the failure to do so. If Bill opposed the proposal (which certainly is
his right), he *should* have actively partaken in the discussion,
pointing out *why* he thought it a bad idea and asking for
clarifications, improvements, etc. Instead, he mostly ignored the
discussion while it was happening (not counting the occasional mails
pointing out what he believed to be inaccuracies), and only making fully
clear that he was going to oppose the proposal when he reverted the
commit that implemented what others thought to be consensus.

I don't think this is appropriate for anyone, regardless of whether
they're policy editors. If you have an objection to a technical change
in Debian, historically we've always required that people come up with
technical reasons for either supporting or objecting to, the change.
Bill did not do that, at least not to the level I would expect from
someone who opposes a proposed change that seems to be building
consensus.

Anyway.

While I applaud your attempts to get the original people around the
table again, I'm not sure that's either productive or the role of the
TC. Not productive, because I feel that the different parties have
pretty much reached set positions that they're extremely unlikely to
deviate from anymore; and not the role of the TC, because it is the
technical committee's role to take *technical* decisions, which this
approach would not necessarily lead to.

Instead, I would prefer if the technical committee would, after
reviewing the arguments pro and con, take a decision on *which menu
system* to move forward with, rather than trying to fix the original
discussion, for which I have little hope that it will be successful.

I do believe Charles' original mail was a request for the TC to do so.
If it isn't in your interpretation, please consider this an official
request in that manner.

Thanks,

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


signature.asc
Description: Digital signature

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and
>> I think the key area where we differ is that I would give
>> preference other things being mostly equal to upholding the work
>> done in debian-policy.  As I understand it, you would vote for
>> the option you thought technically best.  I wouldn't do that
>> because I think the social costs are important and because I
>> recognize a real chance I might be technically wrong.

Ian> I'm not sure precisely what social costs you are referring to.

Ian> Perhaps you mean disappointment on the part of people who have
Ian> spent effort to build consensus in debian-policy in order to
Ian> make progress in a controversial area.  But if there are
Ian> serious objections, which a participant wishes to take to the
Ian> TC, it seems to me that such a consensus (if it exists) has
Ian> probably been achieved by wearing down the sceptics rather than
Ian> by convincing them (or perhaps by the absence of the opponents
Ian> to begin with).

Having such serious objections that have not been adequately considered
means you don't have rough consensus at least in the ways I judge rough
consensus.
It was perhaps not obvious in some of my mail, but  I did:

* evaluate each objection Bill raised in his mail where he reverted the
  change to see if I thought it was addressed at a process level.

* Evaluate each of those objections as a TC member to see if I thought
  it was in my technical judgment a problem with the proposal.

* Try to explain the objections to the rest of the TC so they could make
  their evaluation using their technical judgment (including pointers if
  they want to  dig more deeply)

Doing all of those are important to me.

With regard to the current issue it's my opinion that we have no serious
issues that have not been considered.  It's my opinion that in my
technical judgment I'm comfortable with the resolution to the issues
that were considered.
If you or anyone else wants me to look at some specific issue either
from a process standpoint or to make a judgment about whether I think
the resolution is reasonable, please start another thread on the bug.
If I have not already voted I'll do so.

I'm still in the process of doing my own technical evaluation of the
proposal to see if I come up with any technical objections I consider
serious enough to raise.  It'll be awkward from a TC internal process
standpoint if I do because the ballot is frozen at this point, but I've
completed enough of my evaluation that I don't anticipate any such
objections.  I'll be done before I vote and will definitely be able to
complete within the voting period even if Don calls for a vote now.


Ian> Or perhaps you mean disappointment on the part of the policy
Ian> editors.  

I do not.  Your reasons are somewhat similar to mine.



Ian> To put it another way: the policy editors have cast themselves
Ian> as referees, not judges or designers.  

Agreed to some extent.  The policy editors do have some role as
consensus judges, but to a large extent they have delegated that to
those seconding proposals according to their process document.  In
practice, I suspect they do a fair bit of consensus judging themselves.


Ian> For the TC to do the
Ian> same would mean that - when the question is controversial and
Ian> has a strong political element - the actual decision would be
Ian> simply be based on which side has the most effort and best
Ian> tactics in a mailing list flamewar.

I would urge you to read RFC 7282.  I understand this is not the IETF
and even the IETF has not chosen to bind itself to that document.
However it displays some of the level of thought required in judging
rough consensus.
A judge of consensus is very much responsible for thinking about the
technical issues and making sure they have adequately been considered.
A judge of consensus is very much responsible for making sure the
process does not turn into who-shouts-loudest.

Someone reviewing a consensus process probably isn't in a position to
fix a process where participants were driven away in frustration
(silencing their objections) but should detect this sort of thing and
claim the process failed to reach consensus when significant viewpoints
were excluded.

However, I think the TC has very important roles beyond just judging
consensus.
We need to decide what the policy is.  We can and in my opinion should
factor in the opinions of others in doing that.

As a practical matter the debian-policy list does a lot of that.
When debian-policy properly takes up an issueit's important to me that
the TC value the work they have done.  Part of that to me is that we
should have a reason for deciding differently.

I'd also be fine adjusting how much policy work is done by debian-policy
and how much is done by the TC.  There's a constitutional limit of
course in that the tc ca

Bug#741573: #741573: Menu Policy and Consensus

[Ian Jackson]

Sam Hartman writes ("Re: Bug#741573: #741573: Menu Policy and Consensus"):
> If the TC found itself coming to a different conclusion than an informed
> rough consensus of debian-policy, it should carefully consider whether
> that is the right course.

I have a very different view.  The membership of the policy mailing
list is very self-selecting, and not necessarily selecting for the
properties we would want.

For example, people interested in getting involved in debian-policy
are likely to have a disposition towards trying to make things
uniform, rather than towards valuing diversity.  They are also likely
to have a disposition towards contributing by discussing rather than
by coding.  Discussions (and thereview the view of "consensus") are
easily dominated by those who have much time and many opinions.

> I think the key area where we differ is that I would give preference
> other things being mostly equal to  upholding the work done in
> debian-policy.  As I understand it, you would vote for the option you
> thought technically best.  I wouldn't do that because I think the social
> costs are important and because I recognize a real chance I might be
> technically wrong.

I'm not sure precisely what social costs you are referring to.

Perhaps you mean disappointment on the part of people who have spent
effort to build consensus in debian-policy in order to make progress
in a controversial area.  But if there are serious objections, which a
participant wishes to take to the TC, it seems to me that such a
consensus (if it exists) has probably been achieved by wearing down
the sceptics rather than by convincing them (or perhaps by the absence
of the opponents to begin with).

Or perhaps you mean disappointment on the part of the policy editors.
But the policy editors have adopted[1] a system led by process rather
than own judgement.  The policy process avoids the policy editors
making the primary judgements on proposals and thus becoming invested
in them.  You would be suggesting that the TC should perhaps avoid
overturning a decision reached via the policy process, on the grounds
that this might upset the policy maintainers.  That would mean that
no-one would actually be taking responsibility for the content of the
decision!


To put it another way: the policy editors have cast themselves as
referees, not judges or designers.  For the TC to do the same would
mean that - when the question is controversial and has a strong
political element - the actual decision would be simply be based on
which side has the most effort and best tactics in a mailing list
flamewar.

Not only does that result in bad decisions, but it rewards behaviours
which are effective at generating apparent consensus on mailing lists.
I'm sure it will be obvious to you that there are many behaviours
which are very effective for that but which are also very harmful
(indeed, which work _because_ they are harmful).  In Debian we
normally mitigate this problem by arranging that someone or some group
is in charge of the decision and applies their own judgement.


Finally (and at the risk of sounding like one of those people who
quote the Social Contract at every opportunity) I would like to point
out that your view seems contrary to the spirit of the Constitution.

The Constitution does of course say `may', so the TC isn't required to
determine the content of policy.  But that is just the language used
when determining the powers abnd responsibilities of every
constitutionally defined role.

Ian.

[1] Note that there is nothing saying that the policy editors have to
do things this way.  When I wrote and edited the policy manual I did
so according to my best judgement.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21935.45243.484400.858...@chiark.greenend.org.uk

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> 1. The TC - not the policy process, not the policy editors, and
Ian> not the consensus on debian-policy - has the ultimate
Ian> responsibility to set technical policy.  (Constitution 6.1(1))

Ian> So in the TC the question of whether the policy process was or
Ian> was not followed does not dispose of the question of what the
Ian> policy text should actually be.

We are in strong agreement on this point.

Ian> It would therefore be quite wrong for the TC to confine itself
Ian> to discussions of whether the policy process was followed.

Also agreed.

Ian> 
Ian> More so, whether the policy process was followed is of no
Ian> bearing when we afre considering the technical and social
Ian> merits of the competing options.

Ian> The TC should be looking at the merits of the competing
Ian> options.


I actually think that whether the process is followed has very strong
bearing when considering the social merits of the competing options.
We are a volunteer project.
We thrive when people feel their contributions are valued, when they
feel they can make a difference.
There is a significant cost to the project when we reject contributions
that people have spent a lot of time working on.  People tend to
question whether allocating their time on these activities is valuable,
tend to question whether the project's values are aligned with their
values.

So, between two reasonable technical options, choosing the one that
values the time and work people have put in serves a significant social
good that helps build and strengthen our community.

I  think that there is a huge social benefit to fairness.  I find that I
am more willing to spend energy on organizations where I have rescourse
if I believe that fairness of process has not been met.
So I think it's absolutely critical that there be a way you can get a
process decision reviewed.
We can debate whether the TC is the right place for that.  I'll note
that reviewing a consensus call/a consensus process requires deep
knowledge of the technical issues involved.  If you take a look at
documents like RFC 7282 that discuss what it means to have rough
consensus, you'll find they are filled with judgment calls about the
technical issues.  So whoever does review this sort of call needs to
have significant technical skill.


I also think process has technical bearing.  I value consensus-based
processes because I believe they tend to produce superior technical
results.  I think that debian-policy has a wider set of skills than the
TC, and the members contributing to the discussion on debian-policy have
spent more time understanding the issue than the current TC members
involved in this discussion.
If the TC found itself coming to a different conclusion than an informed
rough consensus of debian-policy, it should carefully consider whether
that is the right course.

However, I absol/absolutely agree that the TC is responsible for the
content of policy and we cannot (or at least should not) delegate that
responsibility.
Even if the TC finds that the process is followed, the TC must evaluate
whether it has any objections to the resulting policy.

I think the key area where we differ is that I would give preference
other things being mostly equal to  upholding the work done in
debian-policy.  As I understand it, you would vote for the option you
thought technically best.  I wouldn't do that because I think the social
costs are important and because I recognize a real chance I might be
technically wrong.

I do think the form of the question posed to the TC has some importance.
I would be thinking about this somewhat differently if someone had asked us to
review menu policy because they had specific technical concerns with the
policy that was adopted.

You note that discussions of whether someone followed a process tend to
be acromonious.  We're in agreement there.  I've been frustrated when
I've seen people making this about Bill or about Charles and whether
they abused rights/responsibility.

I've tried to be careful to make this be about the process and not to
judge specific members of the community.  I'd be really happy if others
would join me in that.

My experience is that having discussions about process tends and whether
it is followed in specific cases tends to allow you to better understand
your requirements and understand gaps in shared expectations.
I find that  tends over time to significantly remove acromony.  As an
exampleI tend to feel a sense of relief that replaces frustration when I
understand that the reason someone isn't doing what I want is that they
have different expectations.  We can get down to the business of seeing
if there are mutually compatible expectations to be had.
It's quite obvious to me that Bill and Charles have different
expectations here, and I think there's significant acromony that can be
avoided if the community is able to clarify which expectations

Bug#741573: #741573: Menu Policy and Consensus

[Ian Jackson]

Sam Hartman writes ("Bug#741573: #741573: Menu Policy and Consensus"):
> In March of 2014, Charles Plessy asked the Debian Technical Committee to
> review one of the policy editors decisions to revert changes to how
> policy talks about the Debian Menu and MIME support.  See
> http://bugs.debian.org/741573 for the TC process and
> https://bugs.debian.org/707851.  for the process within debian-policy.

Hi.

I am concerned at the direction this conversation has gone in.

As you will know, I'm not really in favour of the TC dealing with this
issue by primarily looking at whether the policy process was followed.

There are two problems with that approach:


1. The TC - not the policy process, not the policy editors, and not
the consensus on debian-policy - has the ultimate responsibility to
set technical policy.  (Constitution 6.1(1))

So in the TC the question of whether the policy process was or was not
followed does not dispose of the question of what the policy text
should actually be.

It would therefore be quite wrong for the TC to confine itself to
discussions of whether the policy process was followed.  More so,
whether the policy process was followed is of no bearing when we afre
considering the technical and social merits of the competing options.

The TC should be looking at the merits of the competing options.


2. Discussions about whether someone did or did not follow a
documented process are often acrimonious.  Such conversations should
be avoided if they are not necessary for the decision at hand.


If there is a problem with people not being able to work together, or
a breakdown of trust, that is a matter for the DPL who appoints the
policy team.[1]


I am also once again disturbed to read messages from Bill's opponents
where they declare a system that Bill mostly maintains, and wants to
keep maintaining, "dead" and want to "kill" it.


[1] Personally I am doubtful that the DPL has the authority to appoint
the policy maintainers.  I think the policy maintainers are the
maintainers of a package and therefore the authority lies with the TC
under 6.1(2).

Bear in mind that debian-policy is not the only package containing
policy documents covered by 6.1(1).  Programming-language-specific
policies are often in the language packages; even parts of core policy
are sometimes in dpkg-dev or whereever.  However:

(a) it appears that my view on this point is a minority and not shared
in particular by the policy team, the Secretary, the DPL, or the TC,
so it is rather academic.

(b) if it /is/ the TC's responsibility, the question of who should be
the primary maintainer(s) of debian-policy is a separate question to
what the document should contain in this disputed case.

It would be perfectly consistent (for example) for the TC to conclude
that Alice was right on the substantive question (ie that policy ought
to say what Alice[2] wants it to say), but conclude that Alice's
interactions and ways of pursuing this legitimate objective were
sufficiently disruptive that trust has been lost and it would be
better for Alice to stop down as policy editor.


Ian.

[2] Alice chosen because we already have Bill (B) and Charles (C)...


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21935.36281.896031.368...@chiark.greenend.org.uk

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Josselin" == Josselin Mouette  writes:

Josselin> Sam Hartman  wrote: Bill, in his role
Josselin> of policy editor said that he believed there was not a
Josselin> consensus.  He cited a specific set of messages that he
Josselin> believes were not properly addressed.

>> From the beginning, I have been puzzled by your approach to this
>> issue.
Josselin> With this paragraph, I think I’m beginning to understand
Josselin> how you want to treat the issue. And I can’t say I think
Josselin> it is constructive.

Josselin> Bill used his position as a policy editor to reject a
Josselin> change, not because it was against consensus or against
Josselin> the policy process, but because it was against his own
Josselin> opinion. Not as policy editor, but as menu maintainer.

First, I definitely understand your frustration with the process.  It
 sounds like you expect to have confidence that policy
 editors  follow the community's needs and do not allow their personal
 biases to influence their decisions.  It sounds like you're frustrated
 because you don't see that happening here.

I strongly value building robust processes.  When we treat matters as
confrontations between people, we build frustration, we drive people
away, and we poison the atmosphere of the community.  However, it's also
important that we  address peoples frustrations.  I hope we can get to a
point where we all believe that if there were a similar issue in the
future, it would be resolved much more quickly.

We all have biases.  So, before focusing on blaming people or deciding
they are not acting in good faith, I'd like to focus on looking at what
we can do to have reasonable results even in the case of biases and bad
decisions from time to time.  I think we would all be less frustrated if this
issue had been quickly resolved in a couple of weeks even if Bill had
displayed some bias in his initial call.

When I read Bill's message, he was claiming to act as a policy editor
*not* as a menu maintainer.  So, yes I'll start by assuming that he is
doing what he said he's doing and discard that assumption very
reluctantly.

Now, does Bill have biases?
Almost certainly.
Bill did state his own objections early in the discussion; one of the
messages he pointed to that he claims was not addressed was his own
message.
Would bill have  focused so much on finding objections if he  didn't
dislike the proposal so much?  Probably not.  Would Bill have been more
willing to decide that objections were handled if he liked the proposal
better?  Many people would be more sympathetic to proposals they liked.

Should Bill have recused?
Your current process does not describe when policy editors should
recuse.
One thing we may learn here is that we need to be more clear about how
we handle recusals.

Again, my hope is that we can work on our processes and our
understanding of how we address issues like this.  I think that we could
get to a place where it takes a couple of weeks to resolve these sorts
of disagreements in most cases.
I think we can also do a better job of understanding what we expect.

However, I also recognize that it's possible we'll find ourselves in a
situation where a member of the community is not meeting the
expectations we've jointly agreed.  I think in such cases that the
discussion about that member should be with the DPL.
I also think separating the discussion of how to handle the issue from
discussions of specific members of the community is valuable.  As a TC
member I'm going to focus on the process and the specific technical
proposal, *not* on the personalities.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tsloaj5283m@mit.edu

Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Le lundi 20 juillet 2015 à 22:42 +0200, Bill Allombert a écrit :
> This kind of language while customary of Sune and Josselin is inappropriate 
> and
> rude to any people that have investigated significant time in maintaining 
> menu.

Before complaining about the rudeness of other people’s language, maybe
you should reflect on your own behavior, which is way more offensive
than any kind of swearing.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1437460002.3386.33.ca...@debian.org

Bug#741573: #741573: Menu Policy and Consensus

[Bill Allombert]

On Mon, Jul 20, 2015 at 09:50:21PM +0200, Sune Vuorela wrote:
> The debian menu is de facto dead; it is time to put it out of its misery.

This kind of language while customary of Sune and Josselin is inappropriate and
rude to any people that have investigated significant time in maintaining menu.
Though I strongly suggest that Sune and Josselin be ignored, since anyway they 
have both
clearly stated that they were ignored the menu policy anyway, so they have no 
interest in
the outcome.

If we really want to improve communication on our list, the TC should start by 
rejecting rude statements and offensive referrals.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150720204241.GF4706@yellowpig

Bug#741573: #741573: Menu Policy and Consensus

[Russ Allbery]

Bill Allombert  writes:
> On Sun, Jul 19, 2015 at 09:39:50PM +0900, Charles Plessy wrote:

>> I think that what you wrote does not reflect what happened:
>> 
>>  - Russ gave me the green light for committing the changes, see
>>.
>>Only Policy Editors can decide that a change will be committed, thus
>>it is my understanding that Russ, as a Policy Editor, judged that
>>there was consensus.

> This is not my understanding. It seemed clear that Russ did not have
> time to do such review but trusted you as former policy editor. However
> I really did not expect you to use commit right you should not have had
> anymore to force the isssue.

It would be nice if I could clear this up unambiguously, but this is like
so many other things in life: it was both of those and more.

I did feel that the time that there was consensus, and wouldn't have told
Charles to go ahead if I hadn't.  However, I also personally believed his
approach was correct, and I didn't do a particularly exhaustive job of
separating that impression from my attempt to determine consensus.  I
wasn't sure how strongly you objected, and I have a bias for keeping
things moving forward.

When you felt strongly enough about this to revert it, I personally was
happy to have someone else make a final decision, partly because I didn't
have much time to pursue it further.

So I don't think it's really correct to say that I just trusted Charles.
I did my own evaluation of consensus.  However, at the same time, I
wouldn't argue that it was the best evaluation of consensus I ever did,
and certainly the fact that Charles was the one proposing the change
carried additional weight for me due to his past work on Policy.

It's probably also worth noting that I have a somewhat different approach
on how fast to commit changes.  I'm a huge believer in lazy consensus and
in the power of reverts, so I tend towards committing things and reverting
them if needed, rather than waiting on the first commit.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k2tu90y5@hope.eyrie.org

Bug#741573: #741573: Menu Policy and Consensus

[Sune Vuorela]

On Monday 20 July 2015 17:14:03 Josselin Mouette wrote:
> Bill used his position as a policy editor to reject a change, not
> because it was against consensus or against the policy process, but
> because it was against his own opinion. Not as policy editor, but as
> menu maintainer.
> 
> This is the root of the problem. By asking whether the policy process
> has been respected, you are reversing the responsibility. It was Bill’s
> responsibility from day one to recuse himself from policy decisions on
> the menu.
> It was also Bill’s responsibility, from day one, to raise his own
> concerns to the policy change being discussed, not to rely on other
> people’s nitpicks *after* the new policy had been approved and
> committed.
> 
> Maybe, after all, this issue should not have been sent to the TC but to
> the DPL, to ask for the revocation of the abused delegation.

Seconded.

The debian menu is de facto dead; it is time to put it out of its misery.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/16337487.0xHqSnfGRR@dabney

Bug#741573: #741573: Menu Policy and Consensus

[Bill Allombert]

On Sun, Jul 19, 2015 at 03:06:27AM +0200, Cyril Brulebois wrote:
> Wasting people's hard work, and then using a lack of reply to an extra
> round of nitpicking as an excuse for having wasted the whole lot?

The only hard work here is maintaining the menu system for ten years.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150720133909.GB3970@yellowpig

Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Sam Hartman  wrote: 
Bill, in his role of policy editor said that he believed there was not a
consensus.  He cited a specific set of messages that he believes were
not properly addressed.

>From the beginning, I have been puzzled by your approach to this issue.
With this paragraph, I think I’m beginning to understand how you want to
treat the issue. And I can’t say I think it is constructive.

Bill used his position as a policy editor to reject a change, not
because it was against consensus or against the policy process, but
because it was against his own opinion. Not as policy editor, but as
menu maintainer. 

This is the root of the problem. By asking whether the policy process
has been respected, you are reversing the responsibility. It was Bill’s
responsibility from day one to recuse himself from policy decisions on
the menu.
It was also Bill’s responsibility, from day one, to raise his own
concerns to the policy change being discussed, not to rely on other
people’s nitpicks *after* the new policy had been approved and
committed.

Maybe, after all, this issue should not have been sent to the TC but to
the DPL, to ask for the revocation of the abused delegation. 

-- 
Joss


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1437405243.6245.129.ca...@dsp0698014.postes.calibre.edf.fr

Bug#741573: #741573: Menu Policy and Consensus

[Bill Allombert]

On Sun, Jul 19, 2015 at 09:39:50PM +0900, Charles Plessy wrote:
> Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a écrit :
> > 
> > Bill, in his role of policy editor said that he believed there was not a
> > consensus.
> 
> Hi Sam,
> 
> I think that what you wrote does not reflect what happened:
> 
>  - Russ gave me the green light for committing the changes, see
>.  Only 
> Policy
>Editors can decide that a change will be committed, thus it is my 
> understanding
>that Russ, as a Policy Editor, judged that there was consensus.

This is not my understanding. It seemed clear that Russ did not have time to do
such review but trusted you as former policy editor. However I really did not
expect you to use commit right you should not have had anymore to force the 
isssue.

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150720134236.GC3970@yellowpig

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a
Charles> écrit :
>> 
>> Bill, in his role of policy editor said that he believed there
>> was not a consensus.

Charles> Hi Sam,

Charles> I think that what you wrote does not reflect what happened:

Charles>  - Russ gave me the green light for committing the changes,
Charles> see
Charles> .
Charles> Only Policy Editors can decide that a change will be
Charles> committed, thus it is my understanding that Russ, as a
Charles> Policy Editor, judged that there was consensus.
I agree with that.

Charles>  - Without consulting with the other Policy Editors, Bill
Charles> reverted the commit.  This solo action was done out of the
Charles> usual process for seeking consensus before changing the
Charles> Policy.

Well, I'd phrase it as Bill, in his role as policy editor felt that Russ
had misjudged consensus.
My understanding is that the process is silent on this: it neither
permits nor forbids this.

I actually think you want the process to permit policy editors to
disagree with each other in this way.
There's some question about how to handle a disagreement when it arises.
Immediately reverting is an option that tends to maximize frustration,
especially if it is not explicitly called out in the process.

>> A lot of my experience with consensus process is in the IETF.
>> There, if you're in a position to judge consensus, you have an
>> obligation to help try and build the consensus when you judge
>> that there is not consensus.  If you're in a position to judge
>> consensus, you have an obligation to lead the discussion, to
>> focus on areas of disagreement, and to see if your consensus call
>> is correct.  There's an expectation that when you call a lack of
>> consensus, getting to consensus is going to be a priority, and
>> you're going to put in significant time to help.
>> 
>> Should some or all of the above be part of what we expect from
>> policy editors?

Charles> I totally share this point of view.  (This is why after
Charles> leading the release of the Policy version 3.9.5.0, seeing
Charles> that I would not have time to do the same within a year or
Charles> two, I quitted as a Policy Editor).

OK.
If there's general agreement on this, it might be a good idea to get
this expectation into  the process document and reference that from the
delegation.
Naturally as part of that you'd want to make sure that the policy
editors are comfortable with the responsibility the community is asking
them to take up.

>> On another axis of the discussion, what's the appeals process?

Charles> The only appeal I would see would be through the DPL, since
Charles> he appoints and replaces the Policy Editors, who are DPL
Charles> delegates.

Well, I'll note that's not what you did; you brought the issue to the TC
rather than the DPL.
I'll also note that our constitution explicitly limits the DPL's actions
with regard to a decision of a delegate.

I think the DPL is who you'd bring an issue to if you thought an editor
was consistently not meeting the responsibility of the post.  I think
the DPL has no formal power to reverse a specific decision.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tsl7fpw70ou@mit.edu

Bug#741573: #741573: Menu Policy and Consensus

[Charles Plessy]

Le Sun, Jul 19, 2015 at 08:05:56AM +, Sam Hartman a écrit :
> 
> Bill, in his role of policy editor said that he believed there was not a
> consensus.

Hi Sam,

I think that what you wrote does not reflect what happened:

 - Russ gave me the green light for committing the changes, see
   .  Only Policy
   Editors can decide that a change will be committed, thus it is my 
understanding
   that Russ, as a Policy Editor, judged that there was consensus.

 - Without consulting with the other Policy Editors, Bill reverted the commit.
   This solo action was done out of the usual process for seeking consensus
   before changing the Policy.

> A lot of my experience with consensus process is in the IETF.  There, if
> you're in a position to judge consensus, you have an obligation to help
> try and build the consensus when you judge that there is not consensus.
> If you're in a position to judge consensus, you have an obligation to
> lead the discussion, to focus on areas of disagreement, and to see if
> your consensus call is correct.  There's an expectation that when you
> call a lack of consensus, getting to consensus is going to be a
> priority, and you're going to put in significant time to help.
> 
> Should some or all of the above be part of what we expect from policy
> editors?

I totally share this point of view.  (This is why after leading the release of
the Policy version 3.9.5.0, seeing that I would not have time to do the same
within a year or two, I quitted as a Policy Editor).

> On another axis of the discussion, what's the appeals process?

The only appeal I would see would be through the DPL, since he appoints and
replaces the Policy Editors, who are DPL delegates.

Have a nice Sunday,

PS: I will be on business trip in Trieste for one week.

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719123950.gb4...@falafel.plessy.net

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> Le Sat, Jul 18, 2015 at 01:56:49PM +, Sam Hartman a
Charles> écrit :
>> > "Bill" == Bill Allombert  writes:

Charles> Also, the question is not whether the FreeDesktop menu
Charles> should be described in the Policy or not, or how to split
Charles> the proposal in 3, 4 or 42 parts.  It is not even on
Charles> whether the Debian menu should be a "must" or a "should",
Charles> because for that as well, we got a "rough consensus", where
Charles> at the end of the process there was only a single person
Charles> opposing the change.  Neither it is about re-starting a
Charles> search for people disagreeing (or shall I restart a GR on
Charles> systemd ?).  The question is whether a single individual
Charles> can engage in confrontational commit wars to block changes
Charles> in Debian.

I hear your frustration that a proposal you worked on has been blocked
for over a year by the actions of one person.
For myself, though, I'd like to think of the questions differently,
because I'd like to grow from this experience.

Bill, in his role of policy editor said that he believed there was not a
consensus.  He cited a specific set of messages that he believes were
not properly addressed.
I do think it is the job of policy editors to be involved in judging
consensus.
I've been in the position of judging consensus, and made unpopular
calls.
It's hard.  You know you'll face others with strong negative feelings.
You're typically worried about whether you're making the right call.
You're typically hopeful that others will clearly see your point even
when they disagree.  You're frustrated when that doesn't happen.

While I disagree with Bill, I respect him when he makes a hard call like
that.

I agree with Charles though that one person should not be able to block
the process.

My hope for improvement is in how we handle things when a policy editor
or someone else in a similar role in the project claims we don't have
consensus.  What do we expect from our consensus judgers moving forward
in such situations?  What do we expect from ourselves as advocates of
proposals?  What is the process?

I'd like to share a couple of my thoughts.  I'm nervous that in doing so
I'll bias the discussion more than I like.  However, I'm more concerned
that unless I give some constructive examples of  what I'm talking
about, it will be hard to move forward.

A lot of my experience with consensus process is in the IETF.  There, if
you're in a position to judge consensus, you have an obligation to help
try and build the consensus when you judge that there is not consensus.
If you're in a position to judge consensus, you have an obligation to
lead the discussion, to focus on areas of disagreement, and to see if
your consensus call is correct.  There's an expectation that when you
call a lack of consensus, getting to consensus is going to be a
priority, and you're going to put in significant time to help.

Should some or all of the above be part of what we expect from policy
editors?

On another axis of the discussion, what's the appeals process?  Where do
you go when the discussion stalls or reaches an impass?  (In general,
that should not be the immediate reaction to a call of lack of
consensus; such a call is generally the start of a very fast-paced
discussion.)
Charles tried the TC in this instance.
I think the TC has the expertise to review the technical aspects of
these matters.  I think that's actually important to reviewing a
consensus discussion, and is most of the skills you'd need to review
this sort of consensus evaluation.

However, I think the TC might be more effective in situations like this
if it better understood its role.  There was significant disagreement
between the members of the TC Charles brought the issue to and Charles
about what the role of the TC should be.  During the process, the TC
membership changed, and today, I'd say that the TC is probably unsure
what its role should be here.  For reasons I don't fully understand, the
TC process was slower than I'd like.

I hope by focusing on questions like these we can grow from this
experience and be better positioned to resolve future situations where
we're unsure about consensus.  I hope we can treat everyone with
respect--those judging consensus, those reviewing that decision, those
disagreeing with that decision, and those who just want to see forward
progress.

thanks for your consideration.

--Sam


pgpTPlk83YIrd.pgp
Description: PGP signature

Bug#741573: #741573: Menu Policy and Consensus

[Cyril Brulebois]

Sam Hartman  (2015-07-18):
> > "Bill" == Bill Allombert  writes:
> 
> Bill> On Fri, Jul 17, 2015 at 10:08:04PM +, Sam Hartman wrote:
> >> In March of 2014, Charles Plessy asked the Debian Technical
> >> Committee to review one of the policy editors decisions to revert
> >> changes to how policy talks about the Debian Menu and MIME
> >> support.  See http://bugs.debian.org/741573 for the TC process
> >> and https://bugs.debian.org/707851.  for the process within
> >> debian-policy.
> >> 
> >> One of the issues is the question of whether the Debian Policy
> >> community reached consensus around the proposal.  I've
> >> investigated this question as part of trying to understand how I
> >> will vote within the TC process.
> 
> Bill> I want to point out that I have split the menu policy changes
> Bill> in 3 parts, so that the less controversial part could be
> Bill> decided separately, see #742532.  However nobody was
> Bill> interested in seconding this. So I am let to believe there is
> Bill> no actual consensus on this.
> 
> I agree that there doesn't seem to be consensus on your proposed split.
> 
> I don't think I can infer anything about the overall proposal's support
> from lack of support for the split.  As an example, if I had high
> confidence that I could get consensus on the entire proposal, I would
> not generally support handling the less contraversial parts first.
> 
> If you handle the less-controversial parts first, it's easy to get into
> a situation where that's all you solve.  When you do that because you
> honestly can't get consensus on more than the less-controversial parts,
> the process is working.  However, sometimes those sort of splits can
> create dynamics where you get less of a solution than you might hope.

Well, trying to split topics, menu policy changes, or hairs, seems (at
least to me) to be the new trick of the day to cover up the inexcusable
behaviour that Charles described when he opened up this very bug report.

Wasting people's hard work, and then using a lack of reply to an extra
round of nitpicking as an excuse for having wasted the whole lot?

Shame on you, Bill.


KiBi.


signature.asc
Description: Digital signature

Bug#741573: #741573: Menu Policy and Consensus

[Charles Plessy]

Le Sat, Jul 18, 2015 at 01:56:49PM +, Sam Hartman a écrit :
> > "Bill" == Bill Allombert  writes:
> 
> Bill> I want to point out that I have split the menu policy changes
> Bill> in 3 parts, so that the less controversial part could be
> Bill> decided separately, see #742532.  However nobody was
> Bill> interested in seconding this. So I am let to believe there is
> Bill> no actual consensus on this.
> 
> I agree that there doesn't seem to be consensus on your proposed split.

Hello everybody,

I am not willing to enter discussions on whether I agree on subsets of a
proposal that I already approved as a whole in totality.  This is a waste of
time (that reminds me Zenon's paradox).

Also, the question is not whether the FreeDesktop menu should be described in
the Policy or not, or how to split the proposal in 3, 4 or 42 parts.  It is not
even on whether the Debian menu should be a "must" or a "should", because for
that as well, we got a "rough consensus", where at the end of the process there
was only a single person opposing the change.  Neither it is about re-starting
a search for people disagreeing (or shall I restart a GR on systemd ?).  The
question is whether a single individual can engage in confrontational commit
wars to block changes in Debian.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150719003130.gc15...@falafel.plessy.net

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> On Fri, Jul 17, 2015 at 10:08:04PM +, Sam Hartman wrote:
>> In March of 2014, Charles Plessy asked the Debian Technical
>> Committee to review one of the policy editors decisions to revert
>> changes to how policy talks about the Debian Menu and MIME
>> support.  See http://bugs.debian.org/741573 for the TC process
>> and https://bugs.debian.org/707851.  for the process within
>> debian-policy.
>> 
>> One of the issues is the question of whether the Debian Policy
>> community reached consensus around the proposal.  I've
>> investigated this question as part of trying to understand how I
>> will vote within the TC process.

Bill> I want to point out that I have split the menu policy changes
Bill> in 3 parts, so that the less controversial part could be
Bill> decided separately, see #742532.  However nobody was
Bill> interested in seconding this. So I am let to believe there is
Bill> no actual consensus on this.

I agree that there doesn't seem to be consensus on your proposed split.

I don't think I can infer anything about the overall proposal's support
from lack of support for the split.  As an example, if I had high
confidence that I could get consensus on the entire proposal, I would
not generally support handling the less contraversial parts first.

If you handle the less-controversial parts first, it's easy to get into
a situation where that's all you solve.  When you do that because you
honestly can't get consensus on more than the less-controversial parts,
the process is working.  However, sometimes those sort of splits can
create dynamics where you get less of a solution than you might hope.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/tslpp3p8t7m@mit.edu

Bug#741573: #741573: Menu Policy and Consensus

[Bill Allombert]

On Fri, Jul 17, 2015 at 10:08:04PM +, Sam Hartman wrote:
> In March of 2014, Charles Plessy asked the Debian Technical Committee to
> review one of the policy editors decisions to revert changes to how
> policy talks about the Debian Menu and MIME support.  See
> http://bugs.debian.org/741573 for the TC process and
> https://bugs.debian.org/707851.  for the process within debian-policy.
> 
> One of the issues is the question of whether the Debian Policy community
> reached consensus around the proposal.  I've investigated this question
> as part of trying to understand how I will vote within the TC process.

I want to point out that I have split the menu policy changes in 3 parts, so 
that
the less controversial part could be decided separately, see #742532.
However nobody was interested in seconding this. So I am let to believe there
is no actual consensus on this.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150718123259.GC8903@yellowpig

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

In March of 2014, Charles Plessy asked the Debian Technical Committee to
review one of the policy editors decisions to revert changes to how
policy talks about the Debian Menu and MIME support.  See
http://bugs.debian.org/741573 for the TC process and
https://bugs.debian.org/707851.  for the process within debian-policy.

One of the issues is the question of whether the Debian Policy community
reached consensus around the proposal.  I've investigated this question
as part of trying to understand how I will vote within the TC process.

I had hoped to get the TC as a whole interested in the question of
whether consensus had been reached, but while several TC members have
joined that discussion, it seems that the TC as a whole will not address
that question.


However, I've tried to investigate the process.
I draw your attention to
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=497;bug=741573 .
In that message I outlined my plan for how I'd review whether consensus
was reached as a TC member.

It's probably worth taking a look at that message even if you don't care
about the issue.
I propose that a reasonable way for the TC or anyone else for that
matter to evaluate consensus is to:

* Confirm from the bug log that a proposal gained enough seconds

* Confirm that the people seconding believe (as required by the
  process.txt document) both that the proposal is sound/complete and
  that it has reached consensus.

* Make an explicit call for unresolved technical objections and if any
  objections areraised, consider them. [1]

[1] Note that consider  is complex.  RFC 7282  gives thoughts that some
folks have had on some of these issues in cases where you have agreement
that the work should be done and are trying to come to rough consensus
on how to do it.  Issues like whether the issue has been considered
before, whether it was understood when considered, etc all are
important.  Evaluating rough consensus once you get to a point where you
have objections is kind of an art form.

If my approach does not seem reasonable then I'd recommend revising
process.txt to give better guidance to folks reviewing your work.

I tried to implement my approach.

It is my belief that rough consensus was achieved.  Those who seconded
the proposal more-than-less reviewed the discussion for rough
consensus.  I also looked at significant chunks of the discussion
including the list of objections that Bill raised.
It's my belief that the objections Bill raised were discussed by the
broader community and his points were considered.
It's my belief that the other objections he pointed to (other than his
own) in his mail indicating he'd reverted the change were explicitly
addressed.  In at least one case I got confirmation of that from the
person raising the objection.

That said, I'd like to draw your attention to two of the mails I got
asking people to review seconds and to the  process text surrounding
seconds.  These responses are on the edge with regard to whether the
person seconding actually met the process requirement of evaluating
rough consensus.  If someone wanted to argue that no consensus was
reached, these two seconds would be one way to make such an argument.


What needs to happen next: The proposal needs to be reviewed and
seconded. Any Debian developer who agrees with the change and the
conclusion of rough consensus from the discussion should say so in the
bug log by seconding the proposal.


[TAG: patch]: 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&pend-exc=done&tag=patch

State E: Seconded 
--

The proposal is signed off on by N Debian Developers. To start with,
we're going with N=3, meaning that if three Debian Developers agree,
not just with the proposal but with the conclusion that it reflects
consensus and addresses the original issue -- it is considered
eligible for inclusion in the next version of Policy. Since Policy is
partly a technical project governance method, one must be a Debian
Developer to formally second, although review and discussion is
welcome from anyone. Once this tag has been applied, the bug is
waiting for a Policy team member to apply the patch to the package


Now, I ask you to consider Lisandro Damián Nicanor Pérez Meyer 's
response to my question about his second:

Sam> What I'm hearing is that during the time you made the second you were
Sam> paying attention to the discussion and didn't believe there were any
Sam> counter-seconds--people jumping up and down saying their issues had not
Sam> been addressed?
Sam> If I've got that right, I think that's all we need at this point.

No, you are hearing a different thing ;)

What I'm saying is that the procedure at one point requires people to write 
a 
mail specifying that they are seconding the proposal. And I was one of them.
To the best of my knowledge no one counter-seconded the proposal in this 
way.