[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#741573: #741573: Menu Policy and Consensus



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.


Reply to: