1. General Info

Students, please read information about our application requirements and advice for students in addition to reviewing the ideas on this page. This list is not exclusive, and there are other ways you can find a mentor and define your GSoC project idea. Also, please be sure to contribute some code for the module you are applying to work on before or during the application process.

Mentors, the ideas do not have to be only about modules that are in a GNOME suite. If it's a project on GNOME-related software that can benefit the GNOME community, it's also good to list it here.

When adding a project idea, please try to follow those guidelines:

Discuss your idea with designers in #gnome-design to get their input and plan collaboration, especially if your idea is related to one of the core GNOME modules. If you are not sure who to speak to, start with AllanDay .
Consider ideas that consist of manageable and relevant tasks that the student can land in the main module throughout the internship period. See the information for mentors for more on preferred idea types.
Add your idea to the bottom of the Untriaged Ideas section below
If you're interested in mentoring the idea, put your name. If not, then find someone else who is willing to mentor it.
Do not list multiple ideas with only one item. Use multiple items instead.
Briefly explain why this would be great for GNOME.
Do not write lots of text to explain your idea. If this is going to be long, maybe it's worth creating a page for it?
Make sure students who do not know much about all GNOME modules can understand the proposed idea.
Please list your idea on this page even if you already have a strong applicant applying to it, so that it's triaged and agreed upon. You can put [No longer taking applicants] next to your idea right away, as described in the section below.

When students approach you about the idea you listed:

Be clear with them about whether it is suitable for new contributors or for their experience level.
Be prepared to give them a simple bug to fix or task to complete for your module and help them along with the setup and questions about the code. Encourage them to continue on fixing more bugs or writing code for the idea they are planning to apply for.
If you already have a strong student applying to work on the idea, redirect other students to find other ideas to propose instead or in addition to your idea.
If you already have as many strong students applying to work on the ideas you plan to mentor as you can handle for mentorship or if you are working with as many students as you can handle guiding during the application process, redirect other students to find other ideas and mentors.
If you are redirecting students from your idea, please add [No longer taking applicants] to its title in the list below.
Don't hesitate to reach out to the GNOME GSoC admins if you need help redirecting students.

Please use this format:

 . '''idea title''' (mentor: MentorName linking to your wiki.gnome.org personal info page)
 * ''Benefits'': describe the benefits of your idea
 * ''Requirements'': what should the student know already?
 * Note: one or multiple notes, links, whatever further information
----

2. Confirmed Ideas

Implement GnuPG pinentry program instead of Gnome Keyring GnuPG agent (mentor: StefWalter)
Benefits: Gnome Keyring is currently incompatible with newer versions of GnuPG. We need to reimplement and simplify how we prompt for, save and cache GnuPG passphrases.
Requirements: Usage of GnuPG, how GnuPG pinentry works, how to store a passphrase in Gnome Keyring via the API, how to use GLib and GObject based APIs.
Note: Bugzilla bug outlining and tracking the work: https://bugzilla.gnome.org/show_bug.cgi?id=742094

Improve GtkApplication for Mac OS (mentor: Ryan Lortie)
Benefits: Better support/integration for Gtk applications on Mac OS
Requirements: daily user of Mac OS with good knowledge of Cocoa, Objective C; knowledge of Gtk/GLib/GObject a very big plus.
Note: https://bugzilla.gnome.org/show_bug.cgi?id=722476 contains a list of TODO items. Most items are fairly small and self-contained. This project would involve completing at least several of the items on that list.

GStreamer projects (mentor: SebastianDröge, , Luis de Bethencourt)

GStreamer is a library for constructing graphs of media-handling components. The applications it supports range from simple Ogg/Vorbis playback, audio/video streaming to complex audio (mixing) and video (non-linear editing) processing. GStreamer GSOC projects can be found here: http://gstreamer.freedesktop.org/GSOC/socprojects.html

