Consideration of a Code of Conduct and/or written rules for moderation

achow101 commented at 9:14 pm on February 28, 2024: member

There have been a number of events over the past several months which have resulted in various individuals requesting that moderation action be taken. However, without any actual guidelines for when moderation actions should be taken, and of what sort, the bare minimum of moderating obvious spam is only done. This appears to leave many contributors dissatisfied as I have frequently heard grumblings about the behavior of various people leaving comments on PRs and issues. As such, I think it would be prudent for us to reconsider adding a Code of Conduct or otherwise some written rules of moderation so that moderation actions can be taken more proactively.

While short pithy statements like “be excellent to each other” and “don’t be an asshole” are great sound bites, they do very little to actually establish what behavior is acceptable, and when and what moderation actions can be taken. As someone who does moderation actions, personally I would like to have more guidance from other contributors on the moderation actions that they would like me to do.

The last time this was brought up, in #26890, there were concerns about the specific wording of the proposed Code of Conduct. Instead of proposing a specific text this time around, I’ve opted to first revisit the idea on its own, and we can try to nail down the text at a later date. But here are a few examples of Codes of Conduct that we may want to adopt (with modifications):

CoreDev events: https://github.com/coredev-tech/coredev-tech.github.io/blob/master/files/CoreDev-Code-of-Conduct.pdf
LDK: https://lightningdevkit.org/code_of_conduct/
Linux Kernel: https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
FreeBSD: https://www.freebsd.org/internal/code-of-conduct/
FSF/GNU: https://www.gnu.org/philosophy/kind-communication.html
Python: https://www.python.org/psf/conduct/
Django: https://www.djangoproject.com/conduct/

There were also a few concerns last time about a Code of Conduct or any other written rules being used as a vehicle for harassment. While I don’t doubt that this is certainly possible, I think that having something written down would be overall more beneficial than not. I also think that if such a situation were to arise, it would be possible to amend the document to cover those cases.

As this discussion is about how frequent contributors feel about a Code of Conduct and moderation in their place of work, discussion of this issue is limited to members of the org. Comments from others may be deleted or hidden as off topic. If you are not a member but think you should be, send me a message by email or IRC.

ryanofsky commented at 11:53 pm on February 28, 2024: contributor

I agree more moderation would be useful, but I would propose something more lightweight and less prescriptive than a code of conduct. I think we should try short-term bans of posters who causing specific problems, with full transparency so it’s clear:

Who is currently banned
What specific reasons they were banned for, with links to relevant issues or comments
When the ban will end
Who made the decision to ban them

I think it would be good if bans were fairly short, starting at a few days and not lasting more than a few months.

I think this could be a good approach because a ban does not need to imply that anyone has done something wrong or immoral, it could just be a tool for allowing overheated discussions to cool off.

ryanofsky commented at 2:00 am on February 29, 2024: contributor

Another suggestion: Since discussion about moderation is mostly nontechnical, and also a topic (like the GUI) that a lot of bitcoin developers may be explicitly uninterested in, maybe we could consider opening a new repository like bitcoin-core/moderation or bitcoin-core/gh to track issues like this related to moderation, or management of the github org.

1440000bytes commented at 3:00 am on February 29, 2024: none

Code of Conduct and any such documents are ineffectual. Its not required for moderation or bans in this repository.

Rules will be used or misused or interpreted differently based on a few opinions.

Because opinions are subjective, it is very easy for people who wish to abuse these sorts of systems to choose to be offended by things they don’t like in order to demand punishment for those who disagree with them. In extreme examples, they may even take offense at someone else’s treatment of them, while simultaneously treating others in the same way.

Systems that punish offensiveness open themselves up to exploitation by such people.

https://web.archive.org/web/20150812191347/https://dancerscode.com/blog/why-the-open-code-of-conduct-isnt-for-me/

Pull request authors are expected to respond to all the review comments according to a document that already exists in this repository. However, its not really followed in every case.

You are expected to reply to any review comments before your pull request is merged. You may update the code or reject the feedback if you do not agree with it, but you should express so in a reply. If there is outstanding feedback and you are not actively working on it, your pull request may be closed.

Anyone may participate in peer review which is expressed by comments in the pull request

https://github.com/bitcoin/bitcoin/blob/2649e655b9203d6d08cb1a26fa4846f2c403b297/CONTRIBUTING.md#address-feedback

kanzure commented at 3:37 pm on February 29, 2024: contributor

Here is a comment from #26890 when this was last proposed:

For what it’s worth, I think it will be extremely difficult to prevent the weaponization of the loose language, including the requirement to accept veiled criticism and encouraging weaponized demands for apologies. … After wrangling the nutbar attackers in IRC for a decade, I would offer my gentle warning that the insidiousness of the characters you are going to be dealing with in the coming years can’t really be understated. I would suggest that a CoC of this type will be more likely to be used against you than it will be the tool you hope will become a facilitator of diplomatic discourse.

See also http://esr.ibiblio.org/?p=8609

araujo88 commented at 4:36 pm on February 29, 2024: contributor

It is crucial for the Bitcoin Core project to adopt a code of conduct if it aims to enhance its organization, gain credibility, and attract more dedicated contributors as it grows. In this regard, the Linux kernel’s code of conduct could serve as an exemplary model. Given the anticipated expansion of Bitcoin Core, especially in terms of contributor numbers, it could soon rival the scale of the Linux kernel.

