Moderation guidelines feedback

[achow101]

Previous discussion of the guidelines was at https://gist.github.com/achow101/9192ad26dc4ef08e9c899caeddc968ef

[josibake]

@ryanofsky still a bit confused by this sentence:

Moderators may remove comments that do not contribute new information or constructively reframe existing information.

IIUC, its saying that moderators may remove comments that "constructively reframe existing information." Constructively reframing existing information seems like a good thing to me. For example, there are several comments from two separate people and a third person comes in and summarizes the arguments both are making. I would view that as something that contributes to the discussion in a meaningful way but it seems like this sentences is discouraging that?

[harding]

I think that sentence is meant to read: "...that do not either contribute new information or constructively reframe existing information."

[josibake]

I think that sentence is meant to read: "...that do not either contribute new information or constructively reframe existing information."

Ah, makes more sense. I still find the wording to be a bit ambiguous, what about something like "If a comment does not constructively reframe existing information or does not contribute any new information, it may be removed" ?

[harding]

From the proposed policy:

Meta-discussions about moderation decisions or moderation policy are off-topic in Bitcoin Core software projects.
...
For borderline posts that are not outright spam or attacks, but don't meet standards of discussion, moderators may choose to hide the comments

To me, this implies that off-topic discussion about moderation will be hidden (at least on the first offense). I think it would be advantageous to say that any posts about moderation outside of bitcoin-core/meta will be deleted (even if they have other merits).

The problem I'm concerned about here is:

• A says something inappropriate
• Moderator B hides A's comment
• C complains about the moderation of A's comment
• C's complaint is also hidden
• D offers their opinion about C's complaint
• D's opinion is also hidden
• Etc...

Even though the comments are being hidden, they begin to represent a parallel conversation that undermines the goals of having moderation and of having discussion of moderation happen on a separate repository. It's like how /ignore on IRC and Mute on X/Twitter can be ineffective when too many other people you know aren't ignoring or muting. Making it clear that C's and D's comments will be deleted as soon as a moderator sees them will help ensure discussion about moderation is kept separate from technical discussion.

Suggested edit:

diff --git a/MODERATION-GUIDELINES.md b/MODERATION-GUIDELINES.md
index eb99cf9..7d5968d 100644
--- a/MODERATION-GUIDELINES.md
+++ b/MODERATION-GUIDELINES.md
@@ -8,7 +8,7 @@ On the internet, different discussion forums will have different cultural norms,
 - Comments will be about ideas, not people.
 - Comments may offer pointed criticism, if it is criticism about specific technical ideas or decisions, not general criticism, or criticism of individuals or groups. Even the smartest people can have ideas that don't work out, and people with good intentions can make decisions that backfire. It does not add a lot of value generally to speculate about peoples motives or capabilities when discussing the merits of their ideas, and doing so will be considered off-topic in technical discussions.
 - Comments should contribute new information. A certain amount of repetition is critical for learning, dissemination of ideas, and understanding in communication, but it can be taken too far when the same information is repeated in the same context. Moderators may remove comments that do not contribute new information or constructively reframe existing information.