[No longer taking applicants] Evolution configuration EExtension for ActiveSync (mentor: DavidWoodhouse)
Benefits: allow simple setup of Evolution with ActiveSync back end, instead of having to manually configure it.
Requirements: Basic knowledge of how to put together a GTK+ UI, ideally some familiarity with Evolution's plugin API or the confidence/capability to dig in and learn it.
Note: The Evolution-ActiveSync module has an existing eplugin which is outdated and hasn't built since about 3.4 or even earlier. We really need someone to update it and give us a seamless setup for ActiveSync accounts again. Preferably dragging activesyncd into 2015 by migrating its own config from GConf while we're at it.

[No longer taking applicants] Implement additional event sources for GNOME Shell's Time & Date drop-down (mentor: Florian Müllner)
Benefits: GNOME 3.16 brings an updated notification system which involves a more functional Time & Date Drop-Down. However not all sources from the designs have been implemented: it would be awesome to also have weather forecasts and birthday reminders readily available there. If time permits, it would be great to work with the GNOME design team on integrating Music controls, as the special notification type we used to have was removed by the redesign.
Requirements: knowledge of JavaScript, DBus, ideally some GObject basics and possibly C.

[No longer taking applicants] Nautilus (Files) and Gtk+ Add a drive dialog (mentor: CarlosSoriano)
Benefits: The sidebar of nautilus will be less cluttered and the connection to network dialog will be improved.
Requirements: C, Gtk+
Notes:
- The work is almost all in GtkPlacesSidebar, so the work resides in Gtk+, but this is a small project and very contained. It's easier hacking on this than in a single widget of Nautilus.
- Description: The latest Nautilus designs include plans to rework the places sidebar so that it is more focused and less cluttered. A key part of this design is a new "Add Drive" dialog. This will allow you to permanently add local or remove volumes to the sidebar (removable volumes will be automatically added to and removed from the sidebar, as they are now). The new dialog is intended to replace the existing "Browse Network" item and "Connect to Server" dialog. It has a list of drives, which contains previously used servers, available local drives, and any servers that can be detected on the network.
- Design: https://raw.github.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/add-drive-dialog.png

[No longer taking applicants] GNOME GUI for coala (mentor: Lasse Schuirmann, co-mentor: Mischa Krüger)
Benefits: GNOME needs more developer tools. With coala we can offer developers and especially newcomers a way to fastly check their patches and code. This helps making good contributions easy, increases patch quality and saves review and patch refinement time.
Requirements: Python knowledge useful.
Note: A mockup will be created soon. For any questions about this project and before contributing, please contact lasse.schuirmann@gmail.com. More information is also available at:

[No longer taking applicants] Create HTML output for coala and integrate it into GNOME Continuous (mentor: Lasse Schuirmann, coala-co-mentor: Mischa Krüger, continuous-co-mentor: needed)
Benefits: GNOME needs more developer tools and lacks good continuous integration services. A major goal of coala is to make static code analysis easy. Continuous integration is a great way to provide static code analysis with much less developer overhead.
Requirements: Python knowledge useful
Note: For any questions about this project and before contributing, please contact lasse.schuirmann@gmail.com. This project needs coordination with the GNOME QA team which is not done yet. Consider it a raw proposal. More information is also available at:

[No longer taking applicants] Create gedit plugin using coala (mentor: Lasse Schuirmann, co-mentor: Mischa Krüger, gedit-co-mentor: needed)
Benefits: coala is used to analyze specific patterns in static code and if something does not conform to predefined rules, it brings these to notice to developers (and if possible tries to auto-correct it). It is a good idea to integrate this with gedit where gedit can show these errors while the developer is writing the code.
Requirements: Python knowledge useful, dbus and vala will be helpful too
Note: For any questions about this project and before contributing, please contact lasse.schuirmann@gmail.com. More information is also available at:

