Changes

Jump to: navigation, search

OSD & DPS909 Winter 2018 Release 0.2

564 bytes added, 14:19, 21 February 2018
no edit summary
=0.2 Release=
Your second In this release, you are asked to contribute to a real open source project. This 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. 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)==
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.
==4You 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.
Still need to finish this..==4.Submit Pull Request(s) and Fix Review Comments==
==FAQ==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.
* 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==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 (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 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.
* Where can What do I go for helpdo if someone else is already working on a bug? You can talk What if someone else also wants to your classmates work on Slack. a bug? You can also reach out need to communicate your intent to the developers at Mozillawork on something. Each project/tool at Mozilla has its own communication channelsLeave a comment in a bug, and let people know you are encouraged to join them, whether interested in working on it. If someone else is working on it be Slack, IRCbut hasn't made progress in a long time, mailing lists, Gitter, etcyou can leave a polite question asking if it's OK for you to take it over. Be boldIf another student also wants to work on a bug, introduce yourself, and get started working in communitycome see your professor for help finding another suitable issue.
* 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==
* 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 Please fill out the correct bug tracker. You also need a blog post discussing your process, what you learned, the fixtable below with all relevant links, etc. See below.including:
==4* 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. Submission==
{| class="wikitable"

Navigation menu