Nonetheless, I have concerns about potential misuse of this tool that must be addressed. Specifically, the issues already highlighted in #26890 raise valid points regarding how the code of conduct could be exploited to sow discord within the community and incite unnecessary conflicts. It is imperative that measures are put in place to prevent such outcomes, however I’m unsure of how that could be achieved. I guess that having a code of conduct, in the context of Bitcoin Core, might paradoxically serve as a double-edged sword, obtaining the opposite result of what is intended if not properly used.

jrc-dev commented at 5:48 pm on February 29, 2024: none

After 15 years without a formal code of conduct, the Bitcoin community has thrived. But do we truly need one now? We’ve navigated challenges and disagreements without it, relying on the decentralized nature of Bitcoin itself to maintain order.

Looking at the experience of other communities, such as the Rust language, we must ask: What safeguards us from implementing a code of conduct and facing similar issues? Could we inadvertently pave the way for a Bitcoin foundation tomorrow, potentially leading to centralization and bureaucratic hurdles?

The absence of a formal code of conduct may signify a commitment to preserving the core principles of decentralization and censorship resistance. It’s crucial to differentiate between genuine efforts to foster inclusivity and support and the imposition of rules that may stifle open discourse and innovation.

Let’s continue to uphold the values that have propelled Bitcoin forward, fostering an environment where diverse perspectives can flourish without the need for rigid guidelines.

glozow added the label Brainstorming on Feb 29, 2024

TheBlueMatt commented at 11:51 pm on February 29, 2024: contributor

I think it’s important to point out here that a CoC is basically a formalization of what happens anyway. Either there’s a formal process that’s (hopefully) somewhat transparent to deal with disruptive people or there isn’t and there’s only frustration from being ignored and banned and muted by individuals and the same conversations happen in back rooms instead. There’s not going to be a material change in outcome for a CoC done right (though it can definitely be done wrong), there’s only more transparency and formalism.

araujo88 commented at 11:53 pm on February 29, 2024: contributor

Why was my comment marked as off-topic?

1440000bytes commented at 0:29 am on March 1, 2024: none

Why was my comment marked as off-topic?

Same with me although it was related to topic. I think admins and maintainers of “bitcoin” on GitHub have decided something.

They are trying to embarrass themselves with this.

achow101 commented at 0:38 am on March 1, 2024: member

As this discussion is about how frequent contributors feel about a Code of Conduct and moderation in their place of work, discussion of this issue is limited to members of the org. Comments from others may be deleted or hidden as off topic. If you are not a member but think you should be, send me a message by email or IRC.

1440000bytes commented at 0:43 am on March 1, 2024: none

As this discussion is about how frequent contributors feel about a Code of Conduct and moderation in their place of work, discussion of this issue is limited to members of the org. Comments from others may be deleted or hidden as off topic. If you are not a member but think you should be, send me a message by email or IRC.

Please make some changes to contributing.md and create a bot so that this repository is whitelisted. Only people liked by some will be able to comment.

ChrisMartl commented at 12:46 pm on March 1, 2024: none

NACK

GitHub has already a highly functional moderation mechanism and rules.

Redundancy on this only stagnates Bitcoin-Core’s resources.

glozow commented at 3:06 pm on March 1, 2024: member

I’ll first point out that moderation is very much necessary. Beyond brigading and flamewar PR discussions, it seems many people do not realize the amount of spam (“actual spam”) this repo gets. This is a github repository where people collaborate on code; it’s not a discussion forum for everybody to voice their opinions about Bitcoin and Bitcoin development (there are lots of other places for that).

Another problem is that moderators are often accused of censorship and of making decisions subjectively, due to an absurd notion that “everybody can contribute to this open source project” means that abuse, harassment, and spam should be tolerated and welcomed as part of technical discussion. We also genuinely don’t want to discourage people from joining the community and spend a lot of time worrying whether we’re making a moderation decision that everybody agrees with. This makes moderators too scared to act and, consequently, makes this a worse community and more unproductive place to work.

So apart from agreeing to a code of conduct and moderation policy that establishes what kind of space we want to work in - which is something we should decide on as a community - I’m also interested in formalizing this as a way to protect moderators. Applying a process that is transparent, consistent, and based on objective guidelines we agreed to as a community is a much more straightforward task.

I completely agree that this discussion about guidelines for behavior on this github repository (again, a place where people work on code together) should just include the people who regularly contribute to the codebase.

achow101 commented at 9:38 pm on March 1, 2024: member

I would propose something more lightweight and less prescriptive than a code of conduct.

I think the examples I’ve linked to are fairly lightweight and not that prescriptive. They all really just outline the kind of space that they want to foster for their respective projects, some pointers on how to achieve that, and some things to not do. I think they’re fairly loose and don’t really prescribe how people must actually behave nor necessarily exact things that would be violations or specific consequences for doing so. Rather, they do seem to all just state that they want their communities to be welcoming and respectful, and if anyone feels like that is being violated, they can report a CoC violation.

I think we should try short-term bans of posters who causing specific problems, with full transparency so it’s clear:

Sure, but the question has always been what behaviors do contributors think are ban worthy, and the lack of any guidelines for that is what brings up this issue.

maybe we could consider opening a new repository like bitcoin-core/moderation or bitcoin-core/gh to track issues like this related to moderation, or management of the github org.

