Ask HN: How do technical non-developers help with open source projects?

1) Find an open source thing that I use or think is interesting. This has included OpenStreetMap, LocalWiki, MediaWiki, an interactive map project at my former university, a tool my hacker/makerspace has built for itself, an educational website about open source, a tool made by the local Code for America brigade, etc. The important part is just that I like the thing.

2) Get in contact with the people - join the mailing list, IRC channel, forum, meetups, or whatever they use to communicate; look at the bug tracker and blog. Start learning about how the people work and what they're working on, and start asking and answering small questions, pretty much making friends with them in a low-key way. At this point you can probably tell whether they're reasonable people to talk to - if they're unfriendly or non-responsive, abandon ship.

3) Ask for suggestions for what to work on, and find tasks for yourself based on your expertise. Things will come up as needing improvement, and you can propose solutions to the group and start getting them done. For me, this can involve recognizing and filing bugs about user experience issues, improving website copy, writing marketing materials like social media posts and blog posts, organizing documentation, identifying holes in documentation that people have overlooked, and so on. This kind of non-technical work usually requires getting some amount of buy-in and trust from project collaborators, which is why step 2 is important.

4) Yay, you are now contributing useful things to a cool project.

I've written a little more about this as part of one of the projects I volunteer with, OpenHatch (https://openhatch.org/), an organization that helps people get involved with open source: http://blog.openhatch.org/2013/how-i-found-an-open-source-pr... + http://mergestories.com/s/improving-a-project-homepage/. The second post is from Merge Stories, our collection of posts where people explain how they made an open source contribution, to help give newcomers a realistic picture of what contributing looks like: http://mergestories.com/

This is also a helpful article: http://blog.smartbear.com/programming/14-ways-to-contribute-... - a list of ways to contribute to open source that aren't just writing a pile of code.

I found this link pretty useful to breakdown the activities and roles: http://oss-watch.ac.uk/resources/rolesinopensource

Like everyone else will say...first involvement is a bit nerve-wracking (How will people respond? Can I make a decent contribution? Will I look like a total noob?), but you'll only feel that way once.

I have a list of small to microscopic projects that need this kind of thing. I am totally a Linux nerd, that's not great for lots of end users.

It depends a lot on the kind of project the company is building, of course. A developer platform vs a consumer app will have a vastly different need for such things. I work at a 10 person developer-focused startup and as an ex-PM with engineering chops, I jump between building the product itself, working on developer-facing stuff, and randomly helping out. I definitely wouldn't call myself a product manager at the moment, though -- if you really want that as your job title then you probably need a slightly larger company where you can take the reins on product from the CEO, while the CEO switches to focusing on developing the company itself.