This article has been posted on GNOME's Discourse. Please use this Discourse thread to discuss the subject.
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.
Triage
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, 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 lest 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 | ‼️ Needs Adoption ‼️ | |
| Appearance | ‼️ Needs Adoption ‼️ | |
| Applications | feaneron | |
| Bluetooth | hadess | |
| Camera | feborges | Will be merged with Privacy |
| Cellular | sadiq | Mockups available |
| Color | ‼️ Needs Adoption ‼️ | Panel will be moved out into an separate app |
| Date & Time | ‼️ Needs Adoption ‼️ | |
| Default Apps | ‼️ Needs Adoption ‼️ | Will be merged with Applications |
| Device Security | hughsie, doremihsuan | |
| Diagnostics | ‼️ Needs Adoption ‼️ | |
| Displays | ‼️ Needs Adoption ‼️ | Improved mockups available |
| File History & Trash | feborges | Mockups available; needs bugfixing |
| Keyboard | ‼️ Needs Adoption ‼️ | 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 | ‼️ Needs Adoption ‼️ | Mockups available; critically needs help |
| Notifications | ‼️ Needs Adoption ‼️ | |
| Online Accounts | ‼️ Needs Adoption ‼️ | 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 | ‼️ Needs Adoption ‼️ | To be merged with another panel (System?) |
| Search | feborges | |
| Sharing | ‼️ Needs Adoption ‼️ | Mockups available; needs help |
| Sound | ‼️ Needs Adoption ‼️ | Mockups available; needs bugfixing |
| Thunderbolt | feborges | Mockups available; needs help |
| User Accounts | feborges | Needs bugfixing |
| Wacom | garnacho | |
| Wi-Fi | ‼️ Needs Adoption ‼️ | 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 a 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.