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)...
--
Attachment:
signature.asc
Description: PGP signature