If you don't have coding skills, why don't you help foss software by making it more user friendly instead?
Disclaimer
Not trying to blame anyone here. I‘m just taking an idea I‘ve read and spinning it further:
Intro
A lot of people use free open source software (foss), Linux being one of them. But a lot less actually help make this software. If I ask them why, they always say „I don’t have the coding skills!“.
Maybe its worth pointing out that you don‘t need them. In a lot of cases it’s better to not have any so you can see stuff with a „consumer view“.
In that situation you can file issues on github and similar places. You can write descriptions that non technical people can understand. You can help translate and so on, all depending on your skills.
Other reasons?
I‘d really like to know so the foss community can talk about making it worthwile for non coders to participate.
I'm not a coder but I relate to being a lot more attracted to the idea of problem solving than writing a well-formed document that communicates ideas clearly, haha.
Well, then I can relate because I have this exact situation on lemmy (and IRL) but I write good handbooks and readmes.
I‘m more of an entry level coder and I havent studied IT so I have no idea what the dev thought making something but I know what would have helped me to use it.
What use is a readme written by someone who doesn't know the code, doesn't know the internal designs, the design goals, the plans of the current maintainers, anything? It'd be no better than asking ChatGPT to write it for you.
You don't mean the readme file. You are talking about the manual, or the explanations on the website. Yeah that can make sense. Though I would still say it's weird if you're not too familiar with the direction the application is going, but an experienced user can of course help create better texts and pages for that.
Yeah, that's a good point, but the readmes that I've seen written by those who wrote the code themselves are not much better. Sure, they know what it's all about, which is precisely why it oftentimes isn't much help for a user.
What's needed is someone who'd read the initial readme (written by the guy who wrote the code itself) and ask questions about the parts that were "too straightforward" to be included, or weren't explained clearly enough, or to bring down the general overview back to Earth.
And if there's yet another person who'd go over this second pass, and keep it from being too dumbed down, even better. Keep it to the level of the average user. That requires knowing the kind of person who'd likely use the program.
Why does it have to be documenting internal designs, architecture, and all that? Why not app user manuals or install guides or any of myriad other sorts of documentation?
Just because one specific scenario may not be suited doesn't mean no scenario is suited to what op is proposing.
I mean first, what kind of projects are we even talking about, libraries? APIs? Apps? Command line tools? Etc?
Because the technical writing needs vary depending on what kind of project. They don't all require coding skills for success.
Just writing documentation alone, is a skill worthy of a full-time job! Of course, there'd be people who can volunteer their time to do that, but without someone with such skill at least taking a look and making sure it's understandable to someone who's got no idea what's going on? Let's just say that open source software help documentation is filled with such examples.
Yeah, I probably should think about taking money for it but making descriptions and manuals is just something I like to do. And there are a lot of people who also do this but dont call it „technical writing“. Often it is things like doing glossars or explaining abbreviations. That helps a lot.