Community:SummerOfCode16: Difference between revisions

Removing ServiceWorker project for Servo
(→‎Mozilla Science Lab: Moving from ideas page)
(Removing ServiceWorker project for Servo)
 
(28 intermediate revisions by 10 users not shown)
Line 13: Line 13:
* Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] and avoid doing the things listed there.
* Read [http://blog.gerv.net/2006/05/how_not_to_apply_for_summer_of/ How Not To Apply For Summer Of Code] and avoid doing the things listed there.
* Read our examples of good applications: [[SummerOfCode/SampleApplications/1|1]], [[SummerOfCode/SampleApplications/2|2]], [[SummerOfCode/SampleApplications/3|3]].
* Read our examples of good applications: [[SummerOfCode/SampleApplications/1|1]], [[SummerOfCode/SampleApplications/2|2]], [[SummerOfCode/SampleApplications/3|3]].
* Apply on [http://www.google-melange.com/ the GSoC site] (note that we have an [[SummerOfCode/ApplicationTemplate|application template]]).
* Apply on [https://summerofcode.withgoogle.com/ the GSoC site] (note that we have an [[SummerOfCode/ApplicationTemplate|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.
* 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.


Line 19: Line 19:


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 [mailto:florian@queze.net,clokep@gmail.com 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.
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 [mailto:florian@queze.net,clokep@gmail.com 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 ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}
== Firefox Developer Tools ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}


== Firefox for Android ==
== Firefox for Android ==
Line 58: Line 32:
|-
|-
| Download app assets at runtime
| Download app assets at runtime
| 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.
| [[Community:SummerOfCode16/AndroidDownloadableContent|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.
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 Meta bug 1194338 (Support for downloadable fonts) - Base technology for downloading assets at runtime]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 Meta bug 1194338 (Support for downloadable fonts) - Base technology for downloading assets at runtime]
** [https://bugzilla.mozilla.org/show_bug.cgi?id=1095719 Bug 1095719 - Download hyphenation dictionaries at runtime]
** [https://bugzilla.mozilla.org/show_bug.cgi?id=1095719 Bug 1095719 - Download hyphenation dictionaries at runtime]
Line 71: Line 46:
|}
|}


== Firefox OS / Boot2Gecko ==
== Thunderbird ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 82: Line 57:
! Comments
! Comments
|-
|-
|}
| Implement mbox -> maildir converter
 
| Currently Thunderbird uses mbox as primary storage format for mails (locally). The maildir format is also supported, but we have no converter for it yet. See [https://bugzilla.mozilla.org/show_bug.cgi?id=856087 bug 856087]
== Mozilla Platform (Gecko) ==
| JavaScript, maybe some C++
 
| [mailto:mkmelin+mozilla@iki.fi mkmelin]
{| class="standard-table" border="1" style="border-collapse: collapse"
| [mailto:mkmelin+mozilla@iki.fi mkmelin]
|-
|
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|-
|}
|}


== Thunderbird ==
== Instantbird ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 108: Line 77:
! Comments
! Comments
|-
|-
|}
| Improve & expand the JavaScript XMPP implementation
| The JavaScript XMPP implementation included in Instantbird/Thunderbird works well, but is lacking some features. This project should include a variety of small and larger improvements to the XMPP protocol. Feature-parity with libpurple's XMPP implementation is one of the prerequisites for replacing it with the JavaScript implementation and is an end-goal of this project. Examples of new/missing features include:


== Instantbird ==
* Support for DNS SRV
* Room discovery (i.e. hook XMPP into the "awesometab")
* Misc. bugs
* Test coverage


{| class="standard-table" border="1" style="border-collapse: collapse"
Students are expected to research a list of bugs and unimplemented features in the JavaScript XMPP code they intend to address.
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Improve the JavaScript XMPP implementation and implement new features.
| Includes support for DNS SRV, test coverage and adding new/missing features. Feature-parity with libpurple's XMPP implementation is one of the prerequisites for replacing it with the JavaScript implementation and is an end-goal of this project. Students are expected to compile a list of bugs or unimplemented features in the JavaScript XMPP code.
| JavaScript, XPCOM, an understanding of XMPP is desired
| JavaScript, XPCOM, an understanding of XMPP is desired
| Florian Quèze
| Florian Quèze
| aleth, Patrick Cloke [:clokep]
| aleth, [mailto:clokep@gmail.com clokep]
|
|
|-
|-
| JavaScript Protocol Plug-in
| JavaScript Protocol Plug-in
| Instantbird supports protocol plugins implemented in JavaScript. The student will add support for a new protocol in Instantbird. The student working on new protocols should take every opportunity to improve the code and APIs shared by all JavaScript protocol plugins (IRC, XMPP, Yahoo and Twitter). Students are expected to implement a protocol they use on a day-to-day basis to dog-food the code.
| Google Talk/Hangouts is one of the most popular networks to chat on now and is available over XMPP. Unfortunately, Google has slowly been breaking the interaction with their XMPP bridge such that features stop working. It is desirable to connect directly to Google Hangouts using their proprietary protocol. This would involve:
 
* Adding a new Google Hangouts protocol
* Improving and expanding shared code and APIs used by all JavaScript protocol plugins (IRC, XMPP, Yahoo and Twitter)
* Improving documentation of the process for adding a protocol to Instantbird/Thunderbird
* Reversing engineering of the network protocol
* Add tests for the new protocol
* Using the protocol on a day-to-day basis to dog-food the code
 
Note that some implementations exist for other clients ([https://github.com/tdryer/hangups/ hangups in Python] and [https://bitbucket.org/EionRobb/purple-hangouts purple-hangouts in C]).
| JavaScript, XPCOM, understanding of network protocols
| JavaScript, XPCOM, understanding of network protocols
| Patrick Cloke
| Patrick Cloke [:clokep]
| Patrick Cloke [:clokep], nhnt11
| [mailto:clokep@gmail.com clokep], nhnt11
| Possible protocols include: Google Hangouts, Facebook, Bonjour, TextSecure/Signal, or Telegram
| Don't use Google Hangouts? Protocols we're interested in: Google Hangouts, Facebook, Bonjour, TextSecure/Signal, Telegram, or come talk to us!
|-
|-
| File transfer support
| File transfer support
| API design, backend implementation, frontend UI for supporting file transfers in Instantbird.
| 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:
| XPCOM, JavaScript, webrtc, networking protocols
 
# API design (designing interfaces that could be implemented by different protocols such that the UI can interact in a protocol agnostic way)
# UI design (how will users interact with this feature?)
# Backend implementation (most likely implementing one or two of the XMPP methods, maybe IRC as well)
# Frontend implementation
# Fallback implementation (for protocols that don't support file transfer OR if the file transfer fails, we'd like to use Thunderbird's current FileLink component; we've also discussed whether WebRTC could be useful here)
| XPCOM, JavaScript, XUL/HTML, WebRTC, networking protocols
| nhnt11
| nhnt11
| Patrick Cloke [:clokep], nhnt11
| [mailto:clokep@gmail.com clokep], nhnt11
|
|
|}
|}
Line 189: Line 167:
|
|
|}
|}
== Bugzilla ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}
== Accessibility ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}
== Automation & Tools ==
== Automation & Tools ==


