hacker school getting_started_in_open_source
TRANSCRIPT
Getting Started in Open Source
Why?
• “Scratch your own itch”
• Learn something new
• Solve a different class of problems
• Build your resume
• Make the world a better place
What?
• What you contribute to depends on your motivation and skills
• Itch scratching: fix a bug that’s always annoyed you
• If you’re not scratching an itch, how do you find an appropriate project?
Project selection criteria
• Needs a skill you have (e.g. programming in Python, QA, localization, documentation writing, test writing, answering questions on mailing lists)
• Friendly to new contributors
• Issue tracker, ideally with good first bugs or mentored bugs listed
• Clear process for accepting patches from new contributors
Getting to know a project
• Each open source project - even sub-projects within a larger project - has a different character and way of doing things
• Observation is helpful - mailing lists, newsgroups, IRC, bug tracker, user groups or meetups, conferences
• Understand social norms
• Read the code
• Understand the review process
• Make connections with mentors and others
Impostor syndrome
• Everybody else knows what they are doing.
• I’m not as good as they think.
• I’m a fake, and sooner or later I will be found out.
• I should be doing more.
• I don’t belong here.
• Correlation between impostor syndrome and intelligence
• Many developers feel this way. Remind yourself.
Now what?• Picked a project, what’s next?
• Get a checkout, build, install
• Find a bug
• Code reading
• Make and test a patch or pull request
• (Sign a contributor agreement)
• Put it up for review
• Some combination of waiting and socializing
• Patch lands! You are now a contributor
Getting set up
• This can be one of the hardest parts, and lots of people get put off by this:
• Installation
• Test data
• Building
• Reproducing the bug
• Solutions: this is on the project. Don’t be afraid to ask for help. Persevere.
Code reading
• Hard step on the path to mastery
• “Knowing where to tap”
• Look at the layout of the code (docs can help here, but sometimes not)
• Look for main event loop or controller
• Isolate your bug
Coding standards
• Find out if there is a formal one
• Follow it
• Sometimes you’ll notice informal ones as well
Gotchas
• Avoid end-of-rainbow problems, unwanted features, intractable bugs
• Avoid trolls - every project, like every workplace, has at least one
• Don’t be a troll
Dos
• Blog about your work
• Become involved in the community
• Help another noob get onboard - teaching is the best way to learn
• Make friends, learn stuff, make the world a better place
• WIN
We <3 contributors
• Projects would not exist without their contributors - they are a huge democratizing force
• Thank you!
