OSD & DPS909 Winter 2018 Release 0.2

From CDOT Wiki
Revision as of 08:12, 10 March 2018 by Mgquan (talk | contribs) (→‎6. Submission)
Jump to: navigation, search

0.2 Release

In this release, you are asked to contribute to a real open source project. This release is due Monday March 26.

Below you will find a suggested set of projects and tools to consider, as well as links to possible Good First Bugs. You are free to work on other products/tools/bugs besides those listed below, as long as you talk to your professor first.

Completing this release is a multi-step process, with various deliverables. Please read all instructions carefully so you don't miss any steps.

1. Pick a Possible Project(s)

Your first step is to research and find a suitable open source project on GitHub. Once you've chosen a project, add it to the table at the bottom, along with your name. This will help other students find you, if they are also working on the same code.

Important things to consider:

  • Make sure the project is still active. Many projects on GitHub are no longer being developed.
  • Try to find larger projects with many contributors vs. small projects, or those with only a small number of contributors. It is difficult to get help, feedback, or traction in small projects.
  • Try to find a project with a wide variety of bugs to work on. Projects with only a few issues filed are less likely to be good places to find contributions.
  • Look for signals in CONTRIBUTING.md and README.md files that a project is open to contributors.
  • Pick a project that uses technologies you are interested in learning, or already know well. Don't pick a project that uses things you dislike.
  • Consider picking a project you use yourself, something you love, and/or something you would be proud to say you worked on.

Here are some projects and areas to consider:

Spend some time looking at these projects and find something that fits your skills, interests, and goals. Fixing bugs in a big project is hard, so it's wise to pick something you will enjoy and succeed at doing.

2. Subscribe to your chosen Project(s)

Once you've chosen a project or two, spend some time "lurking" in it so you can get a sense of how things work. Before you dive into picking and fixing bugs, it's a good idea to observe how the project works, what areas are being worked on, what the priorities are, which tools/workflows are being used, etc. Here are a few ways you can accomplish this:

  • Read the project's documentation (website, README, Contributing, Code of Conduct, etc)
  • Watch the project's repository on GitHub to get email when people file/respond to bugs. NOTE: you might want to setup an inbox filter, as you'll likely get a lot of email when you do this.
  • Join the project's discussion channels. This might be Slack, IRC, or some other tool. It's normal to join channels and not say anything, just "listen," so don't feel weird doing it. You'll learn a lot by watching how they work. When you feel comfortable, introduce yourself and let them know you'd like to contribute.

After you've spent some time doing this, write a blog post introducing the project. Here are things to cover:

  • What is the project about?
  • Where is the code located?
  • Where are their docs?
  • How can you get involved?
  • Where can you go to get help?
  • What are some interesting things you've learned while observing the project (e.g., pull requests fixing bugs, adding features, discussions)?

3. Find some Bugs to Fix

Once you've found a project you like, and are happy to get involved, it's time to find some bugs to work on. Look in their Issues and perhaps talk to them on Slack/IRC or wherever they work, and find some possible bugs. Consider looking for issues with labels like good-first-bug, bug, help wanted, etc.

Try to pick a bug (or bugs) you can accomplish in the time you have available. For example, if a bug is really small, consider fixing more than one. If a bug is really huge (adding a new feature), consider whether it's reasonable to do this during this first release, or if you should wait for the next. You can talk to your professor to get help.

You are encouraged to work on any/all of the following:

  • Fixing code bugs
  • Writing documentation
  • Automating processes (e.g., build system work)
  • Localization, translation
  • Writing tests

When you've decided on bug(s) to work on, please leave a comment in the bug(s) asking if it's OK for you to do this. Someone else might be working on it, the bug might not exist anymore, or there might be a better bug you can work on. Communicate with the project's community before you spend hours working on the wrong thing.

4. Submit Pull Request(s) and Fix Review Comments

Submit one or more Pull Requests in order to fix your bug(s). Make sure you follow the project's instructions carefully for submitting work--every project does this slightly differently. When in doubt, go look at other closed pull requests to see how they did things.

When you get feedback, make sure you respond, and push more commits to fix any problems pointed out by your reviewer.

5. FAQ

  • 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 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. Mozilla 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.
  • What do I do if someone else is already working on a bug? What if someone else also wants to work 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.

6. Submission

Please fill out the table below with all relevant links, including:

  • Your name and the name of the open source project you're working on
  • An introductory blog post for your chosen project. See section 2. above for details.
  • Links to all Pull Requests you make to the project on GitHub.
  • A final blog post describing everything you did. Please include links to bugs, pull requests, and discuss what your bug was about, how you fixed it, what you learned, etc. Feel free to include screenshots, screencasts, video, or anything else you need to properly describe your work.
# Name Open Source Project Project Intro Blog (URL) Pull Request(s) (GitHub URLs) Final Blog Post (URL)
1 Matthew Quan VSCode, Brave (browser-laptop) https://mattprogrammingblog.wordpress.com/2018/03/09/osd600-release-0-2-part-1-working-with-vscode/ https://github.com/brave/browser-laptop/pull/13386, https://github.com/Microsoft/vscode/pull/43950, https://github.com/Microsoft/vscode-docs/pull/1487
2
3
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=OSD_%26_DPS909_Winter_2018_Release_0.2&oldid=132160"