bitcoin-core / meta

6 stars 5 forks source link

Moderation policy: add oversight and recomended actions sections #7

Closed pinheadmz closed 1 month ago

pinheadmz commented 1 month ago

Closes https://github.com/bitcoin-core/meta/issues/3

Adds a paragraph to the moderation policy indicating project maintainer oversight of moderators, so that individual moderator actions can be reviewed if necessary.

harding commented 1 month ago

ACK 85f3e39dd19f7ce2981623a63f4a4a093c130b06

jonatack commented 1 month ago

Concept ACK

ariard commented 1 month ago

I had a first read on it. I think there is still the recusation of specific moderators to moderate specific users.

There could be persisting conflict of interests in the future that cannot be solved (e.g 2 contributors belonging to different commercial organizations with competing business products, here it can be hard to safe-guard the appearance of lack of conflict of interests).

Recusation was raised by achow101 on the other issue. I think here we should have an explicit formulation of a contributor, legitimately, asking in private to have another moderator not moderating its posts. I believe it could be also formalized that a moderator can self-recuse themselves in private towards the other moderators.

pinheadmz commented 1 month ago

I think there is still the recusation of specific moderators to moderate specific users.

Achow mentioned how hard it is to define "conflict of interests" and that's why i left that out of this PR. Moderators for sure can recuse themselves, they just take no action at all, another moderator will handle the situation. That's been working just fine so far with Will and I.

The goal of moderators is to make the code maintainers' jobs easier. To take a bit of janitorial work off their plate. Everything we do as moderators would have been done by the maintainers. Any discrepancies in that pattern should be reported to the maintainers (we just set up a very specific email address for this purpose) and the maintainers can decide to remove moderators.

pinheadmz commented 1 month ago

@jonatack thanks for the suggestions, pushed.

ariard commented 1 month ago

Thanks pinheadmz for the answer.

I had a second read on the proposed formulation and it’s all good to me, at the exception of the “persistent conflict of interest” as my previous comment raised so. I’m thinking about the following formulation, which aims to be short and concise.

In “Oversight”:

If you're under a persistent conflict of interest with one of the moderator, which might not be the blame
of the moderator itself or anyone in fact, please acknowledge you can email moderation@bitcoincore.org to
request such moderator to not intervene on your post and that another moderator or maintainer substitute
to it in its actions. Moderator can also self-recuse from moderating a specific contributor for conflic
of interest.

As said Russ on the other issue, the goal of the moderation rules is to keep contributors focus on code writing and review, while limiting the impact of the other factors. On the other hand, it’s still very probable in the future that we have active contributors belonging to commercial organizations with competing interests (e.g an external observer could point out somehow that blockstream is in competition with block inc / spiral in the lightning infra space).

From my experience seeing in live the taproot activation and appointing bip editors controversial discussion in 2021, I think it’s better to have more organization best-practice risk slightly more lay out in written rules, than the lack of it. There is no wish on my side to make the project a bureaucracy, really.

On the other side the project history doesn’t lack examples where some written rules could have been great in some controversial situation which has terminated as zero-sum results, as some recognized contributors have left afterward due to unsatisfactory resolution of the controversies.

If you have a better idea on how to formulate such “persistent conflict of interest” caveat, I’ll review again.

pinheadmz commented 1 month ago

If you have a better idea on how to formulate such “persistent conflict of interest” caveat, I’ll review again.

I don't think it's possible to define "conflict of interest" at all, with or without qualifiers. I also don't think there's a need to qualify moderator-contributor relationships in advance, which I think is what you're getting at?

Here's how I see it:

  1. contributor makes inappropriate comment
  2. moderator takes action
  3. contributor thinks (2) did not follow policy, had other motivation
  4. contributor contacts maintainers
  5. maintainers deal with moderator
  6. someone else deals with the comment in (1) and, potentially, all future comments by contributor

I don't see a need to define "conflict of interest" in the policy document because I do not see (3) ever happening first.

ariard commented 1 month ago

Thanks pinheadmz for the answer.

I also don't think there's a need to qualify moderator-contributor relationships in advance, which I think is what you're getting at?

If I can lay your attention that your present formulation, which was the one proposed by Russ in my understanding, is already employing the terms "conflict of interests". In my impression, it's already an in abstracto qualification of the moderator- contributor relationships. Correct me if I'm wrong, in my understanding, what you're arguing for is more to have only abstract elements to guide the "oversight" decision-making, not giving an exhaustive list of examples.

I don't know if you're aware, though qualification is a reasoning process quite well-defined in legal proceeding, at least in civil law system when a judge submit the factual elements to the the abstract rule of law that can be applied in the case.

I don't see a need to define "conflict of interest" in the policy document because I do not see (3) ever happening first.

Forgive me if there are rude words, though I believe you're naive to think that a moderator cannot be and will never be influenced by external non-technical factors in the pursuit of its moderation actions. There have been numerous accusations in that sense about blockstream in the past decade and here I can only invite you to read this medium article from a blockstream employe and also a FOSS veteran on the risk of janitorial role abuse in the bitcoin space. If that FOSS veteran can see "other motivation" playing out, I'll let you meditate if you can see them yourself.

More deeply, unless you have been through that personal experience (and to my knowledge I don't think so ?), you don't really know how you will react if your employer of the day (chaincode iiuc) comes up to you and submit to you the following dilemma “Pineheadmz, if you don't use your moderation perms to temporary ban contributor ABC we FIRE you from your paid job" What would you do, seriously ? I’m not asking for a public answer, just to meditate on that kind of thorny hazardous situation.

Putting my suggestion under a commit here to make it easier to cherry-pick: https://github.com/bitcoin-core/meta/commit/05cd245c0227af81535e9adb37b1f8f1ca725be1. If we cannot come to agreement this is a valuable addition for the moderation rules, I’ll open it as a PR of its own. That way it doesn’t preempt progress about this branch.

ryanofsky commented 1 month ago

ariard, if I understand you correctly, you feel that it is important for the moderation guidelines to provide a way for posters to request that their posts not be moderated by certain moderators, even before those moderators have taken any actions, and potentially even before any posts have been made.

The benefit of this would be that it could provide a way for posters who feel like they are stepping into an adversarial setting to feel less intimated. And it could give other people (who may not even be posting but just reading the guidelines to find out about how decisions are made in bitcoin development) the sense that the project takes conflicts of interests seriously, and even put in place a mechanism to for moderators to be recused to ensure that discussion is open and free.

But IMO, it seems premature to add something like 05cd245c0227af81535e9adb37b1f8f1ca725be1 now before actually determining whether moderators have made any bad decisions and what might have caused those decisions. I suspect, in reality, that if mistakes were made, they were probably caused by uncharitable readings and conflicts of personality more than conflicts of interest. I also think there could be downsides to moderators being recused before it was necessary, because it could harden battle lines and give people reasons to ignore each other instead of understanding each other and working out their differences.

I think, in general, one difficulty with understanding your feedback is it very abstract and doesn't tend to provide a lot of background information. Like after reading your posts in #3 I still don't know if you think moderators actually did things they shouldn't have done, like removing on-topic posts that contributed to a technical discussion. (If they did, it would be really helpful to know about those posts.) The most specific reference I could find to a concrete disagreement about moderation policy was https://github.com/bitcoin-core/meta/issues/3#issuecomment-2264315555 where you said it was "fully legitimate to question the application of the moderation policy directly on a technical PR." Which could be true, even if it goes against current guidelines ("Comments about moderation decisions or moderation policy are off-topic"), depending on the context, if moderators made a bad judgement call trying to enforce the policy. I would just encourage opening an issue in the future if you see patterns of bad behavior, so we can try to resolve specific problems directly instead of only being able to discuss them in abstract ways.

ariard commented 1 month ago

Thanks ryanosky for the answer, I think you're understanding my position correctly on some lines, not all.

On the prematurity of introducing something like 05cd245 and the downsides you're pointing, I won't get out of my mind that in the project history, there have been situations where github permissions were leveraged to settle some different, the most notable one is the removal of Gavin rights on the repository in 2016. In my understanding of that past situation, you had high quality contributors belonging to organization with opposite interests and that might have played out in the way the technical conversation has played out (whatever, one's own belief on the technical soudnesss of the arguments on each side at that time).

When you go to discuss with people who have been in the bitcoin space for a very long while, history is never a "black or white" thing, it's full of nuances. I'm giving that examples, though I could point out to other examples in the project history when there have been tense situation about perms and their usage, or other large-scale foss projects.

That point said, I think you're making a worthy observation on the downside of asking moderator to be recused before it's necessary, and that it could harden battle lines instead of talk and work out differences to build a common understanding. That's where the new email endpoint moderation@bitcoincore.org could be leveraged, it might be indeed wiser to reach out there with the moderator cc if you have an issue with them (if there is like you said a conflict of personality or more private interest plays out and one does not think a public issue on this repository is appropriate).

About the understanding of my feedback, please re-contextualize in the situation where my call to put in place rules about conflict of interests and oversight about moderation rules was left unanswered for 2 months by the moderators. Under that antecedent, and this what I'm pointing out in my answer to dharding you're linking, one (and I for sure) can legitimately question if the moderation rules are not selectively applied to advance some organizations (technical) viewpoints.

There is not only the text of the moderation rules that matters, though only the consistency and regularity in their applications, and a bit of neutrality in the moderation, I could easily pointed out to other PRs which have not been addressed by months for their authors and who have not been closed (and a critical mind could observe for one PR that the author is the hierarchical superior of one of the moderator, that is feeding doubt on moderation neutrality). Judicial and medical fields have a lot of ethical guidelines, some stamped by the tide of centuriees for reasons.

For all those reasons, and especially given personally I have conflict of interests with the 2 organizations currently financing the 2 moderators (spiral / block inc and chaincode — neither necessary or adequate to re-hash them here, just a fact), I don't think 05cd245 is a premature addition. If you have suggestions on how to soften the downswides, you've been pointing I'm willing to examine them.

As suggested by jonatack on the issue, I think one way to dissipate the impression (at least mine) that moderation is at risk of not being always neutral is to have the list of moderators being public (like it's done in trusted keys for maintainers) and widens their number.

harding commented 1 month ago

have the list of moderators being public (like it's done in trusted keys for maintainers)

I would like to re-advocate for the opposite approach: keep the list of moderators private (known only to the maintainers) or at least have all moderation actions performed by a proxy bot that publicly hides the name of the acting moderator (but privately logs it for later maintainer review). I previously suggested this in https://github.com/bitcoin-core/meta/issues/1#issuecomment-2094361530 (final paragraph of that comment). My motivation there was "That way any criticism of moderator activity is directed at the entire project rather than individual moderators."

Any criticism of a moderation action should start with a convincing argument that the action was unwarranted. That does not require knowing the identity of the acting moderator. If there are many inexplicably unwarranted actions, or some actions that are egregiously unwarranted, it may be worth discussing why the system is failing and how to fix it. However, that discussion should first focus on policy and procedures, with discussion of specific moderators only occurring if it's clear that policy and procedure aren't being followed. Ideally, any discussion of specific moderators should occur in private.

ariard commented 1 month ago

at least have all moderation actions performed by a proxy bot that publicly hides the name of the acting moderator

I think the approach you're proposing is more at risk of worsening the contention and controversies among the project about moderation policy and procedures, rather than softening them. Publicity of all activities is the norm in open-source and moving moderation as a private activity will prevent all active contributors to passively verify and monitor the moderation process. Such passive monitoring is likely a very effective expedient to prevent hijack of the moderation process by organizations or groups of influence, them being open-source organizations activelly bringing technical contributions to this project or far more external.

More, the only decision-making process we have as an "entire project" is the one already happening in public on the repository, on irc, on the mailing list, an individual moderator cannot represent the "entire project” for the sole sake it's done pseudonymously. We have like 40+ contributors in the github org only, and I don’t think each of them wish to have each moderation decision taken in their name, especially if they're controversial.

Neither it will prevent a single individual to go to knock the github platform door and (legally) ask the list of accounts with moderation permissions on the project, if one deeply think the policy and procedures are not being followed.

May I suggest you to have a read of Plato's Republic Book 2 and the well-known myth of the Gyges's ring on the interplay of secrecy, privilege exercise and principles, it's great tale to meditate (here the wikipedia link). In my opinion, publicity of who act the moderation decisions and as such the accountability of individual moderators is a compelling check-and-balance to have in face of many risks.

harding commented 1 month ago

moving moderation as a private activity will prevent all active contributors to passively verify and monitor the moderation process.

That's not what I'm proposing. I'm suggestion that the name of the person who performs a moderation action doesn't need to be publicly disclosed. Anyone is still free to monitor what actions were taken. (And, if all actions are made through a shared account, e.g. using a proxy script, it would probably be trivial to convert actions into an RSS feed or git repository that anyone could trivially follow).

an individual moderator cannot represent the "entire project”

Again, that's not what I'm proposing. I'm suggesting that we ensure criticism of moderator actions is directed at the project rather than at the moderators. This is one of the things the moderators are expected to do for other contributors: ensure that criticism is about the system, not about individuals. It seems only fair for the project to help ensure that any criticism of moderation is about the policy and procedures, not about the individual moderators, to the greatest degree possible.

Neither it will prevent a single individual to go to knock the github platform door and (legally) ask the list of accounts with moderation permissions on the project, if one deeply think the policy and procedures are not being followed.

Sure, a legal action could compel disclosure of any information anyone wants to keep private. That doesn't mean the information should be preemptively disclosed.

publicity of who act the moderation decisions and as such the accountability of individual moderators is a compelling check-and-balance to have in face of many risks

It is not. We should strongly prefer to debate decisions and the policies surrounding those decisions. We should only debate the qualities of the decision makers if their decisions are consistently and inexplicably inconsistent with the policies.

ariard commented 1 month ago

Thanks dave for the answer.

That's not what I'm proposing. I'm suggestion that the name of the person who performs a moderation action doesn't need to be publicly disclosed. Anyone is still free to monitor what actions were taken. (And, if all actions are made through a shared account, e.g. using a proxy script, it would probably be trivial to convert actions into an RSS feed or git repository that anyone could trivially follow).

In my view what you're proposing is moving the moderation as a private activity as the moderator action is hidding behind a shared account, said account access being restrained. As I'm saying, such suggestion prevent to check and verify who is taking what moderation decision, in the same way we can do so for code authorship, PR review or merge decision.

Again, that's not what I'm proposing. I'm suggesting that we ensure criticism of moderator actions is directed at the project rather than at the moderators. This is one of the things the moderators are expected to do for other contributors: ensure that criticism is about the system, not about individuals. It seems only fair for the project to help ensure that any criticism of moderation is about the policy and procedures, not about the individual moderators, to the greatest degree possible.

This is where we're your missing my point. There is no such thing as "the project" as an aloof entity standing on its own. There is only a group of individual contributors, regularly collaborating among themselves to produce and review code, ship release, exchange technical arguments, build consensus. Such collaboration happening through a variety of communication mediums, the github repository, irc, the mailing list, talks at conference. Again you're saying the moderators are expected to do for other contributors, yet it's true of any other janitorial role like maintenance. Assigning praise and blame to individuals rather than an abstraction like the "system" is far more fruitful to make progress.

Sure, a legal action could compel disclosure of any information anyone wants to keep private. That doesn't mean the information should be preemptively disclosed.

In open-source, where publicity is the rule (-- unless we disagree on this principle), it comes as natural that privileged actions by janitorial role should happen under the same public standard too. I don't know your experience with other professional fields, but in the legal or medical sectors, in my knowledge all “disciplinary" actions are made by named people.

If you have to hide behind a proxy to deliver moderation actions, that's only casting a doubt on the legitimacy of what you're doing (and a judge can be very likely expected to follow the same reasoning).

It is not. We should strongly prefer to debate decisions and the policies surrounding those decisions. We should only debate the qualities of the decision makers if their decisions are consistently and inexplicably inconsistent with the policies.

Why it is not ? It's not like we have hundred of centuries of experiences with judges rendering decisions in public under their own name. That practice only makes any substantiated or apparent conflict of interests visible by anyone. Hiding them behind a proxy only level up a posteriori inquiry in case of inconsistent and wrongly biased decisions with the policy and procedures.

I don't understand why moderators would be warry to be accountable of their moderation decisions. If those decisions are legitimate, justifying them in public should be easy and natural. If those decisions are illegitimate, and a moderator is doubtful that they can be justified, obviously they should not taken.

Have you read my wikipedia link about the tale of the Gyges ring ? Really, if you can come up in any example in anthropology, sociology, history of institutions, the legal field, in philosophy or religious text, whatever the cultural origin, where there has been a long-standing practice of conflict resolution decisions in an organized human group taken by an anonymous proxy in private, rather than a collective of individuals in public, I'm very open-minded to re-appreciate your position.

Finally, I've heard in the past individuals entitled with decision-making responsibilities at bitcoin open-source organization being put under pressure in private to suddenly expel senior contributor out of said organization on very dubious ground and apparently with a complete lack of basic due process. I believe such kind of people should meditate more on what they did in the past before to comment on such a delicate topic like accountability in bitcoin open-source, if they wish their viewpoint to be seriously respected.

harding commented 1 month ago

@ariard

Assigning praise and blame to individuals rather than an abstraction like the "system" is far more fruitful to make progress.

Assigning praise and blame to individuals can only be fruitful when something praiseworthy or blameworthy has happened. We also have to concerned with people being praised or blamed without merit, both of which can be harmful.

Nobody wants their comments to be hidden or deleted, or to have their ability to make new comments suspended or revoked, so it is natural that some people who have been moderated will be looking for someone to blame. Yet if the moderation action was taken in accordance with policy, the moderator should not be blamed.

Publicly associating moderator names with moderation actions makes it easy to blame individual moderators for doing what anyone following the policy would do, which discourages moderation. It especially discourages moderation against people who have greater potential for wrath, such as those who are popular, wealthy, or have other types of power. Discouraging moderation against the powerful risks creating a privileged system where some contributors can violate the rules that others must follow, which is highly discouraging and undermines the intent of moderation to cultivate an environment of collegial technical discussion.

In open-source, where publicity is the rule (-- unless we disagree on this principle), it comes as natural that privileged actions by janitorial role should happen under the same public standard too.

That conflates public action with public attribution. This project was created by someone who did not wish public attribution (as evidenced by them using a pseudonym) but who believed in pubilc action (as evidenced by them releasing open source software).

We don't need to know who created Bitcoin to evaluate its usefulness. Similarly, we don't need to know who hid or deleted a comment (or suspended or banned a user) in order to evaluate the correctness of that decision.

If you have to hide behind a proxy to deliver moderation actions, that's only casting a doubt on the legitimacy of what you're doing

Are you arguing that contributions to this project made using pseudonyms should be treated as less legitimate than those made using birth names? I think we should focus on the merit of specific contributions---whether they be code, reviews, or moderation actions---and only consider the characteristics of the contributor as a last resort.

I believe such kind of people should meditate more on what they did in the past before to comment on such a delicate topic like accountability in bitcoin open-source, if they wish their viewpoint to be seriously respected.

Conversely, I believe that arguments should be considered based on their merit and not based on the respectability of the person who made them. I expect the same of moderator actions.

I've expressed my opinion to my satisfaction on this thread and don't think additional comments from me will be helpful. Thank you for the discussion.

reACK c4fd7703638edc48d040956f6216097249371593

ariard commented 1 month ago

Thanks you dave for the answer.

Assigning praise and blame to individuals can only be fruitful when something praiseworthy or blameworthy has happened. We also have to concerned with people being praised or blamed without merit, both of which can be harmful.

Nobody wants their comments to be hidden or deleted, or to have their ability to make new comments suspended or revoked, so it is natural that some people who have been moderated will be looking for someone to blame. Yet if the moderation action was taken in accordance with policy, the moderator should not be blamed.

Publicly associating moderator names with moderation actions makes it easy to blame individual moderators for doing what anyone following the policy would do, which discourages moderation. It especially discourages moderation against people who have greater potential for wrath, such as those who are popular, wealthy, or have other types of power. Discouraging moderation against the powerful risks creating a privileged system where some contributors can violate therules that others must follow, which is highly discouraging and undermines the intent of moderation to cultivate an environment of collegial technical discussion.

Usually when you're into a debate with someone it's good to reformulate the thesis you're defending for clarity, so let's do it here.

I'm thinking one of the main problem with moderation policy and procedings is the manifestation of conflict of interests by moderators in the exercise of their janitorial role.

Solving this problem, publicity of the contributors entitled with moderation permissions is an effective check-and-balance as it lowers the bar for anyone, active as less active contributors to passively monitor moderators in the conduct of their janitorial role actions. This check-and-balance is not only what is the standard in court of justice, though also in open-source as maintenance, review and code authorship is done under public name.

That is my thesis, beyond I think you're misinterpreting my viewpoint or at least you're pointing out another issue with moderation. Namely, that publicly associating moderators with moderation actions can create a self-chilling risk for moderator not taking actions when they should do so about "powerful" people.

Sadly, I think it's an instance of a paralogism again, as the same reasoning can be applied for any reviewer or maintainer rudely evaluating the technical soundness emanating from a wealthy or popular people. On that regard, publicity is a shield as if you're a target of acts of power in private it's easier to throw under public light such actions as you will be already under passive monitoring by many contributors due to the publicity of exercise of the janitorial role (...darkness only make it easier for a moderator to be silently blackmailed...)

That conflates public action with public attribution. This project was created by someone who did not wish public attribution (as evidenced by them using a pseudonym) but who believed in pubilc action (as evidenced by them releasing open source software).

We don't need to know who created Bitcoin to evaluate its usefulness. Similarly, we don't need to know who hid or deleted a comment (or suspended or banned a user) in order to evaluate the correctness of that decision.

And this observation is short of observing that there was a public attribution of the open-source software. Albeit not to a legal name, but to a stable pseudonym which is creating a form of public accountability. Be certain I'm not calling for people to use a legal name to contribute to open-source, just to have a form of accountability for janitorial roles entitled with privileged permissions. Being able to express novel and weird ideas on the internet under a pseudonym is an unpriceable freedom.

Beyond, I think we cannot appreciate code or ideas contributions in the similar fashion than permissioned actions like maintenance or moderation decisions. The first category of actions, anyone is able to produce them. The second category of actions is only valid because as a group of contributors we're entitling a subset of us with administrative rights allowing to produce such actions. By design, there is a risk of abuse and misuse tainting the second category of actions not present with the first one.

This is not only a question of evaluating the correctness of the decision, though also the deliberation process leading to a moderation decision. Whatever the clarity and expciciteness of the moderation rules, the act of qualification itself offers sufficient margin of human appreciation to let private interests express themselves, and this is the expression of those private interests I wish to safeguard against (-- and as I was saying we have centuries of experiences with court of justice and their emphasis on the independence and impartiality of judges).

Moderation actions are altering the project communication space itself as they can "allow" who as a contributor can speak or not in this space. It's not the same with code and ideas which are expressed within that communication space.

Are you arguing that contributions to this project made using pseudonyms should be treated as less legitimate than those made using birth names? I think we should focus on the merit of specific contributions---whether they be code, > reviews, or moderation actions---and only consider the characteristics of the contributor as a last resort.

No, you're misunderstanding my viewpoint. I think contributions to this project, being done under a pseudonym or a birth name, should be treated with the same degree of legitimacy. What matters is a form of accountability accompanying the exercise of janitorial roles like moderation or maintenance, which is layout on the assignment of specific decisions to an "author", that author being a pseudonym, birth name or collective of a mix of the two.

We don't even get to go as far as considering the social characteristic of the contributor, a track record that you can assign is enough. On this topic, the reading of Michel Foucault's essay "Qu'est-ce qu'un auteur" can be more insightful and seeing authorship as a functional element in the wider conversation of code and ideas (— I’m quite sure there are good translations in english).

Conversely, I believe that arguments should be considered based on their merit and not based on the respectability of the person who made them. I expect the same of moderator actions.

Conversely, if an individual maintainer or moderator loss all the respect from a sufficient number of regular contributors for its technical contributions to the project, its entitlement of a janitorial role should be certainly re-evaluated (as it was done in the past). In my opinion, respect is just what you get from the accumulation of deserving (i.e with merits) arguments and actions.

Thanks you too for the overall discussion, be reassured that I don't see such topic of "public accountability of moderators" as a black or white thing, it's a complex topic for sure.

achow101 commented 1 month ago

ACK c4fd7703638edc48d040956f6216097249371593

ryanofsky commented 3 weeks ago

Interesting posts. Seems like there might be other changes to discuss later. But hopefully that can happen when we have more practical experience and specific events to consider, so discussion can be more concrete.

I had some new thoughts reading this, so just wanted to write them below.


re: https://github.com/bitcoin-core/meta/pull/7#issuecomment-2274212435

I could easily pointed out to other PRs which have not been addressed by months for their authors and who have not been closed (and a critical mind could observe for one PR that the author is the hierarchical superior of one of the moderator, that is feeding doubt on moderation neutrality).

I think this is an interesting and accurate observation, but it is leaving out an important variable because there's a difference between PRs that are unlikely to be merged because haven't they attracted review and PR's unlikely to be merged because they have too much controversy and disagreement. I wouldn't deny that personal relationships affect outcomes in both of these cases. In an ideal world, I wish that there would be no need to close either type of PR, and github would just provide better tools for managing them.

Specifically for controversial PRs, I wish we could just tag them "controversial" and automatically turn off notifications for these PRs for developers who aren't specifically subscribed to them or subscribed to controversial issues in general. Then if agreement was later reached, the tag could be removed and the PR could be put back on radar for everyday reviewers. In general, I don't like the idea of closing things and saying they can no longer be discussed. It would better to have a place where discussion could continue for people who are interested, without creating a burden for everyone else.


re: https://github.com/bitcoin-core/meta/pull/7#issuecomment-2274823455

I would like to re-advocate for the opposite approach: keep the list of moderators private (known only to the maintainers) or at least have all moderation actions performed by a proxy bot that publicly hides the name of the acting moderator (but privately logs it for later maintainer review).

There are things I like and dislike about this suggestion. I like the ideas that:

But I would dislike the idea of a having a robot moderator hive-mind account that goes around posting requests to be civil and stay on-topic, and deleting comments. That seems dystopian, and maybe ok as a last resort, but sad to reach the point of needing it. I think it would be good for moderators to have clearly labeled alt-accounts (and fine if some moderators want to be pseudonymous), but they should still be real people you can understand and reason with even if you disagree. And you should be able to tell moderators apart from one another other so you can understand their actions and reactions as people, including understanding that they are not perfect and will sometimes make mistakes.

ariard commented 1 week ago

Thanks Russ for the additional thoughts, some good ideas with which I agree with.


I think this is an interesting and accurate observation, but it is leaving out an important variable because there's a difference between PRs that are unlikely to be merged because haven't they attracted review and PR's unlikely to be merged because they have too much controversy and disagreement. I wouldn't deny that personal relationships affect outcomes in both of these cases. In an ideal world, I wish that there would be no need to close either type of PR, and github would just provide better tools for managing them.

I mostly agree with this comment, with one caveat the highest value PR and technical proposal can be the ones source of a lot of controversy and disagreement. Precisely, because they're the highest value there can be many options on how to architecture them (e.g Cap'n'Proto, proto buff, gRPC, ...). So is a code PR not attracting review, because it's a source of controversy and the champion(s) of the other technial options are deliberately ignoring it, or is a PR not attracting review because it's has zero interest, from let's say more a code-wise or mathematical-wise viewpoint ?

Beyond, so far microsoft is not billing the bitcoin core project to let years-long open issues...

Specifically for controversial PRs, I wish we could just tag them "controversial" and automatically turn off notifications for these PRs for developers who aren't specifically subscribed to them or subscribed to controversial issues> in general. Then if agreement was later reached, the tag could be removed and the PR could be put back on radar for everyday reviewers. In general, I don't like the idea of closing things and saying they can no longer be discussed.> It would better to have a place where discussion could continue for people who are interested, without creating a burden for everyone else.

I think the "controversial" tag to fine-tune the level of notification is a good idea. Same if someone disagrees with the editorial choice by moderator to mark a PR as "controversial", one can call for an oversight review, or maintainer to look on.

Having a proxy bot would make it easier to review actions by moderators. For example in all this discussion started by ariard, I still don't know the actual moderation events that led up to it, because they haven't been clearly listed and there is no log of moderator actions to look at.

Yes, if there is proxy bot to take actions it would go to have a log, and for further review have the logs periodically timestamped in the bitcoin chain with an open-timestamp or an old school pay-to-contract (pay-to-contract you just have to offset the curve point with a hash to the logs). If there is further discussion on what did happen, the logs can be always communicated or published.

When we are reviewing moderation decisions, we should focus primarily on the decisions, not on identities of participants.

This is not an easy problem, to take a moderation decision you need somehow to assign PR comments to a github profile. (or a pubkey linked to it, if you ask for a persistent identifier of the profile...).

If you are a moderator, your roles as a moderator and as a participant in discussion should be different. I think ideally moderators would use different accounts when moderating as opposed to commenting, or otherwise make it very clear in what capacity they are posting. But I would dislike the idea of a having a robot moderator hive-mind account that goes around posting requests to be civil and stay on-topic, and deleting comments. That seems dystopian, and maybe ok as a last resort, but sad to reach the point of needing it. I think it would be good for moderators to have clearly labeled alt-accounts (and fine if some moderators want to be pseudonymous), but they should still be real people you can understand and reason with even if you disagree. And you should be able to tell moderators apart from one another other so you can understand their actions and reactions as people, including understanding that they are not perfect and will sometimes make mistakes.

I think it's a good idea to have moderators using alt-accounts clearly labeled as such to dissociate. And I'm fine too if they wish to be pseudonymous, as long as the permissions right are attached to a persistent profile, and not a completely unrelated profile that contributors have never seen technically contributing to the bitcoin core project before.

edited: corrected some english pronouns misusage.