I agree with having these kinds of issues be in a separate place. I think the Discussions feature could be used for this as well.

For what it’s worth, I think it will be extremely difficult to prevent the weaponization of the loose language, including the requirement to accept veiled criticism and encouraging weaponized demands for apologies.

IIRC this is a criticism of the specific text proposed in the previous PR, but the point of this one is not to propose a specific text yet. It’s not clear to me how the examples I’ve linked to would require accepting veiled criticism or encourage weaponized demands for apologies, so I think this problem can be avoided by using different language.

See also http://esr.ibiblio.org/?p=8609

At the same time, this is open source and no one is obligated to work with you. You could be a genius super coder, but be a complete asshole that is hard to work with, and it is everyone’s right to decide to never speak with you. Being good at something doesn’t give you the right to force everyone to listen to you.

Well-kept Gardens Die By Pacifism and I certainly think we’re well on the road to death considering how little moderation occurs in this repo and the IRC channel. We can even see from the 2023’s contributor survey results that the number of contributors has been steadily decreasing and that disruption from both contributors and non-contributors have been a major frustration in the past couple years. I do not want to suggest that there is evidence for a direct causal link between lacking moderation and fewer contributors, but it’s not so much a stretch to say that this may be a factor, among many others. More active moderation and a guidelines for that moderation (whether that be a code of conduct or something else) seems like proper way to resolve these issues.

ajtowns commented at 7:47 am on March 2, 2024: contributor

As such, I think it would be prudent for us to reconsider adding a Code of Conduct or otherwise some written rules of moderation so that moderation actions can be taken more proactively.

Like I said last time, I think more proactive moderation is a good idea, but adding a code of conduct will likely cause more problems than it solves. Moderation is naturally a judgement call, and either people support the people making those judgement calls or they don’t. Trying to specify what’s good behaviour just encourages lawyer-style parsing of the terms, and if you’re just talking in generalities like “be excellent to each other” you’re not really providing any help to the people who might actually want some help.

If mods/others want to write some “how to constructively engage with other contributors” advice (like productivity.md or developer-notes.md) that’s likely fine, and allows for a positive focus on good behaviour rather than a negative one on the worst contributors. (“oops, I got moderated, how should I react?” might be a good question to have an answer for, for people who’re trying to be constructive, but don’t always succeed, and are afraid that more proactive moderation might cause them to be exiled/excommunicated)

If repo admins/mods want to have a private wiki page with some bullet points for what should be moderated and what shouldn’t so they can be consistent with each other, especially in the early days of being more proactive, that probably also makes sense. (Trying to coordinate a response to attackers while being completely transparent in all your plans on how you’ll respond seems like a losing bet to me, so beyond ryanofsky’s suggestions about making it possible to audit the actual actions taken, I think there are limits on how much transparency is a good thing)

(To be explicit: I don’t support adding a code of conduct, however I do support the current repo admins being more proactive in moderating comments, even if they insist on making a code of conduct as part of doing so)

ajtowns commented at 7:56 am on March 2, 2024: contributor

As someone who does moderation actions, personally I would like to have more guidance from other contributors on the moderation actions that they would like me to do.

To answer this: I think the moderation I’ve seen has been pretty fine, just being more proactive about it would be better; ie don’t wait until there’s been lots of brigading on a PR with content-free ACKs/NACKs before acting; react to messages when they start getting too heated/circular/unconstructive, rather than only after an argument’s gone completely off the rails?

jrc-dev commented at 10:08 am on March 3, 2024: none

@glozow and @achow101 seems that you together already decided, go on.

michaelfolkson commented at 1:06 pm on March 3, 2024: contributor

Concept NACK

The biggest problem seems to be rambling and off-topic comments and discussion. You can’t write a set of rules or an algorithm to determine what is rambling or off-topic. It will be totally dependent on the PR and the proposed change. Stop wasting time, be proactive and transparent with your moderation decisions and certainly don’t start blocking people for weeks or months. That is another terrible rabbit hole to go down. GitHub allows you to mark a comment as abuse or off-topic as you have done on this issue. It also allows anyone to view the comments that you have marked as abuse or off-topic. Use the tools available to you and stop trying to become a subpar lawyer. You’re not a Core maintainer because of your legal expertise.

ariard commented at 2:15 am on March 4, 2024: member

I think it’s important to point out here that a CoC is basically a formalization of what happens anyway. Either there’s a formal process that’s (hopefully) somewhat transparent to deal with disruptive people or there isn’t and there’s only frustration from being ignored and banned and muted by individuals and the same conversations happen in back rooms instead. There’s not going to be a material change in outcome for a CoC done right (though it can definitely be done wrong), there’s only more transparency and formalism.

From my experience of the LDK code of conduct, @TheBlueMatt is the perfect example of someone who does not understand how “conflict of interests” apply to moderators too. For everyone transparency, my access to LDK is blocked since I raised strong observations on Matt’s development style here. If you’re tired to have people pointing flaws in your code and you’re under pressure of your own employer to respect commercial deadlines this is so easy to masquerade this as a Code of Conduct infringement.

At the same time, this is open source and no one is obligated to work with you. You could be a genius super coder, but be a complete asshole that is hard to work with, and it is everyone’s right to decide to never speak with you. Being good at something doesn’t give you the right to force everyone to listen to you. @achow101 If you’re not able to bear with the current pressure of being a maintainer you can resign from your admin rights or open the discussion to have more people vetted with spam management rights if the task is too much demanding. Blocking someone GH account won’t prevent to have sound technical arguments address on another communication interface in an automatic fashion.

Overall, I think this is a discussion better to be held at one of the next Coredev editions, or with wide consensus ecosystem.

ariard commented at 2:17 am on March 4, 2024: member

By the way in the eventuality we have a Code of Conduct would I be able to report @morcos for sending me lawyer letters without material evidences and getting him ban from the repository ?

This is not a troll and a very serious question, given he’s funding at least one maintainer on this repository.

ariard commented at 2:44 am on March 4, 2024: member

SHA256: f7dba0f0e33f4657cc5ed014988f2d8dfce8cd462c48087303fbcc98bc36a385

I’ll do regular and random OTS stamps of this conversation, at least to make it apparent in the eyes of the wider Bitcoin community if there is any tampering of posts by current GH administrators.

ryanofsky commented at 4:44 am on March 4, 2024: contributor

I think it’s important to point out here that a CoC is basically a formalization of what happens anyway. Either there’s a formal process that’s (hopefully) somewhat transparent to deal with disruptive people or there isn’t

Yes, but there can be a big difference between formal a process is and how transparent it is. OpenAI board firing Sam Altman is an example of a formal, legalized process that had no transparency about the reason he was fired.

I feel strongly that any moderation process should be transparent, but I don’t really care how formal it is. For example if the moderation process will involve bans, I think it needs to be clear at all times who is banned, when they will be unbanned, what specific reasons they were banned, and who decided to ban them. I don’t think there needs to be a very formal process for deciding to ban someone for a week, but more formality could be helpful in other cases. @ariard I just want to say I agree with your general complaints, and I don’t really know the details, but would probably also agree you were also treated unfairly in some cases in the past. However, I don’t think it’s helpful to call out people individually and speculate about their motivations in this issue. I really think everybody here has good intentions, and if people acted badly it probably had more to do with interpersonal conflicts and emotions running high, and hopefully there can be less of those things if we try to stick more narrowly to the topics being discussed.

1440000bytes commented at 9:56 am on March 4, 2024: none

@achow101 If you’re not able to bear with the current pressure of being a maintainer you can resign from your admin rights or open the discussion to have more people vetted with spam management rights if the task is too much demanding.

Moderation is working fine without code of conduct and this issue itself is an example. Not sure what exactly are they achieving by hiding some comments but it proves you don’t need CoC for any sort of moderation. It will be the same after CoC and moderation will be done based on bias, opinion, person involved etc.

I think @achow101 should step down as maintainer because some reviews were ignored and an important pull request was merged. This is irresponsible behaviour that nobody expects from bitcoin core maintainers. This is even documented in contributing.md if that makes any difference.

ariard commented at 6:25 pm on March 4, 2024: member

@ryanofsky Thanks for your words, I very appreciate. About the past cases, I’ll for sure keep addressing people with whom I have an opened concern over adequate communication channels. However, note the original subject of dispute was already being in a non-solved situation of conflict of interests with the lack of a neutral tier, apart of already established court of justice, whatever the jurisdiction (which I’m fine with).

I don’t pretend to be exempt of conflict of interests myself. Just historically being far more frank with my discussion partners and being very sensible about them (e.g refusing to accept financial resources to work on consensus changes whatever for-profit or non-profit) and be proactive in private when it arises.

For your own information, “good intentions” have been debunked philosophically numerous times e.g by Max Weber, better to talk about communication process constraining the participants in good faith. That said, I’ll assign “good intentions” to anyone engaging in a conversation as long as they’re opened to have a patient conversation (without threats of preemptive ban or whatever).

Personally, if we’re seeing another “forcing through” of moderation rules adoption, like I’ve been the witness with LDK, I’ll revise my security information sharing policy in consequence. At the stricto sensu excluding anyone being a moderator even if they’re on the security list or already a trusted-keys.

While I’m very open to take time and discuss the establishment of new moderation rules to guarantee minimal civility, I have no sincere wish to collaborate with folks playing a “king-and-president’ culture, and jeopardizing a safety-first culture.

I won’t comment further on this issue. I think the discussion should be handled on the mailing list, a communication space where any current conversation protagonist does not have vetted interest in the discussion, neither is able to unilaterally decide what is “off-topic” from not in a very already arbitrary fashion (cc. @achow101 or anyone who has marked one my previous comment as “off-topic”, do you have “FOSS independence” provisions in your work contract like few Blockstream veterans used to have ?).

Key lesson: I think whatever the moderation rules and process adopted we should have a distinct group of moderators i.e people not being maintainers, not vetted with current GH admin rights, not being on a security list or being an emeritus security researcher like myself in the purpose to minimize future situation of conflict of interests. We can take time to go select the adequate group of people.

Inviting anyone to pursue the discussion on the new google group (I started one though feel free to start another one if you don’t like the communication tone), it’s more appropriate.

glozow commented at 9:22 am on March 5, 2024: member

One way of thinking about this issue is maintainers seeking feedback on the current process for moderation. The recent Core dev survey showed that the number 1 frustration of developers is the brigading/campaigning comments from outside the org. Very recently I’ve received (and made) various requests for more moderation. Up until that point, pretty much 100% of the feedback (at least from my perspective) was “you’re making things worse,” “you are censoring,” “you are acting against bitcoin’s values and should step down,” etc. As I mentioned previously, when moderation doesn’t happen, it’s because people are worried about acting against the group’s wishes.

