Difference between revisions of "DPS909/OSD600 Fall 2017 Release 0.2"

From CDOT Wiki
Jump to: navigation, search
(→‎4. Submission)
(→‎4. Submission)
Line 97: Line 97:
 
|-
 
|-
 
| 3
 
| 3
−
|
+
| Phil Henning
−
|
+
| https://trello.com/c/vIdzadUZ
−
|
+
| WIP
 
|-
 
|-
 
| 4
 
| 4

Revision as of 16:23, 19 December 2017

0.2 Release

Your second, and final release is due Friday Jan 5th.

You are asked to find and fix a bug or bugs in any open source project on GitHub. Unlike your first release, you can work on any open source project, not just Mozilla. Below you will find a suggested set of projects and tools to consider.

NOTE: this release needs to be larger than your first, which could mean working on a more complicated bug, or doing more bugs (e.g., more smaller bugs). You must extend yourself from what you did in your first release and demonstrate some growth. Having said that, don't extend yourself so far that you fail to complete the work. Spend time assessing your skill and goals, and work to find bug(s) that match.

1. Possible Projects

You can work on any open source project for this release. Not all projects are good choices, however, and you are encouraged to discuss your choice with your professor.

One way to find projects is to look at the following:

  • 24 Pull Requests - similar to the Hacktoberfest bugs, with lots of project/bug ideas for you to contribute to in December.
  • GitHub's Trending projects - you can see which projects are trending on GitHub, and maybe find one that would be interesting to you. Try limiting the language to one you want to work in (e.g., JavaScript).
  • GitHub Explore - list of many projects categorized into topics. Maybe you'll find one that you like there.

As was previously the case, you can also work on a Mozilla project. The most successful projects for our students so far have been:

The other Mozilla project areas are also still available:

2. Project Scope

This release needs to be "more" than your first, but defining what "more" is can be hard. What I want to see is that you've consciously taken on a larger and/or more complex piece of work. Where your first release was about learning git, GitHub, how to contribute to a new project, and the like, this release should be a more intermediate task. Perhaps you focused on a documentation issue in your first release, and this one will be about writing code. Or maybe you worked on a fix, and this time you want to try and take on adding a feature. Or maybe you worked on one but, and this time you're going to work on two.

Whatever you do, I want to show some growth during this release. Stretch yourself to do "more" than you did last time, even if that's only a small step--making progress requires that you go a bit further each time.

If you think you're finished after working on this for a few days, it's a good sign that you probably need to pick more bugs to add to your release. This should take you some time, and you have 1 month to do it.

3. FAQ

  • Can I work on some random open source project from GitHub? Yes. But make sure you are picking a project that is active (is anyone still working on it?), wants contributions (not all do), is open to new people, etc. Don't work on something that won't be supportive.
  • Can I start my own open source project and work on that? No. This project is about contributing to existing, large, open source projects, which involves learning many skills, tools, and processes that will be valuable to you in your career as a developer.
  • Can I work with a partner, or in a group? No. You can collaborate with others in the course (or from Mozilla) on your bug(s), but you need to "own" your own bug, and do the work yourself. Having people give you advice or help, and doing the same for others, is fine. However, "help" doesn't mean one person does it all.
  • Can I work on something I don't know (e.g., Rust, Firefox, ...)? Yes. As long as you're willing to push yourself to learn what you need to know, you can do it. You have 4 weeks to accomplish this, which is lots of time to research, learn, fail, and succeed.
  • What if I write a fix and the project rejects it, will I still get marks? Yes. You will be marked on the process, how you work, and what you create. Projects will almost certainly reject your first attempt in code review, and offer comments on what to fix. It might take a few rounds of review/re-submission for you to get your bug(s) finished. That's normal.
  • When should I start working on my bug? Now. Fixing a bug in a large code base you don't know takes lots of time. You have lots of time (1 month), don't waste it. Work on your bug every few days for a short amount of time; don't leave it until a few days before it's due.
  • Where can I go for help? You can talk to your classmates on Slack. You can also reach out to the developers in their communication channels (Slack, gitter, mailing list, irc, etc). Each project/tool at Mozilla has its own communication channels, and you are encouraged to join them. Be bold, introduce yourself, and get started working in community.
  • What do I do if someone else is already working on a bug? You need to communicate your intent to work on something. Leave a comment in a bug, and let people know you are interested in working on it. If someone else is working on it, but hasn't made progress in a long time, you can leave a polite question asking if it's OK for you to take it over. If another student also wants to work on a bug, come see your professor for help finding another suitable issue.
  • How do I submit my work? You need to have a Pull Request or Attachment Patch (i.e., completed code) for your bug submitted to the correct bug tracker. You also need a blog post discussing your process, what you learned, the fix, etc. See below.

4. Submission

You need to do the following in order to complete this release

  1. Find and fix your bug(s).
  2. Follow-up on any review comments you receive in pull requests, an try to get your work merged. This may not be possible in the time we have, but make sure you aren't the reason it doesn't happen.
  3. Blog about your work as you do it, and upon completion. You should document how you do what you do, what you did, what you learned, etc. Make this a record of your abilities that will help show people what you're capable of doing.
  4. Add any bugs you work on to the DPS909 & OSD600 Fall 2017 Bug List
# Name Bug(s) (URLs) Blog Post (URL)
1 Nicholas Krause https://github.com/rust-lang/rust/pull/46623 https://github.com/rust-lang/rust/issues/46478 https://github.com/rust-lang/rust/issues/46449 https://wordpress.com/post/nicholas95com.wordpress.com/236
2 Jay Yin https://github.com/mozilla/foundation.mozilla.org/issues/235, https://github.com/mozilla/mofo-bootstrap/issues/122 https://jyopensource.blogspot.ca/2017/12/looking-for-more-bugs_15.html
3 Phil Henning https://trello.com/c/vIdzadUZ WIP
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909/OSD600_Fall_2017_Release_0.2&oldid=130135"