Hello everyone,

The Technical Committee are planning a BoF for DebConf20. Most of it
will be a Q&A session, and we want to collect questions in advance, in
addition to answering {follow-up ,}questions asked during the session.

A general hope is that this should increase the quality of our answers,
but more specifically, we want to use the BoF to firm up our ideas about
the future of the TC, and we think this goal will be better served if
talking points are submitted in advance.

Please find below a description of our current thoughts about the future
of the TC. We have highlighted points and issues which we think should
be discussed at the BoF, so if you have ideas or questions to ask
specifically on those points, please do submit them. If we amend the
text below, you can find the latest version at [1].

More general questions are welcome too.

Based on what we receive, we will curate a list of talking points before
the session, and structure the BoF around them.

Please address your questions and talking points to <debian-ctte@lists.debian.org>, preferably in reply to this message for
easier collation.

~ ~ ~ ~ ~

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,[2] 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 purely technical. 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 at the technical side. 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 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.

This has the added consequence that the TC is seen (by some) as not
providing any value to the project, because we aren't creating anything,
"we just say no".

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.

No-decision decision
--------------------

A lot of the issues that come to the TC end up being closed with us
declining to rule. There can be many reasons for this:

* We were asked to override a delegate (which we can't do)

* We were asked to do design work (which we also can't do)

* We were asked for advice and gave some advice (no ruling is required
for giving advice).

* The issue got resolved on its own before the TC reached a decision
(see the "Speed" section above).

This might be ok and be part of the nature of the TC. Some committee
members hold that this is fine and that it's not a problem. Still, it's something to take into account when thinking about the current
situation.

Proposals
=========

There's a bunch of things that we can do. Some may imply changing the Constitution, some may not. We should consider how to maximise the value
that the TC brings to the project, not how hard the proposal would be to implement (i.e. it's ok if we need to change the Constitution). Some of
these proposals complement each other, while others contradict each
other. They are here to spark thought, not as a thought out plan
(yet). We should adopt the subset that makes the most sense.

Private Discussions
-------------------

One way to solve the perception issue is to have a way for people to
have private discussions with the TC.

There's a range of options between being fully private (moving the TC
mailing list to private, having a private IRC channel and only informing
people of decisions in public when they are final) and fully public
(basically the current state - while we do have a private mailing list,
it's very rarely used, practically everything happens in the open).

The fully private extreme would hurt the committee's credibility and
probably lead to a lot of miscommunication. But it should be possible
to find a middle point in this range that still keeps important
discussions in the open while allowing social issues to be solved
privately.

It's common for DDs to communicate between them in private and there's
no reason why people couldn't approach the TC privately, as long as the important decisions and discussions are still done publicly.

**Proposal 1**: let developers raise issues privately to the TC when
they feel that they need advice or help in dealing with a hairy
issue. Issues that need a public vote would still need to be raised and discussed in public, but issues that would lead to a "no-decision"
decision, can reach a more friendly resolution this way. This proposal
implies having a documented way of raising an issue privately and a set
of expectations of what happens when this action is taken.

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.

Mediation body
--------------

The project as a whole will always need help solving disagreement that
is social rather than technical in nature. In different ocassions, this
role has been played by the DPL, the TC, the Community team (pka Anti-Harassment team). None of these are actually explicitly designated
as mediation bodies, which sometimes gets in the way of achieving the
desired resolution. So, it might make sense to designate a body
explicitly for 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.

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

Regardless of who is delegated for this task, involved processes would
need to be well documented, so that Debian community members know what
to expect when they get involved in a mediation.

If the TC is chosen as the mediation body, this would require a change
in the Constitution. Otherwise, it's just a DPL delegation.

Whether or not the TC is chosen as the mediation body this can help
define the role of the TC in Debian. If chosen, then we need to
establish the necessary processes. If some other body is chosen, then we
can re-direct social issues to this team and help find quicker solutions
to problems.

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.

One possibility would be to allow design work to happen from the TC in
the form of proposals. These proposals wouldn't have the weight of a TC decision that must be implemented and would instead act as guidance on
how a certain problem might be resolved. This would be a significant
change in the role of the TC, over time it would mean that the work done
as TC members changes more to "thinking up solutions" than to "just
saying no".

**Proposal 3**: Modify the Constitution to allow the TC to do design
work in the form of proposals. These proposals wouldn't override
developers or tell individual maintainers what to do, but rather should
guide the project towards a technical goal.

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.

For this change to be successful, there should be a clear way of
invoking the TC that doesn't imply a "nuclear option". A way of asking
for help solving a technical disagreement without generating resentment.

Developers don't always know how to solve problems before bringing them
to the TC and that's ok. If we can find a way to let the TC help with
conflict without creating "winners" and "losers" we could make it a much
more useful body.

**Proposal 4**: Modify the Constitution to allow the TC to get invoked
early, clarifying how that works.

Split responsibilities into separate groups -------------------------------------------

Some of the criticism that the TC has received is that it has too many
roles, some of them explicit (make decisions when developers can't
agree, overrule a developer, give advice) and some implicit (mediate
social conflict, act as a group of elders). And so instead of adding
more explicit roles (as seen in proposals 2 and 3 above), it would be
better to split these roles into separate bodies, created from scratch:

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

**Proposal 5**: Abolish the TC and split it into separate roles. This
would of course require changing the Constitution and there are a bunch
of open questions regarding who gets to do what and how the members of
each body should be elected.

Please note that the TC members don't actually want this, but this
proposal has been included here for completeness as it has been
suggested by other developers during discussions. There's a lot of
unknowns of what exactly this proposal would look like and in order for
it to get adopted someone would need to clearly outline each of the
roles, resposibilities and processes.

People that want this proposal to actually happen would need to
volunteer time and energy to make it a reality.

[1] https://salsa.debian.org/debian/tech-ctte/-/blob/master/talks/rethinking-the-tc.md
[2] https://www.debian.org/devel/Constitution#item-6

--
Sean Whitton

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAl8d6XYZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQJsbD/43l26eeRFgVtkZo6KyyiYl ebRsE19Iwmu7uLMLnV2pb6yT3u9BwKciEQNY/aOpc0Bbuz995G/tQArJuwL4dGA1 BksVqElDaTQVaEvKl6U+xo5WyEgIufSFFlp6S8aSxf3e4bw7KNA6B1DiUUFhqEK7 PpjgnfHuwfwS++EAxFoA29oyqH8P4YWoewQvHjrIofFjS20j2PPcUJdHmwnx0wkN yacMZO24Gxr7v9u83qqBeFq/AvyRNIW23j9Ec9y/NQOHoF/zQLhtO+XjFEhUwbi5 qEjlk5omUxcFy2mNwzQg6FqhsxUm2DcIol9BIRfr1//Vth3CwPhXEgytKdSYHqmY gWQnSq+Y0FTuNJASPgxrEtZ8GYm0J1p2HgCuCLiWTq4m04cSjZ44FhVtVyqifs+9 53pkhMaADyEs8E+YTaU0RTKGe7tyhESQEzkC+FAdauZgKwk41zOQn8374R6xOMcM /3r+qEeo0v4jzpEPS904JFp040vPV2tLfTRr77KFsWTtju024s5kQMCULHCp5wQ4 ZH9lD6zhQvm+JQVUn9RgZL1E5xBhm2Hn8QAOKoLlmfe9vufw9Saf446EFiTjhg1V RlueUCOqT5LO//QspWcO25ClbKaOJfmKsPDMqb1YCdXWYzEg2KHEy8NnooIKrZ/y H1yDoyGYg0PHv9VHKrXLBA==rN5U
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Us