Skip Navigation
Linux @lemmy.ml
lemmyreader @lemmy.ml

Much ado about "nothing" - Xe Iaso (==Goodbye NixOS)

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 : 

 undefined
        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

You're viewing a single thread.

83 comments

  • I didn't understand a thing about what the actual issues were.

    Based on comments I can see that Jon Ringer objected to inserting gender minority person as a requirement for committee board.

    So, why is he wrong? I totally agree that gender minorities deserve recognition, but making it a hard requirement for having a committee board sounds like nepotism.

    • This is a basic represention and inclusion issue. Unless you are actively seeking out voices of those minorities and addressing their concerns you will have a reinforcing loop where behaviour that puts people off engaging will continue and it will continue to limit people from those minorities being involved (and in the worst case causing active harm to some people who end getting involved). From what I understand the behaviour that has been demonstrated and from who those people leaving it is clear this is active issue within Nix. Having a diverse range of people and perspectives will actually make the outputs (software) and community generally better. It's about recognising the problems in the formal and informal structures you are creating and working to address them.

      Additionally, but just to clarify nepotism would be giving positions based on relationships with people in power and not ensuring that your board contains a more representative set of backgrounds and perspectives.

      • Suppose I have 1000 people from community and 10 out of them are gender minorities. I then have 5 projects, each with 10 members on board committee, and I want a representative of gender minority in each of them. And I choose hard workers based on merit, the best of the best.

        In such case I will be choosing 95 = 45 people out of 1000, and specifically I add 15 = 5 people out of those 10.

        So the board committees will have 45 members each with (worst case) 955/1000 = 95.5% percentile performance, and additionally 5 members of gender minorities, each with mediocre 5/10 = 50% performance.

        The gender minorities will perform worse, because we specifically singled them out of the crowd. This is not how you improve diversity.

        • Others have replied pointing out this is a strawman and that merit doesn't make any sense as a metric if you have discrimination. In practice performance ('merit') is complex interaction between an individual's skills and talent and the environment and support they get to thrive. If you have an environment that structurally and openly discriminates against a certain subclass of people and then chose on "merit" you are just further entrenching that discrimination.

          This is a project that seemed to be having specific problems on gender that was causing harm and leading to losing talent. In a voluntary role particularly this is a death spiral for the project as a whole. Without goodwill and passion open source projects of any meaningful size just wouldn't survive.

          I'm glad you care enough about diversity and evidence to have worked out how to solve these problems without empowering and listening to those minorities. Please do share it.

          • Others have replied pointing out this is a strawman and that merit doesn’t make any sense as a metric if you have discrimination.

            So remove discrimination. Put in the CoC that any information about gender, race, religion and so on must not be disclosed since it is not relevant to the quality of the code/work you submit. Then you have merit only.

            I really find stupid that someone really think that his contribution must be accepted just because he is from a minority, irregardless the quality.

            • You say remove discrimination and then use a discriminatory strawman. No one is suggesting a code contribution must be accepted based on a minority status. They are saying that to get a decent functioning community for everyone you need a diverse range of people in positions that set the behaviour of the community. You can't get the CoC and enforcement of it right unless those affected are in positions that influence it. Your enforced anonymity doesn't work because there are other ways of gendering and racialising people (e.g. based on who people talk). Additionally, what you are saying is that minoritised people have to hide who they are so they don't get discriminated against rather than just deal with those doing the discrimination. They are called communities because that's what's they are: people want to be part of something and that involves sharing a part of themselves too. Open source projects live or die on their communities because they mostly don't have the finances to just pay people to do the work. You need people to beleive in the project and not burn out etc.

              You lose nothing by making sure people from all backgrounds have the same opportunity and enjoyment being part of it. If you aren't in a minority and don't care about those that are then just say so!

              • You say remove discrimination and then use a discriminatory strawman.

                Why ? Because I basically say "keep these personal informations for yourself since they are not needed while developing" ?

                No one is suggesting a code contribution must be accepted based on a minority status.

                But they are saying that a board member should be elected based on the fact that he came from a minority, which is as wrong as asking that a code contribution should be accepted based on the minority status.

                They are saying that to get a decent functioning community for everyone you need a diverse range of people in positions that set the behaviour of the community.

                Agree on this. My point though is that the people in these positions need to be there for the merit and not for a status.

                You can’t get the CoC and enforcement of it right unless those affected are in positions that influence it.

                Nope. You can enforce a CoC if the ones delegated to enforce it are acknowledged as authoritative people and there is a clear path to do it. If you put a person in charge to enforce the code "just becasue [insert your favorite minority reason]" you end in the same place: the CoC will be selectively enforced only on a certain group of people.

                Your enforced anonymity doesn’t work because there are other ways of gendering and racialising people (e.g. based on who people talk).

                Assuming you track them outside the project, yes you are right.

                Additionally, what you are saying is that minoritised people have to hide who they are so they don’t get discriminated against rather than just deal with those doing the discrimination.

                That is what you are saying now, not me.
                I said that I don't care about what your identity is but only about the quality of your work, why did you assume that i mean that only the minorities should not disclose these informations ?

                Else explain to me why it is relevant that the pull request just created is done by someone from a minority group.

                You lose nothing by making sure people from all backgrounds have the same opportunity and enjoyment being part of it.

                Equal opportunity does not mean equal outcome. I lose something if a board member of the project I contribute is elected only because he is from a minority group because he replace a more knowledgeable member and the average quality of the work decline.

                If you aren’t in a minority and don’t care about those that are then just say so!

                It is not that I don't care, it is that in certain situation it not pertinent if you are from a minority or not. Software development, particularly OSS where the entry point is really low, is one of this situation: why I should care about the group you are part of when you submit a contribute ? How it is pertinent. Do you want to have a voice in the project ? Earn it by contributing and being better of the ones you think are bad and or toxic. But wanting to have a say in the project "just because" is toxic too.

                • There are two tensions here:

                  1. Community building
                  2. 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.

                  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.

                  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.

                  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.

                  In our example with NixOS, asking for someone from the community to be a representative on it is not about code quality, but about the issue of visibility. Is there some need that that section of the community needs? Is there a way that the community can do y thing to make the os as a whole more accessible? I don't know the answer, because I'm not a member of that community, just as I'm not a member of the deaf community.

                  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

                  The debate for CoC is about merit, but merit isn't just stubbornly focused on a single talent, it can also be about life experience.

                  • 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.

              • It is impossible to satisfy all minorities at once. The best outcome is to pick an adequate, sane person from the community with proper mindset and proper judgement, irrelevant if they're from a minority or not.

            • I think you are right here. By cherry-picking gender minorities we sow a dissent and we underline their "otherness" from everyone else.

              I am from an ethnic minority myself, and somehow people perceive us as maniacs and killers, try to burn our houses and fire us from work. Often it's the same people who preach equality and diversity. Somehow in my case they don't care about "empowerment" or "representation" at all. And somehow, the only place I feel comfortable is 4chan, where no one gives a damn who you are, and everyone's racist and sexist. To everyone else. Equally.

        • DEI requirements is not nepotism, but let's take on the core issue I think you brought up: meritocracy. If you show me two people with the same level of skill and experience, I would say the one that came from the most disadvantaged environment is more qualified because they were able to get to the same level with less support.

          But you brought in numbers, let me do the same. L Consider that the minority group you mentioned actually has greater barriers to participate, so those 10 people might actually perform better than 80% of the 1000 of the majority group. Assuming both groups have the same distribution of merit is a fallacy.

        • i'd like to see how you'd be measuring "performance" in this context, or what you consider to be worthy of merit, because those things are not the objective measures you seem to think they are.

          people who are contributing to open source projects are not a perfect Gaussian distribution of best to worst "performance" you can just pluck the highest percentile contributors from. its a complex web of passionate humans who are more or less engaged with the project, having a range of overlapping skillsets, personalities, passions, and goals that all might affect their utility and opinions in a decision making context. projects aren't equations you plug the "best people" into to achieve the optimal results, they're collaborative efforts subject to complex limitations and the personal goals of each contributor, whose outcome relies heavily on the perspectives of the people running the project. the idea you can objectively sort, identify, and recruit the 50 "best people" to manage a project is a fantasy, and a naive one.

          the point of mandating the inclusion of minority groups in decision making is to make it more likely your project and community will be inclusive to that group of people. the skillsets, passions, and goals that a diverse committee contains are more likely to create a project that is useful and welcoming to more kinds of people, and a committee that is not diverse is less likely to do so. stuff like this is how you improve diversity. in fact, its quite hard to do it any other way.

        • Hold up, let me just make up some numbers real quick to prove how wrong you are!

83 comments