This page contains information specific to GNOME's participation in Outreachy internships from May 30 to August 30, 2017.
One person did an internship with GNOME during this round, and two more, who applied for both Outreachy and Google Summer of Code, worked with GNOME through Google Summer of Code. The Outreachy internship was generously sponsored by the GNOME Foundation.
Project Ideas
Applicants, GNOME's page for the program explains how you can choose a project. Please see the confirmed ideas below.
If you are a student interested in a coding project, you are likely also eligible for Google Summer of Code. GNOME participating in Google Summer of Code and has project ideas prepared for it as well. You are welcome to apply for Google Summer of Code with any coding idea listed below or ask a mentor for the idea listed for Google Summer of Code to add it below for consideration for Outreachy. If you apply for both programs, you will first be considered for Google Summer of Code, because GNOME typically has more spots in that program. However, please note, that the programs have different stipend amounts.
Mentors, first it's very important that your read GNOME's information for mentors and Outreachy's information for mentors. Both provide important information about expectations and best practices.
Add your project ideas and a link to your contact information here. Because we only usually have a few participants in Outreachy with GNOME, we are limiting the available projects to the ones that are most strategic for GNOME. These include, but are not limited to, projects in the area of privacy, developer experience, GTK+, core experience, core applications, and web infrastructure. We would also like people to think ahead of time how they will be able to provide excellent mentorship to the interns before, during, and after the internship, and whether there is a larger project team the intern will be able to receive support from.
The cross-team triage committee for proposed project ideas consists of Matthias Clasen, Allan Day, and Sriram Ramkrishna.
Please add your idea to the Unconfirmed Ideas section below using the following format:
. '''Idea title''' (mentor: MentorName linking to you wiki.gnome.org personal info page) * ''Benefits'': describe the benefits of your idea * ''Importance'': why is this idea strategic for GNOME? * ''Requirements'': what should the applicant 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 ----
As explained in the section on redirecting on the Outreachy information for mentors page, please feel free to add [No longer taking applicants] next to your project idea if you have as many applicants as you can work with during the application process or have a strong applicant you will likely want to accept.
Confirmed Ideas
Improve GTK+ with pre-compiled GtkBuilder XML files in resource data (mentor: AlexanderLarsson)
Benefits: GtkBuilder XML files are used (amongst other things) to instantiate template widgets. These currently parse the template XML each time a widget is instantiated, which can be slow. In particular, this makes it problematic to use template widgets in GtkListBox rows, or other widgets that get created a lot of times. Having a pre-compiled binary format would speed up GtkBuilder use in general, and make it possible to use templates for list box rows.
Importance: GtkListBox (and similar widgets like GtkFlowBox) are seeing an increased use in GNOME, and being able to efficiently use template widgets with them would be very useful. This also allows for future work on automatic population of template rows from a data model, which seems to be a very good match.
Requirements: Basic knowledge of C and GTK+ is necessary to work on the code, but a quick learner can pick most of it up quickly.
Mentorship: Long time GTK+ developer, but first time mentor. My preference for communication is over IRC, but email and video chat are also an option.
Project team: GTK+ has a few main developers, and a loose collection of developers that help out occasionally. We hang out in #gtk+ on irc. Matthias is also willing to help out with co-mentoring during vacation time.
Note: Here is the documentation for GtkBuilder, and here is a example template for a ListViewRow.
Note: Using a pre-existing binary format like GVariant makes the generation and parsing of the files easier.
Photos: Make it perfect — every detail matters (mentor: DebarshiRay)
Benefits: This project is about polishing various rough edges and filling in small gaps in functionality. Here is a list of candidates to pick from. There won't be time to cover all of them, but I expect to cover at least two — the choice is up to you.
- Exporting albums and multiple images at once.
- Sharing albums and multiple images at once.
- Revamped initial and empty screen.
- Thumbnail RAW files
Importance: Details matter. Small aspects of a user interface have a big impact on how easy and enjoyable it is to use. Photos is a core GNOME application that has been written from scratch for the GNOME 3 paradigm. It is at a point where it has all the big features necessary for everyday use, but there are a few rough edges and smaller shortcomings. Addressing those issues will be a big step towards wider adoption.
Requirements: Basic knowledge of C, GLib, and GTK+ is necessary to work on the code, but a quick learner can pick most of it up quickly.
Mentorship: I wrote Photos from scratch, based on designs from AllanDay, JakubSteiner and WilliamJonMcCann. The internals are loosely modelled on Documents. I can help with technical problems, but you are expected to do your homework and put in your fair share of effort. For the design of the user experience, you will have to work with the GNOME designers.
Project team: I am the primary developer. Former interns hang out in #photos on GIMPNet and might be able to help. The GNOME design team is available in #gnome-design. For general questions about the GNOME platform or build problems you can try #newcomers or #gnome-hackers. For more specific technologies like GEGL and Tracker there is #gegl and #tracker.
Note: Apps/Builder
Make mapbox-gl-native usable from GTK+ (mentor: JonasDanielsson)
Benefits: If we could use mapbox-gl-native to render and interact with maps we would gain support for vector-tile rendering and a bunch of quality map rendering tools. It will also allow us to move away from clutter-gtk that libchamplain (the current map render library) uses and make us more compatible with new GTK+ stacks.
Importance: This would allow us to make use of a state-of-the art map rendering library in Maps and other applications that want to show a map. The use of vector-tiles will save data and allow us to easy re-style maps without re-fetching bitmap tiles.
Requirements: Basic knowledge of C, GTK+ and GObject is necessary to work on the code. C++ knowledge is a plus, since that is what mapbox-gl-native is written in. An interest in maps and map technology will go along way as well.
Mentorship: I will be on parental leave when this round goes on, so I would prefer meetings once or twice a week at fixed times, as well as other asynchronized communication. But the Maps team will be around and available to help.
Project team: Since GNOME Maps is the application that has the most need of this, the project team is the GNOME Maps team, #gnome-maps on irc gimpnet.
- Note: The way I see it the easiest way would be to create a Mapbox widget that would be usable from Maps and other projects. This might be in the form of mapbox-gl-native SDK or a glue GObject based library.
Note: mapbox-gl-native is a library for embedding interactive, customizable vector maps into native applications on multiple platforms. It takes stylesheets that conform to the Mapbox Style Specification, applies them to vector tiles that conform to the Mapbox Vector Tile Specification, and renders them using OpenGL. It has been ported to QT already, as can be read more about in a blog post from Mapbox. There is also a blog post that lays out the requirements for porting the library.
- Note: We also use the BBox API from libchamplain to compute the bounding boxes for showing routes, so either keep using libchamplain (without using the GTK+ component) for that, or wire up a similar replacement in JS (for example).
Unit Testing Integration for GNOME Builder (mentor: ChristianHergert)
Benefits: We would like developers to be able to easily run unit tests for their project during development. To achieve this, we would like to teach GNOME Builder how to locate and run unit tests and provide feedback about whether or not the test succeeded.
Importance: This project helps GNOME developers catch bugs sooner, and encourages a strong practice of software testing. We believe with stronger testing, we can ship more reliable software.
Requirements: Experience with GTK and either C, Python, or Vala.
Mentorship: Primary author of GNOME Builder, so I can answer questions about how things are structured and how to best solve the problem. My preference is over IRC, but email and video chat are also an option.
Project team: Builder has one full time developer (ChristianHergert) and a part-time intern. We also have about 5 regular contributors who understand the code-base well and are active on IRC to help solve problems.
Documentation Cards for GNOME Builder (mentor: ChristianHergert)
Benefits: This project helps GNOME developers find documentation while they are writing code without having to switch to searching documentation on Google or Develop. Think of it as a "twitter card" or "facebook card" describing a user, but instead for code and APIs. By clicking on a piece of code, the developer can see the documentation, or possibly even commentary about that API.
Importance: Solving this task means that we can reduce frustration and friction to getting started with writing software for GNOME. By having quick access to documentation and the ability to explore existing code, we provide developers with a rich environment to self-learn.
Requirements: Experience with GTK and either C, Python, or Vala.
Mentorship: Primary author of GNOME Builder, so I can answer questions about how things are structured and how to best solve the problem. My preference is over IRC, but email and video chat are also an option.
Project team: Builder has one full time developer (ChristianHergert) and a part-time intern. We also have about 5 regular contributors who understand the code-base well and are active on IRC to help solve problems.
A proper unit system for GNOME Recipes (mentor: MatthiasClasen) [No longer taking applicants]
Benefits: Full support for units and unit conversion will make it much easier for people in different parts of the world to cook recipes with their common local measurements
Importance: GNOME Recipes is not a core application, but it has been developed as a birthday present for GNOME's 20th birthday, and we want it to be a useful, feature-ful and polished one. Having an intern would be helpful in reaching this goal in time. A second aspect is that GNOME recipes development has been used to test and push new technologies such as flatpak, portals, gnome-builder and modern GTK+ features. It has already proven to be a very useful vehicle for this, and having an intern could widen this to also provide insight into newcomer-friendliness of these technologies.
Requirements: Working on GNOME recipes will require some familiarity with building software on the commandline and the associated tools. Basic knowledge of C and GTK+ is necessary to work on the code, but a quick learner can pick most of it up quickly. Love for food and cooking will certainly make the project more enjoyable.
Mentorship: I have written GNOME Recipes from scratch over the last 4 months, and I know its code and its dependencies very well. I expect that we will communicate near-daily about on-going tasks and progress. If timezones allow it, using irc or telegram is fine, but communication via email or bugzilla works too.
Project team: The people working on the application are mainly me, Jakub Steiner and Emel Elvin Yildiz, with me doing most of the code, and Elvin and Jakub doing design and visuals.
Note: The Recipes website has a more information, including an intro to the code base and a more detailed description of this project
- Note: I will probably only be able to take on one of the two recipes ideas I have put here as a mentor. I put them both here to provide some choice
Currently, the application has a small bit of code that knows just enough to recognize certain strings (such as "kg", "lbs" or "min") as units. A proper unit system will handle:
- Conversion between different units for the same dimension (e.g. from grams to kilograms)
- Units for weight, volume, time, temperature
- Translation of unit names according to locale
- Heuristics for preferred units for display (e.g. "2.5 kg" is preferred over "2500000 milligram")
- Human-friendly display (e.g. "2 2/3 kg" instead of "2.66667 kg")
- Many cooking units that we currently ignore (such as various spoons)
- Simple preferences for preferred units (imperial vs. metric)
If time allows, we may also look at
- Conversion between volume and mass units (e.g. from liter to kilogram, using density information for ingredients)
- Typical units for ingredients (e.g. you measure flour in grams, not in liters)
Sharing of shopping lists and recipes in GNOME Recipes (mentor: MatthiasClasen) [No longer taking applicants]
Benefits: Sharing of content via various channels is expected functionality in applications nowadays. Good support for sharing of recipes and shopping lists will make GNOME recipes much more useful, and the sharing infrastructure will be reusable for other GNOME applications.
Importance: GNOME Recipes is not a core application, but it has been developed as a birthday present for GNOME's 20th birthday, and we want it to be a useful, feature-ful and polished one. Having an intern would be helpful in reaching this goal in time. A second aspect is that GNOME recipes development has been used to test and push new technologies such as flatpak, portals, gnome-builder and modern GTK+ features. It has already proven to be a very useful vehicle for this, and having an intern could widen this to also provide insight into newcomer-friendliness of these technologies.
Requirements: Working on GNOME recipes will require some familiarity with building software on the commandline and the associated tools. Basic knowledge of C and GTK+ is necessary to work on the code, but a quick learner can pick most of it up quickly. Love for food and cooking will certainly make the project more enjoyable. The sharing work will also involve some D-Bus protocol, and some work with mobile applications.
Mentorship: I have written GNOME Recipes from scratch over the last 4 months, and I know its code and its dependencies very well. I expect that we will communicate near-daily about on-going tasks and progress. If timezones allow it, using irc or telegram is fine, but communication via email or bugzilla works too.
Project team: The people working on the application are mainly me, Jakub Steiner and Emel Elvin Yildiz, with me doing most of the code, and Elvin and Jakub doing design and visuals.
Note: The Recipes website has a more information, including an intro to the code base
- Note: I will probably only be able to take on one of the two recipes ideas I have put here as a mentor. I put them both here to provide some choice
Recipes currently has minimal support for sharing recipes and shopping lists via email. As a first step in this project, we will add support for sending a shopping list to a mobile task-tracking app; Todoist is a good candidate. This will require some research into the APIs for such apps, followed by writing code to talk it. The code will eventually live in a portal service, and recipes will talk to it over D-Bus.
If time permits it, we will look at turning the portal service into a more generally useful sharing portal that can talk to multiple providers, and use it for sharing recipes as well.