[meta] moving conceptual discussion for policy changes
97 views
Skip to first unread message
Matthew Zipkin
Apr 30, 2025, 11:03:29 AMApr 30
to bitco...@googlegroups.com
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. The problem is that many users are not participating in the mailing list discussion and so the first time they hear about a policy change is on twitter, where it may feel like it is too late to do anything about it, and users feel disenfranchised. The result is a brigade of comments that are fast, poorly thought out, uninformed, and repetitive.
It might still be possible to try this for OPRETURN policy or if not, I'd really like to try this the next time a policy change or other controversial code change comes up -- anything where "concept ACK" is not a sufficient technical pull request review comment:
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".
The discussion should actually probably have a click bait title, so the link burns through twitter like wildfire. The whole point is to attract community members to a source of INFORMATION.
And then, after a weekend when the social media storm has rolled over, a nice quiet mature pull request review might be possible.
Sjors Provoost
Apr 30, 2025, 11:52:46 AMApr 30
to bitco...@googlegroups.com, Matthew Zipkin
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 <bitco...@googlegroups.com> 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
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 <bitco...@googlegroups.com> 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.
> 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".
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
Reply all
Reply to author
Forward
0 new messages