Ideas for GSOC 2015
The timeline for GSOC 2015 indicates that the ideas must be submitted by February 20.
See also the GSOC 2015 FAQ.
Adding a Proposal
For a list of examples, please see KDE Ideas for GSOC 2011
(for testing, make sure you link your proposal from the etherpad).
When adding an idea to this section, please try to include the following data:
- if the application is not widely known, a description of what it does and where its code lives a brief explanation
- the expected results
- pre-requisites for working on your project
- if applicable, links to more information or discussions
- mailing list, githut repo, or IRC channel for your application/library/module
- your name and email address for contact (if you're willing to be a mentor)
- If you are not a mentor but have a good idea for a proposal, get in contact with relevant parties to find one.
[add your project below]
Test the Web Forward: Test Results Progress Dashboard
A website that can be used to compare the results of running web-platform-tests across multiple different browsers.
The Web Platform Tests project is a cross-browser testsuite for the web platform. It is designed to improve interoperability between different web browsers by allowing them to check their implementations of various specs against a testsuite.
In order to run web-platform-tests in browsers a couple of tools have been developed. The first is a semi-automatic in-browser runner that produces JSON output by default. The second is wptrunner, a fully automated runner that produces mozlog format messages as output by default. The latter is being used to run the test in several browser CI systems (notably those for Gecko and Servo).
At the moment there isn't a good system for visualizing the results of a specific test run (e.g. to tell where a browser is not matching the spec) or for comparing between different browsers (in order to tell where tests are broken across many browsers possibly indicating a test bug or a spec bug). The Test Results Progress Dashboard project is to develop a Web dashboard that can ingest the output data from wptrunner and allows comparisons between multiple result sets (e.g. between Web browsers).
- A server-side component that can ingest data from a wptrunner run (and perhaps an in-browser runner run) and store the results in a database, retaining the information that is required for the subsequent display. Initially this can just require manual specification of the log files (note that in the case of e.g. gecko there is > 1 log produced per run due to test chunking; this needs to be supported). Some consideration needs to be given of the metadata required to identify the browser version that was being used and the version of web-platform-tests that the browser was being run against.
- A web front end that can display the results of a particular run in a specific browser. This must be able to work efficiently with a subset of the data i.e. it must not be necessary to download and display the results of all the tests in order to see the results of a subset of tests.
- Extensions to the web front end to allow comparisons between various sets of results e.g. to see results that changed between two different runs, or all tests that fail in 2 or more browsers from a given set of runs.
- Server-side web programming (Python)
- Some database knowledge.
Philippe Le Hegaret and James Graham
Through automation, these test suites can be programmatically generated and kept up to date provided minimal initial input. This project consists in setting up this system on top of existing infrastructure build in node.js and improving the current test harness.
- A node.js application which generates Web IDL suites from a database of WebIDL snippets and keep these test suites up to date as the WebIDL snippets evolve over time.
- A standardized system for communicating the minimal data needed for these test suites to be generated (in spec, through a manifest file, tbd).
- Improvements to the test harness to provide more thorough testing and make the results more palatable.
- HTTP APIs
- Manipulating ASTs
- Git and GitHub
Philippe Le Hegaret and Tobie Langel
CSS Validator calc() support
The current version of the CSS Validator does not yet validate calc() function. Doing so would be helpful as the use of calc() in real-life CSS style sheets is becoming more common. The work requires finishing the type checking capabilities of the CSS Validator, as there are checks for type compatibility in an expression, and implement the validation algorithm in the parsing code (The parsing stub is already written, using JavaCC). Once it is implemented, the calc() value should be allowed in many CSS properties, for CSS Level 3 and above.
Be able to correctly parse assertions, and report meaningful errors (There will be positive and negative testing).
- Java Programming (skill level: High)
Alignment of Cordova APIs with W3C APIs
Aligning APIs used in the official Cordova plugins with their equivalent APIs standardized in W3C.
One of the stated goals of the Cordova project is to serve as a stop-gap solution to the development of pure Web applications targeting mobile browsers.
To ensure a smooth transition between hybrid and pure-Web development approaches, it is important to keep the APIs for advanced capabilities provided by Cordova aligned with the equivalent APIs standardized in W3C.
The goal of this project would be to provide patches to the main Cordova plugins to get them aligned with W3C APIs.
- one or several official Cordova plugins aligned with W3C APIs
- documented approaches to facilitate further alignment
- Basic knowledge about Cordova as a development framework
- ideally, some experience with one or more native development languages (Objective C, Java, C++)
Dominique Hazaël-Massieux <email@example.com>. We will use IRC, github and other online communication systems for communication.