[Last-Call] Re: Last Call: BCP 83 PR-Action for Timothy Mcsweeney

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I don’t like that our processes require the IESG to create a PR, and a 4-week community review just to ban someone for obviously poor behaviour over a number of years – which they show no evidence of changing, which John Levine pretty reasonably described as: “arguing about whether behavior that would get a 16 year old sent to the principal's office is acceptable here.”

 

Sometimes navigating the IETF processes feels like wading through treacle, to the point that I’m sure that various folks get to the point that they believe it is just too much effort to make the changes that obviously need to be made.

But I would basically like to see the end of the PR process (too heavy, and too much of a public trial), and instead create a moderation team, in the style of ietf.org/archive/id/draft-ecahc-moderation-00.txt, that has power to quickly control and, if necessary, ban folks from one, several, or all IETF lists (either for a short period of time, or permanently).  This moderation team could be appointed by the IETF chair, the IESG, or even by Nomcom.  But I think that the moderation team should act on behalf of the community, without needing to check for community consensus on the decisions that they take.  They should, of course, listen to feedback from the community on the decisions that they take and adjust their moderation actions as required (which I believe the current ietf@ moderation team already does).

 

Like any action, decisions should be appealable via the normal channels (e.g., probably to the IESG, then the IAB).

 

So, Lars, now that you have copious amounts of free time, ;-), any chance that you and your co-authors would be willing to please bring draft-ecahc-moderation back and try and get it over the line?

Regards,
Rob

 

 

From: Adam Roach <adam@xxxxxxxxxxx>
Date: Wednesday, 12 June 2024 at 04:51
To: Ted Lemon <mellon@xxxxxxxxx>, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Cc: Dan Harkins <dharkins@xxxxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: [Last-Call] Re: Last Call: BCP 83 PR-Action for Timothy Mcsweeney

To some degree, yes. Casting back to what I said in my initial note: it's hard to account for all the potential behaviors that might apply. A rule like "if someone makes an explicit, stated, public promise to become disruptive across a range of IETF mailing lists should a PR action proceed, then that person may be proactively banned from all IETF mailing lists upon the completion of a successful PR action" is likely uncontroversial, but it's also hyper-specific to this situation, and has basically no value to future situations.

 

A key point I was trying to make in my initial message to this thread is that the range of bad behavior that people may choose to exhibit is so difficult to get in front of that it's a fool's game to try to predict the specific style of threat I quote below and to set out specific remedies to address it. We could compose a 1,200-page RFC that described all kinds of specific untoward behavior and corresponding remedies for each, and we'd still miss out things that bad actors are likely to actually do in the future. But once a threat such as "you can be sure that I won't be participating in good faith on any other list after a ban" is levied, the corresponding appropriate remedy is crystal clear.

 

To Brian's point: it's true that we don't have a rule in BCP 83 that says that a blanket ban is an available remedy, but these rules are not handed down ex cathedra from some divine oracle. These rules derive their legitimacy from the consensus of IETF participants -- a consensus that is judged on this very list. Arguably, consensus on this list on a topic should have the same weight as anything written down in a BCP (since consensus on this list is sufficient for something to appear in a BCP).

 

And so I don't think there's any action needed to empower the community to decide what the community is allowed to decide. It seems like make-work.

 

But if it makes people feel better: if there's anything that BCP 83 might be updated to say, I would offer that it be something along the lines of "In addition to the remedies described in this document, as part of the PR action last call, the community may identify and come to consensus on additional sanctions appropriate to the specific actions of the individual whose posting rights are being revoked; and any such sanctions that reach community consensus shall be enforced by the IETF and their delegates to the degree possible." It is my position that this is functionally already true, for the reasons I describe above, but I would not object to codifying it in this manner.

 

/a

 

On 6/11/2024 10:16 PM, Ted Lemon wrote:

Yes, that's indeed what at least some of us are advocating: an update to the BCP.

 

On Tue, Jun 11, 2024 at 10:44PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:

On 12-Jun-24 13:03, Adam Roach wrote:
> On 6/11/24 17:25, Dan Harkins wrote:
>>   So let's rein this in a bit. No blanket bans. I don't know Tim
>> McSweeney from Adam and my opinion on this last-call is pretty
>> worthless given my current standing but unless there is a problem
>> on a list, people should not be banned.
>
>
> In the general case, I agree. In this case, I think the following promise makes a blanket ban not just advisable, but entirely necessary:

But we don't have a rule that allows this. A PR Action *allows* all
list managers to ban the person; the IESG would have to go further
than all existing BCPs to do more than this. That's not impossible,
but would need a separate Last Call, I think.

    Brian

>
>
> On 6/9/24 23:05, Timothy Mcsweeney wrote:
>> And Roman, if I were you, I would expand this ban to all of the lists because you can be sure that I won''t be participating in good faith on any other list after a ban.
>
>
> /a
>
>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx



 

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux