Slashdot Mirror


One Of LLVM's Top Contributors Quits Development Over Code of Conduct, Outreach Program (phoronix.com)

Rafael Avila de Espindola is the fifth most active contributor to LLVM with more than 4,300 commits since 2006, but now he has decided to part ways with the project. From a report: Rafael posted a rather lengthy mailing list message to fellow LLVM developers today entitled I am leaving llvm. He says the reason for abandoning LLVM development after 12 years is due to changes in the community. In particular, the "social injustice" brought on the organization's new LLVM Code of Conduct and its decision to participate in this year's Outreachy program to encourage women and other minority groups to get involved with free software development. "I am definitely sad to lose Rafael from the LLVM project, but it is critical to the long term health of the project that we preserve an inclusive community. I applaud Rafael for standing by his personal principles, this must have been a hard decision," Chris Lattner, tweeted Thursday.

5 of 1,235 comments (clear)

  1. Re:Outreach by Vapula · · Score: 5, Interesting

    Well what outreach does is nothing but discrimination... and is somehow as bad as other discriminating behaviour...

    and Outreach can backfire... The one hired thanks to Outreach may be felt as inferior who needed to put their "diversity" in front to get a job because he is lacking true skills...

    Outreach is a bad idea...

  2. Re:LLVM code of conduct by Bruce+Perens · · Score: 5, Interesting

    I have recently seen a high-profile community project where a key engineer believed (among other things) women should be shielded and kept at home. This engineer, obviously, had conflicts with people in the organization. Actually maybe about 30 people. Eventually, the membership walked off en mass and founded their own project. The new project has essentially the same code of conduct we're discussing here.

    You need rules on paper for when stuff like this happens. It helps make slippery stuff like who offended who and whether such offense is out of scope for the project a lot easier to decide.

  3. Ubuntu and Python CoC is about as bad by sbrown123 · · Score: 5, Interesting

    They actually have this in their CoC:

    "Our open source community prioritizes marginalized people’s safety over privileged people’s comfort. "

    They follow by saying they condone "reversism's". In other words if you are white male or female you can be openly harassed within the community because you are considered privileged. What the hell has happened to these projects?!

  4. Code of Conduct is a Symptom by JimToo · · Score: 5, Interesting

    The code of conduct doesn't just land from Mars. It's the result of various people in the team agitating for change. The CoC might well be being promoted to give people who have a political agenda, not a coding agenda, the opportunity to gain more control.

    Software rewards a high degree of discipline, a coherent technical approach. It's sometimes necessary to prune code contributions that are rubbish in spite of the fact that this might hurt someone's feelings of self-worth. When this happens its easier to blame another's bias than your own incompetence.

    It would be interesting to know the level of code contribution, and its quality, from the promoters of the CoC.

  5. Re: Meet minimum standards of human behavior by Sarten-X · · Score: 5, Interesting

    The problem is that "disrespect" is based on the perception, rather than the intent, and there's an inherent conflict of interest in a review setting (like in any quality-control process or collaborative effort).

    I'm very passionate about what I do. It's part of what makes me good at what I do, because I actually care about doing a good job, rather than just hitting the magic "40" on my time card and getting a paycheck. I will not hesitate to call out anyone's stupid failures. Mistakes or lack-of-training issues are fine, and we will accept those and move on, but failure due to being inattentive or simply lazy is not acceptable, and anyone failing in such a way needs to be aware that they're not performing up to the standards expected of my team. Frankly, I don't care what gender you are (or aren't), or how old you are, or your socioeconomic status, or really any other factor than whether you do the job. In my opinion, I'm perfectly in compliance with any nondiscrimination policy, because I don't discriminate.

    To someone else's perspective, though, they think I'm complaining because they're black, or Jewish, or young, or blonde, or whatever particular insecurity they want to call out, because they're too inattentive to understand that they were actually doing something wrong.

    The moment discrimination is brought up, especially in an enterprise with a "Code of Conduct" that is venerated above producing quality results, it's no longer a discussion about the right way to actually do the job. It's a discussion about sensitivity, and framing discussion, and having nice polite conversations with 3 HR reps and two managers, at whatever time they can all fit a discussion into their schedules. By the time that discussion takes place, the same failures have been repeated three times, and now there's a quality-control issue that needs to be addressed. Of course, that actual process issue has now become "normal", and any further complaint about the failure is just more "harassment".

    In the end, the person who noticed the original problem is punished, the problem persists, and weeks of effort are wasted on what could have been fixed in five minutes of candid discussion. There have been many cases where this process has itself been abused to attack anyone who dares to complain about someone who is more skilled at gaming the management than actually doing their job.

    As an alternative to a flawed "Code of Conduct", I suggest simply an environment of open failures, along the following lines:

    • If you screw up and you realize it, tell the team.
    • If you see someone else screw up, tell them or the team lead.
    • If you are told you screwed up, you are responsible for finding the document that describes the process.
    • Calling out someone who is, in fact, correct according to the documentation is itself a screwup.
    • Anyone on the team may contribute to the documentation.
    • Every day that you work with this team, you are joining a team. Everyone here is useful in some manner, regardless of whether or not you know what that manner is. You do not have the right to question anyone's participation in this team, though you may question how they do it as described above.

    In short, if you want to say someone's wrong, it had better be something that's either not yet documented, or the document supports your opinion. It's very difficult to put discrimination into writing without making it obvious, especially when it's a document that anyone else can fix. At the same time, encouraging people to admit their own mistakes prevents hero worship and excessive egos. It's much easier to take a complaint when you know that your competency is not also under attack.

    --
    You do not have a moral or legal right to do absolutely anything you want.