4 ms·

This is great. I want this information to be in a form easily accessible and readable for any project maintainer who wants to learn about concrete ways to impro

by britta 12y ago

This is great. I want this information to be in a form easily accessible and readable for any project maintainer who wants to learn about concrete ways to improve their projects. So, question: what form should that be? A blog post explaining the highlights, with a title with good keywords? A YouTube video with explanations and anecdotes, like a talk without a conference? Where do maintainers learn about this kind of thing (other than occasional news posts on HN with advice), so that we can make this information show up there? I volunteer for OpenHatch (https://openhatch.org/ https://openhatch.org/), a non-profit open source project that aims to help newcomers contribute to projects + help projects make themselves more welcoming. What do you think is the most effective step OpenHatch could take for helping maintainers? It has some efforts already, and I have some ideas, but I'm curious to hear more ideas. (Also if you want to help, OpenHatch is already a loose collection of people who care about this; come join us.)

Mz 12y ago
I would personally go with a "Best Practices" page that streamlines the info. I have a very long history of doing volunteer work of various sorts. Some of the early observations are things I am familiar with but I find this paper rather clunky. I suspect there are no easy answers for some of the barriers they list. (For example, I feel like "lacks the skill to do the job" is probably not something the project manager can or should solve, anymore than a hiring manager should take just anyone who wants the job even though they aren't qualified.) But the social piece is something I can break down for you into basically two key points: 1) Greet people warmly at the door. People who get that initial "Hi! How are you? We are so happy you dropped by!" kind of response are much, much more likely to keep coming back, even if it takes a bit to figure out where they fit in. Folks who get the cold shoulder often just disappear, never to be heard from again. 2) Never let any question go completely unanswered. If it does not get a meaningful answer in a timely fashion, then the person in charge should at least drop the person a note to say "I don't know the answer." (When I had a directorship on a voluntary health and welfare organization trying to make the transition to full scale charity, my rule of thumb was that if it had no response after 3 days, I would step in and say something, even if I had no answer.) Depending upon the environment in question, that sometimes bumps the question and allows others to notice who may have missed it due to being away, busy, whatever. So, sometimes just answering nominally will get it answered meaningfully by another but even if it doesn't, the person doesn't wind up feeling like they are out in social Siberia and afraid to speak up again.
restless 12y ago
Thank you for the link I will explore it further this weekend
throwaway192837 12y ago
You are not going to like this, but projects like OpenHatch feel to me like extrovert and social people have discovered Open Source and now want their piece of the pie without actually contributing much. The whole site smells of a lot activism with little actual progress. The recipe for successfully contributing to projects is: 1) Shut up and code. 2) Do not be discouraged by project politics (if applicable). Glossy "get together" websites do not help.
- pokpokpok 12y ago
  >someone is having a problem that I didn't have >they must be stupid
- x0x0 12y ago
  I dunno; having project members not actively be dicks to newcomers is always good advice. That said -- and I'm being vague because some people on hn are dicks and I'm careful how trackable my online presence is -- small projects get lots of, well, basically useless people who need tons of handholding to get anything accomplished. I see the upside for them, but I don't see the upside for me: if I where to help them out, I'd spend my limited available time on handholding people who apparently managed to get ms degrees in cs without being able to code instead of doing what I enjoy. So I ignore them. Open source is apparently the new resume chit so people want to spend minimal effort to put a patch into a github project. We're always open to helpful people but I have a depth 1 decision tree for ignoring the idiots: if you can't successfully read and follow the instructions in readme.md and make, you're worthless and I kill your email.
- vomitcuddle 12y ago
  >2) Do not be discouraged by project politics (if applicable). Yeah, too bad this only applies if you're a white male.
- ben0x539 12y ago
  Why are you posting this under a throwaway? Are you perhaps discouraged by politics?
- dictum 12y ago
vitovito 12y ago
Open source project maintainers might also consider a lighter-weight implementation, a CONTRIBUTING file, per Brad Fitzpatrick's CONTRIBUTING project: http://contributing.appspot.com http://contributing.appspot.com

by britta 12y ago

Mz 12y ago

I would personally go with a "Best Practices" page that streamlines the info. I have a very long history of doing volunteer work of various sorts. Some of the early observations are things I am familiar with but I find this paper rather clunky. I suspect there are no easy answers for some of the barriers they list. (For example, I feel like "lacks the skill to do the job" is probably not something the project manager can or should solve, anymore than a hiring manager should take just anyone who wants the job even though they aren't qualified.) But the social piece is something I can break down for you into basically two key points: 1) Greet people warmly at the door. People who get that initial "Hi! How are you? We are so happy you dropped by!" kind of response are much, much more likely to keep coming back, even if it takes a bit to figure out where they fit in. Folks who get the cold shoulder often just disappear, never to be heard from again. 2) Never let any question go completely unanswered. If it does not get a meaningful answer in a timely fashion, then the person in charge should at least drop the person a note to say "I don't know the answer." (When I had a directorship on a voluntary health and welfare organization trying to make the transition to full scale charity, my rule of thumb was that if it had no response after 3 days, I would step in and say something, even if I had no answer.) Depending upon the environment in question, that sometimes bumps the question and allows others to notice who may have missed it due to being away, busy, whatever. So, sometimes just answering nominally will get it answered meaningfully by another but even if it doesn't, the person doesn't wind up feeling like they are out in social Siberia and afraid to speak up again.

restless 12y ago

Thank you for the link I will explore it further this weekend

throwaway192837 12y ago

You are not going to like this, but projects like OpenHatch feel to me like extrovert and social people have discovered Open Source and now want their piece of the pie without actually contributing much. The whole site smells of a lot activism with little actual progress. The recipe for successfully contributing to projects is: 1) Shut up and code. 2) Do not be discouraged by project politics (if applicable). Glossy "get together" websites do not help.

pokpokpok 12y ago
>someone is having a problem that I didn't have >they must be stupid
x0x0 12y ago
I dunno; having project members not actively be dicks to newcomers is always good advice. That said -- and I'm being vague because some people on hn are dicks and I'm careful how trackable my online presence is -- small projects get lots of, well, basically useless people who need tons of handholding to get anything accomplished. I see the upside for them, but I don't see the upside for me: if I where to help them out, I'd spend my limited available time on handholding people who apparently managed to get ms degrees in cs without being able to code instead of doing what I enjoy. So I ignore them. Open source is apparently the new resume chit so people want to spend minimal effort to put a patch into a github project. We're always open to helpful people but I have a depth 1 decision tree for ignoring the idiots: if you can't successfully read and follow the instructions in readme.md and make, you're worthless and I kill your email.
vomitcuddle 12y ago
>2) Do not be discouraged by project politics (if applicable). Yeah, too bad this only applies if you're a white male.
ben0x539 12y ago
Why are you posting this under a throwaway? Are you perhaps discouraged by politics?
dictum 12y ago

vitovito 12y ago

Open source project maintainers might also consider a lighter-weight implementation, a CONTRIBUTING file, per Brad Fitzpatrick's CONTRIBUTING project: http://contributing.appspot.com http://contributing.appspot.com