Difference between revisions of "DPS909/OSD600 Fall 2017 Lab 4"

From CDOT Wiki
Jump to: navigation, search
(3. Blog)
(3. Blog)
Line 231: Line 231:
 
| 36
 
| 36
 
| Teddy Prempeh
 
| Teddy Prempeh
  Thimble,
+
  Thimble
 
  https://teddyprempeh.wordpress.com/2017/10/07/my-first-bug/
 
  https://teddyprempeh.wordpress.com/2017/10/07/my-first-bug/
 
|  
 
|  

Revision as of 00:21, 7 October 2017

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:

# Name Project(s) (e.g., Thimble, Rust) Blog Post (URL)
1 Jiel Selmani DevTools(debugger.html), DevTools(JSON Viewer), A-Frame (WebVR) http://mylyfeincode.blogspot.ca/2017/09/finding-bug-is-harder-than-you-think.html
2 Nicholas Krause Rust(Core language and tools),GCC(C/C++ Compiler) https://nicholas95com.wordpress.com/2017/09/29/finding-open-source-bugs/
3 Michael Pierre Thimble (Online Code Editor) https://michaelpierreblog.wordpress.com/2017/09/29/the-search-for-bugs-and-contribution-to-the-open-source-community/
4 Haoyu Yang Thimble (Online Code Editor) https://haoyu1337.blogspot.com/2017/10/first-time-working-on-bug-for-thimble.html
5 Joshua Longhi Rust tools (rust-bindgen) https://jlonghiblog.wordpress.com/2017/10/03/contributing-to-open-source/
6 Jay Yin Mozilla "network" http://jyopensource.blogspot.ca/2017/10/requesting-my-first-bug-on-open-source.html
7 Dan Epstein Firefox Dev Tools: Framework http://www.danepstein.ca/its-time-to-fix-open-source-bugs/
8 Anthony LoMagno Thimble https://anthonylomagno.wordpress.com/2017/10/03/capturing-my-first-bug/
9 Azusa Shimazaki Thimble http://assmith2017.blogspot.ca/2017/10/bugs-on-open-source.html
10 Sean Prashad Documentation (Crates.io), Documentation (Rust), Documentation & Unit Tests (Neon) http://seanprashad.com/blog/first-contact.html
11 Gaurav Verma Thimble, testpilot, Firefox 48 http://gblogs2017.wordpress.com/2017/09/30/a-quest-to-find-a-bug/
12 Fateh Sandhu Thimble & pdf.js https://firefoxmacblog.wordpress.com/2017/10/03/found-a-bug/
13 Hans van den Pol Firefox Sync: Backend & Firefox for Android https://opensourcetoronto.wordpress.com/2017/10/03/finding-my-first-open-source-bugs/
14 Eric Schvartzman Mozilla Thimble - UI change https://ericschvartzman.blogspot.ca/2017/10/contributing-to-open-source-thimble.html
15 Ajla Mehic Thimble https://amehic.wordpress.com/2017/10/04/first-open-source-bug/
16 Joao Rodrigues Thimble https://jmrodriguesgoncalves.blogspot.ca/2017/09/lab-4-finding-my-first-open-source-bug.html
17 Yankai Tian Firefox Mobile Android https://ytian38.wordpress.com/2017/10/04/bug-not-bug/
18 Parthkumar Patel Thimble https://ppatel221.wordpress.com/2017/10/04/go-away-bug/
19 Mithilan Sivanesan Firefox Toolkit, Firefox Developer Tools:Storage Inspector https://mithilanblog.wordpress.com/2017/10/05/bug-hunting/
20 Hadi Saeed Pontoon https://techbreaksblog.wordpress.com/2017/10/05/getting-started-with-mozilla-pontoon/
21 Eric Suarez Thimble https://esoscode.wordpress.com/2017/10/05/finding-my-first-bug/
22 Dilan Guneratne Thimble https://dnguneratne.wordpress.com/2017/10/05/1-bug-2-bug/
23 Marco Beltempo Thimble http://www.marcobeltempo.com/misc/mozilla-thimble-first-open-source-bug/
24 Leonel Jara Mozilla Toolkit https://lejara.wordpress.com/2017/10/04/my-first-bug-adventure/
25
26 Steven De Filippis PDF.js https://dps909.defilippis.ca/index.php/2017/10/03/researching-bugs-in-mozilla-products/
27 Diana Dinis-Alves Thimble https://ddinisalves.wordpress.com/2017/10/04/catching-bugs-the-path-to-becoming-mushiking/
28


29
30
31
32
33 Phil Henning Addon-server, Balrog https://bluesockphil.wordpress.com/2017/10/01/catching-my-first-bug/
34 Avedis Zeitounilian Thimble, Firefox(Android) http://avedis777.blogspot.ca/2017/09/my-journey-of-fixing-bugs.html
35 Earle white mozilla/activity-stream https://ewhite7blog.wordpress.com/2017/10/05/contributing-to-the-mozilla-code-base/
36 Teddy Prempeh
Thimble
https://teddyprempeh.wordpress.com/2017/10/07/my-first-bug/
37
38
39
40