Re: Dispute resolution in Debian
Hi Sean, On Wed, Jul 29, 2020 at 1:10 PM Sean Whitton wrote: > > So what you are proposing would correspond to the last of our > proposals -- try to remove the meditation role the TC presently has? I am sorry you read my proposal as curtailing TC's "territory". I merely meant to write that mediating between people and making good long-term technical decisions for the project are probably two different things. Your original email stated as much when you wrote that "[often] the conflict is not at the technical side." Kind regards Felix Lechner
Re: Dispute resolution in Debian
Hello, On Wed 29 Jul 2020 at 03:26AM -07, Felix Lechner wrote: > As a computer project, Debian's highest decision making body should > probably be a Technical Committee. Current committee members who like > to adjudicate more along human lines, under my proposal, may wish to > join the Community Team. So what you are proposing would correspond to the last of our proposals -- try to remove the meditation role the TC presently has? -- Sean Whitton signature.asc Description: PGP signature
Re: Dispute resolution in Debian
Felix Lechner dijo [Wed, Jul 29, 2020 at 03:26:00AM -0700]: > > Do you think it shouldn't have those other roles, maybe? That would > > correspond to the last of our proposals, I think. > > As a computer project, Debian's highest decision making body should > probably be a Technical Committee. Current committee members who like > to adjudicate more along human lines, under my proposal, may wish to > join the Community Team. However, most issues that come to the TC have a _strong_ human/social component. We cannot dissociate technical decisions with the emotional meaning they carry to project members. If technical excellence was the sole, or even main, requisite to become part of the Technical Committee, I would not have joined. Purely technical decisions are far from the norm; Debian as a project has quite good inner coherence (which means, project members have a quite compatible view of where they want to drive the project to), and when the TC is asked to participate, the divergence is usually very minor; we do deal with technical issues, but more than that, we deal with what does each decision ultimately mean. I don't think we can keep TC work 100% technical, or separate the inter-human part from the TC's work. > Debian needs more empathy. People are not logical like machines. They > are burdened by ideas and have fears and hopes. Plus, some do not > lightheartedly express how they feel. Solving conflicts in a unified > system brings all that out in one place, and makes peace. On my first reading and when I started replying, I had got your message basically upside down. So, basically - Yes, I (now) completely agree with you :-]
Re: Dispute resolution in Debian
Hi folks, On Mon, Jul 27, 2020 at 07:01:23PM -0700, Sean Whitton wrote: >On Sun 26 Jul 2020 at 07:59PM -07, Felix Lechner wrote: >> >> Like any court, the Community Team and Technical Committee should be >> able provide independent solutions of their own design. Ideally, the >> judges at the lower level, i.e. the Community Team, would be elected. > >I think we think of the community team as mostly about the CoC -- not >just strict violations but conformance with its spirit -- whereas the TC >is about disagreements which do not involve (or do not primarily >involve) CoC issues. In which case, the relationship between the two >would not really fit the model you suggest. Correct - we're *mostly* targeting very different areas. There *can* be some overlap, but I don't see this working as Felix suggests. No harm in proposing new ideas, though! -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: Dispute resolution in Debian
Hi Sean, I hoped respected members like Sam would send additional ideas first, but then did not wish to keep you waiting. On Mon, Jul 27, 2020 at 7:01 PM Sean Whitton wrote: > > Do you think it shouldn't have those other roles, maybe? That would > correspond to the last of our proposals, I think. As a computer project, Debian's highest decision making body should probably be a Technical Committee. Current committee members who like to adjudicate more along human lines, under my proposal, may wish to join the Community Team. > I think we think of the community team as mostly about the CoC Please keep an open mind. The Community Team would quickly shed its image of a pronoun-wielding social reformer and become a universally respected arbiter of justice—especially when elected. They have the human touch. Debian needs more empathy. People are not logical like machines. They are burdened by ideas and have fears and hopes. Plus, some do not lightheartedly express how they feel. Solving conflicts in a unified system brings all that out in one place, and makes peace. Kind regards Felix Lechner
Re: Dispute resolution in Debian
Hello Felix, On Sun 26 Jul 2020 at 07:59PM -07, Felix Lechner wrote: > I would model access to conflict resolution on the US courts. There > should be two levels of jurisprudence: One is quick and easily like > small claims, the other is for appeals. Both can issue rulings that > bind everyone, including delegates and the DPL. > > Private side conversations should remain off-limits. They create an > incurable attack surface that lowers credibility. Decision makers who > expressed an opinion outside the official process must recuse > themselves. To seek their opinion, please file a case. Well, the TC is the closest thing we have to a court of last resort indeed, but I think its members hope that it could be other things as well -- most disputes in Debian do not require a court of last resort-style response. Do you think it shouldn't have those other roles, maybe? That would correspond to the last of our proposals, I think. > As Sean wrote, many problems at Debian are social in nature, I would The text it from the whole committee, I was just the messenger :) (and marga did most of the work) > make the Community Team the first legal instance before a party can > appeal to the Technical Committee. Cases at Community Team level > should be heard before a single member unless someone requests a > hearing en banc. That effectively makes the Technical Committee > Debian's Supreme Court (which hears all cases). In some way, this > resembles Sean's Proposal 2. > > Like any court, the Community Team and Technical Committee should be > able provide independent solutions of their own design. Ideally, the > judges at the lower level, i.e. the Community Team, would be elected. I think we think of the community team as mostly about the CoC -- not just strict violations but conformance with its spirit -- whereas the TC is about disagreements which do not involve (or do not primarily involve) CoC issues. In which case, the relationship between the two would not really fit the model you suggest. -- Sean Whitton signature.asc Description: PGP signature
Dispute resolution in Debian
Dear Technical Committee, In deviation from community standards, I top-post. I hope it provides a simple and coherent narrative that is also compelling. You should be familiar with the issues raised in Sean's email. I would model access to conflict resolution on the US courts. There should be two levels of jurisprudence: One is quick and easily like small claims, the other is for appeals. Both can issue rulings that bind everyone, including delegates and the DPL. Private side conversations should remain off-limits. They create an incurable attack surface that lowers credibility. Decision makers who expressed an opinion outside the official process must recuse themselves. To seek their opinion, please file a case. As Sean wrote, many problems at Debian are social in nature, I would make the Community Team the first legal instance before a party can appeal to the Technical Committee. Cases at Community Team level should be heard before a single member unless someone requests a hearing en banc. That effectively makes the Technical Committee Debian's Supreme Court (which hears all cases). In some way, this resembles Sean's Proposal 2. Like any court, the Community Team and Technical Committee should be able provide independent solutions of their own design. Ideally, the judges at the lower level, i.e. the Community Team, would be elected. Thank you for your hard work on the Technical Committee! Kind regards Felix Lechner -- Forwarded message - From: Sean Whitton Date: Sun, Jul 26, 2020 at 1:37 PM Subject: CTTE requesting questions for DebConf20 BoF To: Hello everyone, ... The technical committee has served the project for many years, acting as a conflict resolution body of last resort. The TC is established in the Debian Constitution,[2] which means that it's a highly regulated body and it's hard to change it. The current setup of the TC has several problems that need to be addressed. This document is split between first a description of the current situation and the problems identified, followed by a bunch of different proposals that we could implement to try to solve said problems. Problems Perception -- Because everything is mandated to be public, discussions must take place in a public forum where anybody can jump in and add wood to the fire. This can be very taxing, so there are community members that just check out and refuse to participate in the discussion even when their input would be valuable. And even those who participate can feel that their voice is being drowned by whoever sends the most emails. The committee strives to hear all opinions equally regardless of how many emails were sent, but the participants of the discussion can still end up with a bitter taste because of how it devolved. Going to the TC is seen as a nuclear option, as a stick to beat others with. This is partly because of how the Constitution establishes that the role of the committee if to be a last resort decision maker. But also because of historical reasons that are very hard to change, even when the committee members have all changed by now. People don't like being on the "losing" side of a decision, but even if they are on the "winning" side of it, lots of people don't want the level of flamewar and attention that an issue raised to the TC brings. Some people would rather orphan a package than participate in a discussion with the TC. Social vs Technical --- Most of the problems that reach the TC are not purely technical. There's a lot of "human stuff" going on. People with different goals or interests that fail to agree on how to move forward, but the conflict is not at the technical side. For discussions around social issues, discussing in the open is like being on public trial. It's very stressful and very hard to find a good resolution. On top of this, because this is the *Technical* committee, we're forced to focus on the technical side of a problem. In various occasions this means that there's really no solution we can offer. We're not explicit mediators, we don't have the authority to be mediators and we're definitely not set up in a way that leads to good mediation outcomes. Speed - In many occasions in the past, the committee took too long to make a decision. There's many reasons for this. Perhaps we wanted to be thorough in looking at the problem from all angles. Perhaps we wanted to explore different alternatives to solve the issue. Perhaps we were busy with other priorities and the discussion just moved slowly. Whatever the case, the long time to resolution also devalues the role that the committee has in solving issues (technical or not technical). If the TC is going to be of value to the project it needs to act quickly when dealing with urgent matters (for example, right before a freeze). It's important to note that the questions brought to the TC typically have no easy and quick solution, that's why they were brought to the TC
