Bitcoin Core maintainers and communication on merge decisions



Summary:

Communication challenges in Bitcoin Core have been a problem for the entire history of the project. While some maintainers, like previous maintainer Wladimir, were extremely responsive on IRC, others are unresponsive and refuse to discuss merge decisions. Poor communication, which creates problems as much as it solves, is not the only way to prevent contentious pull request situations. Two recent examples include the Pull Request to add Vasil Dimov as a maintainer, where despite many ACKs from other maintainers and long-term contributors, two maintainers refused to discuss it on the PR or on IRC, and the CTV Pull Request that ultimately led to a contentious soft fork activation attempt that was called off at the last minute. Maintainers should be free to avoid involvement in a pull request, but as long as a subset of maintainers have an opinion on the pull request, things should be fine. Although poor communication skills, a desire to avoid accountability, fear of unreasonable legal action, and heated debates that go off-topic may contribute to this behavior. However, maintaining a pull request for a long period of time without any commentary is frustrating for a pull request author. A perceived lack of transparency and accountability around merge/non-merge decisions may result in investing more heavily (time and resources) in consensus compatible forks of Core and treating Core like it is a proprietary "open source" project where merge decisions are not explained or justified in the open. 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. If Bitcoin Core maintains poor communication, it can hardly expect it to be better on bitcoin-inquisition/default signet where there is no real monetary value at stake. A custom signet, maintained differently, with more reviews, testing, and regular updates, can kill this perception. Though some maintainers may be unresponsive, some long-term observers of the Core repo would have known that a pull request wasn't ready to merge or attempt to activate, especially given it was a consensus change. While it is unfair to expect every human to behave similarly, each pull request does not necessarily require commentary for merging with enough reviews, ACKs, and no controversy. Honest opinions are not wrong to share if someone agrees with the concept, but it does not make a pull request ready to get merged. The utxos.org site is an external site maintained by Jeremy with opinions on BIP 119. Everyone is free to maintain such lists.


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