[No longer taking applicants] Clocks Redesign (mentor: Lasse Schuirmann, co-mentor: Paolo Borelli)
Benefits: Clocks is one of the very basic applications of GNOME. However it currently does not support some features like multiple timers (heavily needed in kitchens) and the usability could be improved. Some mockups are already available.
Requirements: Vala knowledge useful
Note: For any questions about this project, contact lasse.schuirmann@gmail.com. More information is also available at:

[No longer taking applicants] Documents: Improve the collection UI (mentor: DebarshiRay)
Benefits: The user interface for creating new collections has always been rough, and there are numerous bugs against it. Time has come to refresh it and polish the edges.
Requirements: JavaScript, GLib, GTK+
Note: The intended designs are on this bug.

[No longer taking applicants] Documents: Upload to ownCloud (mentor: DebarshiRay)
Benefits: Improves the ownCloud integration in GNOME. The inability to upload content is one of the bigger missing pieces, and this will be a big step forward in that direction.
Requirements: JavaScript, GLib, GTK+
Note: You should get yourself an ownCloud account.

[No longer taking applicants] Make use of phone as a GPS device (AKA GPS sharing) (mentor: ZeeshanAli)

In GNOME we already have a working Geolocation framework, Geoclue that helps users find their current location in Maps and automatically update timezone among other things. This framework currently relies heavily on wifi-based geolocation (and therefore Mozilla Location Services) since most laptops and desktops out there do not have 3G modems on them. The aim of this project would be to allow people to make use of GPS of their phones (androids at least) on a GNOME system.

Half of this work will involve implement a simple Android app that shares the GPS data over the network and the other half would involve writing a new source in geoclue that handles this data. If time permits, we'll look into iPhone app too.

