Intro to free software/open source
Hi
AJ, Winter 2 batch
FOSS (co)maintainer of several projects
Today
Picking a project
Filing good issues
Finding an issue to contribute commits to
Getting help along the way
Sending a Pull Request
Picking a project
Ideally something you already want to do (bugfix in a library you use, etc.)
Ultimately, something you're passionate about
Easy way to contribute: filing good issues
Step 1: search for duplicates
Check open and closed issues
Use multiple keywords
Search mailing list/chat archives if the project has them
Don't add +1s
The issue itself
Be really precise
Bugs: version numbers, logs, everything you can think of
Steps to reproduce & what you expected to happen and what actually happened
Features: precise description of the feature and the problem
What kind of bug report would you like to receive?
Shared history
Projects have a shared history
Composed of issues, emails, chat messages, git commits, PRs
By contributing to a project you're adding to that history
"Can you rewrite your commit message to follow conventions?"
Why we record all discussions, try to make issues useful for future readers, etc.
Finding an issue
Look for "good first pr", "bite sized", "good first bug", "up for grabs", "first timers only"
Doesn't have to be code
Documentation is great too
Comment in the issue ("I'm working on this")
Prepare
Fork the project
git clone <your fork>
Get set up - CONTRIBUTING.md, README.md
Fix the bug
git checkout -b fix-some-bug
Edit/debug/write tests/etc.
git add
git commit
git push --set-upstream origin fix-some-bug
Getting help
Chat (IRC) - project's IRC channel should be listed
Type the channel name (including the #)
Don't "auth to services"
Don't say "can I ask a question?" - just ask!
No, really
Alternatives
Try a mailing list
Send a work-in-progress Pull Request
Sending a Pull Request
Visit your fork on GitHub
"You recently pushed branches"
Click "Compare and Pull Request"
Edit PR text if you want
If work-in-progress: prefix title with "[WIP]", note "WIP, do not merge" in body, ask your question
When you're happy, click "Send Pull Request"!
Responding to feedback
Status check failures
Maintainer feedback
Status check failures
Found at the bottom of the PR view
Click "details"
Click on the failing test
Examine the log
Responding to status check failures
Are the failures caused by you?
Sometimes they aren't
But if they are, fix them
Create a new commit on the same branch
Push - it'll show up in the PR
Maintainer feedback
Look at inline responses
Fix issues, respond to questions
Don't be afraid to ask for more explanation if you think the maintainer's wrong
(But note that sometimes the answer is "no, because")
Add fixes in the same way: commit and push
Rinse, repeat
Sometimes it takes many cycles
Don't be discouraged
The maintainer isn't criticizing you
They want to help you improve quality
Remove [WIP] if you think code is ready for merging
Finishing PRs
If your PR was merged, great!
Zulip > victory stream
If it was closed, it's okay
Nothing personal
Maintainer sees other factors you didn't consider
Either way, you did it!
Things I didn't cover
Nicer IRC setups
Sending PRs for things that don't already have an issue
Contributing something other than commits
CLAs
Projects not on GitHub
More resources
Me
OSS at RC on Zulip
Access this presentation again