-- Meta-discussions about moderation decisions or moderation policy are off-topic in Bitcoin Core software projects. If you wish to discuss moderation, please file an issue in [bitcoin-core/meta](https://github.com/bitcoin-core/meta/issues/new), which is the home for project management issues, and nontechnical discussions relating to development of the codebase.
+- Comments about moderation decisions or moderation policy are off-topic in Bitcoin Core software projects and will be deleted. If you wish to discuss moderation, please file an issue in [bitcoin-core/meta](https://github.com/bitcoin-core/meta/issues/new), which is the home for project management issues, and nontechnical discussions relating to development of the codebase.
 
 ## Role of Moderators

---

When moderators ban someone, there should be an issue posted https://github.com/bitcoin-core/meta/issues to provide a public indication that some discussion was suppressed. This could be in dedicated issues, or in a catch-all issue for temporary bans. To avoid embarrassment or potential backlash, the post does need not include name of the person being banned or reasons for the ban.

This sounds like an issue can be opened "[Username withheld] was banned for [reason withheld]", which doesn't seem very useful to me in determining what discussion is being suppressed. I would suggest always including the name/username of the person being banned, but also that the posts announcing bans should be made using a bot that obscures the identity of the banning moderator.

On that note, I think it would be ideal if all actions by moderators were performed by a bot that (1) hid the identity of the specific acting moderator from the public and (2) kept a private record of moderator actions for review and (possibly) time-delayed disclosure. That way any criticism of moderator activity is directed at the entire project rather than individual moderators. I don't think this needs to be moderation v1, but it seems like a useful v2.

[mzumsande]

When moderators ban someone, there should be an issue posted https://github.com/bitcoin-core/meta/issues to provide a public indication that some discussion was suppressed. This could be in dedicated issues, or in a catch-all issue for temporary bans. To avoid embarrassment or potential backlash, the post does need not include name of the person being banned or reasons for the ban.

Simple spammers should be exempt from this, I don't think that any extra bureaucracy is needed for those.

[achow101]

I think that sentence is meant to read: "...that do not either contribute new information or constructively reframe existing information."

Made this change.

Suggested edit:

Suggestion taken.

Simple spammers should be exempt from this, I don't think that any extra bureaucracy is needed for those.

I've updated the sentence to exclude obvious spam.

I would suggest always including the name/username of the person being banned,

I'm not as sure about this. If they're just named, I think that's likely to invite other people to chime in speculating and/or defending that person, both of which are noisy and cause extra headaches for the moderators. I think it would either have to be that a name and reason is provided, or none at all, just acknowledgement that some action occurred?

On that note, I think it would be ideal if all actions by moderators were performed by a bot that (1) hid the identity of the specific acting moderator from the public and (2) kept a private record of moderator actions for review and (possibly) time-delayed disclosure. That way any criticism of moderator activity is directed at the entire project rather than individual moderators. I don't think this needs to be moderation v1, but it seems like a useful v2.

I'm not sure that a bot would actually be helpful here since none of these actions should be automated. However, we could just make "bitcoin core moderator 1", "bitcoin core moderator 2", etc. accounts so that the moderator identities are more hidden. That would also fit with the idea of rotating moderators periodically as those accounts can be recycled and handed over to new moderators. But a few concerns there are about the increased friction to being able to take moderator actions, and also whether having separate accounts even affords any real privacy.

[willcl-ark]

For clarity, would comments made outside of the bitcoin core repositor[y|ies] ever be expected to translate into moderation actions here?

My read of the initial paragraphs, and which I would agree with personally, would be that they would not.

Of course there might be some hypothetical extreme circumstance in which it may make sense, but by and large I think it's simpler for moderators to only consider internal repository actions.

[ryanofsky]

re: jonatack's comments [1] [2] I think it would be good to have a separate document with tips and positive advice on how review and discuss things productively. I think the moderation guidelines could link to a separate document with that information, but should avoid trying to be too prescriptive themselves.

---

re: josibake's comment #1 (comment) about reframing existing information, that was just clumsy wording and the suggestion makes it clearer.

---

re: harding's comment #1 (comment) about hidden comments potentially leading to "parallel conversations," that seems like a good point and it's something I didn't think of. I agree with the suggested edit to just say certain comments will be deleted.

Taking a step back, I think this document has two potential audiences. The first audience is people who have had some moderation action taken against them. The hope would be they could read this, not take things personally, and learn how to get their message across while following the guidelines. The second audience is actual moderators and people interested in the topic of moderation.

The first section is targeted at the first audience, and I think should set the simple expectation that any post that crosses the lines can be deleted.

The remaining sections should add more nuance, making a distinction between hiding and deleting comments, and giving moderators the flexibility to hide comments that have problems but contribute some useful information, instead of deleting them.

I think moderators should have a lot of discretion and a lot of options they can choose, at least to start off. We can see what works and doesn't work before before becoming more rigid.

---

re: harding's comment #1 (comment) about opening new issues with "[Username withheld] was banned for [reason withheld]," that is definitely not the intent!

The "When moderators ban someone..." bullet point is trying to be brief and trying to allow for flexibility in handling different situations, but right now it might be too imprecise.

I think in practice we should have a catch-all github issue open in the bitcoin-core/meta repository to track bans. Then, if/when bans happen, moderators can post simple comments in that issue like "username ryanofsky was banned until May 10 to calm down inflammatory discussion in issues #234 and #456" or "2 users were banned until May 13 for making ad-hominem remarks" or something more minimal like "a user was banned until Jun 1." Just if there is are more complicated problems, separate issues could be opened.

I think it is important for there to be some some public indication of when temporary bans happen for the sake of transparency, so there is some visibility into what moderators are doing. Also for the practical reason that if someone is banned, there should be a place they can check to figure out what is going on and how long they are banned.

---

re: harding's comment #1 (comment) about having a moderator bot to hide moderator's username, I agree it could be useful, especially for "v2".

---

re: mzumsande's comment #1 (comment) about not needing to document bans for spammers. Definitely agree with that, and hopefully the text is clearer now. Permanently banning fake usernames that aren't contributing anything should not require any bureaucracy. But if temporary bans are put in place to calm overheated discussions, those should be visible somewhere and informally tracked.

---

re: kanzure's comment bitcoin/bitcoin#29507 (comment) about transparency section imposing too much work, I think we should eliminate anything that is too much work, but it's worth trying something and seeing where the problems are in practice. I also hope being "clear about how decisions are made" is not too high of a standard to meet. But if is, we can weaken that language or rephrase it. On policy documents effectively being "instructions for your adversaries on how to defeat a project" honestly I agree very much with this sentiment, and it's why I think moderators should have a lot of freedom individually to make decisions. But I hope having some transparency after the fact is possible, too. If it doesn't work out in practice, though, we can accept reality and adapt.

---

re: achow101's comment #1 (comment), agree with everything and all the edits look good.

---

re: willcl-ark's comment #1 (comment) about outside comments, maybe it's worth saying something about them, but I think, as noted, current document implies they are not directly relevant because it doesn't consider them. I think when outside discussion spills over and doesn't meet the guidelines, it can be dealt with at that point.

[harding]

Re: #1 (comment) by @achow101

I'm not sure that a bot would actually be helpful here since none of these actions should be automated.

I'm more thinking of IRC-style moderation bots that hold room ops and accept private commands from a list of trusted admins. E.g., if user mallory is being a pain in room #foo, admin user alice types /msg foobot ban mallory 7d

In other words, the bot is just a proxy to the GitHub API which adds in some extra features, like logging or automating the process of things like "ban + leave comment in meta repo".

For example, if a simple script coremod was put on a server which you could login to over ssh, you could do something like:

alias coremod="ssh coremod.bitcoincore.org coremod"
# Ban harding and automatically create (or append to) an issue describing why
coremod ban harding "Making simple things way to complicated for everyone"
# Delete an off-topic comment
coremod delete  off-topic "https://github.com/bitcoin-core/meta/issues/1#issuecomment-2094361530"

I think that would pretty low friction for moderators, and it would allow all actions to be publicly performed by the moderator bot account. With a clever script, it could also log who requested the ban and delete actions.

[pinheadmz]

@harding I have a bot running right now for testing: https://t.me/bitcoinmoderatorbot

On my own server I receive all webhooks from the bitcoin core code repo (which I also use to post updates in https://t.me/bitcoincoregithub as well as #bitcoin-core-github on IRC). I filter these webhooks for issue / PR comments and then send each one to a ChatGPT "assistant" that has been prompted with the moderation policy currently on master in this meta repo. The AI responds with either an "OK" or an explanation of how the comment violates the policy, in which case it notifies me (and anyone else) in the telegram channel.

It's set up to be a tool to assist moderators since there can be hundreds of comments in a day and so far is only costing me $0.50/day or so in openAI API credits.

We have been pretty well behaved this week but here is one example of a triggered response:

[1440000bytes]

I will say it again even if hidden..

These guidelines are bypassed everyday by people who have some influence. It will be used by those against some reviewers to avoid review.

It will be used by governments to win legal cases. It doesn't matter who is involved for them.

[midnightmagic]

I believe you will find that attackers not only don't care about rules, but will use the rules as an explicit vector for attack. These kinds of moderation transparency requirements, and especially the comments about Bitcoin being some kind of organization which implies leaders and followers, will 100% be used against you, especially if there come to be any more lawsuits filed. You have no particular duty to make your decisions to defend your own sanity and/or time from attack a transparent, process-based one.

Your attackers won't be convinced to stop attacking—they don't care.

Bitcoin's population is unique amongst FOSS projects in that some of them are strongly incentivized to attempt to subvert, harm, attack, and abuse people who work on Bitcoin—and when I say strongly incentivized, I mean in the millions or billions of dolllars range. Any rules, CoCs, moderation policy documents, or anything which goes to any particular length to describe literally anything can and will be used as a weapon both against you, and against people who support you in an attempt to erode your base.

Your ability to adapt to a new form of attack also shouldn't be shackled by documents that couldn't have perceived, let alone foreseen, what is or might be coming to make your lives harder.

I strongly recommend you abandon these efforts. They won't serve you. Kanzure is right—they will only serve as a roadmap for attackers whose actual bad intentions are well-funded and fuelled by a small army of people who have the willingness to maintain a literal active daily attack effort for literally more than a decade.

[pinheadmz]

Excuse my naivety but could someone give me an example of how an attacker would use a policy designed to preserve and focus on technical work as an attack? I was under the impression that the moderation policy is designed to mitigate the mental denial of service by participants posting off-topic or non-technical comments

[1440000bytes]

Excuse my naivety but could someone give me an example of how an attacker would use a policy designed to preserve and focus on technical work as an attack? I was under the impression that the moderation policy is designed to mitigate the mental denial of service by participants posting off-topic or non-technical comments

This is just an example and I am sure real attackers can figure out worse things:

• Attacker pays a developer to contribute in core repository.
• Developer is asked to get in conflicts and trigger some long term contributor after a few months.
• Long term contributor writes something in the heat of the moment.
• Developer asks moderators to ban long term contributor for harrasment etc.
• They do not follow moderation guidelines and just give a warning.
• Developer goes to court as advised by attacker and paid for it. She cites the moderation guidelines in lawsuit.