Community:SummerOfCode15
This page lists all the Google Summer of Code 2015 projects with confirmed mentors, and which have been approved by the SoC administrator. New suggestions can be made on the Brainstorming page. Do not edit this page yourself; contact Florian for edits.
Potential students: you may choose from the list below, but you do not have to. Feel free to submit a proposal for your own idea. However, before you do so, see the guidelines for good ideas. You can also discuss your ideas or application in the #introduction channel on IRC: irc://irc.mozilla.org/#introduction . Your idea will have a significantly greater chance of being chosen if you can find an existing member of the Mozilla community who is willing to evaluate or mentor it. (You should name that person in your application.)
In addition to the specifically-named projects below, we have also tagged a number of bugs in Bugzilla with the keyword student-project. However, as the idea of a "student project" is wider than just the Summer of Code, students looking through the list will need to decide whether any particular bug listed there is actually the right size and scope for Summer of Code.
Application Advice
You should do the following:
- Talk to the mentor. Contact details are on this page; if all you have is a nickname, get on IRC and try and contact them.
- Read the GSoC Student Guide and follow its advice.
- Read How Not To Apply For Summer Of Code and avoid doing the things listed there.
- Read our examples of good applications: 1, 2, 3.
- Apply on the GSoC site (note that we have an 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. However, more than 3 seems like spam.
Note that if a project suggests it would be helpful to know XUL (Mozilla's user interface description language), you may be able to get away with learning on the job. Don't be put off from applying if the project otherwise looks right for you.
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 Florian and Patrick. We will try and respond as soon as possible and get your questions directed to the right person. Please allow at least 48 hours for a reply.
Firefox
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Firefox Developer Tools
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Source Map Library | This project would implement missing library support for certain of the source map spec, specifically "indexed" source maps, and experimenting with extensions for encoding the original source code's lexical environment in the source map. | JavaScript, Node.js | fitzgen | fitzgen | Easy for a contributor to ramp up on, because it can be done completely in Node.js without needing to build Firefox. |
Firefox OS / Boot2Gecko
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Mozilla Platform (Gecko)
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Thunderbird
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Mailbox-to-maildir converter | Mailbox and Maildir are two alternative on-disk storage formats for email messages. Thunderbird currently uses Mailbox, but wants to use Maildir. Hence the need for a converter. This is one of the last critical pieces blocking moving away from mbox-style mailboxes. See bug 856087. | JavaScript, C++ | jcranmer | rkent |
Instantbird
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Calendar
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Introducing Calendar Accounts | Traditionally our calendar extension is organized into a list of calendars, each calendar being implemented by a “provider”, for example local storage or using the CalDAV protocol. The service to manage these calendars maintains a simple list, the entries have no connection to each other.
Some calendar providers would greatly benefit from being able to group calendars into accounts, for example free-busy lookups are usually per-server operations and not per-calendar. It would also open the door for some great new features that have been postponed because they can be implemented cleaner with the notion of accounts. |
XUL, CSS, JavaScript | Fallen | Fallen | Click here for a detailed project description |
| Resource Booking Improvements | The Lightning extension has a dialog for inviting attendees to an event, which also shows availability information. Albeit not very obvious, it also allows booking resources and rooms. To improve this experience we would like users to be able to pick rooms and resources in a way that they don't need to remember the room address and quickly see which rooms and resources exist and are available around the proposed time of the event. | XUL, CSS, JavaScript | Fallen | Fallen | Click here for a detailed project description |
Bugzilla
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Bugzilla Extension Exchange Format | Write an installer script for Bugzilla extensions | Perl | dylan (dylan@mozilla.com) | dylan | Spec: http://hardison.net/~dylan/BEEF.html |
Accessibility
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Automation & Tools
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Performance Alerts Release Management Toolchain | This GSOC project will deliver functionality of detecting alerts as they merge between branches. This is mostly important for regressions, but should also include improvements. We generate thousands of performance alerts every year, and we need a way to look at the high level of what is concerning while having the ability to drill down and understand what small details make up the bigger problems. This depends on us seeing these regression when the code was originally introduced and action being taken to file a bug. In many cases we have preferences that turn features on and off which will have an affect on the alerts that we care about. The target here is a release manager can go to a dashboard, and see the state of the release (most important after uplifting code) and get a list of bugs that are of interest.
This will be integrating a system into TreeHerder to store alerts and allow graphs of the data to be annotated. There will be an API so alert can be generated from other sources and managed by other tools as well. |
Python, AngularJS, SQL, Javascript | [Joel Maher] | [Will Lachance], [Joel Maher] | The impact here is the ability for developers and release managers to see the performance impact of their changes while helping us track this. |
| Retry failures in automation and provide annotations for intermittent failures vs real failures | Of the thousands of unitests which are run for each platform and each push we find many intermittent failures. This is a pain point for developers when they test their code on try server. Now that we have TreeHerder, it isn't much work to automatically annotate jobs as intermittent or a regression/failure. In mochitest we have --bisect-chunk which will retry the given test and determine if it is an intermittent or a real regression. The goal here is to do this automatically for all jobs on try server. Jobs will still turn orange. With the outcome of this project failures would need to have a different view in the UI. | Python, Javascript | [Joel Maher] | [Joel Maher] | This will build off an existing set of tools while helping us bridge the gap towards a much better review and automated landing of patches system. In the short term, this will aid in developers who see failures and either do multiple pushes, many retriggers, or just ignore them- in summary we will not need to worry as much about wasting resources related to intermittents. |
| Unittest sanitizer | With our thousands of test files, there are hundreds that have dangerous api calls which result in leftover preferences, permissions, and timing issues. A lot of work has been done here, we need to fix tests and expand our work on these resources to all our tests. In addition to cleaning up dangerous test code, we need to understand our tests and how reliable they are. We need to build tools that will allow us to determine how safe and reliable our tests are individually and as part of a suite. Upon completion of this project we should have the majority of tests cleaned up, and a toolchain that can be easily run and generate a report on how stable each test is. | Python, Javascript | [Joel Maher] | [Martijn Wargers], [Joel Maher] | The impact this has is helping us cleanup our tests to reduce intermittents and give us tools to write better tests and understand our options for running tests in different configurations. |
| mozregression GUI | Using Python, create a graphical user interface for mozregression (http://mozilla.github.io/mozregression) along with an installer and automatic update system to make it easier for less technical contributors to find and report regression ranges in Firefox and Thunderbird. | Python | William Lachance | William Lachance, Julien Pagès | |
| Convert Mozmill test cases to Marionette | he Mozmill framework is being replaced by Marionette to support multi-process Firefox. In the previous Mozmill toolchain we have dozens of libraries and hundreds of tests. This project will entail assessing those tests for uniqueness (compared to browser-chrome) and porting what tests and libraries make sense to Marionette. The goal here is to assess all the tests and have at least 75 converted. | Python, Javascript | [Joel Maher] | [Joel Maher], [Henrik Skupin] | Existing tests live here:
http://hg.mozilla.org/qa/mozmill-tests/file/default new tests live here: https://github.com/mozilla/firefox-ui-tests |
Release Engineering
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Define, test, and publish json hyperschemas for all release engineering APIs | We have several APIs (e.g. buildapi, clobberer, (modern) mapper, mozpool, slavealloc, slaveapi, ...) but have no central standardised way of defining them, publishing them, documenting them, or sharing them. A cool project would be to use json hyperschema (see e.g. https://brandur.org/elegant-apis) to define all our apis, and have a framework for auto testing them, auto-documenting them, even potentially auto-generating client libraries for them e.g. in python, and auto-publishing the schemas to a central location for reference. Another interesting option might be using http://swagger.io/.
Example REST apis that we have are:
This GSoC project would involve creating hyperschemas for the above APIs (and potentially others too), finding a good place to publish these references, and look at setting up some tools to generate documentation for these APIs, together with code generation of client libraries, and their associated documentation (godoc, javadoc, …) and if time allows, even auto-generation and deployment of new documentation, libraries, as and when these json hyper schemas get updated (perhaps with travis ci deploying to e.g. github pages or heroku). |
json, json hyperschema, solid programming skills, enthusiasm, code generation, web interface design | Pete Moore | Pete Moore | Some good starting points:
|
Rust
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| rustfmt | Create a code formatting tool that automatically reformats Rust code to meet conventions. | Experience with Rust. | brson | brson |
Servo
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Speculative HTML parsing | Servo's HTML parser currently blocks whenever it needs to execute JS code (eg. when <script> tags are encountered in a page). We want to split the HTML parsing code into two threads, one of which can continue parsing the rest of the HTML source speculatively while the other is busy executing JS; once the second is finished, the parser can use the result of the first thread's efforts to improve page load performance. | Prior Rust experience valuable. Familiarity with HTML. | jdm | kmc | |
| HTTP/2 implementation in hyper | Hyper, the Rust HTTP library that Servo relies upon, is missing support for exciting new technologies like HTTP/2. This project would design and integrate an HTTP/2 implementation into the client and servo code for hyper. | Experience writing code that interacts with network protocols. Prior Rust experience valuable. | jdm | seanmonstar and reem | |
| Server-Sent Events | Servo lacks an implementation of the EventSource Web API. The goal of this project is to implement that API, following the specification as closely as possible and enabling the tests for this feature that already exist. | Prior experience with Rust valuable. Comfortable reading and writing JavaScript for the web. | jdm | jdm | |
| Improve form support | Servo currently has rather basic form support, with simple widgets. We lack support for many form controls and functionality like file uploads and form validation. We'd like to add support for most form behavior, based on the specification. | Familiarity with web HTML/Javascript. Prior experience with Rust and/or reading web specifications valuable. | Manishearth | Manishearth (or jdm) |
Localization
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Security
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Open(Art)
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|
Mozilla Science Lab
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|