667
edits
Changes
Created page with "=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..."
=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 <code>CONTRIBUTING.md</code> and <code>README.md</code> 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:
* [https://github.com/trending 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).
* [https://github.com/explore GitHub Explore] - list of many projects categorized into topics. Maybe you'll find one that you like there.
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction Mozilla] - you could work on Firefox or any number of other Mozilla projects. Mozilla uses C/C++, JS, HTML, Python, etc. There are literally thousands of ways to get involved.
* [https://github.com/Microsoft/vscode Visual Studio Code] (Electron, TypeScrypt, JS, CSS, React)
* [https://github.com/Brave Brave] - you could work on the Brave web browser for [https://github.com/brave/browser-laptop desktop], [https://github.com/brave/browser-android-tabs Android], or [https://github.com/brave/browser-ios iOS]
* [https://datproject.org/ DAT Project] - p2p web technology, including the [https://beakerbrowser.com/ Beaker Browser]
* [https://github.com/tensorflow/tensorflow Tensorflow] or [https://github.com/PAIR-code/deeplearnjs DeepLearn.js] or any number of other [https://github.com/topics/deep-learning Machine Learning/AI frameworks].
* [https://github.com/topics/bitcoin Bitcoin] or [https://github.com/topics/etherium Etherium] or other [https://github.com/topics/cryptocurrency cryptocurrency/blockchain projects].
* [https://github.com/topics/database Databases] - there are hundreds of open source database projects, libraries, and tools
* [https://github.com/topics/docker Docker] and other container technology is hot right now
* [https://github.com/topics/game-engine Game Engines] - many are open source and have ways to get involved
* [https://github.com/topics/nodejs Node.js] is a huge ecosystem, with thousands of sub-projects, modules, and tools that need help.
* [https://github.com/mozilla/activity-stream Firefox Activity Stream] (JS, CSS, React) [https://github.com/mozilla/activity-stream#for-developers dev docs] [https://github.com/mozilla/activity-stream/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+first+bug%22 "Good first bug"]
* [http://firefox-dev.tools/debugger.html/ Firefox JavaScript Debugger] (React, JS) [https://t.co/4ewG5n9Q8D bugs], [https://t.co/LHCPAxhgVS more bugs].
* [https://pontoon.mozilla.org/ Pontoon localization tool] (Python, JS, HTML5) [https://bugzilla.mozilla.org/buglist.cgi?product=Webtools&component=Pontoon&resolution=---&list_id=10786825 unedited bug list]
* [https://www.rust-lang.org Rust] (programming language, sites, and project) [https://www.rust-lang.org/en-US/contribute.html contribute docs], [https://github.com/rust-lang/rust/labels/E-easy "easy" bugs], [https://github.com/rust-lang/crates.io/issues?q=is%3Aissue+is%3Aopen+label%3AE-easy Crates.io package manager "easy" bugs], [https://www.rustaceans.org/findwork other ideas for contributing to Rust and tooling]
* [https://addons.mozilla.org/ Addons Server] (Python/Django Server and API) [https://github.com/mozilla/addons-server/labels/contrib%3A%20good%20first%20bug "good first bug"]
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 [https://help.github.com/articles/watching-and-unwatching-repositories/#watching-a-single-repository 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 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.
==4. Submission==
{| class="wikitable"
! style="font-weight: bold;" | #
! style="font-weight: bold;" | Name
! style="font-weight: bold;" | Project Intro Blog (URL)
! style="font-weight: bold;" | Final Blog Post, including Bug/PR links (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
|
|
|
|}
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 <code>CONTRIBUTING.md</code> and <code>README.md</code> 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:
* [https://github.com/trending 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).
* [https://github.com/explore GitHub Explore] - list of many projects categorized into topics. Maybe you'll find one that you like there.
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction Mozilla] - you could work on Firefox or any number of other Mozilla projects. Mozilla uses C/C++, JS, HTML, Python, etc. There are literally thousands of ways to get involved.
* [https://github.com/Microsoft/vscode Visual Studio Code] (Electron, TypeScrypt, JS, CSS, React)
* [https://github.com/Brave Brave] - you could work on the Brave web browser for [https://github.com/brave/browser-laptop desktop], [https://github.com/brave/browser-android-tabs Android], or [https://github.com/brave/browser-ios iOS]
* [https://datproject.org/ DAT Project] - p2p web technology, including the [https://beakerbrowser.com/ Beaker Browser]
* [https://github.com/tensorflow/tensorflow Tensorflow] or [https://github.com/PAIR-code/deeplearnjs DeepLearn.js] or any number of other [https://github.com/topics/deep-learning Machine Learning/AI frameworks].
* [https://github.com/topics/bitcoin Bitcoin] or [https://github.com/topics/etherium Etherium] or other [https://github.com/topics/cryptocurrency cryptocurrency/blockchain projects].
* [https://github.com/topics/database Databases] - there are hundreds of open source database projects, libraries, and tools
* [https://github.com/topics/docker Docker] and other container technology is hot right now
* [https://github.com/topics/game-engine Game Engines] - many are open source and have ways to get involved
* [https://github.com/topics/nodejs Node.js] is a huge ecosystem, with thousands of sub-projects, modules, and tools that need help.
* [https://github.com/mozilla/activity-stream Firefox Activity Stream] (JS, CSS, React) [https://github.com/mozilla/activity-stream#for-developers dev docs] [https://github.com/mozilla/activity-stream/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+first+bug%22 "Good first bug"]
* [http://firefox-dev.tools/debugger.html/ Firefox JavaScript Debugger] (React, JS) [https://t.co/4ewG5n9Q8D bugs], [https://t.co/LHCPAxhgVS more bugs].
* [https://pontoon.mozilla.org/ Pontoon localization tool] (Python, JS, HTML5) [https://bugzilla.mozilla.org/buglist.cgi?product=Webtools&component=Pontoon&resolution=---&list_id=10786825 unedited bug list]
* [https://www.rust-lang.org Rust] (programming language, sites, and project) [https://www.rust-lang.org/en-US/contribute.html contribute docs], [https://github.com/rust-lang/rust/labels/E-easy "easy" bugs], [https://github.com/rust-lang/crates.io/issues?q=is%3Aissue+is%3Aopen+label%3AE-easy Crates.io package manager "easy" bugs], [https://www.rustaceans.org/findwork other ideas for contributing to Rust and tooling]
* [https://addons.mozilla.org/ Addons Server] (Python/Django Server and API) [https://github.com/mozilla/addons-server/labels/contrib%3A%20good%20first%20bug "good first bug"]
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 [https://help.github.com/articles/watching-and-unwatching-repositories/#watching-a-single-repository 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 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.
==4. Submission==
{| class="wikitable"
! style="font-weight: bold;" | #
! style="font-weight: bold;" | Name
! style="font-weight: bold;" | Project Intro Blog (URL)
! style="font-weight: bold;" | Final Blog Post, including Bug/PR links (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
|
|
|
|}
