i agree 100%. effective communication is challenging, especially in an environment like this. that being said, alicexbt is probably right that we - probably need a well written spec, RFC-style perhaps - need more anon or nym maintainers where the online reputation isn't trivially linked to real-world reputation - github should be replaced with something p2p (maybe move to https://radicle.xyz/) meta-stuff like that is probably just as important as picking the next cool covenant opcode to ignore On Thu, May 11, 2023 at 2:06 PM Steve Lee via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't see any reason to be antagonistic in your responses. > > One piece of advice I'd offer to you and Michael is to consider whether > your responses are effective. To persuade other people it takes more than > making good points or being right, but you need to find a communication > style and communication path that is effective. My observation is that your > styles need reflection. > > > On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi Andrew, >> >> We can take a look at how previous maintainers were added to see how this >> has played out in the past. >> >> >> Can we learn something from past? >> >> Bitcoin's initial release was in 2009 with one developer and few others >> experimenting with it. It is considered decentralized in 2023 however we >> have 99% of nodes using bitcoin core, 5 developers deciding what's merged >> or not and this includes some trying to implement their ideas without soft >> fork using mempool policies. >> >> We need better process to add maintainers. I am disappointed with the way >> last last pull request was merged. It says more about maintainers and >> leader Michael Ford. If you are so scared about opinions on a pull request >> why not just make him maintainer without pull request? >> >> Maybe you will understand this if your PR to add maintainer was kept open >> for 4 months. >> >> /dev/fd0 >> floppy disk >> >> >> Sent with Proton Mail secure email. >> >> ------- Original Message ------- >> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote: >> >> >> The decision process for adding a new maintainer was according to the IRC >> meeting that the maintainers decided privately there was a need for a >> maintainer “who understood our interfaces and modularization efforts well” >> and that ryanofsky was a “good fit for that”. I don’t know whether this was >> decided in a private IRC channel or was decided at the recent in person >> Core Dev meeting. Regardless, many have had no input into the discussion on >> what kind of maintainer the project needs going forward and it seems the >> maintainers do not want to discuss that aspect of the decision. >> >> Since the project began, the decision to seek out and then add a >> maintainer has always been made by existing maintainers. When the >> maintainers feel that there is a need for additional maintainers, they may >> have an open call for volunteers, or may have a candidate already in mind >> and suggest that specific person for maintainership. Contributors generally >> are not consulted in the decision to seek a new maintainer as they would >> not know whether there are things that are being overlooked or that there >> is maintainership load that needs to be distributed. Even so, it wouldn't >> be appropriate to add a maintainer if many contributors disagreed with it, >> just as with any other PR. >> >> We can take a look at how previous maintainers were added to see how this >> has played out in the past. I think our modern concept of maintainers with >> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and >> Marco Falke were simply announced by Wladimir. There was no public >> discussion, and some IRC logs refer to private emails between the them and >> the current maintainers at that time. After that, meshcollider was added as >> a maintainer after a public "call for maintainers" where a recurring topic >> for a while was finding a maintainer for the wallet. He had volunteered to >> do it by contacting Wladimir privately before it was discussed during an >> IRC meeting and then on Github. Fanquake was added as a maintainer during a >> CoreDev event in Amsterdam during a discussion initiated and led by the >> maintainers. This was also "private" insofar as the discussion was limited >> to those in attendance, although there was some opportunity for public >> discussion in the PR opened on Github. For myself, it was also initially >> private as I messaged Wladimir to volunteer for it after meshcollider >> stepped down. There was some discussion on IRC and on Github, but it was >> also obvious that many already expected me to be the wallet maintainer >> after meshcollider. Hebasto was added with basically no fanfare or >> discussion - the only mention I can find is the PR itself. My understanding >> is that the maintainers asked him he wanted to do it before the PR was >> opened. Glozow was nominated to be a maintainer by some of the current >> maintainers, and her nomination was really the first time that there was >> significant public discussion about it. >> >> Of the past 7 maintainer additions, 5 were nominations/announcements from >> the current maintainers, one was volunteering following an actual "call for >> maintainer", and one was an obvious successor. It's obvious and common >> sense that the maintainers decide when they need help shouldering the load, >> and then find somebody to help them. There was and always will be some >> level of private communication prior to any public announcement of the >> nomination or volunteering of a maintainer. It doesn't make sense to >> blindside somebody with a nomination without talking to them beforehand. >> The fact that most of these were non-controversial speaks to how well the >> maintainers were considering their nominations before publicly announcing >> them. >> >> It's also clear that we have been moving towards more open discussion >> about maintainership and who should be maintainers. The process is >> fundamentally more public than it was previously. We now have public >> discussion with contributors about the merits of a person, even if that >> results in said person not becoming a maintainer. Over time, there's been >> more public participation in the PRs and on IRC meetings when maintainer >> nominations are brought up. We have nominations as topics during meetings >> now when they occur. The PRs to add keys are left open for longer to get >> more discussion. >> >> Ultimately, if you disagree with how the project operates, then you are >> free to leave and start your own fork that is run in a way that you think >> is appropriate. This is open source software, no one is beholden to you, >> and no one is required to do anything. >> >> *** >> >> Since you are intent on discussing and re-litigating the decision about >> Vasil, I will agree that we (the maintainers) could have done a better job >> of communicating. However we stand by the decision that was made in the >> end, and we did have a chat with him about it during CoreDev. >> >> It really boils down to three things: 1) we did not ask for a P2P >> maintainer, 2) some of those who have reviewed Vasil's work expressed >> discomfort with him being a maintainer, and 3) some contributors and >> maintainers were uncomfortable with his responses about how he would merge >> things. You repeatedly insist that it's only the current maintainers who >> blocked Vasil, but that is not the case. There were concerns brought up by >> other contributors that contributed to the decision to ultimately NACK his >> nomination. >> >> One of the justifications for blocking Vasil Dimov as a new maintainer >> despite many initial ACKs from maintainers (including Andrew Chow) and long >> term contributors was according to Andrew [2]: >> >> To be honest, my initial ACK was given without knowing enough >> information. It was given when he was mostly a name that showed up in my >> notification emails, and his work had seemed to be fine with me. At that >> time, I did not think we had a need for a P2P maintainer, but I also did >> not think that having one would be harmful. However I later spoke to a few >> others privately who were more familiar with Vasil's work and they had told >> me that they were not comfortable with Vasil being P2P maintainer. >> >> “Maintainers inherently need to look at the things that everyone else has >> already looked at, if only to give it a final once over before merging (but >> hopefully, an actual review, not just looking it over).” >> >> >> I follow the Bitcoin Core repo pretty closely and I haven’t seen >> ryanofsky do this any more than Vasil does. This is not a criticism of >> ryanofsky, just as I wouldn’t use it as a criticism for Vasil. It would get >> pretty annoying if everyone who wasn’t a maintainer posted an ACK once many >> long term contributors had already ACKed to display supposed “desired >> maintainer traits”. Especially if you are essentially just ACKing that >> others have done the work to review the PR and you just want to get your >> ACK on it to increase your ACK count without doing a fraction of what >> previous reviewers have done. >> >> This opinion was formed not from observing his behavior towards ACK'ing, >> but rather from his responses to questions about reviewing, in addition to >> thoughts shared by other contributors. >> >> From having received plenty of reviews from ryanofsky, I can certainly >> say that his reviews are in depth. He has pointed out subtle bugs, asks >> questions about very low level details, and has well reasoned critiques and >> discussions about design decisions. His reviews are high quality, and he's >> not afraid of being the first person to ACK a pr, the last person to ACK >> it, or the person to prevent one from being merged even when it already has >> a few ACKs. We also had a separate discussion with ryanofsky about his >> approaches to reviewing and merging. >> >> “I also want to mention that the people who have become maintainers in >> the past have had this kind of maintainer attitude towards review prior to >> becoming a maintainer” >> >> >> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again >> not a criticism from me at least) does this mean this was a reason to block >> Vasil but not a reason to block ryanofsky? That seems inconsistent to me. >> >> I don't know why you assume the ryanofsky hasn't had this maintainer >> attitude? Your claim of inconsistency stems from this assumption that >> ryanofsky doesn't have a maintainer attitude, but I would argue that he >> does, as I mentioned above. The idea of adding him as a maintainer has been >> floated around before, although never really seriously proposed until now, >> AFAIK. >> >> When you’re anointed you don’t need to meet requirements but when you’re >> blocked these requirements will be used to block your addition as a new >> maintainer? >> >> It seems obvious to me that when the current maintainers approach and >> nominate a contributor to be a maintainer that that person already meets >> these requirements. I don't know why you would assume bad faith in that >> someone who isn't qualified would be nominated by the current maintainers. >> It's quite frustrating that you seem to just jump straight to the negative >> conclusion rather than considering that there might be actual reasons based >> on the merits of the person. >> >> On a more positive note there does seem to be more energy and momentum >> for collaboration and open communication on the project since I discussed >> communication in a previous post [3]. Hopefully this will continue. It >> doesn’t address my concerns on maintainers and ultimately merge decisions >> but it definitely seems to me to be a step in a positive direction for the >> project. >> >> Don't take credit for what you didn't do. The group-wide effort to move >> towards public discussion again is the result of a discussion that was had >> at CoreDev. Many cited your behavior as a primary reason to stop discussing >> things publicly, with things such as dragging project meta discussions onto >> the mailing list and twitter. These have invited abuse towards maintainers >> and contributors, which in turn makes them takes those discussions to more >> private settings. People feel like they're getting sealioned by you (and a >> few others) when they post publicly, and so they have stopped doing so. >> >> >> Andrew >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >