Confirmed users
656
edits
Community:SummerOfCode19: Difference between revisions
→Project List
| (14 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
This is Mozilla's list of green-lit project proposals for the 2019 Google Summer of Code. | This is Mozilla's list of green-lit project proposals for the 2019 Google Summer of Code. | ||
<b>Are you a student looking to apply to GSoC with Mozilla?</b> You're in the right place. This page lists all | <b>Are you a student looking to apply to GSoC with Mozilla?</b> You're in the right place. This page lists all of our proposed [[SummerOfCode|Google Summer of Code]] projects. New suggestions can be made on [[Community:SummerOfCode19:Brainstorming|the Brainstorming page]]. Do not edit this page yourself; contact mhoye or Florian for edits. | ||
If you're interested in participating in Mozilla's GSoC program, you can choose from the list below, '''but you do not have to'''. You can submit a proposal for your own idea. You should look at the [[Community:SummerOfCode19:Brainstorming|guidelines]], though, and discuss your ideas or application in the #introduction channel on IRC.Mozilla.org. This is important, as GSoC projects '''must have''' a supporting member of the Mozilla community to evaluate and mentor them, named in the application. | If you're interested in participating in Mozilla's GSoC program, you can choose from the list below, '''but you do not have to'''. You can submit a proposal for your own idea. You should look at the [[Community:SummerOfCode19:Brainstorming|guidelines]], though, and discuss your ideas or application in the #introduction channel on IRC.Mozilla.org. This is important, as GSoC projects '''must have''' a supporting member of the Mozilla community to evaluate and mentor them, named in the application. | ||
Please bear in mind that a '''preexisting relationship with Mozilla is not a requirement for a successful GSOC proposal'''. While participating in Bugzilla is a good way to become familiar with how Mozilla works, "spamming" Bugzilla to establish your ''bona fides'' or improve your chances of a successful application has not historically been a successful approach. We're grateful for our volunteers' contributions, as always, but often that effort would be best put towards focusing on the proposals you are specifically interested in, and putting your effort into crafting an application for them specifically. | |||
===Application Advice=== | ===Application Advice=== | ||
| Line 15: | Line 17: | ||
* Apply on [https://summerofcode.withgoogle.com/ the GSoC site] (note that we have an [[SummerOfCode/ApplicationTemplate|application template]]). | * Apply on [https://summerofcode.withgoogle.com/ the GSoC site] (note that we have an [[SummerOfCode/ApplicationTemplate|application template]]). | ||
* It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that can improve your chances. Applying to more than that will seem like spam. | * It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that can improve your chances. Applying to more than that will seem like spam. | ||
* Participation in any Mozilla spaces, forums or events, including our GSOC projects, are subject to Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/participation/ Community Participation Guidelines], and you should read them carefully. | |||
Questions about individual projects are best addressed to the potential mentor of that project. These should be listed in the table below. If you want to contact a mentor and contact details are not here, ask people in the #introduction channel on IRC: irc://irc.mozilla.org/#introduction. If you have questions of any other sort, send mail to [mailto:mhoye@mozilla.com Mike Hoye]. He will try and respond promptly and direct your questions to the right person. | Questions about individual projects are best addressed to the potential mentor of that project. These should be listed in the table below. If you want to contact a mentor and contact details are not here, ask people in the #introduction channel on IRC: irc://irc.mozilla.org/#introduction. If you have questions of any other sort, send mail to [mailto:mhoye@mozilla.com Mike Hoye]. He will try and respond promptly and direct your questions to the right person. | ||
| Line 90: | Line 93: | ||
| | | | ||
|- | |- | ||
| GitHub Checks Support Improvements | | <s>GitHub Checks Support Improvements</s> | ||
| | | (withdrawn) | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
| Support GitHub Logins in Taskcluster | | <s>Support GitHub Logins in Taskcluster</s> | ||
| | | (withdrawn) | ||
| | | | ||
| | | | ||
| | | | ||
| | | | ||
|- | |- | ||
| Line 107: | Line 110: | ||
| [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness. | | [https://github.com/servo/servo/ Servo] currently supports a minimal subset of the [https://w3c.github.io/webdriver/ Webdriver standard]. We would like to improve Servo's support, and verify its correctness by passing a [https://github.com/web-platform-tests/wpt/tree/master/webdriver set of automated tests]. This project would involve writing Rust code to extend the webdriver server inside of Servo, as well as JavaScript and Python to support the [https://web-platform-tests.org/writing-tests/testdriver.html testdriver.js] testharness. | ||
| Familiarity with Python & JavaScript; interest in learning Rust | | Familiarity with Python & JavaScript; interest in learning Rust | ||
| [ | | [mailto:josh@joshmatthews.net Josh Bowman-Matthews] | ||
| [ | | [mailto:josh@joshmatthews.net Josh Bowman-Matthews] | ||
| [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description] | | [https://github.com/servo/servo/wiki/Support-Webdriver-based-tests-project Project description] | ||
|- | |- | ||
| Line 152: | Line 155: | ||
| A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey. | | A lesson learned thanks to our UX team is in Emerging Markets the data plan is dynamic: in late nights we have the most affordable bandwidth. Here's the question: Why not schedule big files and videos and have them downloaded when you're sleeping? The mvp would be an App which we can send urls to. After receiving these urls the App either downloads it directly or defer it to late night. As there are more and more background restrictions enforced on new Android APIs, this should be a fun and challenging journey. | ||
The ultimate goal of this would be to embed this downloader in our browser for Emerging Markets, Firefox Lite. Firefox Lite is not satisfied with the current Android Download Manager in several ways: We'd like to give users the ability to pause/resume a download, we'd like to download a file directly to SDcard (opposed to download it to the main storage and move it into SDcard). That being said, please focus more on the reusablility of your App as a library than the UX/UI of the App itself. Afterall, GSOC is a coding project! | |||
We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App design. | We've also prepared an even more ambitious mission for those who want tough challenges: Design the app and make it dynamic deliverable. With aabs we can satisfy both light and heavy users by defaulting Android Download Manager as the download tool and prepare the aforementioned downloader dynamically so that Firefox Lite itself is still minimized in terms of disk size. Nevin and mTwTm are Android developers who can provide assistance to Android App and library design. | ||
| Android Java/Kotlin | | Android Java/Kotlin | ||
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] | | [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] | ||
| [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com) | | [https://github.com/mTwTm/ mTwTm(Teng-pao Yu)] (mTwTm@mozilla.com), [https://github.com/cnevinc/ Nevin Chen] (nevin@mozilla.com) | ||
| | | We're receiving requests for mockups already; thank you! However, the core of this project to me is the downloading library rather than the App. To illustrate what might make a good proposal, we want you to imagine what would be a convenient way to schedule downloads. There are many ways we could do this: Copy-pasting download links, have the app opened whenever a link is clicked, or find a way to give other third-party apps access to your App's download queue. | ||
I would also encourage candidates to differentiate onself by focusing on demonstrating your understanding to Android Apps and download protocols. Brainstorming for more use cases is encouraged but we would really like to learn more about how you can implement this project efficently instead of what you can plan in your proposal. | |||
Also, we're utilizing the Mozilla Asia Product mail-list (https://groups.google.com/forum/#!forum/mozilla-asia-products) for discussions around this project. You might find some useful discussions there as well. | |||
|- | |- | ||
| Toolkit for sandboxing third-parties libraries in Firefox | | Toolkit for sandboxing third-parties libraries in Firefox | ||
| Line 176: | Line 183: | ||
to be used to compromise Firefox. | to be used to compromise Firefox. | ||
| C/C++, experience with WebAssembly | | C/C++, experience with WebAssembly | ||
| [https:// | | [https://github.com/EricRahm/ Eric Rahm] (erahm@mozilla.com) | ||
| [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd] | | [https://mozillians.org/en-US/u/froydnj/ Nathan Froyd] | ||
| | | | ||
| Line 227: | Line 234: | ||
| [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt] | | [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt] | ||
| [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt] | | [https://mozillians.org/en-US/u/ahal/ Andrew Halberstadt] | ||
| Writing docs for Firefox's in-tree [https://firefox-source-docs.mozilla.org/ source docs] is time consuming and difficult and the end result is difficult to navigate. | | Please see [https://bugzilla.mozilla.org/show_bug.cgi?id=1535452 bug 1535452] for technical information. | ||
Writing docs for Firefox's in-tree [https://firefox-source-docs.mozilla.org/ source docs] is time consuming and difficult and the end result is difficult to navigate. | |||
With [https://developer.mozilla.org/en-US/ MDN] de-prioritizing build and workflow docs, we need a suitable replacement for all of Firefox's contribution and workflow documentation. The great advantage of documentation living in-tree, is that it can be updated along with the source. Unfortunately the current system to build and generate docs is difficult to write for, slow to build and generates poorly organized documentation. These factors discourage developers from creating or updating docs. | With [https://developer.mozilla.org/en-US/ MDN] de-prioritizing build and workflow docs, we need a suitable replacement for all of Firefox's contribution and workflow documentation. The great advantage of documentation living in-tree, is that it can be updated along with the source. Unfortunately the current system to build and generate docs is difficult to write for, slow to build and generates poorly organized documentation. These factors discourage developers from creating or updating docs. | ||