Confirmed users, Bureaucrats and Sysops emeriti
421
edits
Community:SummerOfCode17: Difference between revisions
Jump to navigation
Jump to search
Reordering a bit.
(Reordering a bit.) |
|||
| Line 23: | Line 23: | ||
Proposals can be in almost any part of the Mozilla project - don't be fooled by the "Code" in "Summer of Code". If there is no category below for your part of Mozilla, add one! | Proposals can be in almost any part of the Mozilla project - don't be fooled by the "Code" in "Summer of Code". If there is no category below for your part of Mozilla, add one! | ||
== Mozilla Platform (Gecko) == | == Mozilla Platform (Gecko) == | ||
| Line 505: | Line 485: | ||
| [https://mozillians.org/en-US/u/gideon/ gideon] | | [https://mozillians.org/en-US/u/gideon/ gideon] | ||
| thimble repo: https://github.com/mozilla/thimble.mozilla.org | | thimble repo: https://github.com/mozilla/thimble.mozilla.org | ||
|} | |||
== Open Innovation (Open Source Student Clubs) == | |||
{| class="standard-table" border="1" style="border-collapse: collapse" | |||
|- | |||
! Title | |||
! Details | |||
! Skills Needed | |||
! Reporter | |||
! Mentor(s) | |||
! Comments | |||
|- | |||
| Measuring the Development of an Open Source Contributor | |||
| We are looking for a passionate developer to work with the GitHub API to build a platform for measuring contributors performance/engagement across multiple open source projects over an extended time period. | |||
| Javascript, javascript framework, a sequel database, HTML, GitHub API | |||
| [https://mozillians.org/en-US/u/lucyeoh/ :Lucy] | |||
| [https://mozillians.org/en-US/u/bacharakis/ :Christos] | |||
| For questions about this project please leave a comment in [https://github.com/mozilla/Campus-Program/issues/363 this issue] | |||
|- | |||
|} | |||
== Instantbird == | |||
{| class="standard-table" border="1" style="border-collapse: collapse" | |||
|- | |||
| Matrix protocol support | |||
| [http://matrix.org/ Matrix] is an open, decentralized protocol for instant messaging (and more!) It has bridges to many other networks and protocol, e.g. IRC, Slack, and more. Initial support for Matrix was added in {{bug|1199855}}, but there's a lot to do still: | |||
* Support more features from the Matrix SDK (room topics, typing notifications, read receipts, etc.) | |||
* Support one-on-one conversations. | |||
* Add tests specific to Matrix. | |||
* Improve the Matrix JS-SDK that Instantbird and Thunderbird depend on. | |||
* 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. | |||
* Using the Matrix protocol on a day-to-day basis to dog-food the code and see what else is missing. | |||
| JavaScript, XPCOM, experience using HTTP APIs | |||
| Patrick Cloke [:clokep] | |||
| [mailto:clokep@gmail.com clokep] | |||
| If you're interested in supporting a different protocol, please come talk to us. Protocols we're interested in: Matrix, Google Hangouts, Facebook, Bonjour, TextSecure/Signal, Telegram, or others! | |||
|} | |||
== Calendar == | |||
{| class="standard-table" border="1" style="border-collapse: collapse" | |||
|- | |||
! Title | |||
! Details | |||
! Skills Needed | |||
! Reporter | |||
! Mentor(s) | |||
! Comments | |||
|- | |||
| Introducing Calendar Accounts | |||
| Traditionally our calendar extension is organized into a list of calendars, each calendar being implemented by a “provider”, for example local storage or using the CalDAV protocol. The service to manage these calendars maintains a simple list, the entries have no connection to each other. | |||
Some calendar providers would greatly benefit from being able to group calendars into accounts, for example free-busy lookups are usually per-server operations and not per-calendar. It would also open the door for some great new features that have been postponed because they can be implemented cleaner with the notion of accounts. | |||
| XUL, CSS, JavaScript | |||
| [mailto:mozilla@kewis.ch Fallen] | |||
| [mailto:mozilla@kewis.ch Fallen] | |||
| [[Media:Calendar-gsoc2015-calmgr.pdf|Click here for a detailed project description]] | |||
|- | |||
| Resource Booking Improvements | |||
| The Lightning extension has a dialog for inviting attendees to an event, which also shows availability information. Albeit not very obvious, it also allows booking resources and rooms. To improve this experience we would like users to be able to pick rooms and resources in a way that they don't need to remember the room address and quickly see which rooms and resources exist and are available around the proposed time of the event. | |||
| XUL, CSS, JavaScript | |||
| [mailto:mozilla@kewis.ch Fallen] | |||
| [mailto:mozilla@kewis.ch Fallen] | |||
| [[Media:Calendar-gsoc2015-resourcebooking.pdf|Click here for a detailed project description]] | |||
|- | |||
| Advanced Preferences System | |||
| Today, Lightning preferences can mostly only be set on global level. A different, but smaller set of preferences is available on calendar level, whereas several preferences are currently only available from within the config editor. The goal of this project is to create a preference system like Thunderbird uses it - making most of the preferences available on calendar level with an option to fall back to corresponding globally configured preferences. | |||
This is mainly a JavaScript project, but to a smaller extent some UI extensions are required. The emphasis is on the functional part here. | |||
| XUL, HTML, CSS, JavaScript | |||
| MakeMyDay | |||
| [mailto:mozilla@kewis.ch Fallen] / MakeMyDay | |||
| | |||
|- | |||
| Convert from XUL to HTML | |||
| Lightning has traditionally been using XUL for its user interface. To modernize, we would like to convert dialogs, tab content and other parts of the user interface to HTML. The new components should use web standards as much as possible, avoiding extensive use of third party libraries. | |||
This is a fairly open ended proposal, which requires the applicant to first identify parts of the user interface that would make sense to convert to HTML and put up a timeline how long to spend on each component. Focus should be on the quality of the conversion, not the quantity of components changed. | |||
| HTML, CSS, JavaScript | |||
| [mailto:mozilla@kewis.ch Fallen] | |||
| [mailto:mozilla@kewis.ch Fallen] | |||
|} | |} | ||