6 ms·

Do you think there's room for contributors to OSS outside filing bugs and making pull requests? I'm a technical product/project manager by day and a hobby prog

Do you think there's room for contributors to OSS outside filing bugs and making pull requests? 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 :)

spikej 10y ago
I think it totally depends on the lead/project. I've been invited to do so on a project, and I felt I didn't have the time (or deep enough knowledge) to do so. I would say all help is welcome in successful projects -- it has to be, for longevity
secure 10y ago
Yes! Yes! Yes! 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.
gsnedders 10y ago
While I think I know some people who'd take it as trampling on their toes for the reasons you mentioned, I for one would absolutely overjoyed if someone was willing to help with such things—though obviously I have my opinions about them too! 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!
jrochkind1 10y ago
It would be very easy to contribute by writing documentation to most open source projects, they'd be happy to take it. 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.
- voltagex_ 10y ago
  >But I bet people will welcome documentation contributions with little hesitation. 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.
  - merb 10y ago
    well not treating them as critical, but there are many projects that do so. One scala Project for example: https://github.com/playframework/playframework/labels/documentation https://github.com/playframework/playframework/labels/docume... 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)
pryelluw 10y ago
Ive been thinking about contributing with my marketing/business skills. Though Im not sure how receptive people might be. Marketing is such a taboo issue in tech that it might backfire and create a shit storm of incredible proportions around me. What do fellow HN'ers think?
- BuuQu9hu 10y ago
  I think FLOSS projects do such a bad job at marketing and publicity that you would be doing them an immense favour volunteering your skills in that way. OTOH, increasing popularity increases workload so you would have to be careful about scaling the user community at the correct rate.
  - pryelluw 10y ago
    Good points. I've been thinking about this for about a while and really want to do it. Anyone interested? Do you think I should do a ASK HN type of thread offering my contribution?
    - BuuQu9hu 10y ago
      Go with an Ask HN thread.
      - pryelluw 10y ago
        Thanks for the feedback. I shall do that once new year has passed. :)
buovjaga 10y ago
If LibreOffice is interesting to you in any way, it has a solid organization making it easy to start contributing. For triaging: https://wiki.documentfoundation.org/QA https://wiki.documentfoundation.org/QA For documentation: https://wiki.documentfoundation.org/Documentation https://wiki.documentfoundation.org/Documentation For marketing: https://wiki.documentfoundation.org/Marketing https://wiki.documentfoundation.org/Marketing The technical docs in the wiki could also benefit from stylistic improvements.
BuuQu9hu 10y ago
Absolutely, here is a bunch of examples from the Debian project: https://www.debian.org/intro/help https://www.debian.org/intro/help

spikej 10y ago

I think it totally depends on the lead/project. I've been invited to do so on a project, and I felt I didn't have the time (or deep enough knowledge) to do so. I would say all help is welcome in successful projects -- it has to be, for longevity

secure 10y ago

Yes! Yes! Yes! 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.

gsnedders 10y ago

While I think I know some people who'd take it as trampling on their toes for the reasons you mentioned, I for one would absolutely overjoyed if someone was willing to help with such things—though obviously I have my opinions about them too! 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!

jrochkind1 10y ago

It would be very easy to contribute by writing documentation to most open source projects, they'd be happy to take it. 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.

voltagex_ 10y ago
>But I bet people will welcome documentation contributions with little hesitation. 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.
- merb 10y ago
  well not treating them as critical, but there are many projects that do so. One scala Project for example: https://github.com/playframework/playframework/labels/documentation https://github.com/playframework/playframework/labels/docume... 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)

pryelluw 10y ago

Ive been thinking about contributing with my marketing/business skills. Though Im not sure how receptive people might be. Marketing is such a taboo issue in tech that it might backfire and create a shit storm of incredible proportions around me. What do fellow HN'ers think?

BuuQu9hu 10y ago
I think FLOSS projects do such a bad job at marketing and publicity that you would be doing them an immense favour volunteering your skills in that way. OTOH, increasing popularity increases workload so you would have to be careful about scaling the user community at the correct rate.
- pryelluw 10y ago
  Good points. I've been thinking about this for about a while and really want to do it. Anyone interested? Do you think I should do a ASK HN type of thread offering my contribution?
  - BuuQu9hu 10y ago
    Go with an Ask HN thread.
    - pryelluw 10y ago
      Thanks for the feedback. I shall do that once new year has passed. :)

buovjaga 10y ago

If LibreOffice is interesting to you in any way, it has a solid organization making it easy to start contributing. For triaging: https://wiki.documentfoundation.org/QA https://wiki.documentfoundation.org/QA For documentation: https://wiki.documentfoundation.org/Documentation https://wiki.documentfoundation.org/Documentation For marketing: https://wiki.documentfoundation.org/Marketing https://wiki.documentfoundation.org/Marketing The technical docs in the wiki could also benefit from stylistic improvements.

BuuQu9hu 10y ago

Absolutely, here is a bunch of examples from the Debian project: https://www.debian.org/intro/help https://www.debian.org/intro/help