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

Bug#741573: #741573: Menu Policy and Consensus



>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> 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 we as a
community hold.


Reply to: