maintainers: remove eclairevoyant

[eclairevoyant]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[drupol]

Oh sad to see this... what's happening?

[eclairevoyant]

Consider it a "culture shock".
I had an extended back-and-forth with other committers about whether we should move to by-name without any other changes, which was resolved with a change to the contribution guidelines to reflect that this is now permissible.

Though I don't necessarily agree with every aspect of the end-result, this would've otherwise been nothing of note, except Atemu made a comment to the effect of "the guidelines are downstream of whatever the reviewer has in their head that day" and "the only way to enforce anything in nixpkgs is an RFC", which got agreement from other committers.

Of course the guidelines will never cover everything, and they must be fluid enough to change with our needs. However, to have committers actively advocating for disregarding statements in the contribution guidelines is shocking, and demonstrates to me that committers making up their own guidelines during review is a "feature" not a "bug" as I had assumed. I always thought the worst feature of nitpkgs (sic) was lack of support for various review statements, but if that's by design, this is not a project that makes sense to contribute to for me.
(I won't even comment on the RFC process, that's been done to death. But we still have formatting nits despite having a RFC-approved formatter, so even an RFC cannot dissuade the most stubborn of nitters.)

Cliquey behaviour from moderation seems to only cement this counterproductive design.
Code and docs can be changed, culture can't (certainly not from where I stand).

Nevertheless, the majority of folks I've worked with (yourself included) have been great and I wish you all the best.

[eclairevoyant]

PS I could self-merge but I find that quite gauche in any but the most extenuating circumstances, so a merge from someone else would be appreciated.

[drupol]

Let me reply before merging, I'm afk until 9pm

[drupol]

@eclairevoyant Thank you for sharing your thoughts and giving us some context. I'm not here to try to convince you to close this PR or to stay in the community if that’s not what you want, but I’d like to share my perspective.

Contributing to an open-source project can indeed be frustrating at times. It's a risk we all take when we get involved. Over time, you learn to manage those frustrations and find ways to emotionally detach from the aspects that weigh you down. I’ve been there myself, more than once, particularly within this community (this is also the reason why I'm not going to the Nixcon this year too btw!).

There were moments when I thought about doing the same thing as you're considering now, but in the end, I realized how much I enjoy working with Nix and the technology behind it. I knew I would regret stepping away completely.

Instead of leaving, I decided to adjust how I contributed. I took a break from most of the Matrix channels and gave myself the space to step back. That alone made a huge difference. Afterward, I focused on smaller, easier tasks like quick PR reviews, which kept me engaged without feeling overwhelmed. Eventually, my motivation returned, and I started to take on more again.

What I’ve learned from this is that contributors, especially in open source, need to find a balance. Burnout happens when we get too emotionally attached or overcommitted. Sometimes it helps to slow down, step back, or shift focus on something else rather than leaving entirely.

Whatever you decide, I truly appreciate your contributions and hope you find a way to stay involved in a way that works for you.

[eclairevoyant]

Of course, if it was simply frustration, I'd continue, I mean I stuck around for over a year so far 🙂 In this case, though, I think writing up all these guidelines which turn out to not matter does a massive disservice to (especially new) contributors who try to follow them, and dissuades said contributions. I mostly stuck around because I had hope that we can actually try to improve the experience for new-to-nixpkgs contributors, not intentionally cause them confusion over the capriciousness of reviewers. So, I think my entire reason to stay doesn't make sense anymore.

Of course stepping away entirely from nixpkgs doesn't require stepping away from using nix, I have a long-running fork of nixpkgs that I use for my own configs, and in any case the packages I init'd are mostly self-maintaining due to the time I spent on update scripts for them. So, it should be alright.

[drupol]

Fair enough...

[numinit]

Thanks for your work @eclairevoyant. The few times I interacted with you were pleasant, safe travels. :-)

[AndersonTorres]

I had no time to write an acceptable farewell letter.
I am sad you are going away.

Our bad interactions were by my fault, but our good interactions were fun and light, and I learned a thing or two from them (except about splicing - I am unable to understand that thing!).

Good bye!
Stay safe, and show up more often!

[cafkafk]

Though I don't necessarily agree with every aspect of the end-result, this would've otherwise been nothing of note, except Atemu made a comment to the effect of "the guidelines are downstream of whatever the reviewer has in their head that day" and "the only way to enforce anything in nixpkgs is an RFC", which got agreement from other committers.

fwiw I think you're completely right to be annoyed by this. I really do hope we one day get better ways to deal with review conflicts than just making it up to the fleeting whims of those that review your PR, and requiring an RFC to do so would be a major step back, and like... we don't require RFCs for that, that's just made up.

Thanks for all the reviews you've given me, I've learned a lot from them ❤️

[huantianad]

Hey @eclairevoyant, a bit late to the party, but just wanted to say a real quick farewell, express a hope that I'll still see you around, and thank you for all your help :)