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

Attachment: signature.asc
Description: PGP signature

Reply via email to