OSD & DPS909 Winter 2018 Release 0.2

From CDOT Wiki
Revision as of 14:11, 21 February 2018 by David.humphrey (talk | contribs)
Jump to: navigation, search

0.2 Release

Your second release is due Monday March 26.

You are responsible to find and fix a bug or bugs. 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.

1. Pick a Possible Project(s)

Your first step is to research and find a suitable open source project on GitHub. 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.

==4. ...

Still need to finish this...

FAQ

  • Can I work on some random open source project from GitHub? No. Please focus on a Mozilla project, so that you get connected into the Mozilla project, which is welcoming of new contributors and students. Not all open source projects on GitHub are like Mozilla.
  • 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 Mozilla 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.
  • Where can I go for help? You can talk to your classmates on Slack. You can also reach out to the developers at Mozilla. Each project/tool at Mozilla has its own communication channels, and you are encouraged to join them, whether it be Slack, IRC, mailing lists, Gitter, etc. Be bold, introduce yourself, and get started working in community.
  • 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.
  • 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

# Name Project Intro Blog (URL) Pull Request(s) (GitHub URLs) Final Blog Post (URL)
1
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