Erik has kindly pointed out a typo: clearly, I mean "respectfully" rather than "respectively". At least I am consistent with my error, since I did it twice! Rob > -----Original Message----- > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Rob Wilton (rwilton) > Sent: 14 October 2022 20:23 > To: ietf@xxxxxxxx > Subject: Is there any way that we can progress from the repeated > moderation discussions? > > >From the threads that I read in the IETF, the WG meetings that I attend, and > the conversations that I have with other participants, then out of the 1000's > of participants in the IETF community, I can probably name less than 10 > people who I perceive of sometimes not participating in the IETF respectively. > From my read, the vast majority of IETF participants either support the > current moderation policy or otherwise accept that something like the > current moderation policy is necessary to encourage new younger > participants to show up at the IETF, which I regard as being vitally important > to the long-term health of the IETF, Stuart Cheshire gave a better description > here: https://mailarchive.ietf.org/arch/msg/last- > call/iO9LaRb4y0JeccHG7vhT1xsteiI/ > > I'm also not aware of anyone arguing that some level of tolerance is > important and helpful during conversations. > > But, for me, I regard not participating in the IETF respectively roughly as: > - sending unnecessarily rude or impolite emails on a recurring basis, or > - continually making the same arguments repeatedly, particularly > when adopting a position [very] in the rough, or > - repeatedly bringing back the same topics that have been discussed to > exhaustion. > > In my view, in all of these cases, the key problem is not that the broader > community is not listening, the problem is the polar opposite, i.e., these few > participants seem to be unwilling or unable to accept conflicting feedback > from the community (or leadership). E.g., even if a high percentage of the > comments in the conversation disagree with their (normally repeatedly > stated) position, then my perception is that they assume that they just need > to try harder to explain. Hence, you often see the same position being > restated repeatedly, perhaps in only very slightly different ways, or recurring > rude behaviour. > > Unfortunately, in my experience, trying to engage with these participants > privately doesn't help either. Sending a polite constructive email (generally > the method that I try) or more sternly worded warning seemingly makes no > difference, my conjecture being that they are simply not open to listening or > receive the feedback. They just see the private conversation as another > avenue to explain why their repeatedly stated position is right, and everyone > else is wrong. > > I personally find these repetitive threads both very frustrating and > emotionally draining, partly because I have a leadership position and feel like > I have some level of responsibility towards the community, who I am failing, > but also because I regard these threads as being generally harmful to the > IETF and the IETF community, and I'm at a loss to know how we can stop > them from continually happening and move discussions on the main IETF > mailing list to a better place. > > I have a few suggestions, which I'm sure some people will have strong > opinions against: > 1) We create a more effectively process than BCP 83, specifically with > some more gradual steps (maybe the initial steps are entirely private without > community awareness or review), and also without the public trial aspect > currently specified in BCP 83. IMO, a better PR action process would > probably involve the feedback being provided privately to the IESG, with only > a short community summary of the broad aspects of the feedback received, > the number (and optionally names) of people supporting or opposing such > an action, and what the final decision was. > 2) I think that we should maintain a community curated list of > "exhausted topics" for the ietf@xxxxxxxx mailing list, that would only accept > new input on a discussion if the input was significantly different from what > has been discussed before (and an explanation of how it is different), or > otherwise the poster would be moderated using the existing IETF mailing list > moderation mechanisms. E.g., I would place "Discussions related to IPv10" > in the list of exhausted topics, that the community seems to be fed up > repeatedly discussing. > 3) Perhaps most contentiously, I would also place "discussing IETF > moderation" onto the list of "exhausted topics", at least for the main > ietf@xxxxxxxx mailing list. My perception is that the wider community is, like > me, also fed up with this endlessly recurring discussion with no possible > change in the IETF consensus. However, I fully appreciate that there is need > for somewhere within the IETF where moderation can be discussed (aka, > who guards the guards), but this could reasonably be hived off to a separate > mailing list to spare those members of the community that don't want to > hear the same views and positions a hundred times over. But generally, if > we really want to have a useful constructive conversation about moderation, > then I think that conversation needs to prominently happen in person, e.g., > in a side-meeting, and/or via some video enabled interim meetings. Email > has repeatedly been shown to not be an effective mechanism to progress > this discussion. > > Obviously, I appreciate the irony of both suggesting that we stop discussing > moderation on ietf@xxxxxxxx and at the same time starting a new thread on > moderation. To that end, whilst I am happy to provide clarifying comments if > requested, I will decline to actively participate in a broader discussion on this > topic over email, probably limiting my involvement to reading initial > responses, if any, from the broader community. I would be more than > happy to participate in a side-meeting (or virtual interims) on this topic if > other people believe that this could in any way be a constructive way > forward. > > Kind regards, > Rob
