Hi Michael, I will share something even though you didn't let me write things on several occasions on github, twitter etc.
Try this: - As Gloria said (respect people you don't like and shared something against), create a competition for Brink. Fund bitcoin developers. - Do more reviews personally and devs you train even if they are neglected. - Acknowledge some reviewer know more than you. Try to learn and test things. - After some time you will achieve the power you crave. Its not possible to satisfy everyone even if you were bitcoin core maintainer now, some people would have issues. Closing a pull request hurt more so I respect them if they kept open something. Note: Do not disrespect people who are new and say something. Do not try to harass them. Do not try to be boss. /dev/fd0 floppy disk guy Sent with Proton Mail secure email. ------- Original Message ------- On Wednesday, April 19th, 2023 at 7:03 PM, Michael Folkson <michaelfolk...@protonmail.com> wrote: > Hi alicexbt > > > I don't think commentary is required for each pull request that gets merged > > with enough reviews, ACKs and no controversy. > > > The problem is defining what is "enough". "Enough" is determined by the > quality of the review, the expertise of the reviewer(s), the complexity of > the pull request and most importantly what risks a merge of the pull request > poses. When there is zero communication on merge decisions (both merging and > not merging over a long period of time) it creates frustration and worse > vacuums and soft fork activation chaos. It is a complete black box. The vast > majority of merge decisions are uncontroversial but it would still be nice to > have a comment saying something like: > > "This pull request only has 2 ACKs but it is low risk, relatively simple and > is unlikely to be reviewed by anybody else in the near term" > > "This pull request is a consensus change, extremely high risk and is unlikely > to be merged in the near term" > > On the rare occasions when merge decisions are controversial communication > becomes a lot more important. If some maintainers aren't responsive on IRC > and refuse to discuss merge decisions what can we expect in future? We wake > up one day, a contentious consensus change has been merged with little review > in advance of a release window and the maintainer won't discuss why they have > merged it. This isn't a toy anymore, it is supporting hundreds of billions of > dollars of value and could end up supporting a lot more. It is surely > completely unreasonable to let maintainers merge or not merge whatever they > like with no explanation and no willingness to discuss their merge decisions. > > > So I'll add that if you wish to have more decentralization in Bitcoin Core > > funding, you can start by creating a nonprofit, gathering donations, and > > funding somebody who works on Bitcoin Core." > > > As I responded on the pull request if any long term contributor from this > alternative nonprofit is blocked from being a maintainer and current > maintainers refuse to discuss merge decisions it is irrelevant. To contribute > you need a maintainer to merge your pull request(s) and to spend your review > time wisely you need to know what pull request(s) could viably be merged by a > maintainer. Otherwise you're just wasting your time. We not only have opacity > on merge decisions for normal pull requests (e.g. code) we also now have > opacity on decisions for the addition of new maintainers. I was always under > the impression that any long term contributor who demonstrated over time that > they were sufficiently competent, qualified and able to contribute both > through opening pull requests and reviewing other people's pull requests > could become a maintainer. To me and many others (until it was blocked by two > maintainers for 5 months) Vasil met this criteria. This not only impacts > Vasil's and others' commitment to the project but it impacts what pull > requests are ultimately reviewed and merged. What is the point of spending > time opening or reviewing a pull request if the current maintainers won't > look at it or are unqualified to review it and hence won't merge it? > > Gloria's advice effectively boils down to spend months setting up a > non-profit, spend years becoming a long term contributor to the project and > then you can have the honor of being blocked from becoming a maintainer and > have your contributions stunted by the current maintainers with no recourse > or ability to discuss their merge decisions. So yeah thanks for repeating > that advice but I'm sure most would rather pass and do something else. > > Thanks > Michael > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > > ------- Original Message ------- > On Wednesday, April 19th, 2023 at 13:24, alicexbt alice...@protonmail.com > wrote: > > > > > Hi Michael, > > > > I was initially sad about the politics in Vasil's pull request, written > > about it and also tried to document the process. Still think he deserves to > > be a maintainer. Although I have some counter arguments: > > > > > Maintainers merge a pull request and provide no commentary on why they’ve > > > merged it. > > > > I don't think commentary is required for each pull request that gets merged > > with enough reviews, ACKs and no controversy. > > > > > Maintainers leave a pull request with many ACKs and few (if any) NACKs > > > for months and provide no commentary on why they haven't merged it > > > > This could be considered normal in pull requests that involve code changes. > > > > > The difference between say previous maintainers like Wladimir and some of > > > the current maintainers is that previous maintainers were extremely > > > responsive on IRC. > > > > Unfair to expect every human to behave the same or work similarly. > > Sometimes the unresponsiveness could be to avoid controversies and heated > > debates that go off-topic. > > > > > One farcical recent example 0 was the pull request to add Vasil Dimov as > > > a maintainer where despite many ACKs from other maintainers and other > > > long term contributors two maintainers (fanquake and Gloria) refused to > > > discuss it on the pull request or on IRC. It took almost 5 months for > > > Gloria to comment on the pull request despite many requests from me on > > > the PR and on IRC. I even requested that they attend the weekly Core Dev > > > IRC meeting to discuss it which they didn’t attend. > > > > - Maintainers should be free to avoid involvement in a pull request. As > > long as a subset of maintainers have an opinion on the pull request, things > > should be fine. > > - I agree with Gloria's comment: "I had not NACKed this either because my > > opinion could change over time, NACKs are sometimes needlessly interpreted > > as personal attacks, and Brink has been antagonized on Twitter each time > > multiple grantees have similar opinions about this. So I'll add that if you > > wish to have more decentralization in Bitcoin Core funding, you can start > > by creating a nonprofit, gathering donations, and funding somebody who > > works on Bitcoin Core." Last part of this comment also solves the problem > > shared in other thread related to new bitcoin implementation. Brink needs > > some competition and bitcoin core needs more reviewers. > > - I also agree with Andrew's comment: "frankly, I think opinions aren't > > being shared because of potential backlash from aggressive users such as > > yourself and bytes1440000" > > > > > Maintainers and long term contributors (if they commented at all) were > > > gently enthusiastic (Concept ACKing etc) without ACKing that it was ready > > > to merge. A long term observer of the Core repo would have known that it > > > wasn’t ready to merge or ready to attempt to activate (especially given > > > it was a consensus change) but a casual observer would have only seen > > > Concept ACKs and ACKs with 3 stray NACKs. Many of these casual observers > > > inflated the numbers on the utxos.org site 4 signalling support for a > > > soft fork activation attempt. > > > > - I don't see anything wrong with sharing honest opinion if someone agrees > > with the concept. It does not make a pull request ready to get merged. > > - utxos.org is an external site maintained by Jeremy with opinions on BIP > > 119. Everyone is free to maintain such lists and I think you had also > > created one as GitHub gist. > > > > > I will probably write about bitcoin-inquisition/default signet in a > > > future email as I do think the perception that it is “the one and only” > > > staging ground for consensus changes is dangerous 6 if the maintainer(s) > > > on that project have the same inclinations as a subset of the Core > > > maintainers. > > > > This perception (if exists) can be killed by creating a custom signet, > > maintaining it differently, get more reviews, testing and share details > > with community regularly. > > > > /dev/fd0 > > floppy disk guy > > > > 0: https://github.com/bitcoin/bitcoin/pull/25871#issuecomment-1381654564 > > 1: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2023-01-12#883748 > > > > Sent with Proton Mail secure email. > > > > ------- Original Message ------- > > On Tuesday, April 18th, 2023 at 6:10 PM, Michael Folkson via bitcoin-dev > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > Communication has been a challenge on Bitcoin Core for what I can tell > > > the entire history of the project. Maintainers merge a pull request and > > > provide no commentary on why they’ve merged it. Maintainers leave a pull > > > request with many ACKs and few (if any) NACKs for months and provide no > > > commentary on why they haven't merged it. I can only speculate on why and > > > it probably depends on the individual maintainer. Sometimes it will be > > > poor communication skills, sometimes it will be a desire to avoid > > > accountability, sometimes it will be fear of unreasonable and spiteful > > > legal action if they mistakenly merge a pull request that ends up > > > containing a bug. But search through the pull requests on Bitcoin Core > > > and you will rarely see a rationale for a merge decision. The difference > > > between say previous maintainers like Wladimir and some of the current > > > maintainers is that previous maintainers were extremely responsive on > > > IRC. If you disagreed with a merge decision or thought it had been merged > > > prematurely they would be happy to discuss it on IRC. In present times at > > > least a subset of the current maintainers are not responsive on IRC and > > > will refuse to discuss a merge decision. One farcical recent example 0 > > > was the pull request to add Vasil Dimov as a maintainer where despite > > > many ACKs from other maintainers and other long term contributors two > > > maintainers (fanquake and Gloria) refused to discuss it on the pull > > > request or on IRC. It took almost 5 months for Gloria to comment on the > > > pull request despite many requests from me on the PR and on IRC. I even > > > requested that they attend the weekly Core Dev IRC meeting to discuss it > > > which they didn’t attend. > > > > > > A pull request to add a maintainer isn’t a normal pull request. Generally > > > pull requests contain a lot more lines of code than a single line adding > > > a trusted key. Not merging a pull request for a long period of time can > > > be extremely frustrating for a pull request author especially when > > > maintainers and long term contributors don’t comment on the pull request > > > and the pull request is stuck in “rebase hell”. Clearly it is the lesser > > > evil when compared to merging a harmful or bug ridden pull request but > > > poor non-existent communication is not the only way to prevent this. > > > Indeed it creates as many problems as it solves. > > > > > > Another farcical recent(ish) example was the CTV pull request 1 that > > > ultimately led to a contentious soft fork activation attempt that was > > > called off at the last minute. If you look at the comments on the pull > > > request there were 3 individuals (including myself) who NACKed the pull > > > request and I think it is fair to say that none of us would be considered > > > long term contributors to Bitcoin Core. I have criticised Jeremy Rubin > > > multiple times for continuing to pursue a soft fork activation attempt > > > when it was clear it was contentious 3 but if you look at the pull > > > request comments it certainly isn’t clear it was. Maintainers and long > > > term contributors (if they commented at all) were gently enthusiastic > > > (Concept ACKing etc) without ACKing that it was ready to merge. A long > > > term observer of the Core repo would have known that it wasn’t ready to > > > merge or ready to attempt to activate (especially given it was a > > > consensus change) but a casual observer would have only seen Concept ACKs > > > and ACKs with 3 stray NACKs. Many of these casual observers inflated the > > > numbers on the utxos.org site 4 signalling support for a soft fork > > > activation attempt. > > > > > > I set out originally to write about the controls and processes around > > > merges on the default signet (bitcoin-inquisition 5) but it quickly > > > became obvious to me that if communication around Core merges/non-merges > > > is this weak you can hardly expect it to be any better on > > > bitcoin-inquisition/default signet where there is no real monetary value > > > at stake. I will probably write about bitcoin-inquisition/default signet > > > in a future email as I do think the perception that it is “the one and > > > only” staging ground for consensus changes is dangerous 6 if the > > > maintainer(s) on that project have the same inclinations as a subset of > > > the Core maintainers. > > > > > > As I stated at the beginning there is an element to this which is not > > > individual(s) specific and an adverse reaction to outright malicious > > > actors external to any of these projects. I do not think any of the > > > current maintainers on Core or bitcoin-inquisition are outright malicious > > > even if a subset of them consistently frustrate me with their lack of > > > transparency and accountability. But this issue isn't going away and I'm > > > sure we'll hear more on this from others in the coming months. To me it > > > is a straight choice of taking transparency and accountability much more > > > seriously or failing that 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. > > > > > > -- > > > Michael Folkson > > > Email: michaelfolkson at protonmail.com > > > Keybase: michaelfolkson > > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