Imo this issue has been productive for feedback collection. My takeaways are:

Be more proactive #29507 (comment)
Don’t want a formal process, but do want a more transparent one #29507 (comment)
Avoid “conflict of interest,” separate the moderation team from the maintainer team #29507 (comment)
A formal public CoC may just be weaponized to DoS moderators while still allowing undesirable behavior. Perhaps we can jsut create written guidelines to be shared amongst the moderators (to make consistent decisions) #29507 (comment)

Sjors commented at 12:01 pm on March 5, 2024: member

As a non-moderator reviewer I find brigading and campaigning comments annoying, but easy to ignore. However I do think they reduce review quality overall, and thus code quality. That’s made worse if the original author is discouraged from improving their code.

Moderation may have the advantage of showing that person that they’re being ignored, which is especially helpful if they had good intentions. That may be what @TheBlueMatt was getting at? #29507 (comment)

My two main concerns with “code of conduct” are:

the risk of getting drawn into culture wars stuff
controversial or unsafe stuff getting merged, without a “paper trail” of objections

I think my suggestion from last year #26890 (comment) should help mitigate (1):

Perhaps a better approach is to start with an extremely small document that simply list things you shouldn’t do and potential consequences: don’t spam, don’t go off topic, no ad homonyms, etc. Expand that list as new bad things happen, rather than trying to preempt every contingency.

(in the context of avoiding “fluffy” language that is more likely to be seen as political)

But as the description says:

Instead of proposing a specific text this time around, I’ve opted to first revisit the idea on its own, and we can try to nail down the text at a later date.

So we can do that.

And I also see how such rules can be used to endlessly “litigate” the meaning of these terms. Which is an argument in favor of allowing moderators to use their own judgement - but that’s risky too.

Regarding (2):

I don’t know if there’s enough volunteers around to completely separate moderators from trusted-keys people. It does seem like a good standard to strive for.

A good start would be that if moderator A is closely involved with (the topic of) a heated discussion, they ping moderator B to do the ban. That way at least there’s two eyes on it. Combined with a published list of bans.

I also wrote this:

I’d rather not ship a zero-day because a mean person couldn’t point it out. On the other hand […]

So one guideline I would suggest is to delay merging stuff if a potential competent reviewer is on a ban list (probably can’t be a hard rule, because that would be DoS vector on the process).

If mods/others want to write some “how to constructively engage with other contributors” advice (like productivity.md or developer-notes.md) that’s likely fine, and allows for a positive focus on good behaviour rather than a negative one on the worst contributors. (“oops, I got moderated, how should I react?” might be a good question to have an answer for, for people who’re trying to be constructive, but don’t always succeed, and are afraid that more proactive moderation might cause them to be exiled/excommunicated)

Yes, that seems useful content. But as I mentioned in my meta-comment last yet, it should not be in the codebase: #26890 (comment) (but e.g. on a wiki)

sdaftuar commented at 4:33 pm on March 5, 2024: member

I think we need more moderation of this github repo. I think it’s important that anyone be able to contribute to reviewing PRs, opening PRs and issues, etc; however it’s also important that no one feel obligated to read and respond to every message that anyone on the internet might post here (particularly when some of the content is abusive to other contributors). And unfortunately Github’s mechanism for allowing one user to “block” another seems to be too heavy-handed for use in our repo, as it can be used to prevent people from reviewing and commenting on PRs, which seems inappropriate for this project.

So in the absence of better tooling to help contributors ignore inappropriate content and harassment by others, I think moderation is our only real option. I don’t feel strongly about whether we have an explicit code of conduct, or if we find some other way to empower moderators to use their judgment to cut down on off-topic posts, brigading, ad-hominem attacks, and the like, but broadly speaking, I’m supportive of us moving in this direction so that we can keep this place productive in a way that is consistent with the ethos of open-source development.

TheBlueMatt commented at 6:02 pm on March 5, 2024: contributor

the risk of getting drawn into culture wars stuff

The best defense against this is having a code of conduct committee that absolutely despises spending time on a code of conduct committee. Pick people who are reasonable and rational but also engineers who, above all else, want to be able to focus on getting work done. No matter what the Code of Conduct says in textual form, people who want to create dramaz and inject culture war into anywhere they go will do so, if they end up in the set of people who control the ban button (whether that’s a code of conduct committee or repo admins) they’ll create dramaz you don’t want.

controversial or unsafe stuff getting merged, without a “paper trail” of objections

This sounds like a major issue for consensus changes, but I don’t see how its super relevant for day-to-day Bitcoin Core contributions and PRs. There’s nothing wrong with a controversial PR getting merged in the wallet or GUI or even P2P (as long as they aren’t unsafe). We obviously want every competent person to contribute to Bitcoin Core, but if someone’s net contribution is to distract others from doing their work (no matter how they do that) more than they actually add, then we can live without them. There’s simply no excuse for keeping people around who, net, result in less productivity and focus, just because they might raise some legitimate issues in the future. You also have to consider the people who are being distracted are also likely to point out some other issues elsewhere, and aren’t able to because they’re being distracted!

ariard commented at 7:28 pm on March 5, 2024: member

Inviting anyone to pursue the discussion on the new google group (I started one though feel free to start another one if you don’t like the communication tone), it’s more appropriate.

Apparently my previous post is still under moderation (cc @kanzure). I did a second one more polite and civil, as such being able to collect open feedback from the wider Bitcoin community.

Adding few more thoughts here as I cannot express myself on the google group mailing list for now.

The best defense against this is having a code of conduct committee that absolutely despises spending time on a code of conduct committee. Pick people who are reasonable and rational but also engineers who, above all else, want to be able to focus on getting work done. No matter what the Code of Conduct says in textual form, people who want to create dramaz and inject culture war into anywhere they go will do so, if they end up in the set of people who control the ban button (whether that’s a code of conduct committee or repo admins) they’ll create dramaz you don’t want.

I think it’s wise to pick up moderators who are contributors to Bitcoin Core, or the wider Bitcoin community. Not only technical contributors, we can pick up people with a substantial track record organizing local Bitcoin meetups or conferences.

On the call to just apply “reasonable and rational” norms this is one of the more discussed subject in philosophy (cf. Gaston Bachelard on the history of epistemology).

It sounds to me there is an ignorance of the underlying political ideology already behind the notion of a “code of conduct”, even as practiced by other major listed FOSS projects. It’s already a practice standing for social justice warriorism, politely. What can be drama in the eyes of one contributor can be a very justified topic of discussion in the eyes of another contributor.

As a simple objective fact, to the best of my knowledge we have already 3 maintainers (glozow, russ, achow) who are US-college educated. Without this being a criticism of US-education (I would bet I know a better deal about US history than the average US-college graduate), I think it would be very fruitful to have moderators coming from a different cultural and geographical background.

E.g in my local culture it’s an accepted fact to go to reach out to journalist when you think someone in a public position of authority is adopting a misappropriate sequence of actions in the conduct of its public role.

This sounds like a major issue for consensus changes, but I don’t see how its super relevant for day-to-day Bitcoin Core contributions and PRs. There’s nothing wrong with a controversial PR getting merged in the wallet or GUI or even P2P (as long as they aren’t unsafe). We obviously want every competent person to contribute to Bitcoin Core, but if someone’s net contribution is to distract others from doing their work (no matter how they do that) more than they actually add, then we can live without them. There’s simply no excuse for keeping people around who, net, result in less productivity and focus, just because they might raise some legitimate issues in the future. You also have to consider the people who are being distracted are also likely to point out some other issues elsewhere, and aren’t able to because they’re being distracted!

Given how much you can have interactions among consensus rules between the wallet and the P2P and their given deployment market shares, conversations in those areas are as much significant in term of funds at risk than other areas. Personally, I don’t think contributors whatever their level of competence or legendary track records are legitimate to justify whatever level of moderations to accommodate their subjective appreciation of being harassed (if they’re working for a well-funded entity they can ask for additional psychological support as part of their compensation, they do that at Google and Facebook I think ?). As a security researcher, I have sadly experience with “bad faith” software vendors.

As it’s said in Qubes OS community guidelines: “we are most definitely thankful and appreciative of your efforts, but must also remain vigilant in order to ensure continued quality and safeguard against potential sabotage.”

On some more constructive and proposed points:

make the moderation discussed in public and moderation decisions authenticated by default (e.g OTS or GPG-signed)
introduce the ability to appeal or recall any ban, at least if they start to be substantial
have moderators coming from a wide social, bitcoin and geographical background
have moderators nominated for a time-bounded period e.g as done by the Linux kernel project (2 years iirc)
train moderators in term of public internet discussion standards, e.g have them read a list of classics of FOSS culture

Finally, I think we can automate a lot of pure spam management (e.g anonymous chat-gpt PRs) to make the “bear-load” already encumbered by maintainers more acceptable. Looking into the hoods of Github API right now, we can discuss this topic on another issue.

1440000bytes commented at 8:07 am on March 6, 2024: none

This sounds like a major issue for consensus changes, but I don’t see how its super relevant for day-to-day Bitcoin Core contributions and PRs. There’s nothing wrong with a controversial PR getting merged in the wallet or GUI or even P2P (as long as they aren’t unsafe).

I don’t agree with this and P2P is as important as consensus code. Sometimes changes look safe and end up introducing vulnerabilities: https://github.com/bitcoin/bitcoin/pull/9049/

ajtowns commented at 8:49 am on March 6, 2024: contributor

One way of thinking about this issue is maintainers seeking feedback on the current process for moderation.

You might consider phrasing that as “Moderation Guidelines” or similar rather than a Code of Conduct – ie something that talks about how moderators will behave, rather than how everyone will. Having “guidelines” rather than “policy” or “rules” might help that be a living document, and minimise the amount of legalistic nitpicking based on it (and having it be authored by the people it affects might make it feel like less of an imposition on contributors). If it were up to me (and it’s not!), I’d do something like this:

setup a “Mod Guidelines” page somewhere, maybe in the devwiki. limit edits to org members, and say on the page that only mods should edit it
- state what the goals are for moderation: presumably we want PRs/issues/reviews/comments to be friendly, professional, and focussed on technical issues, but probably the “bitcoin is money for enemies” philosophy and the desire to accept contributions from anons limits how effective moderation can be in practice; probably technical limitations about how github works also limits things
- state what tools you’ve got: hide comments, limit PRs/issues to org members, block users, (…?) and give an idea when they’re expected to be used, mostly so mods can be consistent but also so contributors know what to expect
- give some advice on how to react to being moderated. main points are probably:
  - “take a step back and calm down, this isn’t permanent, and isn’t going on your permanent record”
  - “generally, escalation will only make things worse”
  - “if you’re sincerely confused, you can ask for more of an explanation; but expect that to be an explanation of what you did wrong, not a sudden realisation from the moderators that you were right all along. arguing with the ref is how you turn a yellow card into a red card”
