Difference between revisions of "DPS909/OSD600 Fall 2017 Lab 10"
m (→Submission) |
m (→Submission) |
||
| Line 108: | Line 108: | ||
| Sean Prashad | | Sean Prashad | ||
| https://github.com/mozilla/activity-stream/issues/3409, https://github.com/rust-lang/rust/issues/29378, https://github.com/rust-lang/rust/issues/44061, | | https://github.com/mozilla/activity-stream/issues/3409, https://github.com/rust-lang/rust/issues/29378, https://github.com/rust-lang/rust/issues/44061, | ||
| − | | | + | | https://github.com/mozilla/activity-stream/issues/3373 |
| WIP | | WIP | ||
|- | |- | ||
Revision as of 19:48, 10 December 2017
Contents
Planning Release 0.2
In this lab you will begin working on Release 0.2, and create a plan for what you'll work on, and how you'll get that work done.
Step 1. Read about Release 0.2
You should begin by reading Release 0.2. After you've read it, ask yourself the following questions:
- Do you have any questions? If so, please ask them via Slack so that we can clarify the release.
- Do you know how to extend myself for this release? What will working on a "larger" piece of open source look like for me? More bugs? Larger bug? What's my plan for growth?
- Do you have any immediate ideas for what you'd like to do next? If the answer is "no," that's OK, but you need to do something about that. See step 2.
Step 2. Find some bugs
After you've read the release and answered the questions above, you need to find some bugs to work on. It's important not to put this off, and finishing this lab will mean you must find the bugs you'll do. Here's how to do it:
- You should look at the links of potential projects and first narrow things down to one or a few projects. Ideally you should have a backup plan (i.e., a secondary project) that you could work on if you get stuck with your first somehow.
- Next, pick a few bugs that interest you. You need more than one, since something could go wrong with a single bug (someone else might fix it first, you might get stuck, it might be way harder than you imagined, you might find that it's already solved, etc). You should aim to pick at least one more bug than you need. So if you're planning on fixing 2 bugs, you should probably find 3 at this stage.
- Follow your chosen projects' instructions for "claiming" bugs. At the very least, you probably need to leave a comment in the bugs saying that you'd like to try and work on these. Make sure you connect with someone in the project so that they know you are going to try and work on this.
Step 3. Make a plan
After you've chosen your bugs, you need to begin thinking about how you'll fix them. This includes the following:
- How will you use the time you have left in the semester to get this done? You have other courses, holidays, etc, and still need to find time for this. What is your plan?
- What do you need to know in order to do this work? Do you have to learn something new? Are there tools you'll need to learn, code you don't understand?
- Do a quick survey of your bug and what's going to be involved in fixing it. Sometimes we don't fully understand what a bug is all about until we start trying to work on it. After 30 mins of research you might discover that it's going to be easier or harder than you thought. How will you respond to that?
Submission
Please add your info to the table below. You need to include a blog post which covers the following:
- How will you try to grow during this release? What are your goals (e.g., work on larger bugs, try to do more bugs, learn technology X, ...)
- Which projects did you consider? What made you end up choosing one over the others? How did you decide?
- Which bugs are you going to work on (include links)?
- Which bugs are you saving as backups in case something goes wrong?
- Document your plan from Step 3. above.
