Using GitHub is a skill of it's own, and requires knowledge of coding practices. It's hugely confronting to someone without coding experience

Tried submitting a relatively simple change to the Ansible code base once. Added an option to the telnet module to support different ports. Submitted a pull request. Was told I needed to change and update the documentation. Didn’t know how to do that, and I didn’t get any guidance, so I abandoned the pull request. Kept on using my own hack until someone else added the option.

Make contributing easy, and more people will contribute.

Because UX/UI is just as painful as coding.

Because every time you try to suggest more modern interfaces you run into the type of people that like it when software looks utilitarian and bland.

I'm a programmer and I find dealing with other programmers frustrating and pointless if you discuss anything that's not programming related.

They'll happily discuss algorithms or language paradigms for hours but if you mention design, UI/X, marketing, etc they shut you down claiming some greater-technical reason for the feature.

Lemmy is a good, recent example. As part of being a web dev I've also done a lot of SEM. The devs have a Github issue for making readable URLs. They completely refused to consider it claiming other technical requirements for not allowing it. Any arguments outside the narrow technical reasons are discounted. So what if readable URLs will help people find the site through Google easier (because Google will better index the site). It breaks X feature and we don't see a need. No discussion and no listening.

If devs don't see a strict technical need for something they ignore it at best and at worst they insult you for being an idiot.

Hubris and ignorance make it a PITA to deal with them.

If you give me an extremely easy way to submit feedback, then I will. Don't expect me to go way out of my way, though, researching how to get into contact with you and such. I don't actually care that much, you know how many products exist out there, right?

But, just by way of example, an early access game I started playing recently has a very convenient button in the main HUD for submitting bug reports/suggestions, and I've been considering different ideas to submit with it. Any I cannot throw out as impractical or counter-productive will get submitted eventually. I'll also report bugs I encounter, of course.

I will not look up your team's forums just to talk to you though.

If you can't code (or have limited coding skill) but know the system well, one of the best ways to contribute is by writing end-user focused documentation. Write about things that confused you. Improve the "getting started" guide. Add more articles to the docs. Create video tutorials. Things like that.

I think a major deterrent from contributing things that aren't code is that whoever is implementing it might think their design is better just because it's theirs.

Try talking to the GNOME team, for example. You will never be able to get a suggestion past them because they're always right and you're always wrong.

Even when you prove them wrong and they backpedal, they are still correct and you are still wrong.

As someone who knows how to code and wants to contribute to FOSS, there is very little guidance in doing so even if I half-know what I'm doing.

Writing documentation of all kinds seems like it would help a great deal. I would be hesitant to file UX complaints, because those tend to be ignored by programmers who focus their limited available time on fixing defects and shipping features.

Where are all the programmers who enjoy improving UX and enjoy the challenge of changing legacy code? 😉

Considering how often feedback is met with "where's the PR"... that's why.

Some people are better at technical writing, some are better at coding, some better at UI/UX design

I don't think op is asking people with zero technical aptitude to jump in writing user manuals.

Just because you don't code doesn't mean you can't contribute in some fashion. If you have the skills to improve a user manual, wiki, or help file.... Why not right?

I do with translations.

OP, your post has inspired me! I'm going to write a small python program that works as a multiple choice questionnaire that spits out a comprehensive 'contributing.MD' at the end of it.

When I'm done, will you test it for me and give some feedback?

An organised, easy way to do this would be great. Kind of like a test audience for FOSS.

Right now, people basically have to appoint and organise themselves as reviewer, which is a big ask.

Because my skills when it comes to coding (absolutely none), is using the program until it breaks and telling someone what happened from an uneducated stand point.

If you are going to make things for "idiots" you need to hand it to "idiots" for testing.

I think the biggest issue with this would be that it would require non-technical people to use ticketing systems (have you ever worked in admin IT?).

They tend to put things like, button broken, or will not load, which are not necessarily helpful tickets.

I would be happy to give feedback, but I have no idea how to do so. On a few occasions, I have responded to posts, such as like on Lemmy where someone asked for suggestions to improve KDE. I still have no idea how to use GitHub at all, much less to provide feedback. I know GitHub is something I can work on to learn to interact with the FOSS development community, but it's probably a major barrier to the non-tech people that use FOSS.

Now that I think about it, I'm thinking it would increase non-tech interaction if developers of FOSS engaged the community through social media. Like, get on Lemmy, Mastodon, even Reddit, FB, and Instagram, and engage the community in these discussions. I think that will definitely increase engagement from the non-tech users, though some of those sites may feel like a betrayal of values. It seems like an interesting ethical dilemma.

Edit: So I looked into it for KDE in particular. They actually have a Wiki that simplifies user engagement. Maybe promoting these avenues will also help engagement.

I think just spreading awareness is a step in the right direction. Most people I know just have no clue and continue purchasing the established mainstream programs. I encourage people to give GIMP a try instead of buying photoshop, or OfficeLibre instead of MSOffice. Most of them are ecstatic to save a couple hundred bucks. The more people that use FOSS software the more likely we are to get the support it needs.

I wish I or someone else who understands CAD modeling could help make FreeCAD work better. A LOT of the issue is tools that are commonly used are hidden in weird places that make sense only to people who don't used cad for a living.

I have to write userscripts to make websites bearable, software UI is not as customizable( bright white background at night, tiny 9pixel fonts, huge empty margins and content crammed into 200x200 boxes,lots of tiny cryptic icons crammed into toolbars that suppose to be menus,etc )

It takes a certain kind of a skill set and experience to be able to translate this "consumer view" into something that can be acted upon by a developer.

Sure, the skill set can be developed, the knowledge (about software development, the available technologies, and having an idea of what is and isn't feasible in the first place) can be built up, and the experience (communicating with developers) can be accrued, but that really stops a lot of people from even thinking of contributing.

Perhaps a subset of the (open-source) community can help in developing these (skills, knowledge, experience) among interested people. Teach people how to look for issues, bugs, or come up with feature requests; teach them how to put these into a form that's easily understood and appreciated by the developers, and finally, teach them how to communicate with developers without losing the "non-techie user POV" which makes their feedback valuable in the first place.

IDK though, having read what I've just written, it seems to be quite a task.