Difference between revisions of "DPS909/OSD600 Fall 2017 Lab 4"
(→3. Blog) |
(→3. Blog) |
||
| Line 73: | Line 73: | ||
|- | |- | ||
| 5 | | 5 | ||
| − | | | + | |Joshua Longhi |
| − | | | + | |Rust tools (rust-bindgen) |
| − | | | + | |https://jlonghiblog.wordpress.com/2017/10/03/contributing-to-open-source/ |
|- | |- | ||
| 6 | | 6 | ||
Revision as of 22:04, 2 October 2017
Contents
Getting Ready to Fix Open Source Bugs
In this lab you will work to find and claim two bugs from the list of possible bugs for the 0.1 Release, join the developer community, and begin working on your first release.
1. Finding Bugs
Begin by reading the entire document for the 0.1 Release.
You need to pick one or more projects/products to work on from the list in order to find two bugs for your first release. Why two? It is possible, and perhaps likely, that during the month that you're working on this first release, that someone else could come along and take your bug (i.e., submit a fix). Or, you might find that once you start working on the bug, you realize that it's not a good fit for your skills/interest.
In both cases, you need to have a backup plan. Having at least two bugs will mean that you have options. You can choose more than two, but it's rare for a project to assign more than one bug to the same person at a time: we don't want to encourage "hoarding" of open bugs.
Once you've found the bugs you want to work on, pick one and leave a comment on the bug/issue, introducing yourself, and indicating that you'd like to work on it. Here's an example (feel free to write whatever you think makes sense):
I'm a student at Seneca college learning open source, and I was hoping to work on this bug for my course. If no one else is currently working on it, I'd like to give it a try.
This step is important, or else there will be confusion in the community about who is actually working on the bug. You don't want another classmate, or community member somewhere in the world, to take a bug that you are working on and submit it themselves.
Open source requires open communication.
2. Getting Started on your Bugs
After you have picked your bugs, and left a comment on one of them, start to research the following questions:
- Where is the code that I need to work on for this bug?
- What do I need to install, setup, configure, etc. in order to begin?
- Where does the community of developers working on this code do most of their communication? Are they on Slack, IRC, a mailing list, a Google Group, something else? Locate them, and join their communication channel(s). Introduce yourself, and let them know you're a new community member who is hoping to contribute.
You should begin working on your bug(s). The sooner you start, the better, since you will have lots of learning to do before you can fix things. Don't procrastinate: try to spend a little time on it each day, or every other day. If you leave this until the last minute, you'll have endless problems.
3. Blog
Write a blog post about your bugs, and the experience of getting started. Here are some things to consider and discuss:
- Which bugs did you choose? Include links to them.
- Why did you choose these bugs? What was it about these projects that interested you?
- What are you hoping to learn by working on these bugs?
- What are you nervous about?
- What are you going to need to learn?
- Where do the developers on the project(s) you chose communicate online? What happened when you introduced yourself? Were you greeted warmly, ignored, or met with hostility?
- What's your guess as to how long it will take you to solve this bug? Later, you'll be able to compare this estimate to the reality of what it really involved.
After you've completed the lab, add your name, project(s) and blog url:
