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.
- 1 Application Advice
- 2 Firefox
- 3 Firefox Developer Tools
- 4 Firefox OS / Boot2Gecko
- 5 Mozilla Platform (Gecko)
- 6 Thunderbird
- 7 Instantbird
- 8 Calendar
- 9 Bugzilla
- 10 Accessibility
- 11 Automation & Tools
- 12 Release Engineering
- 13 Rust
- 14 Servo
- 15 Localization
- 16 Security
- 17 OpenArt
- 18 Webmaker
- 19 Mozilla Science Lab
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.
|Download Integrity|| Enhance detection of broken downloads in Firefox. Methods may include:
Firefox Developer Tools
Firefox OS / Boot2Gecko
Mozilla Platform (Gecko)
|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.
|Bugzilla Extension Exchange Format||Write an installer script for Bugzilla extensions||Perl||dylan (firstname.lastname@example.org)||dylan||Spec: http://hardison.net/~dylan/BEEF.html|
Automation & Tools
|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.
|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|
new tests live here: https://github.com/mozilla/firefox-ui-tests
|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:
|Decouple Mozharness internals by breaking it into standalone modules|| What is Mozharness: It's a configuration-driven script harness that is used for automating > 90% of Mozilla's build and test jobs. It is also used by release engineering services outside of continuous integration.
What needs to decoupled: Mozharness has reached some scaling issues. Jobs that do builds and tests inherit and share exhaustive number of mixins. This leads to a complicated Method Resolution Order and objects with too many attrs that are not even needed.
How can this be done: replace the mixins with standalone classes that act as services. The classes can be instantiated many times and are aware of only their own responsibilities. Once stand alone, you then make them into packages within a mozharness library and installable by pip.
steps and goals for gsoc:
|python, solid programming skills, enthusiasm||Jordan Lund, Armen Zambrano||Jordan Lund||more details:|
|rustfmt||Create a code formatting tool that automatically reformats Rust code to meet conventions.||Experience with Rust.||brson||brson, nrc|
|Rust Code Completion for SublimeText||This project would develop a plugin for the Sublime Text editor that provides code completion for the Rust programming language, by integrating with the Rust Racer project. This would require interfacing between Python (for the Plugin) and Rust (for Racer).||Rust, Python||pnkfelix||pnkfelix|
|Refactoring Rust||Create a tool for refactoring Rust code.||Experience with Rust.||nrc||nrc|
|Tools and macros||Develop tools and/or APIs for comprehension and manipulation of macros. For example, extend DXR to work with macros or demonstrate a proof of concept refactoring or formatting tool that works with macros.||Experience with Rust, particularly macros.||nrc||nrc|
|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|
Mozilla Science Lab
|Code as a Research Object||Using the proposed crosswalk schema between existing software metadata, create a service (can be a simple website) that will allow users to search and filter software across existing data archives and repositories (Zenodo, figshare, GitHub). Comparing the existing schemas for code storage to help create a metadata standard that allows for discoverability, reuse and citation.||json, zenodo api, figshare api, github api||Abby||Abby|| "Code as a Research Object" is exploring integrating software into the scholarly workflow. Collaboration with GitHub, figshare and Zenodo.
Background reading: http://www.mozillascience.org/code-as-as-research-object-new-phase/