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
Re: Rethinking the role of the TC
These are a great start for discussion; I think every single one of them is worth discussing, and probably deserves a BoF in its own right. On Sat, 18 Jul 2020, Margarita Manterola wrote: > No design work > -- > > One of the constraints that the TC has to deal with is that we can't > do any design work, it can only choose between options already > presented to it. A consequence here is that even when we have a group > of experienced individuals from different areas of Debian that can > maybe come up with great ideas to solve a problem, we can't really put > those ideas to work, as we can't do design work. Several times it has > happened that a discussion that was interesting in nature had to be > stopped because we were falling into the trap of doing design work. What if the TC still didn't do design work, but instead suggested ideas and working groups (optionally including TC members) to come up with solutions and implementations of those solutions? Alternatively, the TC could issue an opinion about what parameters an ideal solution/implementation would have, and once implementation exist, empower the winning implementation to be implemented. > Also, related to this is the fact that the TC has the power to make > technical decisions that developers then need to implement, without > being involved in either the design or the implementation of those > decisions. This can be seen by some developers as too much power with > too little responsibility. This is the difficult balance; at the end of the day, the TC can only empower someone (potentially TC member(s)) to do the implementation. -- Don Armstrong https://www.donarmstrong.com Some pirates achieved immortality by great deeds of cruelty or daring-do. Some achieved immortality by amassing great wealth. But the captain had long ago decided that he would, on the whole, prefer to achieve immortality by not dying. -- Terry Pratchet _The Color of Magic_
Re: Rethinking the role of the TC
Hello, On Sun 26 Jul 2020 at 08:47AM -07, Sean Whitton wrote: > It's late in the day but I would like to suggest including this > paragraph in the document in some form. Thank you for doing this in commits today. I'd like to suggest going a bit further, however -- how about this: As work done inside the Debian is inherently technical, it's hard for an issue to be *purely non-technical*, there's always something technical behind the conflict. But in many conflicts, the *issue that needs solving* is of a social nature rather than a technical nature. In this sort of situation the TC members can readily observe that making a decision on the technical issue will not really help matters, but it is the only thing the TC is actually empowered to do. -- Sean Whitton signature.asc Description: PGP signature
Re: Rethinking the role of the TC
Hello, On Thu 23 Jul 2020 at 07:40PM -03, David Bremner wrote: > I think it makes sense to formalize the "I'm thinking of bringing the > following issue to the TC" discussions that already happen, to reduce > the amount that people need to rely on existing personal relationships. Might be good to include this in the doc? > I don't know whether this is a point in favour or against this proposal, > but I don't think developers are always that great at trying other ways > of resolving problems before bringing them to the TC. This is related to > the issue of mediation above. I think the idea might be to accept that people aren't very good at this and try to help them earlier. -- Sean Whitton signature.asc Description: PGP signature
Re: Rethinking the role of the TC
Hello Marga, I'm sorry I didn't reply sooner. On Sat 18 Jul 2020 at 07:50PM +02, Margarita Manterola wrote: > This is true, TC members are expected to be able to deal with "social > issues". But still when issues arrive at our doorstep and we come to the > conclusion that there's no technical issue to decide upon, we are > usually left wondering what to do about them. In other words, if the > problem is that two members of the community are clashing in the way > they communicate and there's no option A or option B to select from, the > TC is ill-equipped to deal with that. > > [...] > > As work done inside the Debian is inherently technical, it's hard for an > issue to be *purely non-technical*, there's always something technical > behind the conflict. But in many conflicts, the _issue that needs > solving_ is of a social nature rather than a technical nature. It's late in the day but I would like to suggest including this paragraph in the document in some form. > I think clarifying who's in charge of mediating social conflict between > developers might help the TC, whether the TC is that body or not. > > If we (as in the Debian project) decide that the TC should be in charge > of mediation between developers (as long as there's no CoC violation), > we can establish processes to do that. Probably add a few points to the > constitution that clarify this role, how it works, etc. That way, > developers can come to us and understand what they can expect from us in > this situation. > > If we decide that a different body (Community Team or a new one) should > be in charge of mediation, then we can re-direct social issues to this > team and stop wringing our hands when there's no technical option to > select. I see what you mean now -- the existence of something technical somewhere within the issue prompts the dispute to be brought to the TC, but if the TC makes a decision on the technical side of the dispute, it won't really help anything; the TC members can see that, but the only thing they can do is 'solve' the technical side of the dispute, which is not very useful. So, you're not really talking about those very rare, purely non-technical, non-CoC issues I mistakenly thought you had in mind. >> With respect to the "separate responsibilities" proposal, I would like >> to ask for more detail on how it is thought this could make the TC more >> useful. Right now I can't see how it would, given what I just wrote >> about how social issues tend to come throughly tangled up with >> technical >> ones, except for the purely non-technical, non-CoC issues, which the TC >> does not presently have responsibility for anyway. > > Well, that option is very much in the air, but I wanted to include it > because it had been floated around in this mailing list and also during > the talk at DC19. The goal of that option is to basically abolish the > TC as it is now, and in its place construct new teams that are better > equipped to deal with each type of problem (advice & guidance, social > conflict, technical conflict). > > Some developers take issue at the fact that the TC has too much power. > So, splitting it into pieces would reduce the amount of power that each > piece has. If we decided that this was the way to go, we'd need to work > on the wording of exactly what each piece is in charge of. I saw your reply to Gunnar, on salsa, that this is mostly included for completeness. I'm on the fence about whether that's a good idea. If no-one in the TC wants to pursue this, then I'm concerned that starting a discussion on it is not going to achieve anything, and lead to fractious and overly general discussions like we saw regarding the formation and the delegation of the Community Team. If someone outside the TC wanted to pursue something like this, it would of course always be open to them start that discussion and draft the GR proposal. On the other hand having it on the list of proposals could forestall "what about ..." discussion from people who aren't really in favour of the option but are inclined towards discussing each possibility. In the end, I'm happy to trust your judgement on whether completeness is a good reason to keep this in, but I do think that avoiding subdiscussions that will go nowhere but have the potential to raise the temperature is something that teams starting discussions within Debian should consciously try to do, given how the past year has been on the mailing lists. -- Sean Whitton signature.asc Description: PGP signature
