Difference between revisions of "DPS909/OSD600 0.1 Release"
(→4. Submission) |
(→4. Submission) |
||
| Line 224: | Line 224: | ||
|- | |- | ||
| 31 | | 31 | ||
| − | | | + | | Arpit Gandhi |
| − | | | + | | https://github.com/devtools-html/debugger.html/pull/4905 |
| | | | ||
|- | |- | ||
Revision as of 23:38, 18 December 2017
0.1 Release
Your first release is due one month from today, Friday Oct 20.
You are responsible to find and fix a bug or bugs in a Mozilla product or tool. 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 Mozilla products/tools/bugs besides those listed below, as long as you talk to your professor first.
1. Possible Good First Bugs
- First, have a look at Bugs Ahoy! tool showing good starter bugs from across Mozilla. It covers bugs across many technologies, products, and tools. See also the refined search with only "simple" bugs. You can further limit your search by selecting options on the left. If you end-up working on Firefox/browser bugs specifically, see these docs.
Some other specific ideas to consider:
- Thimble code editor/learning tool (node.js, HTML5) "Good First Bug"
- Firefox Activity Stream (JS, CSS) dev docs "Good first bug"
- Addons Server (Python/Django Server and API) "good first bug"
- A-Frame WebVR framework "help wanted, easy"
- Firefox Dev Tools (JavaScript, CSS, React, etc) "easy" bugs.
- Firefox JavaScript Debugger (React, JS) bugs, more bugs.
- Mozilla Network site (Python web app) "help wanted"
- Network Pulse API (Python REST API server) "help wanted"
- Pontoon localization tool (Python, JS, HTML5) unedited bug list
- Testpilot experimental feature tool (React, HTML5, JS) "good first bug"
- PDF.js (JavaScript PDF viewer used in Firefox) "good-beginner-bug"
- Firefox Mobile iOS (Objective-C, Swift, iOS) "good first bugs"
- Firefox Mobile Android (Java, C++, JS) "good first bugs"
- Balrog Update Service (Python) https://github.com/mozilla/balrog - some potential bugs: 1396859, 1138418, 1374638, 1386400
- Neon (Rust bindings for node.js) see recent post about ways to get involved
- Build/Automation Tool: Linting (Python, JS) Possible bugs, talk to your professor if interested
- Rust (programming language, sites, and project) contribute docs, "easy" bugs, Crates.io package manager "easy" bugs, other ideas for contributing to Rust and tooling
- rr (C++ debugging tool for Linux) "goodfirstbug", good podcast about what rr is here.
2. 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 you help me, I'm totally lost, I have no idea what to work on. I'd suggest you work on Thimble https://github.com/mozilla/thimble.mozilla.org.
- 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.
