On october 27, I posted a message to debian-project [1] pointing to a blog post [2] and starting a discussion of some concerns I have with the Technical Committee process. I am currently serving as a member of the TC; I'm speaking as an interested and knowledgeable individual. [1] https://lists.debian.org/msgid-search/tsl1sloxgyf.fsf@suchdamage.org [2] https://hartmans.livejournal.com/97174.html Martin Steigerwald[3] emphasized the importance of including non-technical considerations in our decision making. He also reminded us that conflict tends to produce a response of fight, flight, or stand still panicking. He said: >I agree with you that an important aspect is that each party receives the >chance to fully express their own position and be heard, seen, felt and >valued. So I think there needs to be a shift to see conflicts as something >positive and provide a safe space to express them. >Challenging for me is the answer to the question: How can such a safe place >look like in a community that is spread around the globe and can often only >connect via the means of the internet? [3] https://lists.debian.org/msgid-search/20398250.g3Mo30JhmK@merkaba Gunnar Wolf [4] said he thinks the TC works amazingly well today. He talked about how much the project has improved since the early days. It's a lot easier to be involved in Debian without such a thick skin. [4]https://lists.debian.org/msgid-search/20171028215011.j7ui7apd3oxylubu@gwolf.org Russ Allbery spoke about the difficulty of the problem[5]: >I think there are several principles that I suspect most people bring to >TC decisions. Certainly, I did. I think it may be helpful to look at >them and realize that they're *inherently* in conflict. In other words, >it's clearly possible to find cases (and we have found cases) where it is >literally impossible to satisfy all those principles at the same time. >We should always try to do better. >We should avoid expecting ourselves to be superhuman. I left out Russ's principles, but his entire message is recommended reading for anyone thinking seriously about this. [5] https://lists.debian.org/msgid-search/87r2tmua04.fsf@hope.eyrie.org >Russ also pointed out [6] that it is impossible to make everyone feel valued because some people on/only feel valued if their preferred option is chosen. Russ went on to explore the difference between listening to someone and agreeing with them and how hard it is to feel heard when the listener does not agree. [6] https://lists.debian.org/msgid-search/87o9ongun1.fsf@hope.eyrie.org Ian Jackson [7] proposed more formal structure in the TC process. He believes this would help especially for package maintainers (respondents) to a concern raised before the TC. He would like to see something similar to a tribunal/court process. >One of the most toxic things that can happen in any kind of dispute is >for there not to be a clear understanding of what the rules are, >within which the dispute will be conducted. Ie, who is allowed to do >and say what, and when. He said one of the most exhausting parts of the TC process is the limitless email discussions. Rules could limit this. He elaborated in another message [8]: >Unstructured mailing list discussions work reasonably well when >everyone feels that everyone else is on the same side, and everyone is >trying to understand the issues and feel they will be able to come to >a consensus, or at least a conclusion that everyone finds tolerable. >When things get more difficult, they become sprawling horrors. >Participants (quite understandably) feel the need to respond to >everything their now-opponents say. People feel under time pressure. >It becomes difficult to see the wood for the trees. Because the >parties are replying directly to each others' emails, there is ample >opportunity for misunderstanding, and all the escalations of minor >aggressions or poor word choices etc. into meta-disputes and anger. >I think it would be better if we asked participants to write a much >smaller number of longer and more comprehensive statements. In this message, Ian also outlined a list of factors that tend to be critical to TC decisions. [7] https://lists.debian.org/msgid-search/23032.45880.193971.897331@chiark.greenend.org.uk [8] [🔎] 23035.8784.982211.812147@chiark.greenend.org.uk">https://lists.debian.org/msgid-search/[🔎] 23035.8784.982211.812147@chiark.greenend.org.uk Sam Hartman [9,10] said that it is important to work on reducing the defensive reactions maintainers have when they are asked to work with the TC. One part of that may be making it clear to maintainers if the process ever gets to a point where the TC is considering recommending a change. Some issues may be best addressed by helping a complainant understand the maintainer's position rather than by proposing any particular change. Sam also said that he's more concerned with maintaining our community than with technical correctness. He believes the court style process emphasizes technical correctness and is not well-suited to maintaining a community. In [10], he proposed cases where maintaining the community might be in conflict with technical correctness. [9] [🔎] tslmv44rfcw.fsf@suchdamage.org">https://lists.debian.org/msgid-search/[🔎] tslmv44rfcw.fsf@suchdamage.org [10] [🔎] tsly3nnpl48.fsf@suchdamage.org">https://lists.debian.org/msgid-search/[🔎] tsly3nnpl48.fsf@suchdamage.org Diane Trout [11] said that communication skills are important in conflict resolution, pointing particularly to Active Listening. [11][🔎] 1509648485.1245.75.camel@ghic.org">https://lists.debian.org/msgid-search/[🔎] 1509648485.1245.75.camel@ghic.org Scott Kitterman [12] said that it's important for the TC to only act as a last resort. Having the TC act too early can be harmful. [12] [🔎] 85668C87-9316-485B-A7E3-220F446CBFE1@kitterman.com">https://lists.debian.org/msgid-search/[🔎] 85668C87-9316-485B-A7E3-220F446CBFE1@kitterman.com Didier Raboud [13] agreed with Scott. He pointed to IRC discussion of this issue and proposed initial things for the TC to go over when issues are referred to it. [13] [🔎] 3456407.PWododFiyj@odyx.org">https://lists.debian.org/msgid-search/[🔎] 3456407.PWododFiyj@odyx.org One issue didn't come up in the mailing list discussion on -project, but has come up in a number of other forums. Several people have pointed out that the current process significantly disadvantages non-native English speakers.
Attachment:
signature.asc
Description: PGP signature