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
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
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
