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

Planning Poker?

We have someone non-technical helping us in the https://github.com/angular-ui/bootstrap/ - he helps us triage issues, putting labels and helping get the reporter of issues to be more clear about the information or helping issuers of pull requests get tests in the pull request before it gets reviewed, which helps us developers of the project save time when reviewing the issues or pull requests.

Sprint planning isn't as critical in open source - it is more important to get things done right than to confine progress to sprints. Open source is hard, and core developers of projects can use all of the help they can get.

> "Is there a need for someone like me in any open source projects and if so, how do I contribute?"

This is an excellent question. I doubt that anyone is going to turn you away but there are some things you should probably consider. I'm drawing this from my experience with MirageOS [1] and OCaml-related projects I've been involved with.

1. Why are you doing this?

After you've figured out what you care about you should still ask yourself why. Is it CV points? New experiences? Specific project goal? To stretch yourself? Accolades?

If you can be upfront with yourself about what you're hoping to get from contributing then it makes it a little easier to frame what it is that you can offer. As I said above, no-one's going to deny a new contributor but having a flaky contributor is also frustrating. Most projects won't have any kind of 'onboarding' process so knowing why you want to do this at all will help you create your own.

In my case, I can see how a new method of building software (with unikernels) could be transformational. I also want to know that I'm helping to promote the creation of better software for distributed systems. There's a specific use-case I want to be able to highlight too (see point 2).

2. What do you actually care about?

This matters more than you might think. If you're only peripherally interested in a project it'll be difficult to remain motivated, especially if you already have a full-time job. This is more than buying into a project's wider goals (assuming it even has any stated goals) but more about what would actually drive you to continue contributing. It's somewhat related to the above point but a little more specific.

Do you like writing docs? How about blog posts or giving talks? Or doing tests? Triaging bugs? Helping users with issues? Organising stuff (community/devs)? Small project or a large one? Move fast or be considered?

Can you match any of these up with gaps you see in the project?

From my point of view, I want to work towards distributed systems that empower users [2] and I can see how parts of the project can get me there [3]. I wanted to write more (personally), I care about good organisational practices/structures/communication and onboarding new people. Those are the things I tend to think about and it's led to me coordinating fortnightly calls, curating a set of Pioneer Projects and writing a lot more.

3. How will you build credibility?

Since you're not contributing code, it's almost inevitable that you'll end up in bike-shed territory (though even code has plenty of bike-shedding). Everyone has an opinion so why would anyone listen to yours?

I think this is why 'documentation' (inc tutorials) gets touted as the first, semi-technical way to get involved with a project. It's rarely threatening to the existing team and provides immediate value. Many of the other things you mention in your list provide long-term value but they need to welcomed. Again, no-one will state that they don't need these things but that doesn't mean that any offering will be accepted. If you're willing to believe that customers can't always articulate what they really want, then the same applies to any open-source project :)

I don't have a pithy answer for this. I think it just takes consistent behaviour over time. Be reasonable and try and back up any claims but don't be afraid to stand firm.

4. Just start!

All of the above points may seem cautionary but it's best to just get involved. Open source projects can be pretty awesome and there's nowhere else where I've been able to be as transparent about what I'm working on. There's probably a useful blog post in this comment so I may write my thoughts up properly some day (as opposed to this brain dump).

[1] http://openmirage.org

[2] http://nymote.org/blog/2013/introducing-nymote/

[3] http://amirchaudhry.com/brewing-miso-to-serve-nymote/

If you're technical enough... unit tests.

Docs, testing, but triaging, community wrangling (IRC), web presence maintenance, etc.

There are many ways that open source projects can benefit the help of a non developer. In fact, it is often what projects need the most!