Benefits: Greatly improve the reliability and accuracy of our geolocation framework (especially for desktops as they typically don't even have WiFi hardware).
Requirements: C, Familiarity with GObject, D-Bus or writing android and/or iOS apps will be an advantage
Note: Design page here.

[No longer taking applicants] Nibbles: Modernization (mentor: MichaelCatanzaro)
Benefits: GNOME Nibbles is looking pretty old and needs a revamp.
Requirements: Experience with C, Vala, and GObject programming; previous contributions to GNOME; and experience designing a significant programming project
Note: Before coding begins, we'll work with a designer to come up with a modern design for this game. The code is old and crufty but there is not very much of it, so your first task will be to rewrite the application in Vala. This will be difficult for new programmers to do well, so this project is better suited to more experienced students. As you go, you'll take special care to rethink the worm data structure, so as to avoid the many discontiguous worm bugs that plague the current version. Lastly, you'll create an installed test to make sure the worms stay contiguous when other people change your code in the future.

[No longer taking applicants] Refactor a gstdataprotocol library and create GStreamer's debugger (mentor: SebastianDröge)
Benefits: gstdataprotocol can be used for debbuging GStreamer's pipelines remotely. Library doesn't implement a few useful features for now. Moreover, library might be buggy. Debugger (which will use gstdataprotocol internally) will allow user to preview selected buffers/events/queries and log messages on-line, watch and change properties.
Requirements: knowledge of GStreamer, C, C++ and GObject.
Note: currently gstdataprotocol is a part of gda plugin, in gst-plugins-bad module.
Note: documentation(GStreamer 0.10): http://www.freedesktop.org/software/gstreamer-sdk/data/docs/2012.5/gstreamer-libs-0.10/gstreamer-libs-gstdataprotocol.html
Note: other GStreamer GSOC projects: http://gstreamer.freedesktop.org/GSOC/socprojects.html

[No longer taking applicants] Disable USB on lockscreen (mentor: TobiasMueller)

Modern devices expose a large attack surface via external interfaces such as USB. In fact, maliicious USB devices could be observed in the wild. This proposal is about disabling USB when the screen is locked, i.e. when the user is not present. While the idea sounds simple, there will be issues along the way, such as the problem of new HID devices being attached. This projects probably involves tinkering with Linux, udev, D-Bus, GNOME Shell, and whatever currently locks the screen.

Benefits: By increasing security against physical attacks with malicious USB devices, GNOME would extend its position as the thought leader in the security aware Free Desktop scene.
Requirements: Python important, D-Bus and Gtk+ useful, C nice to have
Note: This has been copied off from Foundation/PrivacyCampaign2013. If you are interested, make sure to make contact early as this might need coordination with a few people as I don't know the technical detail regarding the screen locking. You will need to research a few things on your own. I think the implementation itself is comparatively easy. The UI can be reduced to an absolute minimum, the best might even be to have no user visible parts.

[No longer taking applicants] Make GNOME Keysign GNOME-ready (mentor: TobiasMueller)

The GNOME Keysign tool is very new and the code is not yet ready for proposing for people to actually use it. This proposal is about working on remaining issues with GNOME Keysign such that it becomes user- and GNOME-ready. This involves moving off of weird dependencies, adding support for internationalization, and supporting a more secure file transfer. The list is not extensive but it shows that interns can get a grand tour within GNOME, touching many aspects of how software development within GNOME works.

Benefits: Having an easy-to-use keysigning tools which nicely integrates with the desktop, GNOME's profile is raised even among those security people who tend to be not fond of integrated desktops [citation needed]
Requirements: Python mandatory, Gtk+ important, Experience with GnuPG beneficial, D-Bus nice to have
Note: Don't let the list of requirements or the rather unstructured presentation of this proposal put you off! If you are interested in security and are able to conduct some research on your own, we can probably work something out. I would expect interested interns to make contact so that we can work simple tasks to create initial patches.

[No longer taking applicants] Using TrueCrypt encrypted devices (and EncFS as time permits) from the GNOME Desktop (mentor: VivienMalerba)
Benefits: allow seamless usage of TrueCrypt encrypted devices and others (or EncFS) like LUKS is at the moment. The integration will be done exclusively using the available features of cryptsetup, part of every Linux distribution (it's the program which handles the LUKS encrypted devices).
Requirements: knowledge of UDisks and Nautilus (plus some experience about GNOME technologies), no knowledge of crypto is required, though.
Note: The use cases to cover are the following ones:
1. the GNOME user inserts a TrueCrypt encrypted USB key (or HDD) and wants to mount it to access the contents, then from Nautilus she right click on the disk and select "Mount TrueCrypt encrypted drive". After the user gives the password or keyfile in the corresponding form, the contents appear as with LUKS. She can then unmount the volume when finished.
2. the GNOME user has a TrueCrypt container file, and wants to mount it to access the contents. Then from a right click on the file shown in Nautilus, she can select "Mount TrueCrypt container". After the password or keyfile is given, the contents appear as with LUKS. She can then unmount the volume when finished.
3. If time permits:
  1. from the Disks application, the user who wants to create a TrueCrypt container or encrypt a USB key or a partition using the TrueCrypt format could do it as is currently possible with the LUKS format. This feature would only be available if the tcplay program is available.
  2. same features for EncFS encrypted directories. This feature would be present only if the EncFS program is installed.

[No longer taking applicants] Multiplayer support for GNOME games (mentor: RobertRoth)

Telepathy tubes allow collaborative features to easily be added to any application. This project is to develop multiplayer support on top of telepathy for one or more of the GNOME games.

Benefits: allow playing games with your contacts instead of playing against the computer
Requirements: Vala mandatory, Gtk+ important, Experience with telepathy beneficial
Notes:
1. this covers adding multiplayer support to already existing GNOME game(s) (Iagno, Four-in-a-row, Chess), not new ones
2. at least one game must have multiplayer support implemented
3. if time permits
  1. the generic multiplayer support should be moved into libgames-support to share as much of the code as possible
  2. more games can be enhanced with multiplayer support

3. Untriaged Ideas

4. Ideas from previous years

CategoryGsoc