Community:SummerOfCode14

This page lists all the Google Summer of Code 2014 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 #developers channel on IRC: irc://irc.mozilla.org/#developers . 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 Gerv. 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 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

Mozilla Platform (Gecko)

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
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	Tasks would include finishing the sndio backend for OpenBSD (Bug #911450), upstreaming to webrtc.org the patches already commited to mozilla (#807492 and its dependencies), and make sure the webrtc integration tests also run fine on major BSDs. The project will be successful if an A/V call can be done from firefox nightly from a BSD to another firefox instance on Linux or Windows, and also in-between different BSDs, using the tests from http://mozilla.github.io/webrtc-landing/ and https://apprtc.appspot.com/.

Thunderbird

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
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.

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.

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). (more information)
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.

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

Rust

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
Package Rust in key distributions	Having {apt-get,yum} install rust	deb packaging / Rust (LLVM appreciated)		Sylvestre Ledru & Luca Bruno	Main issues: https://wiki.debian.org/Teams/RustPackaging/Bootstrap & https://github.com/mozilla/rust/issues/4259. Will focus on Debian/Ubuntu first

Servo

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
Implement XMLHttpRequest	Make common sites using XHR work in Servo.	Linux or OS X only; familiarity with XMLHttpRequest; desire to write Rust code (C++ experience helpful)	Josh Matthews	Josh Matthews	In-depth project guidelines

Localization

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
Mozilla Intellego -- Terminology-driven automatic translation of web sites	Intellego is an initiative to develop a machine translation platform from open corpus data, open corpus gathering techniques, and open web services APIs to lower the linguistic accesibility barrier for users and websites and further promote the exploration of freedom of linguistic expression on the web. This piece of the project will lay the foundational code for Intellego by aiming at the completion of the first key milestone: creating an automatic translation tool for web sites aimed to translate all key source terminology in a site into the target language equivalents. This will be accomplished by scanning the DOM of a site, extracting the translatable text nodes, searching for source terminology matches from within a bilingual termbase, and returning target language terminology within the rendered page. This project will aim to perform these tasks within the Mozilla support sites. If the student can accomplish the basic scope of the project before the necessary eight weeks, the stretch aim would be to enable the addition of context sensitive retrieval of target terminology.	DOM manipulation (JavaScript) Information retrieval XML Understanding of open webservices APIs Python Familiarity with a library used for quickly generating a web UI to a server-side Python script	Jeff Beatty (gueroJeff)	Jeff Beatty (gueroJeff)	Week by week timeline for GSoC Project wiki Weekly status meetings IRC: #intellego

Security Engineering

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
Implement Zest recorder and runner	Create a Firefox add-on for recording and Running Zest scripts as well as editing them graphically	Java Script, knowledge of Firefox add-ons	Simon Bennetts	Mark Goodwin, Simon Bennetts

Open(Art)

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
Porting key Meemoo modules to NoFlo	Meemoo.org is a platform for web-hackable creative image/animation apps. Noflojs.org is a more-powerful dataflow environment, with hooks to Node.js and Arduino. This project idea involves designing a Canvas 2d library of Noflo components which will allow Meemoo components to be ported as Noflo subgraphs. Proposals should include a generative image (meemoo, processing, or vanilla js + canvas) and a sketch of the graph and low-level 2d drawing components that would be needed. This idea could be also focused on a data visualization or 2d game. Other Noflo-related proposals welcome.	Solid javascript. Understanding of Dataflow / Flow-Based programming.		Forrest Oliphant

Mozilla Science Lab

Title	Details	Skills Needed	Reporter	Mentor(s)	Comments
Browsercast	The goal of this project is to implement an HTML5+Javascript replacement for screencasting and integrate it with a composition tool. A prototype of the playback tool is on GitHub (see this page for a demo and explanation of why we want such a thing), and some useful experiments with composition tools have also been built (see this page for an example). The end result of this project will allow non-specialists to author an HTML5+Javascript slideshow using something like Thimble, add a voiceover, and create something that plays back in the browser (so that search engines and accessibility aids can "see" the content) with a fraction of the data download required by video.	Javascript, HTML, CSS; experience with Popcorn and Thimble are useful but not essential.	Greg Wilson	Greg Wilson
Peer Instruction on the Web	Peer instruction (PI) is a teaching technique which alternates between instructor-led Q&A and peer discussion in small groups. It has been proven to reduce failure rates in introductory programming classes (and many other courses), but is not directly supported by existing online learning platforms. The goal of this project is to use WebRTC to create a bimodal real-time voice-and-video chat system to support PI. Mode 1 is broadcast: the instructor transmits audio+video to a large class. Mode 2 is small-group discussion: learners are placed in an all-to-all chat in teams of 2-6. Crucially, the tool allows smooth switching between modes: the instructor can press a button to initiate the small-group discussion, then push another to give groups a 30-second warning, after which they are instantly pulled back into the main class. (See this page for more information.) Such a tool would be useful in other contexts, such as breakout groups for online meetings, but would primarily be intended to bring modern evidence-based teaching practices to web-based learning.	WebRTC, Javascript, HTML, CSS, and something (Python, Ruby, JS) for building a simple back end to manage groups.	Greg Wilson	Greg Wilson