Bug#741573: #741573: Menu Policy and Consensus
>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> 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 cannot come up with the proposals itself (although
members can be part of that).
I won't drive such an effort, but if you think that we'd get better
policy by changing the policy process such that when there is
contraversy the proposals are tossed up to the TC to decide between,
then I urge you to build support for your view and see if you can get
the debian-policy process changed, or to work at the debian-project
level to build support for a different role for debian-policy.
Ian> Not only does [allowing the decision to be about who shouts loudest] result in bad decisions, but it rewards
Ian> behaviours which are effective at generating apparent consensus
Ian> on mailing lists. I'm sure it will be obvious to you that
Ian> there are many behaviours which are very effective for that but
Ian> which are also very harmful (indeed, which work _because_ they
Ian> are harmful). In Debian we normally mitigate this problem by
Ian> arranging that someone or some group is in charge of the
Ian> decision and applies their own judgement.
I believe that's the TC's job.
I'd like to try and characterize areas where we disagree because I think
it will help us understand each other and give others something to think
about. In my previous mail I said:
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.
Ian> Finally (and at the risk of sounding like one of those people
Ian> who quote the Social Contract at every opportunity) I would
Ian> like to point out that your view seems contrary to the spirit
Ian> of the Constitution.
Ian> The Constitution does of course say `may', so the TC isn't
Ian> required to determine the content of policy. But that is just
Ian> the language used when determining the powers abnd
Ian> responsibilities of every constitutionally defined role.
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.
Reply to: