Homework - Bugfix
Real learning in computing comes more from doing and less from studying. Debugging, figuring out how some software works and how it doesn't, is an interactive process that develops basic engineering practices and, in the open source context, community engagement and collaboration.
A bug can be anything: an unintended side-effect in a low-level routine, a user-interface cleanup, a feature enhancement, grammatical errors or lack of clarity in the project's documentation.
Broadly, you have two different options here. You can:
In the event of the second case, make sure you file the bug in the project's tracker before proceeding.
You can fix a bug in any project you like. The best to pick is something you already use, something with which you're already familiar. If you can't think of any projects to investigate off the top of your head, here's a list of suggestions.
Listed by the Fedora Project
http://github.com/and filter by language (to a language that you know).
Really, the sky is the limit here.
For background, you might want to also check out the project on
It can help you characterize what kind of community orbits around
Once you've identified a bug that needs fixing, you'll need to get
ahold of the source. In most cases, the code for a project will be
hosted on a forge and the process of forking and cloning the source
should be straightforward. If you forget how to do this for
github, you can
Homework - First Flight.
For whatever project you've chosen, you should ask that project's
community for help. Look for IRC channels and project
mailing lists. You'll be communicating with developers who have a lot
on their plate so make sure to
be polite and leave your ego at the door.
Find the code related to the bug; use whatever code navigation tools
you're more familiar with. The instructor's favorite method is:
$ grep -inr "SOMEKEYWORD" project_src/ .
Fix the bug, this may require some thinking, and some more asking around.
Test your fix! Project maintainers hate nothing more than receiving a patch that breaks every other function of the project. Often, projects have built-in test suites. If yours does, run it!
Prepare your patch with descriptive commit messages. Follow the method for submitting patches recommended by your project and submit!
Make sure the project community can easily understand what you did and why you did it.
Make sure there is a reference in the tracked bug ticket to your patch (that is, if the project maintains a bug tracker).
Write a blog post about this process and provide relevant links where possible to documentation.
You will be graded on your post and the explanation of your process. Extra kudos (but not extra credit) for super epic patches. Extra credit (actual extra credit) for patches that are actually accepted upstream.
As with all of your assignments, you'll be submitting them via your
.yaml file through a pull request on Github. Be sure to follow formatting and whitespace, and to name your entry in the hw directory like so:
Once your patch has been accepted, mosey on over to
- Create an account
- Find the project you patched
- If it doesn't exist, you can add it yourself
- "Claim your position" as the author of the commit(s) you sent in to increase your rank among open source developers of the world!