Maintainership of GNOME Settings

Maintainership of GNOME Settings

GNOME Settings is one of the largest modules of the GNOME desktop. It sits comfortable as one of the bigger repositories out there. Not only that, but feature-wise, Settings is a pretty big hub of the desktop, connecting to GNOME Shell, Mutter, gnome-settings-daemon, the Bluetooth stack, NetworkManager, XDG portals, upower, CUPS, colord, online accounts, only to name a few.

Of course, such a big piece of software requires constant maintainership, issue triage, reviews, and design work. The project is virtually eternal, since it evolves with the platform, and there’s no effective point where we can call it done.

Sadly, the number of contributors and maintainers hasn’t been growing at a pace that matches the number of new features and new designs. That’s why we’re putting out a call for people to help out with this critical part of GNOME.

In the rest of this post, I’ll go through some of the current issues and how you can help.


Every big repository must keep track of issues. It is important to keep this issues database clean, actionable, and properly tagged. In the case of Settings, I have found 3 recurrent situations while keeping the issue tracker in a good state:

  • Confusion with the source of bugs: due to the very nature of GNOME Settings - a hub of many, many parts of the desktop - oftentimes people report bugs on our issue tracker that are not actually bugs in Settings’ codebase. Say, for the sake of argument, that Mutter has a certain bug applying the new position of a monitor; this will most likely be reported against Settings, because that’s the user facing part of monitor configuration. These issues need to be moved to the appropriate repository, so that the appropriate people can look at the appropriate part of the codebase.
  • Design changes: the design team recurrently revisits the designs of Settings, and when these redesigns are implemented, entire classes of issue reports might become obsolete. Figuring out which issues can be closed due to design changes is relatively easy!
  • Feature requests: feature requests are disallowed in Settings’ issue tracker, with the exception of issues from the design team. That’s because triaging and eventually rejecting these requests is disproportionately more time consuming than diagnosing bug reports. It is also not rare that people request features in Settings that are entirely out of scope of the application. For feature requests, I’ve been directing people to discuss them on GNOME Discourse (here!), which is more appropriate of a place to hold these discussions, as a user forum.

Doing good issue triage in our case requires diagnosing these bugs, finding out if they’re easily reproducible, requesting more information, and eventually reaching out to domain experts with enough information for them to be able to help.

Diagnosing, in particular, is extremely helpful. The mere act of checking if reproduction steps actually reproduce the reported issue - and, if not, tagging the issue approprately - is a simple and easy, yet of massive help.

We would certainly appreciate more help in triaging issues!

Domain Expertise

GNOME Settings currently has 30+ panels controlling a variety of aspects of the desktop. From power usage to hardware configuration to networking to application permissions, Settings covers a lot of ground.

That of course means we need domain experts to maintain specific panels and parts of the codebase. But these domain experts are not around!

Currently, the panels that are in desperate need of help are:

  • Networking: by far the most complicated part of Settings, it includes wired network, VPN, wi-fi, cellular, USB, and bluetooth connections; it also has rudimentary support for network configuration, security methods, metered data, and a few other settings that
    NetworkManager exposes. We really, really, really need more people maintaining these panels. Sadiq has been doing a stellar job maintaining the Cellular panel, and Ludovico’s recent cleanups are fantastic, but we certainly need more networking people involved.
  • Color: after years struggling with the Colors panel, I think there is enough consensus with the future of the panel: excise it into a separate tool. The Color panel is pretty solidly the least used and tested panel we have. Nobody is working on it. Nobody wants to work on it. Maintainers don’t have hardware to use it with. It took more than an year for people to find out that the panel was completely and utterly broken. We need someone to get this code, put it into a separate app, and keep this app in a good shape.
  • Keyboard: historically, although the Keyboard panel is not the most complicated panel around, it is the biggest source of bugs. We need bug fixers here.

The following panels, while not drowning in despair, could use some help:

  • Displays: basically a frontend to Mutter’s monitor configuration APIs, this panel sees eventual contributions, but it needs more care.
  • Region & Language: not much happens here, but there are cleanups and better designs available in the queue for years.
  • Online Accounts: the panel itself is relatively fine, but the online accounts stack is in need of updates.

Adopt a Panel

With the context above, I’m launching a new community-wide initiative: adopt a panel. Here’s the list of panels, and their current states:

Panel Owner Notes
About feborges
Accessibility :bangbang: Needs Adoption :bangbang:
Appearance :bangbang: Needs Adoption :bangbang:
Applications feaneron
Bluetooth hadess
Camera feborges Will be merged with Privacy
Cellular sadiq Mockups available
Color :bangbang: Needs Adoption :bangbang: Panel will be moved out into an separate app
Date & Time :bangbang: Needs Adoption :bangbang:
Default Apps :bangbang: Needs Adoption :bangbang: Will be merged with Applications
Device Security hughsie, doremihsuan
Diagnostics :bangbang: Needs Adoption :bangbang:
Displays :bangbang: Needs Adoption :bangbang: Improved mockups available
File History & Trash feborges Mockups available; needs bugfixing
Keyboard :bangbang: Needs Adoption :bangbang: Mockups available; needs bugfixing
Location feborges Will be merged with Privacy
Microphone feborges Will be merged with Privacy
Mouse & Touchpad feborges Mockups available
Multitasking feaneron
Network :bangbang: Needs Adoption :bangbang: Mockups available; critically needs help
Notifications :bangbang: Needs Adoption :bangbang:
Online Accounts :bangbang: Needs Adoption :bangbang: Mockups available; service needs help
Power hadess Mockups available
Printers feborges, mkasik Mockups available; needs active development
Privacy Screen 3v1n0
Region & Language robert.ancell Mockups available; needs help
Removable Media :bangbang: Needs Adoption :bangbang: To be merged with another panel (System?)
Search feborges
Sharing :bangbang: Needs Adoption :bangbang: Mockups available; needs help
Sound :bangbang: Needs Adoption :bangbang: Mockups available; needs bugfixing
Thunderbolt feborges Mockups available; critically needs help
User Accounts feborges Needs bugfixing
Wacom garnacho
Wi-Fi :bangbang: Needs Adoption :bangbang: Mockups available; critically needs help

