Re: Rethinking the role of the TC
Margarita Manterola <marga@debian.org> 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.
Reply to: