Subject: Re: [bitcoindev] [meta] moving conceptual discussion for policy changes

From: Sjors Provoost <[email-masked]>
Date: Wed, 30 Apr 2025 17:49:49 +0200

I think it's worth trying, but I don't think it's going to work.

There's always going to be people who deliberately link directly to a pull request with the goal of wreaking havoc.

It could just be normal online impulsive behaviour*, similar to road rage. Someone might first comment on the PR, but feels insufficient heard there. This (briefly) makes them angry and they want to share this frustration. The social media algorithm does the rest. By the time you cool down, the damage is done.

But it can also be done by people who know exactly how this stuff works.

> Op 30 apr 2025, om 16:30 heeft 'Matthew Zipkin' via Bitcoin Development Mailing List <[email-masked]> het volgende geschreven:
> 
> The comment brigade on the OPRETURN pull requests has gotten out of hand and I think we should consider adding a new process step for policy changes.

That said, people with good intentions should be given every opportunity to voice their concerns in a non-destructive way. It's fair to say that the mailinglist can be a high bar, especially if the social media link takes you to Github. Seeing your comment be moderated without a simple and immediate alternative can lead to extra frustration, it's good if we can prevent that. Since the mailinglist also has a moderation delay, this could add extra fuel to the frustration.

> What I think we need is a second step between the mailing list and the pull request. GitHub "discussions" are probably the best format for this, either in bitcoin-core/meta or bitcoin/bitcoin. 
> 
> Taking a hint from Russ' comment in /meta#18, the discussion could be opened with position statements listing all the pro's and con's and most importantly, FAQs and busting myths like "bigger opreturns make it harder to run a full node".

If someone volunteers to write this, that's fine of course. But we should not set this as an expectation. The normal process is to propose on the mailing list and then implement in Bitcoin Core, which this PR followed.

Perhaps a simpler rule of thumb would be to leave at least two weeks between the mailinglist post and the actual PR. Or a maintainer can mark it as draft with a do-not-merge-before note. That way people don't perceiving the change as a surprise attack.

Additionally, the top of such a PR could say when the Bitcoin Core release is expected (late 2025!), and that changes can be reverted until then - if new convincing arguments are brought up. 

- Sjors

* = which I'm not immune to

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2294D284-77C1-4885-9585-E591FEE4878A%40sprovoost.nl.