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
Reply to: