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
Re: Rethinking the role of the TC
Margarita Manterola writes: > Problems > I might bikeshed the wording a bit, but nothing that should keep us from discussing it. > > Proposals > = > Private Discussions > --- > [...] > As long as no decisions are made in private, this wouldn't require a > change to the Constitution. However, it might be good to amend section > 6.3 to make explicit which discussions can happen privately and which > ones need to happen publicly. 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. > Mediation body > -- > > > **Proposal 2**: Explicitly delegate the mediation task for solving > social conflict between developers, when no code-of-conduct violation > is in place. This could be to: > > a. A new group of developers > b. The Community Team > c. The Technical Committee. Recent history suggests that there will be meta-disputes about whether the conflict is technical or not. As you remark above few conflicts are purely technical; I suspect the converse is also true (maybe Sean also mentioned this), few conflicts are purely social, at least in the eyes of the conflictees. > Allow design work > - > > As mentioned, the restriction on the TC only being able to choose > between options limits the work that the TC can do. It also limits > the legitimity that the committee has, because it's seen as a bunch of > people that just issue decisions without doing any of the work. I imagine when most people resent decisions imposed on them, it isn't because they want a more design work, but rather that want the imposer to do the implementation work, and deal with the fallout. Or maybe I'm just projecting my own resentments. > Allow the TC to be invoked early > > > The requirement to make decisions as a measure of last resort means > that by the time the committee is called to action, most issues have > already become a flamewar where no matter the result people will end > up unhappy. Removing this requirement would allow the TC to get > involved earlier, helping developers find consensus rather than > beating them with a stick. 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. > > Split responsibilities into separate groups > --- > > * Advisory body (give advice § 6.1.5, make technical proposals [Proposal > 3]) > * Mediation body (solve social conflict [Proposal 2]) > * Technical decision resolution body (decide when developers can't agree > § 6.1.2, override developers, § 6.1.4) I have the feeling that people that resent being told what to do by the TC will still resent the TDRB (part 3 of the split). Maybe if the responsibilities are narrowed that can help some of the process issues. Part 2 is already discussed, I and I think it makes sense to think about (lack of) mediation in Debian. Part 1 sounds like a less noisy version of debian-devel@l.d.o. It's not to me that it needs organizational structure.
Re: Rethinking the role of the TC
Hi, Thanks for your feedback, I reply below to the points that you raised. Please know that my document is mostly intended to start a conversation, not to finish it :). On 2020-07-18 19:16, Sean Whitton wrote: Non-CoC social issues often arrive tangled up with the technical issues that come before the TC, such that the project already expects the TC to mediate, and people are appointed to the TC on the basis that they will be capable of mediating. 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. Then with respect to the "mediation body" proposal, the point seems to be for the project to assign mediation responsibility for purely non-technical, non-CoC social issues to a new body, or to an existing body, the TC, which is meant to already have people capable of mediating on it. 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 might be a good idea for Debian to do that, but the sense in which it might make the TC more useful to Debian is quite different from the three proposals I said I am particularly keen to discuss, which are about making the TC more useful for issues it already has responsibility for. 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. 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. Additionally, in light of the discussions we had about the formation and delegation of the Community Team, I am concerned that we could end up in quite fractious, overly general discussions about the role of mediation in mostly-but-not-wholly-technical projects like ours. So I would like to have a concrete conception of how this could make the TC more useful before going down that road. Well, the TC itself would cease to exist and be replaced by a bunch of other bodies. So, this wouldn't really be "make the TC more useful", but rather, solve the problems that the TC is solving in a different way. One thing that I didn't include in the doc, because I wasn't sure what to do with was the matter of member selection. TC members are self-selected and that leads to questions of legitimacy. If we were to deconstruct the TC and construct new bodies out of it, we might want to go through a different process to select the members of each. We might even consider a different election process for the TC as it is right now. But really, I don't know where we would even start for something like that. -- Regards, Marga
Request for input -- rethinking the role of the TC
Dear Ian, On Sat 18 Jul 2020 at 10:16AM -07, Sean Whitton wrote: > On Sat 18 Jul 2020 at 04:29PM +02, Margarita Manterola wrote: > >> The doc collects the main problems that have been raised about the TC >> and a bunch of proposals of what we can do about it. Neither list is >> complete and your input is welcome. >> >> I've created it as a Markdown doc in our git repo and created a merge >> request for it, so if you want, you can add your comments to that MR: >> https://salsa.debian.org/debian/tech-ctte/-/merge_requests/1 > > I think that the document is well-written. Thank you for working on it. > I am particularly keen to discuss the "private discussion", "allow > design work" and "allow the TC to be invoked early" proposals. Your > descriptions of those seem complete. As the original author of our constitution, I would like to ask you to take a look at the three proposals for TC reform I list in the quoted message. Would it be possible for you to summarise the rationale for these restrictions on how the TC works, or provide us some links to old discussions, please? I am hoping that this can help us better determine precisely how to loosen these restrictions. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Re: Rethinking the role of the TC
Hello Marga, On Sat 18 Jul 2020 at 04:29PM +02, Margarita Manterola wrote: > The doc collects the main problems that have been raised about the TC > and a bunch of proposals of what we can do about it. Neither list is > complete and your input is welcome. > > I've created it as a Markdown doc in our git repo and created a merge > request for it, so if you want, you can add your comments to that MR: > https://salsa.debian.org/debian/tech-ctte/-/merge_requests/1 I think that the document is well-written. Thank you for working on it. I am particularly keen to discuss the "private discussion", "allow design work" and "allow the TC to be invoked early" proposals. Your descriptions of those seem complete. At the present time, I am not convinced of the value of discussing the "mediation body" and "split responsibilities" proposals, because I don't yet see how they are in scope for a reform project led by the TC. I'll try to explain what I mean, and then maybe you could expand your descriptions, ideally with some concrete examples, such that I and others can see better what you're getting at. Non-CoC social issues often arrive tangled up with the technical issues that come before the TC, such that the project already expects the TC to mediate, and people are appointed to the TC on the basis that they will be capable of mediating. Then with respect to the "meditation body" proposal, the point seems to be for the project to assign mediation responsibility for purely non-technical, non-CoC social issues to a new body, or to an existing body, the TC, which is meant to already have people capable of mediating on it. It might be a good idea for Debian to do that, but the sense in which it might make the TC more useful to Debian is quite different from the three proposals I said I am particularly keen to discuss, which are about making the TC more useful for issues it already has responsibility for. So, ISTM that a project to assign responsibility for mediating non-CoC, purely non-technical issues is a distinct project from that of rethinking how the TC handles what it already has responsibility for, and moreover, it is not clear to me such a project should be led by the TC. 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. Additionally, in light of the discussions we had about the formation and delegation of the Community Team, I am concerned that we could end up in quite fractious, overly general discussions about the role of mediation in mostly-but-not-wholly-technical projects like ours. So I would like to have a concrete conception of how this could make the TC more useful before going down that road. -- Sean Whitton signature.asc Description: PGP signature
Rethinking the role of the TC
Dear committee members and friends subscribed to this mailing lists, After months of procrastinating on this issue, I've finally managed to put down all the thoughts collected during and after DC19 regarding the role of the TC into a doc. The doc collects the main problems that have been raised about the TC and a bunch of proposals of what we can do about it. Neither list is complete and your input is welcome. I've created it as a Markdown doc in our git repo and created a merge request for it, so if you want, you can add your comments to that MR: https://salsa.debian.org/debian/tech-ctte/-/merge_requests/1 I'm also including the current text of the doc here. So, if you prefer to discuss over email, you can do that as well. I will update the merge request as comments come in (through both MR comments and mail comments). I'll keep the mailing list updated of major changes, but not of nitpicks. If you have important comments, please try to make them during before next Sunday (July 26th), so that I can incorporate them before we share this doc with more people. Thanks! Here's the first draft. = 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 (https://www.debian.org/devel/Constitution#item-6), 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 technical in nature. 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 technical in nature. 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 in the first place. Still, we could do a lot better. 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 c
