Intro to free software/open source


AJ, Winter 2 batch

Serial FOSS contributor

FOSS (co)maintainer of several projects


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")


Fork the project

git clone <your fork>

Get set up -,

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

Probably on Freenode - just use

Type the channel name (including the #)

Don't "auth to services"

Don't say "can I ask a question?" - just ask!

No, really


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


Projects not on GitHub

More resources


OSS at RC on Zulip


Producing Open Source Software

How I passed 2k GitHub contributions


Access this presentation again

Or get the source code