| Gijs
| Gijs
| Are we sure that this project represents 3 months of effort for a student, and that it is worth spending that much time? Have the people working on eg. about:memory expressed the desire for this change? I'm just trying to be really sure that we aren't going to ask a student to do something, and then discover later that it wasn't actually wanted. [[User:Florian|Florian]] ([[User talk:Florian|talk]]) 22:49, 13 February 2014 (PST)
|-
| Provide proper WebRTC testing and integration on BSD systems
| Gaston
| Gaston
|Can you be more specific about the scope of the project? (is there a list of bugs you could point potential students at?) How is completion of this project defined? [[User:Florian|Florian]] ([[User talk:Florian|talk]]) 22:49, 13 February 2014 (PST)
|-
|}
! 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.
| [https://mozillians.org/u/fabrice/ Fabrice Desré]
| [https://mozillians.org/u/fabrice/ 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
| [https://mozillians.org/u/gasolin/ Fred Lin]
[https://mozillians.org/en-US/u/gweng/ Greg Weng]
| [https://mozillians.org/u/gasolin/ Fred Lin]
[https://mozillians.org/en-US/u/gweng/ Greg Weng]
|-
| Implementation of a default Voice Recorder app
! Comments
|-
| Make Lightning Fast
| The Lightning Extension has a few performance problems, especially with lots of calendars. Now that the [http://mikeconley.ca/blog/2012/06/15/gecko-profiler-now-works-in-thunderbird-daily/ 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:
# [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=keyword%3Aperf%20prod%3Acalendar&list_id=6253887 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 [http://mxr.mozilla.org/comm-central/source/calendar/base/public/calIChangeLog.idl#83 provider inteface] to the [http://mxr.mozilla.org/comm-central/source/calendar/base/public/calIItemBase.idl 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
| [http://tools.ietf.org/html/rfc5546 iTip Standard] allows different email clients and servers to schedule meetings based on email messages. The scheduling extension to CalDAV RFC has become a [http://tools.ietf.org/html/rfc6638 full spec now]. However Lightning's invitation processing implementation lags behind. A student working on this would be expected to:
* Explore some of the [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=itip&list_id=9388044 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.
|}
! Comments
|-
| Add markdown support to Bugzilla. {{bug|330707}}.
| Currently Bugzilla only supports plain text for comments. Adding support for [http://daringfireball.net/projects/markdown/ markdown] allows for rich text formatting in a way which degrades nicely to plain text.
| Perl
| [https://mozillians.org/u/glob/ Byron Jones]
| [https://mozillians.org/u/glob/ 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
| [https://mozillians.org/u/glob/ Byron Jones]
| [https://mozillians.org/u/glob/ Byron Jones]
| Yahoo [https://code.launchpad.net/~evan-goer/bugzilla-yui3/yui3 started the work] however progress has stalled.
|}
! 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
|
|}
! 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:
|
|-
| 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
|}
! 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
|-
|}
! Mentor(s)
! Comments
|-
| Implement XMLHttpRequest
| Make common sites using XHR work in Servo.
| Familiarity with using XMLHttpRequest, desire to write [http://www.rust-lang.org Rust] code (C++ experience helpful)
| [https://mozillians.org/u/jdm/ Josh Matthews]
| [https://mozillians.org/u/jdm/ Josh Matthews]
| [https://github.com/mozilla/servo/wiki/XHR-project In-depth project guidelines]
|-
|}
|}
== Open(Art) ==
{| class="wikitable"
|-
! 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. <br /><br /> 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
|
|-}
== Localization ==
! 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
| {{mozillian|gueroJeff|Jeff Beatty}}
| {{mozillian|gueroJeff|Jeff Beatty}}
|
* [https://intellego.etherpad.mozilla.org/GSOC-proposal Week by week timeline for GSoC]
* [[Intellego|Project wiki]]
* [[Intellego/Meetings/Status|Weekly status meetings]]
* IRC: {{IRC|intellego}}
|-
|}
! Comments
|-
| Implement [https://developer.mozilla.org/en-US/docs/zest 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
| [https://mozillians.org/en-US/u/psiinon/ Simon Bennetts]
| Mark Goodwin, [https://mozillians.org/en-US/u/psiinon/ Simon Bennetts]
|
|}
