Much ado about "nothing" - Xe Iaso
xeiaso.net

https://discourse.nixos.org/t/much-ado-about-nothing/44236

Not directly related to this blog post but from NixOS discourse forum, a tl;dr from another person about the NixOS drama here :

If you’re looking for a TL;DR of the situation, here it is:

    Nix community had a governance crisis for years. While there has been progress on building explicit teams to govern the project, it continued to fundamentally rely on implicit authority and soft power

    Eelco Dolstra, as one of the biggest holders of this implicit authority and soft power, has continuously abused this authority to push his decisions, and to block decisions that he doesn’t like

    Crucially, he also used his implicit authority to block any progress on solving this governance crisis and establishing systems with explicit authority

    This has led uncountably many people to burn out over the issue, and culminated in writing an open letter to have Eelco resign from all formal positions in the project and take a 6 month break from any involvement in the community

    Eelco wrote a response that largely dismisses the issues brought up, and advertises his company’s community as a substitute for Nix community
  • gian @lemmy.grys.itEnglish
    1·
    7 months ago

    There are two tensions here:

    Community building Code production

    Community building can be done without any coding, coding can be done without any community. However, to build a large project you need them both.

    We agree on that.

    In a large volunteer project like this, not everything can be worked on. You become selective. We are going to major on this thing, or specifically talk about that project to get community engagement and get the thing done. This drives the project, she helps it to stop chasing hairs. Someone has to decide what feature is going in this release to make it ready to be a release candidate.

    That group of people, ultimately making and influencing those decisions, is the CoC.

    Nope.
    CoC mean “Code of Conduct”. It dictates how the interperpersonal relations should be in the community, not the direction the project need to follow. Which means that if you make a request I should not answer with “fuck your request” but with some more appropriate “we have not the manpower/motivation/infrastructure/whatever reason to do it, but feel free to do it yourself and submit it for review” answer (that’s of course is a simple example, bear with me in this case) if I am not interested in your request or there are some real limitations.

    Let’s take a for-instance: Sign up boxes.

    For years, Linux sign up allows you to record random data into your profile, office, phone number, etc. These are text, and can be anything. Now, what if there’s a rising need to add a minicom number(minix, used to be used by the deaf to send messages to an organisation, before email). As a hearing person, this is going to be a low priority for me, so I work on something else. I’ve got spare capacity, so if the project leaders are calling for help on this thing, I can go and help.

    True, but if you think that it is the CoC that produce this result, you are way wrong.
    What produce this result is that people are willing to work on a feature even if they don’t need it and if there is enough request for that feature. If you are the only one person who ask for a feature you will get low priority even if you are deaf (just to keep up with your example).
    What do you think you can do if I don’t want to work on your feature ? Use the CoC to compel me to do the work ? Do you think you can threaten me with a ban from the project ? Try it and you lose one developer (and probably others).

    This, ultimately, builds a better over-all product, but it’s not something I’d have noticed by myself, because I’m not part of the deaf community.

    True, but it is simply the fact that the developers lowered the barrier to make a request on one side and on the other side someone made a good and motivated request.
    The point is that this has nothing to do with the fact that a deaf person is in a leadership position.

    In this case, the merit, the qualification, for being on the CoC is being a member of a section of the community. It brings valuable a viewpoint, and adds a voice at the table that can make a real difference. Most coders know that having a wish list of features at the start can make it infinitely easier to add them, than having to go back an rewrite to make them happen. Having a voice that might need that feature makes a difference

    Again, what you are asking for is to have a way to communicate with the developers and possibly a clear way that indicate how a request is handled.

    But having a way for the community to communicate with the developers and the leadership of the project is not the same as having a CoC that mandate that the leadership must include members from minorities.

    But in the end we are debating about nothing, the project was forked so I suppose that we just need to wait to see how it will end.