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
Attachment:
signature.asc
Description: PGP signature