Contents
1. Students Information
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.
2. Mentors Information
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? * ''Mentorship'': what is your experience for mentoring this project and what communication channels and frequency will you use to communicate with the mentee? * ''Project team'': what is the project team like? * Note: one or multiple notes, links, whatever further information ----
3. Confirmed Ideas
Music: audio tag edition support (mentors: FelipeBorges, CarlosGarnacho)
Benefits: Making gnome-music more than a read-only view of your music collection.
Requirements: knowledge of Python, ideally together with the gtk+ library. Basic knowledge of Sparql (more especifically the UPDATE syntax) is a plus.
Note: tag writing is meant to be performed using Tracker's tracker-writeback daemon, the UI will be solely responsible of performing the Sparql updates modifying the data. See bug#706352
[No longer taking applicants] Music: ownCloud source support (mentor: FelipeBorges co-mentor: VictorToso)
Benefits: Making gnome-music able to play songs from ownCloud.
Requirements: knowledge of Python and C, ideally together with the gtk+ library.
Note: for more details about the feature, see previous discussions at bug#708937
[No longer taking applicants] Nautilus: Batch renaming (mentor: CarlosSoriano)
Benefits: We will provide the user a way to do a batch renaming inside nautilus with a nice UI.
Requirements: knowledge of C, ideally together with the gtk+ library.
Mentorship: I have been maintainer of Nautilus for 1 year and a half. I am usually on IRC during working hours in Central European Time. I might, on occasion, be there at other times too. I am happy to answer questions and review patches.
Project team: Other than me, there are approximately 2 regular contributors. You can find them in the IRC channel and they would be happy to help you out in my absence.
- Note: It will need discussion with the designers and we will discuss ideas about it.
[No longer taking applicants] Nautilus: Integrate file-roller and compressed file management (mentor: CarlosSoriano, CosimoCecchi)
Benefits: We will have file compression management as a first class citizen in Nautilus, will improve the code currently in file-roller.
Requirements: knowledge of C, ideally together with the gtk+ library.
Mentorship: I have been maintainer of Nautilus for 1 year and a half. I am usually on IRC during working hours in Central European Time. I might, on occasion, be there at other times too. I am happy to answer questions and review patches.
Project team: Other than me, there are approximately 2 regular contributors. You can find them in the IRC channel and they would be happy to help you out in my absence.
- Note: It will need discussion with the designers and we will discuss ideas about it.
[No longer taking applicants] Photos: Upload to Google Photos (mentor: DebarshiRay)
Benefits: Sharing is critical for Photos. The inablity to upload content is one of the bigger missing pieces, and this will be a big step forward in that direction.
Requirements: C, GData, GLib, GTK+
Mentorship: I have been maintainer of GNOME Photos since it was started in 2012. I am usually on IRC during working hours in Central European Time. I might, on occasion, be there at other times too. I am happy to answer questions and review your patches.
Project team: Other than me, there are approximately 3 regular contributors. You can find them in the IRC channel and they would be happy to help you out in my absence.
Note: You should get yourself a Google account. See bug #751181 for UX mockups.
LibRsvg: Add fuzz-testing framework (mentor: FedericoMenaQuintero)
Benefits: Librsvg takes SVG files and renders them into bitmaps. GNOME uses librsvg in various places, and external projects like Wikimedia use it to render their own SVGs, too. Fuzz testing has helped uncover important bugs in librsvg, but unfortunately fuzzing is not baked into librsvg's build environment. Having a way to run "make fuzz" or something like that would make it easier to find bugs.
Requirements: Basic knowledge of Automake. Knowledge in fuzz testing frameworks, especially afl-fuzz.
- Note: it is not necessary to use afl-fuzz, although the maintainer would like to see it used, as it is well-supported and has ongoing development.
Boxes: Import & export of VMs (mentors: ZeeshanAli)
Benefits: While Boxes allows for import of virtual machine disk images, it's not the best method to import a VM. We really need a proper method to export and import VMs and the industry standard seems to be OVF format. We've been meaning to implement that for many years now but just never got around to getting it done.
Requirements: Decent knowledge/experience of C. Vala and XML skills would be a definite plus.
Note: Most of the work is going to be implementation of a C library that transforms libvirt domains into OVA files and viceversa. Once this library works on a basic level, the next task would be to make it work in Boxes .
Boxes: More SPICE features (mentor: ZeeshanAli co-mentors: VictorToso, FabianoFidencio, PavelGrunt)
Benefits: The goal of this project would be to implement/fix a bunch of SPICE-based features/bugs to/in Boxes.
Requirements: Decent knowledge/experience of C. Familiarity with Vala and GLib/GNOME will be a big plus.
- Note: Some features (e.g Shared folders) will likely require working on libosinfo.
[No longer taking applicants] Games: Provide games more metadata (mentor: AdrienPlazas)
Benefits: Currently most games don't have a cover or an icon, we should provide one. Also, we will tag the games with enough metadata to make searching one smarter: the user could search for a game by its genre, its developer, the number of players allowed, etc.
Requirements: Knowledge of Vala, knowledge of Grilo would be probably help. This will probably imply scraping website.
GNOME Logs: search improvements (mentor: DavidKing)
Benefits: Logs currently has a somewhat rudimentary search, offering little in the way of ways to refine the results, and only searches the data in the current view. Improving the searching interface would make it easier to find the logs one wants, and make it possible to write a search provider
Requirements: proficiency in C essential, knowledge of systemd, GTK+ and GLib preferable
- Note: several related parts of the journal model inside Logs would need refactoring, and unit tests would be written to ensure no regressions
[No longer taking applicants] Polari: Implement search (mentor: FlorianMuellner, BastianIlsø, CarlosGarnacho)
Benefits: Finding a past conversation through search instead of scrolling up endlessly is an obvious improvement. Ideally the project will also involve exposing results to gnome-shell via a search provider
Requirements: JS, SparQL, GTK+
- Note: A tracker miner for chatlogs is currently in the works and should be operational at the time the project starts
[No longer taking applicants] Polari: Improve the user experience for new and existing users (mentor: FlorianMuellner, BastianIlsø)
Benefits: We could do a much better job at getting users started, both after running polari for the first time and when initially joining a new channel. And with logging moving to tracker, we can leverage the history to add some interface smarts in the background, like ordering the list of tab completions or whitelisting/filtering status messages.
Requirements: JS, SparQL, GTK+
- Note: A tracker miner for chatlogs is currently in the works and should be operational at the time the project starts
[No longer taking applications] Web: Bookmarks Subsystem Update (mentor: MichaelCatanzaro)
Benefits: Our bookmarks dialog is very broken. You will work on refactoring the bookmarks code, and implement the new bookmarks menu proposed by our designers.
Requirements: Significant experience with GObject programming and with GTK+. This is not a good project for newcomers.
- Note: Our bookmarks subsystem is very old and crufty. The code may make your eyes bleed. Accordingly, eye protection will be required.
[No longer taking applications] Web: Session Sync (mentor: MichaelCatanzaro)
Benefits: Users will be able to sync bookmarks, history, and saved passwords, which will be encrypted in the cloud, between computers
Requirements: Experience with programming against network APIs
Note: We'll want to sync as much as we can between Epiphany instances. We will want limited sync support for some mobile browser, as well. You will perform research to determine whether to use OwnCloud or Firefox Sync for this. You'll gain experience with GObject programming and with GTK+, as you will need to develop a user interface for the sync feature in Epiphany.
[No longer taking applications] PKCS#11 certificate chooser (mentor: DavidWoodhouse or maybe StefWalter or DanWilliams)
Benefits: allow simple choice of SSL certificates/keys for various GNOME tools.
Requirements: Basic knowledge of how to put together a GTK+ UI, ideally some familiarity with SSL certificates and PKCS#11.
Note: Various tools need a decent way to choose a certificate, showing the available PKCS#11 tokens (like seahorse does) and letting the user select a cert from them. The result should normally be a PKCS#11 URI which the application then uses as appropriate. See bug #679860 for the open GCR bug. The primary use case for this would be to implement the NetworkManager PKCS#11 Plan. See bug #719982 for discussion of NM 802.1x support. Other things like Evolution should also be using PKCS#11 URIs internally to specify certificates, and any GUI widgets should be designed with use cases other than NetworkManager in mind.
Synchronize GNOME Maps With Owncloud (mentor: Jan-Christoph Borchardt, co-mentor: JonasDanielsson
Benefits: Furthering the OwnCloud integration with GNOME. Having access to your favorite places and recent searches where ever you go.
Requirements: Basic knowledge of programming and the GNOME stack. An interest in synchronization.
Note: Some more information in bug #753406 the general idea is syncing recent searches and favourite places from Maps to OwnCloud. Some integration with GNOME Online Accounts will be needed as well. To enable the backend.
[No longer taking applicants] Add simple python plugin interface to Builder (mentors: LasseSchuirmann, ChristianHergert, co-mentor: AbdealiKothari)
Benefits: GNOME Builder has a decent plugin API that can be simplified using some decorators. This can reduce plugin development for Builder to just writing a single function.
Requirements: Basic knowledge of programming in python. Patches to both coala and Builder are needed for a successful application.
Mentorship: For the coala part, we are usually able to maintain a mean response time of less than an hour (also applies to code reviews) as we have a growing community over multiple timezones. Lasse is available on a daily basis in the gitter channel to help you succeeding in your projects.
Note: A coala plugin is to be written with the new API to validate its usefulness. coala already contains code that does similar simplification and may be used as an inspiration. More info at http://coala-analyzer.org/ and https://gitter.im/coala-analyzer/coala .
Pitivi: Color correction interface with color wheels (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Benefits: Pitivi has many effects with auto generated UI to control them which is not great for the end user experience, this tasks means adding a custom UI mechanism for effects and implementing a specific UI for color correction which is very important for a video editing application.
Requirements: knowledge of Python, ideally for graphical user interface canvases and multimedia-intensive applications. Previous knowledge of GLib and GStreamer are a plus.
Mentorship: Thibault likes designing and will make sure we all agree on a good future-proof technical solution. Alex likes reviewing code and will provide feedback to keep the code simple and easy to understand. The Pitivi community has many members who are knowledgeable about the project and you will always be able to talk with somebody to solve your issues, just join the #pitivi channel and ask your question!
Note: More information about GSoC ideas for Pitivi: http://wiki.pitivi.org/wiki/Google_Summer_of_Code
Pitivi: More/configurable keyboard shortcuts (mentors: Alexandru "aleb" Băluț, Thibault "thiblahute" Saunier)
Benefits: Keyboard shortcuts are really important for productivity, we need to make sure that Pitivi has all the needed keyboard shortcuts and allows you to be as effective as possible.
Requirements: knowledge of Python, ideally for graphical user interface canvases applications. Previous knowledge of Gtk is a plus.
Mentorship: Thibault likes designing and will make sure we all agree on a good future-proof technical solution. Alex likes reviewing code and will provide feedback to keep the code simple and easy to understand. The Pitivi community has many members who are knowledgeable about the project and you will always be able to talk with somebody to solve your issues, just join the #pitivi channel and ask your question!
Note: More information about GSoC ideas for Pitivi: http://wiki.pitivi.org/wiki/Google_Summer_of_Code
Maps: Support for vector map tiles in GNOME (mentor: JonasDanielsson, HashemNasarat)
Benefits: Having vector based map tiles instead of bitmap based ones will cut the size of the tiles significantly as well as allow us to style them ourself to a proper GNOME style. And maybe have a HighContrast theme of tiles.
Requirements: Some C/C++ background, some experience with the GNOME geo-eco-system.
Note: Investigation is big part of this. Can we (re-)use Mapbox-gl C++ code and make it fit into GNOME? Do we want to make vector-tile-glib better? Talk at GUADEC2015 on the subject here. More information on Maps wiki here
[No longer taking applications] Calendar: Day & Week Views (mentor: GeorgesNeto)
Benefits: GNOME Calendar misses day and week views, which are very important views for planning ahead and organizing one's schedule. The new views will make Calendar a great calendar manager option.
Mentorship: IRC and emails will be used for communication. We coordinate mainly through email and IRC, and try to document the relevant data using Google Drive.
Requirements: C/GObject knowledge, Evolution-Data-Server experience is a plus.
Project Team: There is 1 regular contributor (GeorgesNeto) and 2 eventual contributors working on Calendar.
Note: Mockups are available.
Modernising GNOME Keysign (mentor: TobiasMueller)
Benefits: GNOME is pushing the envelope when it comes to balancing security, functionality, and security. We have modern technologies like GTK Builder or xdg-app, but we're not making much use of it just yet. This project is about bringing a GTK Builder based UI to GNOME Keysign as well as investigating what's missing for it to become an xdg-app.
Requirements: You should know Python, Gtk, and Gtk Builder.
Mentorship: I expect to hear learn about the progress, road blocks, or non-developments once a week via a voice chat.
Note: Before applying, send me an email and nag me on IRC. I will task you with simple exercises to see how much developing Python or GTK pose a problem to you. Also note that we already have designs available which we will want to implement, so we should discuss whether we are on the same page regarding the expected user experience.
[No longer taking applications] Games: Add gamepad support (mentor: AdrienPlazas)
Benefits: A video game player with no gamepad support is ridiculous, we need to support them to make the games really playable.
Requirements: Knowledge of Vala and C.
Note: You should look at existing joystick and gamepad APIs (Linux and W3C).
Maps and libchamplain: Make the map wrap horizontally in the libchamplain map widget (mentors: JonasDanielsson and JiříTechet)
Benefits: Wrapping of the map is a pretty standard feature that we lack. The benefit would be a smoother map panning experience and not having the whole of Taveuni island (geo:-16.825323,-179.936756;crs=wgs84;u=0) rendered.
Requirements: Proficiency in C and an interest for geo stuff.
Mentorship: IRC will be used for communication. But day jobs and families makes asynch communication of importance. Bugzilla and mail convos will be had.
Project Team: We have an active helpful community in #gnome-maps!
- Note: There might be room and time to find other areas of improvement in the libchamplain Map widget.
Bug: here
Builder: only taking one student, idea can be picked amongst the following. (mentors: ChristianHergert)
Mentorship: IRC will be used for communication. Typically, Christian is available on a daily basis and responsive via IRC.
Project Team: There are about 5 regular code contributors to Builder and associated projects. We coordinate primarily via IRC and would expect new contributors to be available here.
Add history and scripting engine to command bar
Benefits: Builder has a vim-like command bar to execute tasks. We would like to see it extended to include visual history of commands that return results (such as hex(10) => "0xa"). This will use the internal language embedded in Builder which is implemented in C (and part of template-glib).
Requirements: Candidate should be proficient in C, and know or interested in learning GObject. Experience with GObject Introspection or language bindings is a plus.
- Note: An experienced student may opt to take this further and implement auto-completion for the embedded scripting language.
Implement spell check, search, and replace
Benefits: Currently builder lacks a simplified search and replace feature. Much of the design can be shared with Gedit. Additionally, since this has such overlap with spell-check, we would like the candidate to implement spell check as well. This too can large be inherited from Gedit.
Requirements: Proficiency in C and a desire to learn GObject and Gtk.
Note: Much of the search and replace algorithms have been implemented and are available as part of GtkSourceView. This project involves as much UX as it does C.
Implement worker-process recycling
Benefits: Browsers have shown the value of moving intensive work out of process. Builder does this too. However, Builder currently lacks the ability to restrict memory and cpu of those worker processes. The candidate will implement basic containment for Linux (using cgroups) and tweak libIDE to support restarting crashed or miss-behaving worker processes. To prove the implementation, the candidate will port the clang and vala plugins to run out of process.
Requirements: Proficiency in C. Willingness to study in detail the containment APIs available to us on Linux. Familiarity with D-Bus.
Implement code-snippet editor
Benefits: Builder has a robust snippet engine, but currently lacks the ability to edit those snippets from the code editor. The candidate will write a plugin for Builder that allows editing snippets and saving the modified snippets back to the users home directory.
Requirements: Experience with Gtk. Profficiency in either C, Vala, or Python.
- Note: Builder has support for writing snippet files back to disk. This is largely a process of plumbing various sub-systems together.
Integrate GNOME Terminal features into Builder
Benefits: Builder currently has a very simple terminal embedded. We would like more of GNOME terminals features integrated into Builder including 1) Search through command line output 2) Color palette selection 3) Use exiting profile from GNOME Terminal.
Requirements: Proficiency in C. Experience with Gtk and GSettings.
- Note: This will require reading a lot of code from GNOME Terminal.
Implement full-screen distraction-free mode
Benefits: Builder's earliest designs had the concept of a "distraction free" full-screen mode. This has already been implemented in Gedit, which can serve as inspiration on how to implement this feature. Ensuring that plugins can extend the full-screen mode will also be part of this project.
Requirements: Proficiency in C and experience with Gtk.
Implement custom project commands
Benefits: Many editors and IDEs support running custom commands for a project. This project will involve adding a "Custom Command" extension to the project configuration UI which stores them in the .buildconfig files. Additionally, the users should be able to execute these commands with either a keyboard shortcut, or from the command-bar. Output of the command should be displayed to the user in an "output panel".
Requirements: Proficiency in C. Some experience with Gtk will be useful.
- Note: You will be adding API to libIDE to support custom commands which will need to integrate with custom runtimes such as Jhbuild and Xdg-App.
Pintail: Documentation site generator (mentor: ShaunMcCance)
Mentorship: On IRC most of the time, in US Eastern time. Have mentored before. Pintail is on GitHub. I'm flexible with respect to pull requests vs branch reviews vs patch reviews.
Project team: Primarily Shaun, with feedback from entire docs team.
- Note: Two large features available. Will only take one student. A highly skilled student may be able to accomplish both, but pick one as a first priority.
Implement hosted search using e.g. Elasticsearch
Benefits: Easily find content within documents, or documents globally.
Requirements: Python, JavaScript, XML, Mallard for bonus points, XSLT for bonus points.
- Note: Search system should be pluggable. Primary implementation to use hosted service with client-side queries.
Implement translations
Benefits: Let people read docs in their own language.
Requirements: Python, XML, Mallard for bonus points, XSLT for bonus points, ITS for bonus points.
- Note: Not about translation workflow, but about outputting translated copy when localization is already done. Should be pluggable to support different workflows/tools, but itstool workflow as used by GNOME is priority.
4. Untriaged Ideas
[No longer taking applications] Proxy handling fixes (mentor: DavidWoodhouse)
Benefits: make proxies Just Work™.
Requirements: Networking knowledge, ideally some familiarity with NetworkManager.
Note: See plan at https://wiki.gnome.org/Projects/NetworkManager/Proxies — basically, make NetworkManager pick up proxy settings from the network (DHCP, WPAD, etc.), make it push them to PacRunner, then make everything ask PacRunner which proxy they should use for a given URL. Fix up the GNOME proxy configuration to defer properly to NetworkManager as a per-network configuration item.
[No longer taking applications] Games: Support more game formats (mentor: AdrienPlazas)
Benefits: Currently Games can handle only a small number of game formats, we want to support as much as possible. Good candidates are for example GOG and PlayStation games.
Requirements: Knowledge of Vala. This will probably imply working on retro-gobject, retro-gtk, retro-plugins, shared-mime-info and maybe on the emulators' code.
Note: See the issues list to get an idea of potential formats to support.
4.1. More Owncloud ideas
https://github.com/owncloud/core/wiki/Google-Summer-of-Code#2016-gnome--owncloud-current.