2024-02-12, 06:10 PM
Mostly copy and pasted from an old comment of mine, but should cover most of the bases.
As far as contributions from our non coding users, there's a few ways that are always helpful.
I'll add more if I think of them, or others might have some more input. Always happy to see more people get involved, and if you have any questions there's usually somebody who can point you in the right direction.
As far as contributions from our non coding users, there's a few ways that are always helpful.
- Translations. Most of us only speak one language, maybe two. So translations from those community members who do know more are always helpful. We have a weblate instance set up for this.
- Documentation. This is kinda a trend in a lot of open source projects, but often the docs are written by devs. What that usually means is that they make assumptions that the user already knows what certain terms or situations are. In the event that they don't, then trying to read and follow the docs can be frustrating. So other input about what makes sense or rewording things to be more approachable to somebody less familiar with the project are always helpful.
- Bug reports. Fairly obvious. Oftentimes the details are what makes a bug report actionable or not. "This doesn't work" vs "I tried to do X by Y, I was expecting Z to happen but instead it did this" is way easier to work on. We've refined our issue templates over time to try to pull more info out of users initially so we don't get as many of the first kind, but people gonna be people.
- Bug reproduction. Less obvious, but no less important. Sometimes we'll get bug reports we can't reproduce (don't have the right hardware, don't have the right subscriptions, technology just hates being consistent, etc), or the user reported an issue and then disappeared when asked for more data. So if we can have multiple people reproducing an issue and providing some more datapoints (preferably with logs, versions, examples, etc. not just "me too") that goes a long way to narrowing down where a problem could be.
- Backlog issues. This one is definitely not obvious, but something that has come up a lot in the past. Our issue backlog is ... a lot. And we're sure a lot of them can be closed because it's been fixed already from another issue, or it was never actually an issue (see bug reproduction above). But we just don't have the time to go back through all the issues ourselves. There's still issues reported from releases that are several years old now, so realistically they're probably not relevant, but it's another time sink where we have to choose between trying to reproduce issues that are likely obsolete or writing code that we know is needed currently. Note: we now have a team of community members who have been doing a lot of work on this front in recent months, and we're immensely grateful for them.
- User support. If you have the project running and are relatively confident about your knowledge, or are just willing to participate and learn as you go, user support is huge. Let me tell you, once the community started to grow and we didn't have to answer every single help request ourselves was an immense load off of the devs. Especially when we were using reddit as our "home" and search was terrible, and it was basically the same ~20 questions over and over again. And this goes for anywhere. Here on the forums, on real time chat (matrix/discord, doesn't matter which you choose really), on our lemmy board, etc.
I'll add more if I think of them, or others might have some more input. Always happy to see more people get involved, and if you have any questions there's usually somebody who can point you in the right direction.