pass that text around to regular contributors and ask them if they’re comfortable endorsing it; revise it until you’ve got something that does seem widely supported
setup somewhere that collects logs of moderation actions, possibly only viewable by mods or by org members
setup somewhere for contributors (not necessarily org members) to give feedback about moderation (maybe the irc channel and the annual survey are good enough)

The recent Core dev survey showed that the number 1 frustration of developers is the brigading/campaigning comments from outside the org. Very recently I’ve received (and made) various requests for more moderation. Up until that point, pretty much 100% of the feedback (at least from my perspective) was “you’re making things worse,” “you are censoring,” “you are acting against bitcoin’s values and should step down,” etc.

I think that’s to be expected tbh – when moderation is working well, the only people that really notice are the ones being moderated, and they’ll complain; and when you add in people with significant financial motivation to see the project either fail or make little progress (eg, so that their altcoins can compete, or so that they can get control over bitcoin’s future for themselves) then I think attacks on the development process and maintainers even when things are working fine is also to be expected. If those sorts of attacks are seen to be effective at slowing the project down or pushing existing devs out, I’d expect more of them. YMMV, of course.

ariard commented at 6:12 pm on March 6, 2024: member

setup somewhere that collects logs of moderation actions, possibly only viewable by mods or by org members

I think this overall “Mod guidelines” proposal is reasonable and actually wise to precise how the moderators should behave, rather than everyone will. One divergence, I strongly believe that all the moderation process should happen in public (e.g on a dedicated irc channel), including the logs of moderation actions. I don’t see any technical or philosophical reason why this should happen in private ? Publicity of moderation allows anyone to verify moderation decisions are generally following the guidelines. If you have a private inter-personal issue, I think it’s better left to existent conflict resolution mechanisms or other new ones.

I still very think “moderators” selection should be a careful process. We can afford to select people who are not necessarily highly technical contributors though yet with a past track records of bitcoin contributions. I think it can be judicious to pick up e.g regular meetups organizers or operational people at bitcoin orgs outside of the circle of maintainers and proficient reviewers. They might have more time to investigate and take a listening-first and grounded moderation decision and they will be certainly more neutral w.r.t to any technical discussion (I don’t think it’s fair practice if you have a moderator moderating on its own PR ?).

Additionally, I think it’s good to rotate moderators every X and have them elected by the regular technical contributors (this is done by Linux kernel where every contributors with more than Y commits over the last N releases can participate in the vote). Someone could be re-elected through election acts as a check-and-balance, and avoid any unaccountable and opaque bureaucracy phenomena.

Lastly, I think it’s good if the “Moderation guidelines” offers some public or personal apologies (e.g “sorry for the heated conversation, I owe you a beer next time”) mechanism for offenders to recall the ban. It can happen to be “rough” towards someone in the flux of online events, we’re human beings we all have highs and lows. I hope we’ll design “Mod guidelines” that are cultivating community appeasement and communication reestablishment, over narrow “blame culture”.

Sjors commented at 10:33 am on March 7, 2024: member

controversial or unsafe stuff getting merged, without a “paper trail” of objections

This sounds like a major issue for consensus changes, but I don’t see how its super relevant for day-to-day Bitcoin Core contributions and PRs.

That’s a fair distinction. Though I’d add DoS resistance and various critical pieces of the wallet to that list (it seems both you and @ariard agree on that).

ariard commented at 5:44 am on March 8, 2024: member

On the recommendation of the Bitcoin Dev Google Groups maintainers, I read the piece entitled Well-Kept Gardens Die By Pacifism and they invited me to keep the discussion here.

I think it’s a flawed piece on how to maintain high-quality online community. Mostly, it’s justifying the necessity of putting barriers in online discussion by taking example from the meatspace academics world then go to jump at the end to say it’s okay for online communities moderators to listen to their emotional impulsions when to decide when to apply censorship.

On the academic world, it’s very true there is a lot of barriers and check-and-balances to guarantee high-quality of the discussion. E.g all major university systems are selecting their participants based on their GPA records or one-time exam like baccalaureat result. And indeed taking speechs on public subject inside a university most of the time you have to be member of an association or fraternity, which have themselves their own selection criteria.

However it forgets a lot of crucial points of the academics world, the “opinion moderators” (i.e the university professors) are going through a long list of initial exams to guarantee diversity and richness of their viewpoints (PhD / post-doc / threshold of academic paper citations / “aggregation” rituals). They are also guarantee life-long job tenures in most systems, motivated to avoid temporary pressure from the crowd in the filtering of ideas and who is allowed to speak.

All their act of moderations are constantly evaluated and re-evaluated by their academic peers in an open fashion. Moderators or administrators accused of plagiarism can very easy seen their careers jeopardized as one Harvard president recently learnt it.

Finally, it’s ignoring the “Trused Party Are Security Holes” philosophy which in my opinion not only underpinning the Bitcoin ecosystem though also ignoring the traditional critics of the “masters” or “moderators” living in academics life (e.g see George’s Steiner Lessons of the Masters).

