Participating in the Corepack-vs-npm debate/attending meetings #613
Description
Hello PWMG group (what does PWMG stand for?),
I am a developer with some time to spare and I am considering donating some of my time to participate in the ongoing debate regarding Corepack and npm. By this I mean, attending meetings, asking questions, taking notes and helping guide the conversation and keeping it informed by the points of view of the community and users of the technologies involved.
In order to make it easier for you to decide if I can be effective in this role, you might want to check something I wrote here, in which voiced my aspiration for a better decision-making process. I will quote my post here for convenience:
A little disclaimer: I am one of those with 0 involvement in the project. I am a developer and a long-term user of Node.js, and that is about it. However, I still think that an outsider's point of view can be helpful, especially when at a higher-level.
@joyeecheung you are absolutely right (here) in that it is difficult for people like me (who are effected by the decisions you guys make) to follow the conversation and meaningfully contribute to it. There is just too much noise and also the feeling that my points of view is never going to be informed enough for it to be worth voicing or sharing.
One of the main issues I can see in the case of the Corepack-vs-npm debate, is the conversational format for knowledge management throughout the decision-making process, which is very inefficient and makes it harder to follow along by enough people if the large solution space is to be sufficiently explored, and the needs of most users adequately met. It also makes it harder to make people accountable after months of debate.
A living-document is a much better format, for example, which is provided in the case of the much less controversial goals.
The goals are clear and take a few second to read and understand. I do not think anyone would disagree with them, yet, the governance process around them seems prone to leading to "agreements" that do not meet them well. This same observation has been meme'd as "how one asking for turning Corepack on by default led to a decision to de-bunde Corepack from NodeJS". It is not a criticism of the decision made, as much it is a criticism of the decision-making process.
@ovflowd I think you are mistaking voting systems in general with the social-media-inspired style of voting. Emojis (likes and dislikes) are not the only way to carry voting. However, you are absolutely right if what you mean is that voting exclusively with a "yes" or a "no" is unproductive and leads to suboptimal agreements.
But this not the only way to conduct voting, both synchronously (during a video meeting) or asynchronously (on a platform like Loomio). For example, check these hand signals developed by seedforchange, they present a very interesting approach and a tested alternative to the yes-or-no approach to voting.
The problem with voting using yes'es and no's is that some votes, coming from meritocratic leaders which carry so much weight get equated with votes from people with no merits, and no involvement, leading to incoherent and destructive decisions. Loomio, the platform I mentioned, offers a variety of tools to assess and prep for consensus, as well as offering seedforchange-style responses to consensus calls, as shown below:
Before attempting a consensus call, it is likely a good idea to carry what Loomio calls a sense-check, which has a different (but a well though out) set of responses as shown below:
In the case of a consensus call, and unliked a yes-or-no approach, people can step aside, agree, request changes to agree, admit to not knowing enough to give a meaningful vote, or block the change, which is an important instrument. Blocking allows people to impede decisions by offering compelling argument as to how these decisions work against the stated goals.
A tool like Loomio can create visibility to the decision making process in a more-efficient, living-document format. Conversations are still possible, but only to the end of providing a summary for later sense-checking and consensus calls.
This will allow everyone in the community to participate meaningfully without having to go through long pages of dialogue, which I think is important.
The reason I am compelled to writing this is because to me, NodeJS is different than most software projects in the sense that it always has been prototypical in nature and relied heavily on the community, with a price to pay, which is that it always had many issues and edge cases as a result, yet, it had been quite unique in how inclusive it had been to everyone's input. It invited and relied on contributions like no other project. This understandably can lead to novel governance challenges.
I do not think that I will say anything more because I feel a lot of responsibility not adding to the existing noise, but I thought this was worth sharing.
An important note here is that I am not associated with either seedforchange or the Loomio open-source platform, which were only used as examples of better governance processes that are worth taking a look at.
If you think someone like myself with the ideas above can serve a role in this particular discussion, then I would like to attend the meetings and educate myself more in order to figure out a way to be effective.
If you think that the discussion is saturated and the participation of and outsider with many questions might be counter productive, then I can take my efforts to make the world a better place elsewhere.
Please let me know what you think.
Activity