Community:SummerOfCode14: Difference between revisions

no edit summary
No edit summary
No edit summary
 
(21 intermediate revisions by 9 users not shown)
Line 1: Line 1:
This page lists all the [[SummerOfCode|Google Summer of Code]] 2014 projects with confirmed mentors, and which have been approved by the SoC administrator. New suggestions can be made on [[Community:SummerOfCode14:Brainstorming|the Brainstorming page]]. Do not edit this page yourself; contact Florian for edits.
This page lists all the [[SummerOfCode|Google Summer of Code]] 2014 projects with confirmed mentors, and which have been approved by the SoC administrator. New suggestions can be made on [[Community:SummerOfCode14:Brainstorming|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 [[Community:SummerOfCode14:Brainstorming|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.)
'''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 [[Community:SummerOfCode14:Brainstorming|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 [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=student-project&resolution=--- 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.
In addition to the specifically-named projects below, we have also tagged a number of bugs in Bugzilla with the keyword [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=student-project&resolution=--- 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.
Line 63: Line 63:
| [https://mozillians.org/u/gasolin/ Fred Lin]
| [https://mozillians.org/u/gasolin/ Fred Lin]
[https://mozillians.org/en-US/u/gweng/ Greg Weng]
[https://mozillians.org/en-US/u/gweng/ Greg Weng]
|-
|}
== Mozilla Platform (Gecko) ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! 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/.
|-
|-
|}
|}
Line 121: Line 141:
| 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.
| 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
|}
|}


Line 151: Line 164:
Depending on remaining time and student experience, adding performance tests to Lightning would be a bonus.
Depending on remaining time and student experience, adding performance tests to Lightning would be a bonus.
| Javascript; Python and make for perf tests
| Javascript; Python and make for perf tests
| Philipp (:Fallen)
| [http://mozillians.org/u/kewisch Philipp (:Fallen)]
| Ludovic (:ludovic) / Mohit(:redDragon)
| Ludovic (:ludovic) / [https://mozillians.org/en-US/u/redDragon/ 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.
| 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.
|-
|-
Line 162: Line 175:
* Turn the CalDAV calendar into a cache-only provider (no bug yet)
* Turn the CalDAV calendar into a cache-only provider (no bug yet)
| Javascript, SQL,  
| Javascript, SQL,  
| Philipp (:Fallen)
| [http://mozillians.org/u/kewisch Philipp (:Fallen)]
| Mohit (:redDragon)
| [https://mozillians.org/en-US/u/redDragon/ 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.
| 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.
|-
|-
Line 173: Line 186:
* udpate the caldav provider to the latest spec chunk by chunk
* udpate the caldav provider to the latest spec chunk by chunk
| Javascript, SQL,  
| Javascript, SQL,  
| Philipp (:Fallen)
| [http://mozillians.org/u/kewisch Philipp (:Fallen)]
| Mohit (:redDragon) / Philipp(:Fallen)
| [https://mozillians.org/en-US/u/redDragon/ Mohit(:redDragon)] / [http://mozillians.org/u/kewisch 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.
| 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.
|}
|}
Line 194: Line 207:
| [https://mozillians.org/u/glob/ Byron Jones]
| [https://mozillians.org/u/glob/ Byron Jones]
| [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).
| 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). ([https://wiki.mozilla.org/Bugzilla:Markdown more information])
|-
|-
| Migrate from YUI2 to YUI3. {{bug|453268}}
| Migrate from YUI2 to YUI3. {{bug|453268}}
Line 202: Line 215:
| [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.
| Yahoo [https://code.launchpad.net/~evan-goer/bugzilla-yui3/yui3 started the work] however progress has stalled.
|}
== Accessibility ==
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! Title
! Details
! Skills Needed
! Reporter
! Mentor(s)
! Comments
|-
| Implement speech synthesis on desktop Firefox
| We have an implementation of speech synthesis via the [https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html 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.
| [https://mozillians.org/en-US/u/eeejay/ eeejay]
| [https://mozillians.org/en-US/u/eeejay/ eeejay] (and probably [https://mozillians.org/en-US/u/smaug/ smaug] doing the bulk of the reviewing).
| We should also explore how far along in the specs [https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi-errata.html errata] we could go.
|-
|}
|}


Line 225: Line 258:
See meta bug at {{bug|916295}}; actionable bugs for this project are {{bug|916265}} and {{bug|886570}}.
See meta bug at {{bug|916295}}; actionable bugs for this project are {{bug|916265}} and {{bug|886570}}.
| JavaScript, Python
| JavaScript, Python
| Jonathan Griffin
| [https://mozillians.org/en-US/u/jgriffin/ Jonathan Griffin]
| James Graham
| [https://mozillians.org/en-US/u/jgraham/ James Graham]
|
| [https://wiki.mozilla.org/Auto-tools/GSoC/2014#Structured_Logging_for_Mochitest Detailed Outline]
|-
|-
| Mochitest failure investigator
| Mochitest failure investigator
Line 235: Line 268:
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.
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
| JavaScript, Python
| Joel Maher
| [https://mozillians.org/en-US/u/jmaher/ Joel Maher]
| Joel Maher
| [https://mozillians.org/en-US/u/jmaher/ Joel Maher]
|
|
|}
|}
Line 254: Line 287:
| Having {apt-get,yum} install rust
| Having {apt-get,yum} install rust
| deb packaging / Rust (LLVM appreciated)
| deb packaging / Rust (LLVM appreciated)
Must have demonstrated packaging capabilities (packages in Debian or Ubuntu, bug fixes, etc).
|  
|  
| Sylvestre Ledru & Luca Bruno
| [https://mozillians.org/en-US/u/sylvestre/ 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
| Main issues: https://wiki.debian.org/Teams/RustPackaging/Bootstrap & https://github.com/mozilla/rust/issues/4259. Will focus on Debian/Ubuntu first
|-
|-
Line 271: Line 305:
! Comments
! Comments
|-
|-
| Implement XMLHttpRequest
| Implement [https://developer.mozilla.org/en-US/docs/XMLHttpRequest XMLHttpRequest]
| Make common sites using XHR work in Servo.
| Make common sites using XHR work in [https://github.com/mozilla/servo/ Servo].
| Familiarity with using XMLHttpRequest, desire to write [http://www.rust-lang.org Rust] code (C++ experience helpful)
| Linux or OS X only; familiarity with 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://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]
| [https://github.com/mozilla/servo/wiki/Summer-of-Code-2014:-Implement-XMLHttpRequest In-depth project guidelines]
|-
|-
|}
|}
Line 307: Line 341:
| {{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|Project wiki]]
* [https://wiki.mozilla.org/Intellego/GSoC GSoC wiki ]
* [[Intellego/Meetings/Status|Weekly status meetings]]
* [[Intellego/Meetings/Status|Weekly status meetings]]
* IRC: {{IRC|intellego}}
* IRC: {{IRC|intellego}}
Line 314: Line 348:
|}
|}


== Security Engineering ==
== Security ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 329: Line 363:
| Java Script, knowledge of Firefox add-ons
| Java Script, knowledge of Firefox add-ons
| [https://mozillians.org/en-US/u/psiinon/ Simon Bennetts]
| [https://mozillians.org/en-US/u/psiinon/ Simon Bennetts]
| Mark Goodwin, [https://mozillians.org/en-US/u/psiinon/ Simon Bennetts]
| [https://mozillians.org/en-US/u/mgoodwin/ Mark Goodwin], [https://mozillians.org/en-US/u/psiinon/ 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.<br>
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.<br>
<br><b>Goals</b>: To take Kitherder to a level where it can be deployed to allow the matching of mentors and mentees and manage the basic relationship work.
<br> GitHub Source: https://github.com/ygjb/kitherder
<br> Gist: https://gist.github.com/ygjb/4543418
| Python, HTML, CSS, JavaScript
| Curtis Koenig
| Yvan Boily
|
|-
|}
|}


== Open(Art) ==
== Open(Art) ==
Line 348: Line 396:
| Solid javascript. Understanding of Dataflow / Flow-Based programming.
| Solid javascript. Understanding of Dataflow / Flow-Based programming.
|  
|  
| Forrest Oliphant
| [https://mozillians.org/en-US/u/forresto/ Forrest Oliphant]
|
|}
 
== Mozilla Science Lab ==
 
{| class="standard-table" border="1" style="border-collapse: collapse"
|-
! 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 [https://github.com/tarmstrong/bcast-experiments is on GitHub] (see [http://third-bit.com/bcast/ 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 [http://labs.toolness.com/temp/thimble-dzslides-spike/?notypekit=1 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.
| [https://mozillians.org/en-US/u/gvwilson/ Greg Wilson]
| [https://mozillians.org/en-US/u/gvwilson/ Greg Wilson]
|
|-
| Peer Instruction on the Web
| [http://en.wikipedia.org/wiki/Peer_instruction 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 [http://teaching.software-carpentry.org/wp-content/uploads/2012/08/porter-halving-fail-peer-instruction-2013.pdf 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 [http://www.webrtc.org/ 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 [http://software-carpentry.org/blog/2014/02/online-peer-instruction-tool.html 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.
| [https://mozillians.org/en-US/u/gvwilson/ Greg Wilson]
| [https://mozillians.org/en-US/u/gvwilson/ Greg Wilson]
|
|
|-
|}
|}
Confirmed users
87

edits