Adopting a panel involves the following:

  • Clean up the codebase: port away from deprecated APIs, remove build
    time warnings, etc.
  • Implement new designs from the design team
  • Review incoming merge requests
  • Monitor and triage issues from that panel
  • Fix eventual bugs

There are no deadlines, deliverables, or requirements. For smaller panels, an hour or two every fortnight is more than enough. Bigger panels might be more involving given their complexities, but even there, adopters decide how much they can dedicate to it. We’re running a marathon, not a sprint; we’re working over the course of months and years, not hours, and adopters should be extra careful not to burn themselves in the process!

As usual, panel adopters who stick around and contribute for long enough eventually gain the trust of the community become maintainers, and may become members of the GNOME Foundation.

Settings is an critical part of GNOME, and a healthy settings app helps to drive improvements across the rest of the desktop. If you think you can help with a relatively small amount of ongoing maintenance work, this would be an amazing way to contribute to GNOME.


I wish you added the links to mockups.

1 Like

The keyboards panel is down my alley, I’ll have a look at the opened issues.


Mockups for Settings can generally be found in Teams / Design / settings-mockups · GitLab


Thanks, I will try to contribute something


Since I already have an open PR for a sound panel redesign, I’d like to fully adopt that panel. I also have a local branch for the redesign of the sound test dialog.


@melix99 oh yes, I forgot about this one. Allow me to suggest something: instead of doing the entire redesign in one go, can you split the redesign in smaller steps (e.g. increase the icon size; use hi-color app icons; rearrange some ui; etc) that we can land piece by piece?


Yeah, I’ve just thought the same thing. I will do that :slight_smile:


@Eimantas personally, I think the best way to learn something is by jumping head first into it. I’d suggest your first steps to be (1) successfully build GNOME Settings from the main branch; then (2) pick any one of the issues labeled with Newcomers, they’re super easy to fix and are great for starting.

This is probably going to take you a handful of days, or even a few weeks, to go through. That’s okay. There’s no rush. Take your time learning and asking around.

1 Like

I’ll help with triaging the backlog; go through the panels I can test and comment on issues that can be closed due to design changes (or fixes).

When I spot an issue that is a feature request how can I best indicate that?


For those looking to get started, I think the easiest way to build the latest version of Settings is via toolbox. If you create a new toolbox container with Fedora rawhide and use dnf builddep gnome-control-center, you will have all of the dependencies necessary to build and run Settings in the container.


@jakedane I see you’ve been doing some triage already - commenting on bugs that you think can be closed is working well for me, as I receive emails for these comments. Will go through them over the next week, closing.

As for spotting feature requests, I guess that’s still an open question. I’m not sure. I don’t think I can give you enough permissions to add the “Feature” label on GitLab, because permissions are often reset. Let’s coordinate each issue you find, individually, on the GNOME Settings Matrix room, and if a pattern emerges while dealing with them, we can stick to it.

1 Like

Okay, I will go on with triaging. I’ve not used Matrix yet but will see to get on there sometime next week.


I want to contribute. However, I am finding the first steps considerably hard. Right now I am trying my first build of the gnome settings project, but I don’t know where to find instructions to set up my environment, dependencies, how to build, etc (I don’t know even if they exist at all). I am making progress, but I am not sure I am going in the right direction.
Should I know this beforehand? I am new to the open source community (even though I’ve been developing for over a decade), but I don’t have much time in my day so it would be nice to deep into this world in a gentle manner.

1 Like

You can start from the Newcomers guide, but I have to warn you: starting from GNOME Settings as a first project is like jumping off of the deep end of the pool: Settings interfaces with lots of system services, and requires many dependencies that are considered to be on the bleeding edge. It not only requires a very up-to-date base OS—so using Debian stable or an Ubuntu LTS release is definitely not possible—but it also requires building multiple other projects.

If you’re just starting out, I’d recommend going over the issues to do triaging; or you could start from another project: every GNOME project could use more contributors.

1 Like

I understand. Thank you for clearing this up for me.
I will do as you suggested.


While this is true, I should emphasize that if you are motivated to start with Settings anyway and not so interested in other GNOME projects, we can still help you get started with Settings. It’s a more difficult project to get started with, but it’s still doable; once you have a little GNOME development experience, it’s not hard at all.

You’ll want to use either toolbx or jhbuild as your development environment. If you’re comfortable with one tool or the other, and know how to build missing dependencies when pkg-config complaints that something is missing, then you’ll be in a good position to get started with this or any other GNOME project.


Yep, I know neither C nor GTK, yet I do manage to make little code changes there, learning everything in the process. Absolutely doable, still hard though.

You can also build the Flatpak version of GNOME Settings with a single click in GNOME Builder. Although it wont work for every panel.


I suggest you start with triage - while you are learning. That way, you are familiar with settings through the issues. Triaging is one of those things that takes a lot of time from maintainers. You would be taking a huge burden off of them - just 10 minutes a day!

The others is that you can get a sense of what maintainers are looking for when it comes to supporting the codebase. It’s not just hacking, it’s also what is required for it to be maintainable.

1 Like

can anyone look into and can able to include this feature mock up available

1 Like