That's more the desktop environment than the Linux kernel though. Gnome, for example, is a simple, good looking, accessible desktop environment.

I don't know a single ui person or artist that gives a single f about open source.

I think as a dev you naturally grow to respect the open source space because of how much you take from it.

I would love to be proven wrong though

I mean, Microsoft and Apple have career pages stating exactly what is needed. Does Linux have something like this for volunteers? I think it's just very inaccessible to someone from the outside. Maybe start there, improve the recruitment of volunteers

How does someone like me, a PhD candidate who has a background in Human-Computer Interaction, contribute? Or the accessibility researchers I collaborate with who sit one office down and use and love Linux and make their own hacks for Linux to improve its accessibility?

I think part of the problem is a matchmaking (as as you said a PR) problem. I'm sure a lot of the experts you describe would love to contribute some cycles (including myself) but your post is the first time I'm hearing that people like me are needed in my HCI capacity. Otherwise I would have assumed there are plenty of programmers better than me available so why bother?

This plea for help is specifically for non-coding, but still deeply technical work.

Without too much knowledge, I have the strong feeling this is equally true for the Fediverse and Lemmy.

And while it is fairly obvious and straight forward how to contribute as a programmer, it's less so for all the other, equally important, tasks.

I know a thing or two about UI/UX, but tbh it feels very weird to me to butt in somewhere and tell people what to do. Because unfortunately, while I probably could design a good UI, I have no experience in implementing UIs.

I can deal with C++ so I thought I might as well learn Qt, but I couldn't even get Qt Creator or KDevelop to run properly on my distro and didn't find the time to get into it since.

This stuff sadly not that trivial which is probably why you don't find too many people who can do it.

I'm not sure the UI/UX is anyhow related to kernel development.

I3/Sway/Hyprland/other WMs are already much more superior to anything that can be achieved in Win/Mac desktops in terms of flow and performance. Only polishing is needed. Other desktop options like Gnome/KDE are fine and more lightweight desktops are okay too. They need polishing too, but already great.

Isn't there some kind of volunteer-project market with easy access?

This must be a reference to someone, right? Casual femicide sounds a bit off.

Oof. The filesystem was great though.

You offered a lot of suggestions, and I'm sure people will disagree over the specifics, but I think your overall point is excellent and not talked about enough. I wonder if anyone has ever even attempted a survey on the ages of maintainers/contributors? I bet it's skewing older fast.

Nothing wrong with that of course, especially given the project's age, complexity, and being written in C - but you're right, at some point you have to attract new talent - people can't maintain forever.

I'm a 29 year old developer - I didn't even know you could do git patches via email until recently. And while it's super cool, it also sounds kinda terrible, especially at the volume they must be receiving? Their own docs are saying the mailing lists receive some 500 emails per day and I can't imagine the merge process is fun.

So many doc pages are dedicated to how to submit a patch - which is great that it's documented, and I'm sure it will always be somewhat complicated for a large project - but it also feels like things that are all automatically handled by newer tools / bots which can automatically enforce style checks, etc.

I guess they could argue that the complicated process acts as a filter to people submitting PRs who don't know what they are doing, but I'd argue it also shuts out talented engineers who don't have 40 hours to learn how to submit a patch to a project on top of also learning the kernel and also fixing the bug in question.

From what little I read of their git process, does anyone know if there's anything preventing the maintainer of a subsystem from setting up a more modern method for receiving patches? As long as the upstream artifact to the kernel has the expected format?

and its linking ability is a huge simplifier for long term planning.

What long term planning? Who is going to come up with that plan? Will everyone agree to that plan? Who will be paying for the resources to work on that plan?

Combined with a Kanban board for tracking, progress of tickets. You remove a ton of pain.

I am not seeing how that would help. What are you going to do if there is no progress on something? Fire volunteer X because he didn't make progress on ticket Y (as he has no interest in ticket Y)?

Similarly moving on to a decent issue tracker, Jira’s support for Epic’s/stories/tasks/capabilities and its linking ability is a huge simplifier for long term planning.

Modern ticket system or issue tracker? Yes, absolutely. But Jira? Certainly not, considering Atlassian's business practices. A project like Linux deserves a system where they can maintain some control and it probably should be open source.

Yeah email is ancient and certainly terrible from a usability perspective if you're an outsider to the workflows, but at least it can't be shut off or taken away on a whim. Also it's universal and therefore accessible.

Its like everyone outside, knows a breaking the ABI definition from the sub system implementation would create a far more stable ABI which would solve a bunch of issues and allow change when needed, except no one in the kernel will entertain the idea.

We also can’t go back to fix SMTP either. Simply saying “we need to break ABI” is not a solution for the same reason, the fear Darrick mentions in the email is justified, it’s the fear of e-mails when you change something that breaks everyone’s widget in a way they don’t expect or care to learn about and demand you fix it for them. It’s all well and good to say that they should simply wash their hands of it, but that’s not an option when your inbox is flooded with automated bug reports that don’t explain the problem

https://kernelnewbies.org/

Same.

Isn't "anyone can fork if a project doesn't really fit their taste" sort of the curse of open source?

Swallowing your pride, merging into another project and taking a less glamorous role in that project is not as easy as it was to fork when steering your project.

This is generally speaking. I'm definitively not saying any of this is that case with the XFS project.

Ps. Murdering your wife is also something that seems to be bad for filesystems....

I guess the best start would be to have a person to organize volunteers.