nixos

they say "you [person struggling to report a package-specific issue] are the problem; our system doesn't need to change. YOU need to change".

I have not met anyone in the Nix community who's opposed to fixing actual systematic issues. I just highly doubt that the discoverability of github issue tracking in particular is a problem that Nixpkgs is in any way responsible for.

I too wouldn't be entirely opposed to adding i.e. a little section on how to report issues but when you've read half a README, then opened CONTRIBUTING.md and read through that, you really should have discovered the "issues" tab to report your, well, issue by then.

It's the reason Determinate Systems has a separately maintained nixpkgs-installer script, and separately maintained documentation.

No. The reason they have separate instances of those is that they allow a green-field approach to things. "Move fast and break things" is great for development but you can't do that when the entire ecosystem relies on the things you might be breaking.

The installer is a great counter example actually. If someone wanted to replace the regular installer with the detsys installer right now, the greatest opposition they'd likely face is "hey, let's be careful to not break users' setups, does (niche feature) still work?".
I wouldn't be surprised to see it replace the current official installer within the next year.

Adopt a legacy codebase that is massive and requires EXACTLY ruby 2.6.0-rc1. On ubuntu, using rbenv, it takes a newby 30 sec to list all the available versions, and 30 sec to install ruby 2.6.0-rc1.

Try finding that version on search.nixos.org.

Nixpkgs has never has supported that version and does not support using multiple versions of Nixpkgs either (not even the currently maintained branches). You can try to and it'll probably (perhaps even likely) work but it's not "intended" to and nobody will want to deal with issues you might encounter with that.

We regularly kick out packages that have stupid version requirements like that for a reason. Eventhough we could technically have an infinite amount of versions of any package we choose not to because it's a maintenance burden we cannot support.

The "proper" way of handling an issue like that (I'm sorry to say but depending on some old specific version is actually an issue of the dependant) is to "vendor" the dependency; copying its expression out of the Nixpkgs tree and maintaining it yourself.

try searching for the extremely-commonly-needed "Core Framework" package on search.nixos.org

According to repology, a package under than name exists in no repository and it knows about a damn lot of repositories:

https://repology.org/projects/?search=Core+Framework&maintainer=&category=&inrepo=¬inrepo=&repos=&families=&repos_newest=&families_newest=

I don't know which "Core Framework" you are referring to either.

But more importantly please ignore those details and look at the bigger picture; we are on the same team. I'm not insulting or ignoring the massive accomplishments nix team has made. They (maybe you as well) are giants that have moved moutains and accomplished things I wouldve considered basically impossible. I want to help the core devs have LESS work. I want to have productive discussions about the trade-offs of federated vs monorepo, searchability, documentation improvements, installer scripts, etc.

But we can't.

Not until the discussion starts with "I agree there's a problem" instead of "there is no problem other than YOUR lack of skill" I've yet to see a "bigger picture"-issue described in what you wrote.

At this point I'm not sure whether we're talking about the same Nix community anymore. We have a lot of those "big picture" issues in the Nix community and we're aware of them. What we need the most help with is fixing them, not finding them.