Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mentorship #3

Open
afeld opened this issue Mar 11, 2015 · 3 comments
Open

Mentorship #3

afeld opened this issue Mar 11, 2015 · 3 comments

Comments

@afeld
Copy link
Member

afeld commented Mar 11, 2015

As has been pointed out in #1 (comment) and other places, simply giving a giant list of open issues for people new to open source doesn't seem to be super successful. In my experience, people new to open source are interested in getting involved generally, rather than wanting to contribute to any particular project. I just put out a tweet:

looking to get involved w/ open source? look through @18F's and my "help wanted" issues, and id be happy to mentor. https://t.co/U0pCK2vrkp

https://twitter.com/aidanfeldman/status/575445289991041024

Instead of having people find random projects via issues, what if we highlight volunteer mentors/coaches who can help guide people to projects and tasks that might be good fits for them? From there, the mentors could help answer any questions the participant is shy to ask publicly, etc., and generally help them along in the process of contributing. It's a lot smaller of a hurdle to reach out to a person (especially in their developer community) and say "how do I get started?" than to ask a complete stranger through an issue tracker, when they may not even be comfortable with version control yet.

This model could be asynchronous, and/or in workshop-type formats. @jlord I know you've thought a lot about the latter...any insight?

@kytrinyx
Copy link

In my experience, people new to open source are interested in getting involved generally, rather than wanting to contribute to any particular project.

I think you're right about this, and it's a very interesting observation. I'm not really open to mentoring someone in the abstract, because I have too many things on my plate, but if someone were to commit to contribute to my project and the exchange was that I would mentor them in that process, then I would be absolutely delighted to make that happen.

On a number of occasions I've offered something similar, and have spent a bunch of time trying to figure out how to help someone get started with my project, only to have them never actually contribute anything. I'm pretty sure I'm doing something wrong, and I would love to figure out how to change that, because it's just burning me out, and I don't think it's helping anyone (much less my project).

@tute
Copy link

tute commented Mar 19, 2015

I respond pretty quickly to issues/PRs in my projects, and people get surprised that there's a person (a person!) willing to help them. Some newcomers send a PR out of the blue, don't expect much, and find they could send two more that same day. They get excited and actually do it! This makes me think that having a personal approach in the README or CONTRIBUTING documents helps people taking that hand and moving forward. Adding a note: "if you are new and would like to work with me, here's my contact details" can be a useful onboarding step.

I observed the opposite on the other side of the coin. Two "real world" mentees who expressed interest in contributing to OSS projects couldn't find a good project to work on, nor follow along with one I would point and help with. I assume this is related with #1 (comment): it's daunting to study a monolith so you can fix some parts of it, and you don't have enough experience to read the relevant parts only. I believe these mentees where learning ten things at a time and didn't feel committed enough to any library to understand how it works and how to improve it. This leaves me with two thoughts:

  1. Inviting a new comer to contribute to a project might add unnecessary noise, in the form of soft skills you need to learn until you can actually deliver value. To be able to "scratch their own itch" they need to be intermediate level and understand how a given library they use could be improved. Meanwhile, being just a user might help with focus.
  2. Hand-holding through the first issues/PRs, explaining the etiquette surrounding an Open Source contribution is a must, until the person is comfortable enough asking questions to unknown people, poking around with the library, sending PRs for the discussion and not for the merge, etc.

@tute
Copy link

tute commented Aug 23, 2015

Suggestion on setting up a failing test in a repo, as a starting point for new contributors: https://medium.com/@kentcdodds/first-timers-only-78281ea47455

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants