Hello, I am "storing" here a copy/dump of the Etherpad we scribbled on during our DebConf20 session. I am doing nothing but to copy + send the text expor there; in case you find it useful to see what person wrote what, I am attaching the exported HTML - It does not have the people's names (only internal tags to colors), but it helps find which blocks are written by distinct people.
And, in case you want a clearer attribution, you can still refer to:
https://pad.online.debconf.org/p/16-meet-the-technical-committee
But be aware, it will disappear at some point. Oh, and for
completeness sake, the video is available at:
https://meetings-archive.debian.net/pub/debian-meetings/2020/DebConf20/16-meet-the-technical-committee.webm
It was a good and productive session IMO, but now we should do
something more.
What, how, when? Well... We all have to push for it :-|
------------------------------------------------------------
Private discussion
(ehashman to introduce)
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.
Sometimes you just need to hash out things in private. It can be particularly
benefitial for issues that can be contentious. It could be a good option to
defuse conflict.
OdyX: to some extent (at least in the [recent] past), the TC already discussed
_some_ things in private (such as potential nominations); mostly because it's
unreasonable to do it completely in public.
gwolf adds: it is known that the TC has a private list/alias, that it uses. "We
have learned that private discussions are not as bad as we thought they were".
But, can somebody come with an issue to the committee _on record_ and that
conversation being private? Of course, details on the procedure still have to
be discussed... -> Not right now.
marga: We have a private mailing list, but it is _not meant_ to be used for
discussion (only for minor things, such as wording)
Q: What are the issues needing a public vote?
A: When constitutional powers other than providing advice are to be invoked.
Then such private communication looks like the discretion of the people who
happen to be members of the TC. Who are we to forbid that? :)
It should be possible for people to ask whether we would overrule or not
without it becoming public.
We could say constructive things both publicly and privately.
"I think that the TC should formally announce that it can do informal chats
too, and that such informal chats are not a substitute for formal
announcements, and that'd be great." (asheesh).
Elana: Many of these discussions will end up showing conflicts between what the
constitution says, what best practices are, and what happens in reality...
Sean: If we're not going to make this change let's be clear about why the TC is
so significantly different from every other team that has to handle conflict
resolution. I don't think, as a project, we have a clear idea about this atm.
Allow the TC to be invoked early
(smcv to introduce)
Proposal 2: Modify the Constitution to allow the TC to get invoked early,
clarifying how that works.
- We are defined as a "last resort" resource, but it's somewhat of an empty
definition
smcv: Positions are already entrenched by the time an issue is brought to the
TC. By the time things come to us, parties are probably are already in
conflict. Constitution allows us to do some _non_last-resort powers which we
don't use. (i.e. "give opinion", "unsolicited advice"). Perhaps we should do it
more often → Maybe offering advice with TC hats instead as of "just individuals"
bremner: Can we do it? We were recently contacted informally by IRC. How can
we actually do such things in practice?
Would a smaller committee be more wieldy? maybe not _everyone_ has to agree if
one or two members is happy to provide advice. The extreme formality is for
when things are already contentious.
OdyX: … and it ended up being "enough members of the TC agree that it's a good
idea, but not formally as a body, so it ended up being done".
Q: isn't there some sort of "TC consensus" that's already mostly understood
within the TC, that any member can go around waving to people? (I certainly did
argue at times saying "I'm quite sure that the TC would agree with me on that
one…").
(comment by OdyX): out of my term's experience, it's very
hard/inconvenient/time-consuming to "act as the TC", early or late. So maybe it
would make sense to allow "invoke TC members with [to-be-defined] powers early"
vs "invoke the TC as a body early".
marga: A tricky part is to act as a committee. Even if informally we agree, we
need to have a meeting or discussion or something (even if not a formal vote).
How can we get "rough consensus" earlier?
marga suggests some sort of "on-call" system to jump in earlier. Possibly
involving something analogous to a preliminary injunction (this is someone
else's suggestion).
Gunnar: how can someone trigger the TC to get involved in a less formal /
quicker way?
Simon: There's a tension between the TC as "ask advice from" and the TC as
"make decisions" / "break ties"
bremner - some sort of marker of issues that are important, but have not yet
been discussed enough
Q: Does the TC feel like it could take on more problems?
A(from gwolf only): Right now, load is not high. Please don't throw a
initsystem vote at us! But some more issues could be fine
Q: Why would the TC be better qualified for early advice than other developers
(who might be more familiar with the problem domain)?
A(from gwolf only): Just for being there. People's nominations for TC are
accepted partly considering their opinion weight. Of course, people still need
to be OK with approaching a specific TC member - but that could be part of the
"job description"
A(from non-TC member OdyX): "problem domain experts" might not be impartial
either. Think systemd-centered vs "init-freedom-centered".
asheesh (non-TC): I'm in favor of seeing more informal non-binding TC advice.
Personally, I think informal non-binding advice doesn't have to be particularly
impartial.
Comment (non-TC moray): I'm not sure impartiality concerns should stop early
advice, but giving an early opinion might make the opinion-givers entrench
themselves in a position before a formal TC consideration of an issue (just as
we are concerned about other contributors getting entrenched in a position by
extended discussion).
Comment: I would like to be able to come to TC earlier, and get advice, quite
possibly in private. It's a way to get a wider collective opinion on a tricky
issue. I'm not sure how to arrange this best, but I do hope you can work out a
way of providing such a service.
Mediation body
(marga to introduce)
Proposal 3: 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.
Arguments for:
* A lot of the issues that need to be dealt with have a strong social
component but are not code of conduct violations and developers don't know
where to go to deal with those issues.
* Having this explicitly delegated would make it clear for people to know
where they need to go.
Arguments against:
* People will might have conflicts with the members of the mediation body and
then they have nobody to complain to.
Question (from Holger): what do other Committee members think is the right
option?
phil → Depends on who is involved in the dispute, that will determine whether a
given mediator is acceptable. There are important human social issues.
True: mediation can only work if both parties accept mediation.
ehashman: What if someone in the TC is part of that dispute?
OdyX: Idea: what about adhoc (per issue) mediation/facilitation persons?
gwolf: who appoints said persons? TC proposes; the participants agree? That's
the only way it could work IMHO
mdb (CT) - I think we need to clearly define what "mediation" means, as to many
of us on the CT it means a specific negotiation process. We are not interested
in mediation as we think of it. Also, I disagree that everything has a
technical aspect. We have plenty of issues these days that are purely social.
↑ Very good point...
'Binding mediation' is essentially what the TC already does, right? So a new
mediation process would be some kind of lesser 'non-binding' mediation.
mdb - What I would be interested in is collaborating with the TC on appropriate
issues. I think this would be a much longer conversation than we have time for
right now though. :)
COMMENT (gregoa): all disputes coming before the TC are both technical and
social:
- technical, as Debian is about technology (and not gardening etc.)
- social, as disputes are social per se; as they would have been resolved
before if they were purely technical; as history shows, that the TC cases
revolve around communication breaksdowns and feelings like not being heard, not
being appraised, being powerless, …
As a consequence I believe
- a purely "technical" committee is impossible
- separating "technical" from "social" issues is also at least challenging
- both the TC and the project should acknowledge that the TC is de facto
already a both technical+social body
+1, specially in the last point
moray (non-TC): In some cases, asking people to go to mediation may itself be
seen as an attack by one side of an argument. Is it proposed that mediation is
offered and only happens if the parties agree, or that we require them to go
through mediation before the TC is involved (or something else)?
bremner: Part of defining mediation on non-technical issues is, what would make
a developer abide by a TC decision? (Maybe avoiding the term "mediation", at
least as long as it's not defined, would help the TC to make progress. --
gregoa, also suggested by marga)
(IRC → Delib suggests "facilitation" rather than "mediation") +1
Allow design work
(fil to introduce)
Proposal 4: 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.
[ I (Philip Hands) support the status quo here, but I'll try to present a
reasonable selection of the points that have been raised on both sides of this
-- Feel free to add more if you think I've missed something important ]
Arguments for:
1. When given a choice between A and B, occasionally the TC agrees
that C would be better ... but cannot design C.
1. The TC sometimes perceives the conflict as being a symptom of a
wider systemic problem, but is not allowed to design a solution to that problem.
1. Individual(s) on the TC often have some insight on how to fix the
issue at hand that needs something new to be designed, which imediately gets
blocked by the "No Design" rule
1. Apparently some people dislike the fact that the TC gets to choose
between things without having to do any of the design, nor really taking
responsibility for the effort that might be required to implement their
decissions.
Arguments against:
1. There's nothing stopping the individuals on the TC to act alone or
as a group and do design outside the TC
1. Having a TC created design added to a dispute imediatly gives rise
to a perceived (and perhaps real) conflict of interest
1. do we really want Design by Committee? ;-)
1. Trying to impose a TC-sponsored design seems likely to result in
both sides of the dispute agreeing that they dislike the new solution almost as
much as the one they were upset about in the first place, at which point nobody
is going to be willing to imprement the TC rulling.
How you judge the above points seems likely to be a matter of opinion relating
to how you weigh the various concerns, but there is one thing that occured to
me that seems of a rather different character:
* The idea of joining the TC is already a daunting prospect, which
presumably contributes to the number of nominations that are declined. If
design is added to the job description this will be made significantly worse.
Some very wise words from phil there.
+1
marga: "design by committee" is known to be bad. Adding the TC ability for
design work is prone to anger people.
Phil's 'working group required' concept is the right way to get something that
might actually work, and get buy-in from people.+1
smcv: But we could specify, "here are the requirements we would need for a
proposal C" <-- let's try to include this in our docs as something we want to
do much more often.
bremner: We don't need a GR for this, we need to work on our processes to
allow us considering this.
moray (non-TC): Perhaps it's ok for TC members to be involved in offering
design proposals, separately from the decision itself, though? i.e. not
officially as part of the TC decision -- so Phil's concerns don't need to limit
TC members from doing such work if inspired to carry it out in a particular
case? ← I think it's explicitly in phil's text; "nothing stopping the
individuals on the TC to act alone or as a group and design outside the TC" --
yeah, the discussion seemed to be going against any design involvement
though... (Of course, it also depends on how such things are perceived by the
people who will be impacted by the formal TC decision.)
Sean: TC could co-ordinate forming these working groups to add some impetus and
avoid looking like just passing the buck.
All proposals in fuller form are here, plus a proposal we do not intend to
discuss today:
https://salsa.debian.org/debian/tech-ctte/-/blob/master/talks/rethinking-the-tc.md
Ask your questions to the Debian Technical Committee here:
Do we want the bikeshed to be red or blue? Red, obviously. I thought blue
was nicer. Okay, why not; what shade of blue? Obviously it should be green!
COMMENT: Regarding the type of mediation that Marga is talking about, *this*
DPL would like to shed as much of that as possible to make the load easier for
future DPLs. I think it's completely fine if the Community Team and the
Technical community share this, there might be cases that are better suited to
one or the other. We have way too many deep personal issues that are
technically rooted for which I think the technical committee might be a better
fit than the community team.
Comment: As I can see it, the TC is practically a Jury. And my opinion is that
mixing the jury responsibility with, let's say, attorney responsibility is some
ind of conflict of interest. Also, I think the goal should be to prevent
escalating issues this high.
Comment: Thanks to everyone for your work on the TC! And especially Phil if
he's been at it longest (and escaping soonest)...
--
<<< text/html; charset=utf-8: Unrecognized >>>
signature.asc
Description: PGP signature