Overall, Eliezer Yudkowsky’s piece sounds to me inaccurate as it’s more an empty justification of the pure arbitrary of an online moderator capabilities usage rather than giving example of concrete mechanism that an online community can put in place to guarantee it stays intellectually lively or lines of code productive.

After looking more on Github API and its architecture, I think it will cost someone with domain expertise like myself 100$ / month in terms of domain names and infrastructure to permanently nuke any GH-based moderation decision.

I’ll check this line of research rather than keep commenting on establishing a moderation process that might not be technically plausible to follow.

petertodd commented at 8:35 pm on March 11, 2024: contributor

By the way in the eventuality we have a Code of Conduct would I be able to report @morcos for sending me lawyer letters without material evidences and getting him ban from the repository ?

This is not a troll and a very serious question, given he’s funding at least one maintainer on this repository.

We should be willing to discuss concrete, real-world, examples where a proposed Code of Conduct would be relevant. While this is a particularly extreme example, it certainly is relevant given that it is alleged to have happened, with people closely involved in the repo. It raises an important point: is conduct outside of the direct communication of the project relevant?

Similarly, a discussion about standards of proof and openness is certainly relevant.

cfunk7777 commented at 9:14 pm on March 11, 2024: none

OP will probably minimize this comment too since it will be deemed off-topic to address how relevant comments are being hidden

isghe commented at 0:36 am on March 19, 2024: contributor

at this point, why don’t use a more cultural language, like Italian? The English language, it really sounds like the language of geese

bitcoin deleted a comment on Mar 19, 2024

achow101 commented at 10:36 pm on March 21, 2024: member

You might consider phrasing that as “Moderation Guidelines” or similar rather than a Code of Conduct – ie something that talks about how moderators will behave, rather than how everyone will. Having “guidelines” rather than “policy” or “rules” might help that be a living document, and minimise the amount of legalistic nitpicking based on it (and having it be authored by the people it affects might make it feel like less of an imposition on contributors).

That is essentially what I imagine. It’s really just the need for an established set of rules at all, whether it’s called a “Code of Conduct” or “Moderation Guidelines”, I don’t think it particularly matters.

we should have a distinct group of moderators i.e people not being maintainers, not vetted with current GH admin rights, not being on a security list or being an emeritus security researcher like myself in the purpose to minimize future situation of conflict of interests. We can take time to go select the adequate group of people.

Indeed, and I would, in fact, prefer that. Frankly, I really don’t want to be spending my time on moderation and only do so because there are few others with the requisite github permissions to do so. If we establish a group of moderators who can take over that duty, that’d be great.

I do want to mention however that the repo does actually get a ton of spam, and there are hundreds of currently blocked users because they open spam PRs and issues (just look at everything that’s closed and titled as “.”). Currently one of the maintainers just renames and closes the issue/PR, and blocks the spammer. I don’t think this is at all controversial. I would not want this process to be bogged down in procedural things that are intended for dealing with more nuanced disputes.

I suggest that we move forward with the following:

Create a wiki page “Moderation Guidelines” with text outlining the suggestions from #29507 (comment)
Choose a couple of people to be moderators and give them the moderator permission. I don’t think this needs to be particularly rigorous, but a ACK/NACK vote-ish thing like we do for maintainers seems fine.
Enable the Content Reporting feature so that things can be reported to the moderators (I did not know this feature existing until now).
Setup a new repo bitcoin-core/modlog (or something like that) where moderators should be record moderation actions.

kanzure commented at 1:14 pm on May 8, 2024: contributor

Here is a “moderation guidelines” document that was created 5 days ago apparently: https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md as it seems directly related to the previous discussion in this issue, I thought I would bring it up. All previous comments here, I believe, still apply.

In #29507 (comment) @ajtowns proposes a “Moderation Guidelines” document. I like the idea of writing about goals, explaining the available tools moderators have on github, and some helpful text about de-escalation for enraged internet users. All of that sounds somewhat helpful or at least harmless to the github project.

However, the current meta “Moderator Guidelines” doc’s transparency section introduces a requirement that “it is critical for [moderators] to be clear about how decisions are made” which seems like a very big departure from formlessness for the project overall? Another issue with the transparency section is that it imposes a bunch of extra work that doesn’t scale with denial of service attacks against moderator attention or project resources. At most, surely, maybe a statement that a moderator has made a decision & then move on.

Bitcoin is for enemies. It is important to recognize that CoCs and similar policy or governance are effectively just instructions for your adversaries on how to defeat a project. At the same time, I believe the github repository and its members should absolutely defend itself (including by using moderators) and fight spam or other attacks on contributors’ scarce time and attention.

Also: I would like to propose someone opens an issue for follow-up discussion in the meta repo, links to that issue here, and then closes this issue. I think moving meta talk to meta makes sense.

mzumsande commented at 2:33 pm on May 8, 2024: contributor

Also: I would like to propose someone opens an issue for follow-up discussion in the meta repo, links to that issue here, and then closes this issue. I think moving meta talk to meta makes sense.

There already exists one: https://github.com/bitcoin-core/meta/issues/1

achow101 commented at 5:36 pm on May 8, 2024: member

Since there is a draft guidelines and a meta repo with an open issue for discussion, I’m going to close this one.

achow101 closed this on May 8, 2024

Consideration of a Code of Conduct and/or written rules for moderation #29507