Mozilla community members - submit proposals here for 2015 Google Summer of Code projects with Mozilla. (If this page looks empty, it's because accepted ideas have already been transferred to the official list.) The absolute last deadline for submitting ideas in time to help us get accepted by Google is February 20th.
Are you a students looking to apply to SoC with Mozilla? Your first stop should be the official list of ideas. This page is full of weird and whacky ideas, some of which are still on here for a reason - it could be that they are not properly defined, the wrong size, or don't have a mentor. That makes them less likely to get accepted. You can, of course, also submit your own ideas - you don't have to put an idea on this page and get it 'made official' in order to send in a proposal for it.
How To Write A Good Project Proposal
Before adding an proposal to this list, please consider the following:
- Be specific. It's hard to understand the impact of, or the size of, vague proposals.
- Consider size. The student has eight weeks to design, code, test and document the proposal. It needs to fill, but not overfill, that time.
- Do your research. Support the idea with well-researched links.
- Don't morph other people's ideas. If you have a related idea, place it next to the existing one, or add a comment.
- Insert only your own name into the Mentor column, and then only if you are willing to take on the responsibility. If you think the SoC admins won't know who you are, leave contact details.
- Check back regularly. The administrators may have questions about your idea that you will need to answer.
- Know when to give up. If you've added the same idea for the last three years and it hasn't made it to the official page, perhaps you can predict what will happen this time.
Suggestion List
Here are the ideas lists from previous years.
Proposals can be in almost any part of the Mozilla project - don't be fooled by the "Code" in "Summer of Code". If there is no category below for your part of Mozilla, add one!
Mozilla Platform (Gecko)
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Firefox
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Firefox for Android
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Firefox OS / Boot2Gecko
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Thunderbird
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
| Performance testing
|
Add and deploy a performance testsuite for Thunderbird to catch regressions in areas such as startup, message search, folder display, message display, etc.
|
JavaScript, Python, preferably some performance analysis experience
|
jcranmer
|
?
|
|
| Secure email UI
|
Develop good interfaces for key management and illustrating the security levels of messages succinctly, preferably applicable to both S/MIME and OpenPGP.
|
Strong UX experience; JS, XUL or HTML; crypto background advantageous
|
jcranmer
|
?
|
This may be too large a task; narrowing focus could be useful
|
| 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
|
probably rkent
|
|
| Alternate protocol for mailnews folders
|
Thunderbird has long-term plans to implement a variety of mail and mail-like protocols to be managed as mailnews folders. An existing addon (SkinkGlue) exists to provide the glue for this. Implement one other protocol, which might be Twitter, Fastmail's JMAP, or Calendar events & tasks
|
Javascript
|
rkent
|
rkent and, depending on protocol, a chat guy (clokep?), brong from Fastmail, or Fallen
|
|
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
|
SeaMonkey
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
NSS (Network Security Services)
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Bugzilla
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Firefox Support (SUMO)
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
QA
| 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
|
Joel Maher, Will LaChance
|
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
|
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.
|
Documentation
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Mozilla Developer Network
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Mozilla IT and Infrastructure
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Sync / Services
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Developer Tools
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Add-on SDK
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Foundation
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
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. clobberer, buildapi, mozpool, modern mapper, 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/.
|
json, json hyperschema, solid programming skills, enthusiasm, code generation, web interface design
|
Pete Moore
|
Pete Moore
|
Some good starting points:
|
Emscripten
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Rust
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
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
|
Security Engineering
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Localization
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Build system
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Security Assurance
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Mozilla Science Lab
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|