>>>>> "Ian" == Ian Jackson <ijack...@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. -- 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/tslbnf4xs6g....@mit.edu