Line 229: Line 180:
| Web-based GDB Frontend
| Web-based GDB Frontend
| Write a graphical frontend for gdb/rr in react.js communicating with backend (gdb/rr) over a websocket.
| 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 [https://public.etherpad-mozilla.org/p/react-gdb etherpad notes] (feel free to add notes). Initial code sketches are taking place on [https://github.com/taskcluster/react-gdb github.com/taskcluster/react-gdb].
| Javascript, react.js, CSS/HTML (gdb/c++ is nice to have)
| Javascript, react.js, CSS/HTML (gdb/c++ is nice to have)
| [https://mozillians.org/en-US/u/jonasfj/ jonasfj]
| [https://mozillians.org/en-US/u/jonasfj/ jonasfj]
Line 234: Line 187:
| I'll happily add the backend to TaskCluster workers, so we can debug processes in CI tasks from a browser.
| I'll happily add the backend to TaskCluster workers, so we can debug processes in CI tasks from a browser.
|-
|-
| <strike>Make WebDriver/marionette match the featureset of Selenium FirefoxDriver.</strike>
| <strike>WebDriver is a protocol for remote control of browsers that is in the process of being standardised at W3C. At this time, the most common WebDriver implementation used with Firefox is Selenium FirefoxDriver. However this has a number of problems e.g. incompatibility with e10s. For internal testing we have developed "marionette", a remote control API with the featureset to replace FirefoxDriver, but using a simple JSON-based protocol rather than HTTP used by WebDriver. To bridge these two worlds we have developed "wires", a proxy written in Rust that translates between W3C-standard WebDriver and the marionette protocol. This allows Firefox to be controlled by any WebDriver-compatible client.</strike>
<strike>Although "wires" currently implements most of the features of the W3C spec, there are a number of improvements required before it can match the functionality of FirefoxDriver. In particular it currently doesn't support the "actions" API which allows simulating low-level events (key presses, mouse clicks, touches, etc.), although this is well supported in marionette itself. There are also some non-standard features that are much requested by early adopters, including the ability to explicitly provide a Firefox profile to run. The purpose of this project would be to add those features to wires.</strike>
| <strike>Rust (basic level only) and other programming experience.</strike>
| <strike>jgraham</strike>
| <strike>jgraham</strike>
| 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
| [https://mozillians.org/en-US/u/armenzg/ armenzg]
| [https://mozillians.org/en-US/u/jmaher/ jmaher] armenzg
| [https://docs.google.com/document/d/1rgZyUpHcIBuyo68Hr0fKuVd1w1j-Xdxae6LK4EXDnek/edit]
|-
| Give Treeherder the ability to schedule TaskCluster jobs
| On Treeherder you can schedule Buildbot jobs which had not been scheduled before (see [[Try#Scheduling_jobs_with_Treeherder|Scheduling jobs with Treeherder]]). You can read more about the project in [https://docs.google.com/document/d/1TDF-UKYb16wxvAtqdzCFauTvJXSx_fjf7i1f8F3l7bk/edit# here].
| Python
| [https://mozillians.org/en-US/u/armenzg/ armenzg]
| armenzg [https://mozillians.org/en-US/u/jmaher/ jmaher]
|}
|}


Line 247: Line 221:
! Comments
! Comments
|-
|-
| Reduce the frequency of update races in Balrog
| [https://bugzilla.mozilla.org/show_bug.cgi?id=1223872 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.
| One of the key features of [https://wiki.mozilla.org/Balrog 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
| Python
| [https://mozillians.org/en-US/u/bhearsum/ bhearsum]
| [https://mozillians.org/en-US/u/bhearsum/ bhearsum]
| [https://mozillians.org/en-US/u/bhearsum/ bhearsum]
| [https://mozillians.org/en-US/u/bhearsum/ bhearsum]
|  
|  
|}
== Rust ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|}
|}


Line 285: Line 246:
| [https://mozillians.org/u/manishearth Manish Goregaokar]
| [https://mozillians.org/u/manishearth Manish Goregaokar]
| [https://github.com/servo/servo/wiki/Summer-of-Code-2016:-File-support In-depth project details]
| [https://github.com/servo/servo/wiki/Summer-of-Code-2016:-File-support In-depth project details]
|-
| Service Worker building blocks
| Implement some fundamental pieces of the missing ServiceWorker API
| Familiarity with Javascript; desire to write [https://rust-lang.org Rust] code (Rust or C++ experience helpful)
| [http://mozillians.org/u/jdm Josh Matthews]
| [http://mozillians.org/u/jdm Josh Matthews]
| [https://github.com/servo/servo/wiki/Summer-of-Code-2016:-ServiceWorker-infrastructure In-depth project details]
|}
== Localization ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
|-
|}
|}
Line 327: Line 268:
|}
|}


== OpenArt ==
==NSS (Network Security Services)==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 336: Line 277:
! Reporter  
! Reporter  
! Mentor(s)  
! Mentor(s)  
! Comments  
! Comments
|-
|-
| Implement RFC7512 PKCS#11 URI support and system integration
| [https://tools.ietf.org/html/rfc7512 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1162897 bug 1162897] for details. Also, NSS does not obey the system configuration for which PKCS#11 tokens to load, as described in [https://bugzilla.mozilla.org/show_bug.cgi?id=248722 bug 248722]. We should fix this too.
See dev-tech-crypto email at https://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg12493.html
| C coding, familiarity with PKCS#11 preferable
| dwmw2
| [mailto:rrelyea@redhat.com Bob Relyea], [mailto:david.woodhouse@intel.com David Woodhouse (dwmw2)]
|}
|}


== Webmaker ==
== Mozilla Science Lab ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 351: Line 298:
! Comments
! Comments
|-
|-
| [https://github.com/mozillascience/paperbadger 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
| Strong JavaScript programming skills. Familiar with node.
| Abigail Cabunoc Mayes
| [https://mozillians.org/en-US/u/Abby/ Abigail Cabunoc Mayes :abbycabs]
| The [https://mozillascience.org/ Mozilla Science Lab], an initiative of the Mozilla Foundation, works to make research collaborative, accessible and usable.
|}
|}


== Mozilla Science Lab ==
== MozVR ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 359: Line 321:
! Title  
! Title  
! Details  
! Details  
! Skills Needed
! Reporter
! Reporter  
! Mentor(s)  
! Mentor(s)  
! Comments
! Comments  
|-
|-
| Contributorship Badges for Science.
| [http://www.aframe.io aframe.io] - Building Blocks for the VR Web
| Exploring the use of digital badges for crediting contributors to scholarly papers for their work. 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.
 
In this project, you will integrate with the publishers paper submission system to generate the badges.
| Strong JavaScript programming skills. Familiar with node.
| Abigail Cabunoc Mayes
| [https://mozillians.org/en-US/u/Abby/ Abigail Cabunoc Mayes :abbycabs]
|  
|  
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.
| JavaScript and Computer Graphics (OpenGL / WebGL)
| Diego Marcos : dmarcos
| Diego Marcos : dmarcos
|}
|}
Confirmed users
512

edits