This page lists all the Google Summer of Code 2016 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.
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 for Android
|Download app assets at runtime|| More detailed description of the project
With Firefox for Android we just made the first steps to stop shipping everything in the APK and to instead download assets the application needs at runtime. We started with fonts but we want to do much more (hyphenation dictionaries, translations, ..) in order to reduce the APK size.
| Java / Android
Basic knowledge of the HTTP protocol
|Sebastian Kaspari (:sebastian)||Sebastian Kaspari (:sebastian)|
Note that some implementations exist for other clients (hangups in Python and purple-hangouts in C).
|File transfer support|| This involves a lot of interacting pieces so would require good planning up front. There has been a few failed efforts to do this in the past, but some partial implementations might exist. Generally this involves:
|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.
|Advanced Preferences System|| Today, Lightning preferences can mostly only be set on global level. A different, but smaller set of preferences is available on calendar level, whereas several preferences are currently only available from within the config editor. The goal of this project is to create a preference system like Thunderbird uses it - making most of the preferences available on calendar level with an option to fall back to corresponding globally configured preferences.
Automation & Tools
|Web-based GDB Frontend|| Write a graphical frontend for gdb/rr in react.js communicating with backend (gdb/rr) over a websocket.
The idea is to pipe stdin/stdout/stderr from gdb over a websocket, and implement a complete graphical debugger in the browser. Architecture and discussions are talking place in a collection of etherpad notes (feel free to add notes). Initial code sketches are taking place on github.com/taskcluster/react-gdb.
||This project has been reprioritized and is no longer suitable for GSoC.|
|Redesign SETA and give it TaskCluster support||We currently have multiple continuous integration systems running Firefox tests. On the original CI (Buildbot), we use SETA (Search for Extraneous Test Automation) to help reduce the number of jobs that get scheduled on every push by doing analysis of previous test results. Unfortunately needs to be redesigned to be more reliable and to support our new CI (TaskCluster). This will help us migrate faster to the new CI which gives us much more flexibility.||Python||armenzg||jmaher armenzg|||
|Give Treeherder the ability to schedule TaskCluster jobs||On Treeherder you can schedule Buildbot jobs which had not been scheduled before (see Scheduling jobs with Treeherder). You can read more about the project in here.||Python||armenzg||armenzg jmaher|
|Reduce the frequency of update races in Balrog||One of the key features of our update server's (Balrog) API is that it guards against update races - where multiple clients overwrite each others' changes to the same piece of data. In many cases clients are updating small, independent parts of the same larger piece of data, and the server should be able to safely merge the changes together rather than forcing clients to try again. This project will involve the design and implementation of an improved algorithm for safely accepting changes to Balrog's Release objects through the API.||Python||bhearsum||bhearsum|
|Mozilla Investigator: Auditd integration||Implement support for syscall monitoring on Linux system via the Audit daemon. This should include integration with the audit-go library, as well as reporting and escalation. A key component of the project is to correlate anomalies across nodes, to identify unusual systems registered by isolated systems but not by the rest of the infrastructure.||Strong Go and C programming skills. Good knowledge of Operating Systems architecture and the Linux kernel.||Julien Vehent||Julien Vehent :ulfr & Guillaume Destuynder :kang||MIG (github.com/mozilla/mig) is a distributed digital forensics framework deployed across thousands of systems at Mozilla. It is used by various groups to maintain good security levels across the environments, and investigate incidents and vulnerabilities.|
NSS (Network Security Services)
|Implement RFC7512 PKCS#11 URI support and system integration|| RFC7512 defines a URI standard for identifying PKCs#11 tokens and the objects therein. We need to implement a PK11_FindCertByURI() or similar function, and also make it possible to obtain/generate the URI for a given CERT and other objects which have been found/selected by other means. See bug 1162897 for details. Also, NSS does not obey the system configuration for which PKCS#11 tokens to load, as described in bug 248722. We should fix this too.
See dev-tech-crypto email at https://email@example.com/msg12493.html
|C coding, familiarity with PKCS#11 preferable||dwmw2||Bob Relyea, David Woodhouse (dwmw2)|
Mozilla Science Lab
|Contributorship Badges for Science.|| Issuing badges to credit authors for their work on academic papers. As the research environment becomes more digital, we want to test how we can use this medium to help bring transparency and credit for individuals in the publication process.
Using Mozilla's Badgekit-api to implement our badges, we can issue and fetch badges from badgekit via the badgkit-api-client. By authenticating against ORCID, a user can reliably issue badges to a valid ORCID, the standard unique researcher identifier.
Since launching our MVP last fall, we've realized that badgekit-api isn't optimized for our use case. In this project, you will migrate our badge system away from badgekit-api and update the system to make it easier for publishers to integrate Paper Badger in their submission system.
More details: https://github.com/mozillascience/PaperBadger/issues/159 https://github.com/mozillascience/PaperBadger/issues/160
|aframe.io - Building Blocks for the VR Web||
To bring the library to the next level we need new demos that focus on the strengths of the VR medium. We need someone to help us create new exciting and visually stimulating a-frame examples that show new interaction techniques to handle locomotion (how do you move quickly in the VR space without inducing motion sickness?), object manipulation (how do we integrate novel input controls that track your arms and hands?), and multi user experiences (How will social activities express in VR?). Those explorations will result in examples and components that we will make available to the a-frame users. This is a great opportunity for someone to explore the next big medium, play with cool gadgets and interact with an emerging open source community.