I'm a technical product/project manager by day and a hobby programmer by night. Things like writing documentation, triaging issues, coordinating teams, and planning releases is my bread and butter. I'd like the idea of spending time on an OSS project(s) that I find interesting, but I wonder if this is the kind of thing that would be welcome or even considered helpful. OSS projects are passion projects, and it feels like trying to help out uninvited with management tasks would come across as asserting ownership.

I do try to contribute what I can, but they're small hit and runs -- update deprecated information in documentation or add some examples, add more information to bug reports, etc., but I'd like to do more. Just without offending anyone :)

Coordinating teams and planning releases.... I think a lot of open source projects could _use_ help planning releases (release management is incredibly important), but I'm not sure they'd _take_ it from a stranger they didn't trust (and they might be right). "Coordinating teams" not as sure how it would even look or would be needed. But anything that looks like being a "boss", people are going to be resistant to, esp from a newcomer stranger, for obvious reasons.

But I bet people will welcome documentation contributions with little hesitation. For the rest... if you want to try, I recommend taking a product you're familiar with (as a user, not a developer), and offering your services being very careful to come from a real service perspective. Your job is to figure out what they need help with and how they want it done, and help them do it -- not to tell them what they ought to want to do or how they ought to want it to be done, not at first even to helpfully _suggest_ it. At least not until you've built up a lot of trust.

After writing documentation, I think the thing you mentioned people would be most welcome to and least resistant to would be 'triaging issues' -- but I think you'll have to build up some trust (say, by writing documentation!) before people will be willing to trust you with it.

Because of my skills, I'm not going to stumble onto something by chance where I'm contributing upstream to scratch my own itch and then sticking around. I'm expecting I would need to spend time to find a project that seems like a good fit both ways, and become an active user intentionally where without my side agenda I'd be better off using a larger OSS project or a paid service.

I'm cool with putting that time in to help something grow and to help kindred spirits out. I don't want to put in that time just to be a source of annoyance or frustration to someone who's already done me and the world a solid by putting something cool out into the world.

Documentation is where it seemed to me like the best first step, and what people are saying here as well. As a followup, what's the general consensus on the least bothersome approach? Editing/prettifying existing documentation; appending to existing documentation (adding diagrams or examples); or creating "newbie docs" (how do I install this, how do I compile this on Windows, or aggregating a central FAQ from closed issues); or perhaps something else?

I think any of those could be good, whatever the project needs. If it's got existing docs that need editing/prettifying, that's def a natural first step.

People should treat documentation issues the same way as critical bugs IMO. Can anyone point me to projects where this is done? e.g. documentation category on a bug tracker, open issues requesting additional documentation.

FreeBSD also does this, which will surprise no one who has ever read the FreeBSD docs.

Also, one of the reasons I asked this question in response to antirez is because the Redis docs are excellent and have been since I first set eyes on the project three or four years ago. I don't know what he's doing or how he does it, but whatever it is, it's working.

However to return to your original question of what is possible to do to help, issues verification/triage is a HUGE thing because the issues are of hugely mixed quality. Moreover Github does not help by making users not able to label the issues in order to make them into categories: only the collaborators can label issues.

Another problem I face is high quality QA, that is, a person that explores certain parts of Redis to understand where there is a quality problem and how it is possible to fix it.

Code reviews are also crucial. For a few months I had a contributor, Sun He, that prevented a number of bugs in Redis by reading each commit and by understanding non trivial bugs just reading the code. Impressive. Eventually he got a job after the university and now contributes only from time to time, but I'll be thankful forever ;-)

Unfortunatly once they are there not many PRs will address, these, only if their are actually critical. (Well the problem with play is actually that you need to read the README.md of the documentation carefully to make documentation and to understand a little bit of sbt and scala.)

Also it's actually not easy to write understandable documentation for many users. Some people are just too different, so that some actually need a way more detailed view, while for others this would be disturbing and useless noise, the golden middle is hard, especially if you contribute documentation to a framework which includes different libraries, it's really hard to keep the documentation simple.

P.S.: gitlab also treats documentation very seriously. (just to have at least two examples)

Triaging issues especially can be a big time-sink, and is something that is relatively easy.

How do you tell who you'd be trampling on it and who else would be shouting "YES!" excitedly? I'd just drop an email!

I see so many opportunities for contribution where a project manager could make such a big difference. This starts with simple things like “I had an hour to spare and the contributor documentation was non-existant, so I did something else” and goes to “this issue would be good to fix, but I don’t have the energy to get little fixes upstreamed into five different projects”.

I’m sure many projects would be lucky to have your help.

What do fellow HN'ers think?

I would say all help is welcome in successful projects -- it has to be, for longevity

For triaging: https://wiki.documentfoundation.org/QA

For documentation: https://wiki.documentfoundation.org/Documentation

For marketing: https://wiki.documentfoundation.org/Marketing

The technical docs in the wiki could also benefit from stylistic improvements.

https://www.debian.org/intro/help

A "bad sign" would be increasing or stagnant issues with no resolution. Say if a project has a single maintainer and said maintainer decides to stop all work on it. There's plenty of examples of projects like that and if you're choosing a library or backend, you need to know what you're getting into.

(For the record, Redis doesn't fall into that category at all!)

It's also the case that the average age of open issues will grow without bound. (As the number of open issues grows, eventually you get to a point where more issues are untouched in any given period than are either opened or closed.)

So, it's very easy to get into the state where there are lots of stagnant issues. It's going to happen automatically unless you do something to fix it. Something needs to happen so that either fewer issues are opened or more issues are closed.

So from a maintainer perspective, you have to act like people's contributions are your contributions. You have to evaluate the code as if you have to maintain it later, you have to understand the circumstances surrounding it, etc. You have to be aware of everyone's concerns at the same time and make sure you don't end up messing up other people's use cases without good reason. And more often than not PRs reflect a "selfishness" of sorts wherein it solves their problem but breaks the general case.

In four separate occasions, people tried to take control of my github organization and npm repos by complaining to github and npm support, because they disagreed with the trajectory of the project. Some people seem to have no respect for OSS.

THat blows my mind a bit. Particularly since forking a repository is not exactly a difficult thing.

[edit] an interesting vector: open source politics

lots of people are crazy. they walk among us!

[edit] the significance of my being into OSS for such a long time is I can say I don't think the environment used to be so hostile for maintainers as it is now

That sounds like a good recipe for getting into trouble because of tax fraud if it gets public. And even you are in the position to accept the money (e.g. by being self employed) it would not be worth the effort. If you charge a low sum the overhead will make it not pracitable and if it's a large sum no individual will want to pay you and companies will often not be able to pay you.

Part of the point of setting a high bar would be to either:

1) receive adequate compensation or 2) get the company that can't afford to pay you to contribute in some other manner