Bitcoin Core maintainers and communication on merge decisions

Summary:

Communication has been a challenge on Bitcoin Core for the entire history of the project, with maintainers merging pull requests without providing commentary on why they have merged them, or leaving pull requests with many ACKs and few (if any) NACKs for months without providing any commentary on why they haven't merged them. The lack of communication creates problems for pull request authors, especially when their pull request is stuck in "rebase hell." Poor non-existent communication is not the only way to prevent harmful or bug-ridden pull requests from being merged, and it creates as many problems as it solves. The difference between previous maintainers like Wladimir and some of the current maintainers is that previous maintainers were extremely responsive on IRC and would discuss merge decisions if there was disagreement. However, at present, a subset of current maintainers are not responsive on IRC and will refuse to discuss a merge decision. Recent examples include the pull request to add Vasil Dimov as a maintainer and the CTV pull request that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. Maintainers and long-term contributors were gently enthusiastic (Concept ACKing etc.) without ACKing that the CTV pull request was ready to merge, with only three individuals NACKing the pull request. Many casual observers inflated the numbers on the utxos.org site signalling support for a soft fork activation attempt. The author originally intended to write about the controls and processes around merges on the default signet but realized that if communication around Core merges/non-merges is weak, it can hardly be expected to be any better on bitcoin-inquisition/default signet. The author believes that the perception that bitcoin-inquisition/default signet is "the one and only" staging ground for consensus changes is dangerous if the maintainer(s) on that project have the same inclinations as a subset of the Core maintainers. The lack of transparency and accountability around merge decisions is not individual(s)-specific, and there is an adverse reaction to outright malicious actors external to any of these projects. The author suggests that taking transparency and accountability more seriously or investing more heavily (time and resources) in consensus-compatible forks of Core and treating Core like a proprietary "open source" project where merge decisions are not explained or justified in the open are possible solutions.

Updated on: 2023-06-16T17:29:13.716756+00:00