Mozilla community members - submit proposals here for 2014 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 14th.
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
|
| Convert in-content XUL pages to HTML
|
Some of Firefox's in-content pages like about:newtab, about:memory, etc. use XUL. If we used HTML instead, it'd be easier for people to hack on them, they'd benefit from performance/bugfix improvements to the web, and so on. It would be nice to convert some of these pages away from XUL.
|
Good knowledge of HTML, CSS and JS. Knowledge of XUL and/or possibly the new shadow DOM specs will likely come in handy.
|
Gijs
|
Gijs
|
|
| Provide proper WebRTC testing and integration on BSD systems
|
As of now, WebRTC is enabled by default on BSD systems but needs more testing and bugfixes in real-life situations to make it rock-solid and usable, on par with Tier1 platforms. The WebRTC code that already landed for *BSD needs proper integration upstream too.
|
Good knowledge of C and IPC.
|
Gaston
|
Gaston
|
|
Firefox for Android
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Firefox OS / Boot2Gecko
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
| A Desktop Environment based on B2G
|
The goal is to package b2g desktop as an alternative to desktop environments like Gnome or KDE.
|
Familiarity with packaging systems for popular linux distributions (deb, rmp, yum). Support for some APIs will also need to be implemented to provide an acceptable experience, like the Wifi api. Some gecko knowledge is a plus but not an absolute requirement.
Steps would be:
- Package b2g desktop as a Desktop Environment.
- Fix/add missing APIs in gecko.
- Tune Gaia's tablet UI to be nice to use with a keyboard.
|
Fabrice Desré
|
Fabrice Desré
|
|
| Battery Included B2G Build Environment in a VM (FoxBox).
|
The goal is to help potential contributor/ROM maker bootstrap their B2G/gecko/gaia dev environment without burden. Especially important for web developer (gaia). Current project already able to configure a GUI environment with Firefox Nightly, export USB/repository PATH with host OS.
|
Familiarity with bash and unix system configuration. Vagrant or provisioning tools such as puppet/chef/salt is plus. Some helper scripts will also need to be implemented to provide an acceptable experience.
Project Site http://github.com/gasolin/foxbox
|
Fred Lin
Greg Weng
|
Fred Lin
Greg Weng
|
| Implementation of a default Voice Recorder app
|
There is no built in voice/sound recorder app in gaia, as stated in Bug 877286. The taking of memos shouldn't be left to external apps. The goal would be to create such an app for the built-in package. An addon for the Music app is also considered.
|
Familiarity with gaia and a good knowledge of CSS, Javascript and HTML5 is needed. Should have a fairly good idea about hosted app structure and UI layout. Understanding of the Media Recording API is a plus, but can be caught up on the fly.
|
Vedad Hadžić
|
|
|
Mozilla Open Badges
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Thunderbird
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Calendar
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
| Make Lightning Fast
|
The Lightning Extension has a few performance problems, especially with lots of calendars. Now that the Gecko Profiler works in Thunderbird Daily, its a great time to harness its power and improve Lightning's performance. A Student working on this project should:
- Browse Bugzilla to get an overview of reported performance problems.
- Use the Gecko Profiler to identify performance bottlenecks, for example occurrence calculation.
- Propose a method to improve performance in a way that would move the bottleneck elsewhere and discuss with mentor.
- Fix the bottleneck.
- Continue with (2).
Depending on remaining time and student experience, adding performance tests to Lightning would be a bonus.
|
Javascript; Python and make for perf tests
|
Philipp (:Fallen)
|
Ludovic (:ludovic) / Mohit(:redDragon)
|
A student applying for this project should be able to work with large codebases. Getting familiar with the Lightning source code early improves chances of being accepted. Look for Fallen on irc.mozilla.org / #calendar if you need help getting started.
|
| Improve Calendar Backends
|
Lightning has historically supported two modes for calendar providers: cached and uncached. In uncached mode, each request is directly relayed to the remote end, causing a lot of traffic. Therefore, cached mode was introduced, which is close to a "real" synchronization, where only changes are transferred. In the future it would be nice to use cached mode exclusively. To do so, there need to be some changes in the backend. This project consists of a combination of the following bugs, depending on time and student skill:
- Finish the patch I started for async storage (bug 501689)
- Move calendar metadata from the provider inteface to the item interface (no bug yet)
- Turn the ICS calendar into a cache-only provider (bug 780992)
- Turn the CalDAV calendar into a cache-only provider (no bug yet)
|
Javascript, SQL,
|
Philipp (:Fallen)
|
Mohit (:redDragon)
|
As these changes will partially require some migration steps, it is important to write unit tests for the code produced during the Summer of Code. Not all of the mentioned bugs need to be fixed for passing mid-terms and finals, please read through the bugs and consult with mentor or reporter with your suggestion when applying.
|
| Update Lightning Invitations to Latest Specification
|
iTip Standard allows different email clients and servers to schedule meetings based on email messages. The scheduling extension to CalDAV RFC has become a full spec now. However Lightning's invitation processing implementation lags behind. A student working on this would be expected to:
- Explore some of the bugs related to the iTiP processor.
- write a few mozmill tests on various invitation scenarios
- analyse the current itip interfaces and check what can be improved, especially keeping the caldav scheduling rfc in mind
- udpate the caldav provider to the latest spec chunk by chunk
|
Javascript, SQL,
|
Philipp (:Fallen)
|
Mohit (:redDragon) / Philipp(:Fallen)
|
The work involved will be significantly more and would require deep analysis of the calendar code base. However, the end-product would bring cheers to a lot of users and end complaints of lightning not functioning with a particular server. As a start dive into the RFC and the buglist to find out some of the easy cases which can be solved to gauge the difficulty of the project.
|
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
|
| Add markdown support to Bugzilla. bug 330707.
|
Currently Bugzilla only supports plain text for comments. Adding support for markdown allows for rich text formatting in a way which degrades nicely to plain text.
|
Perl
|
Byron Jones
|
Byron Jones
|
I have a working proof of concept which performs the markdown to html conversion in a way which is compatible with Bugzilla's existing markup. This needs to be tidied up and integrated a all points where comments are created and displayed (web UI and email).
|
| Migrate from YUI2 to YUI3. bug 453268
|
Bugzilla currently uses YUI2 as its widget library. We need to migrate to YUI3 as version 2 is no longer maintained.
|
JavaScript
|
Byron Jones
|
Byron Jones
|
Yahoo started the work however progress has stalled.
|
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
|
| Add structured logging to mochitest
|
Traditionally at Mozilla, test harnesses have written test results as arbitrary strings to stdout. Other tools that want to gather data about test runs are forced to parse the entire logfile produced by capturing stdout, and using a set of regexes on each line in order to identify test results, test summaries, and other items of interest.
We'd like to replace this very inefficient approach to test logging with a more robust mechanism: "structured logging". In this approach, a test harness writes a file containing data in JSON format for each test event that needs to be logged, as well as producing human-readable data on stdout. Other tools can then easily parse the JSON data when they want to know what happened during the test run.
We have developed the structured logging format, and started using a Python implementation for a small subset of our tests. Now we would like to use it with our Mochitest harness, which is used for running many regression tests for the Gecko browser engine. This harness has external Python components and Javascript components running in the browser, both of which need to write structured log messages to the same file in (approximately) chronological order. When run in continuous integration, the structured log file must be uploaded at the end of the test run as a test artifact.
See meta bug at bug 916295; actionable bugs for this project are bug 916265 and bug 886570.
|
JavaScript, Python
|
Jonathan Griffin
|
James Graham
|
|
| Mochitest failure investigator
|
We spent countless hours investigating tests and managing known failures that occur occasionally. In many cases we have investigated test failures and cannot reproduce them while running the test by itself. It has been found that some tests alter the state of Firefox which can cause future tests to behave differently. Some tests are even written to depend on this state change.
To build this tool we need to take a given test failure and work backwards to find its failure point. Starting with the given test failure, we need to start a fresh instance of the browser/profile and verify the single test case passes on it's own. Then we can repeat this process by adding more tests for each run until we find the failure. The most logical way to add tests will be per directory as each directory usually contains tests of similiar behavior. This would be added into the mochitest python harness. Doing so will give people the ability to quickly run this locally and with a small adjustment to our Try server (passing in the correct command line arguments), we can run this on production machines.
|
JavaScript, Python
|
Joel Maher
|
Joel Maher
|
|
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
|
Persona / BrowserID
| 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
|
Instantbird
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
| WebRTC support
|
Goal: Support voice/video chat using WebRTC via XMPP (and potentially other protocols).
Add voice and video chat to Instantbird via WebRTC. This will involve adding APIs to allow protocols to prepare a voice/video connection to a contact and some basic user interface to show the video feed.
|
JavaScript, XPCOM, XUL
|
Florian Quèze
|
Benedikt Pfeifer
|
XEP-0320, XEP-0338, XEP-0339, XEP-0343 for XMPP
|
| Single window UI:
|
Goal: Provide an alternative UI that works well in a single window.
To design and implement a single-window UI that does not require a separate contact list and makes good use of the available space when the window is full-screen. Avenues to explore are e.g. multiple side-by-side chats (extending what is currently possible with tabs), and automatic resizing of conversations. The student should bring a good (if not complete) vision for this project, demonstrated via mockups in the application.
|
JavaScript, XPCOM, XUL
|
Florian Quèze
|
|
|
| FileLinks in IMs / File transfer
|
Goal: File transfers that work reliably for every protocol.
The Thunderbird Filelink feature allows users to upload attachments to an online storage service, replacing the email attachment with a link. This existing code could be used to implement file transfer. While some protocols support file transfer directly, this approach would provide a fallback that should always work. Designing and implementing a good UI frontend would also be required.
|
JavaScript, XPCOM, XUL
|
Florian Quèze
|
aleth
|
The frontend should be flexible enough to be able to handle other file transfer methods when they are implemented, e.g. WebRTC for XMPP or DCC for IRC.
|
| Improve JS-XMPP
|
Goal: Ease working with the JavaScript XMPP implementation and implement new features.
Include better syntax for XML handling, implementing handling of MUCs and other features. Feature-parity with libpurple's XMPP support is one of the prerequisites for replacing the libpurple XMPP plug-in that is currently used. One possible improvement would be to support voice and video calls between a JS-XMPP client and a Jingle client using WebRTC.
|
JavaScript, XPCOM
|
Florian Quèze
|
Patrick Cloke
|
|
| Additional JavaScript protocol plug-ins
|
Goal: Implement new protocol plug-ins in JavaScript, or create more stable implementations of existing ones.
Instantbird supports protocol plugins implemented in JavaScript. The student will either add support for new protocols in Instantbird (if so, explain why this protocol matters) or reimplement in JavaScript an existing protocol that is poorly supported by libpurple (if so, explain what will be better supported in the new implementation, or why the current implementation is not adequate). The student working on new protocols should take every opportunity to improve the code and APIs shared by all JS protocol plugins.
|
JavaScript, XPCOM, maybe js-ctypes
|
Patrick Cloke
|
Patrick Cloke
|
IRC, XMPP, Twitter and Yahoo have already been implemented in JavaScript and should not be considered; Some base code exists for OSCAR (AIM/ICQ); SIP, Bonjour and OSCAR are probably the most wanted protocols.
|
| Off-The-Record messaging integration
|
Goal: Integrate OTR in an easy to use fashion.
OTR is an often requested feature, but must be integrated in such a way to require little user interaction. Furthermore, the student could try to make Instantbird compliant with the secure messaging checklist suggested by Saint-Andre (link?)
|
JavaScript, XUL, XPCOM, maybe js-ctypes or C++
|
Patrick Cloke
|
Patrick Cloke
|
Emscripten
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Rust
Servo
Security Engineering
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Open(Art)
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|
Localization
| Title
|
Details
|
Skills Needed
|
Reporter
|
Mentor(s)
|
Comments
|