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 #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.
Contents
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:
|
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 | Fred Lin |
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:
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:
|
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:
|
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. |
Accessibility
| Title | Details | Skills Needed | Reporter | Mentor(s) | Comments |
|---|---|---|---|---|---|
| Implement speech synthesis on desktop Firefox | We have an implementation of speech synthesis via the Web Speech API. Currently, only Firefox OS devices have an engine via SVOX Pico. It would be good to have speech synthesis supported on Firefox for desktop OSs as well. Also, the current implementation should be tested and updated to interop with other browsers that support speech synthesis, such as Safari and Chrome. | Knowledge of C/C++, and perhaps Objective C. | eeejay | eeejay (and probably smaug doing the bulk of the reviewing). | We should also explore how far along in the specs errata we could go. |
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 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 | Detailed Outline |
| 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.
|
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)
Must have demonstrated packaging capabilities (packages in Debian or Ubuntu, bug fixes, etc). |
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. |
|
Jeff Beatty (gueroJeff) | Jeff Beatty (gueroJeff) |
Security
| 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 | |
| Kitherder | Kitherder is a web application that is designed to facilitate participation in the Mentorships program. Note that while this program is currently limited to security projects, the goal of KitHerder is to provide the matchmaking and relationship management features required to open the program to the Mozilla community. The requirements here are driven by the documentation from the mentorship program and it is expected that the system will leverage Mozillians.org accounts to reduce the amount of personal data stored in Kitherder, and issue badges using the Mozilla Foundation badge system based on participation criteria.
|
Python, HTML, CSS, JavaScript | Curtis Koenig | Yvan Boily |
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 |
