Author: Allan

This post is a response to what Tobias posted yesterday on his blog. I would really prefer not be writing it. There are many other things that I would prefer to be doing, and I do not enjoy engaging in public disagreements. I honestly find all of this very stressful and unpleasant, but here we are.

For context, I joined the board in July last year, having previously been on the board from 2015 to 2021. This means that I wasn’t on the board during some of the events and decisions described in Tobias’s post. I am assuming that I am not one of the unnamed individuals he is calling on to resign, though I would be significantly impacted if that were to happen.

The post here is a personal view, based on my close involvement with the issues described in Tobias’s post. As such, it is not an official board position, and other directors may disagree with me on some points. It’s possible that the board may produce its own official statement in the future, but boards are inherently slow-moving beasts, and I wanted to get something posted sooner rather than later.

I want to start by saying that it is difficult to respond to Tobias’s post. The Foundation has a policy that we don’t comment on specific code of conduct cases, in order to protect the privacy of those involved. And, when you get down to it, this is mostly about the particulars of one specific case. Without being able to discuss those particulars, it is hard to say very much at all. That, in my opinion, is the elephant in the room.

The other reason that it is difficult to respond is there are just so many broad brush accusations in the blog post. It presents power conflicts and financial mismanagement and reckless behaviour and so on and so forth. It’s impossible to address every point. Instead, what I will do is provide a fairly high-level view of each of the two main themes in the post, while calling out what I consider to be the main inaccuracies. The first of those themes is the code of conduct decision, and the second relates to the performance of the Foundation.

The big elephant

In the blog post, Tobias throws around a lot of accusations and suggestions about the code of conduct decision to suspend Sonny Piers from the GNOME project. His description of the chain of events is both misleading and a misrepresentation of what happened. Then there’s an accusation of recklessness, as well as an accusation that the code of conduct decision was somehow politically motivated. All of this is clearly intended to question and undermine the code of conduct decision, and to present a picture of mismanagement at the foundation.

My view is that, despite the various twists and turns involved in the decision making process for this case, and all the questions and complexities involved, it basically boils down to one simple question: was the decision to suspend Sonny the correct one? My view, as someone who has spent a significant amount of time looking at the evidence, talking to the people involved, and considering it from different perspectives, is that it was. And this is not just my personal view. The board has looked at this issue over and over, and we have had other parties come in to look at it, and we have always come to the conclusion that some kind of suspension was appropriate. Our code of conduct committee came to this conclusion. Multiple boards came to this conclusion. At least one third party who looked at the case came to this conclusion.

I understand why people have concerns and questions about the decision. I’m sympathetic to the experiences of those individuals, and I understand why they have doubts. I understand that some of them have been badly affected. However, ultimately, the board needs to stand up for the code of conduct. The code of conduct is what provides safety for our community. We do not get to set it aside when it becomes inconvenient.

The argument that the code of conduct decision was somehow politically motivated is false. We even had an external reviewer come in and look at the case, who confirmed this. Their report was provided to Tobias already. He continues to make this accusation despite it standing in opposition to the information that we have provided him with.

Tobias seems to think that Sonny’s importance to the GNOME project should have been taken into account in our decision for the code of conduct case. To me, this would imply that project leaders would operate according to a different, less stringent, set of conduct rules from other contributors. I believe that this would be wrong. The code of conduct has to apply to everyone equally. We need to protect our community from leaders just as much as we need to protect them from anyone else.

No one is suggesting that the management of the code of conduct decision was good. Communication and management should have been better. Community members were significantly impacted. We have sincerely apologised to those involved, and are more than willing to admit our failings. We’ve also been working to ensure that these problems don’t happen again, and that’s something that I personally continue to spend time and energy on.

However, to understand those failings, you also have to look back at the situation we faced last year: we had just lost an ED, board members were burned out, and our processes were being tested in a way that they never had been before. We still had all the usual board and foundation work that needed taking care of. In the middle of it all, elections happened and the board membership changed. It was a complex, shifting, and demanding situation, which looks rather different in retrospect to how it was experienced at the time. We learned a lot of lessons, that’s for sure.

The other elephant

The other part of Tobias’s post addresses the performance of the Foundation.

He points out various problems and challenges, some of which are real. Unfortunately, while being convenient, the theory that all of these challenges are the result of the incompetence of a few individuals is, like most convenient answers, incorrect. The reality is more complex.

One of the major factors for the Foundation’s current situation is our recent history with Executive Directors. Neil left as ED in November 2022. It took us about a year to hire Holly, who was ED for seven months, during which time she had to take a non-trivial amount of time off [1]. And the Foundation is a small organisation – there aren’t lots of people around to pick up the slack when someone leaves. Given these circumstances, it’s unsurprising that the Foundation’s plans have changed, or that they didn’t happen in the way we’d hoped.

This is why the current board has been focusing on and expending considerable effort in recruiting a new executive director, who will be joining us very soon. Hurrah!

Tobias’s proposition that anyone who tries to change the Foundation gets burned out or banned is not true. I am living proof of this. I have changed the Foundation in the past, and continue to change it as part of my role as director. The Foundation today is radically different from the one I first joined in 2015, and continues to evolve and change. A lot of this is due to the interventions of previous and current directors over time.

Amid all this, it’s also important not to forget all the things that the Foundation has been successfully doing in recent years! I went into some of this in my recent blog post, which provides more details than I can here. It is worth stressing that the ongoing successes of the Foundation are mostly thanks to the dedication of its staff. We’ve run successful conferences. We’ve supported Flathub during which time it has experienced extraordinary growth. We’ve supported development programs. And the organisation has kept running, sailing through our taxes and registrations and all those other bureaucratic requirements.

On resignations

From the outside the GNOME Foundation can seem a little opaque. Part of the reason for that is that, as a board, we have to deal with sensitive and confidential matters, so much of the work we do happens behind closed doors. However, when you are on the board you quickly learn that it is really much like any other community-based open source team: there’s usually more work to do than we have capacity for, and the majority of the work gets done by a small minority of contributors.

Speaking as part of that minority, I don’t think that it would be beneficial for members of the board to resign. It would just mean fewer people being available to do the work, and we are already stretched for resources. I’m also of the view that no one should be asked to resign in response to upholding the code of conduct. Conduct work is difficult and important. It requires tough decisions. As a community we need to support the people doing it.

And if people think we should have different directors, well, that’s what the elections are for.

Closing

Readers might wonder why the Foundation has not spoken publicly about this topic (reminder: I’m not speaking on behalf of the Foundation here). The main reasons are confidentiality and legal concerns. We also tried very hard to respect the wishes of those who have been involved and affected. Now with Tobias’s post it is harder to avoid saying things in public. I’m personally skeptical of how useful this is: with opaque and complex issues like these, public discussions tend to generate more questions than they do answers. Contributor relationships are unfortunately likely going to get damaged. But again, here we are.

It should be said that while the foundation hasn’t spoken publicly about these issues, we have expended significant effort engaging with community members behind the scenes. We’ve had meetings where we’ve explained as much of what has happened as we can. We even went so far as to commission an external report which we made available to those individuals. We continue to work on improving our processes in response to the, ahem, feedback we’ve received. I personally remain committed to this. I know that progress in some areas has been slow, but the work continues and is meaningful.

Finally: I am sure that there are contributors who will disagree with what I’ve written here. If you are one of those people, I’m sorry that you feel that way. I still appreciate you, and I understand how difficult it is. It is difficult for all of us.

[1] Edit: we were extremely lucky to have Richard Littauer as interim ED for the second half of 2024, and he did a huge amount. However, Richard was only working for us part-time, so was unable to deliver on strategic initiatives.

I’m currently serving as a member of the GNOME Foundation Board of Directors, and am also a member of the Foundation’s Executive Committee. The last major GNOME Foundation update was back in October 2024, when we announced our budget for the current financial year, along with associated staffing changes. There have been some communications since then, particularly around events strategy and board membership changes, but it’s been a while since we provided a more complete general update.

This update is intended to fill that gap, with a summary of the GNOME Foundation’s activities over the past six months or so. You will hopefully see that, while the Foundation is currently operating under some challenging circumstances, we have been active in some significant areas, as well as keeping on top of essential tasks.

Board of Directors

The Board of Directors has been busy with its regular duties over the past six months. We continue to have regular monthly meetings, and have been dealing with high-level topics including ED hiring, finances, committee memberships, and more.

There have been a few membership changes on the board. We had an empty seat at the beginning of the board year, which we appointed Philip Chimento to fill. Philip is a previous board member with a lot of experience, and so was able to easily pick up the reins. We are very grateful to him for helping out.

In January, Michael Downey resigned from the board, and recently we filled his empty seat by appointing Cassidy Blaede. Members of the community will already be familiar with Cassidy’s contributions, and I think we can all agree that he will be a fantastic director.

Both of these seats are due for re-election in the summer, so the appointments are relatively short-term.

Michael was previously serving as treasurer, a position which we have been unable to fill from the existing pool of directors. We are currently in the process of speaking to a couple of candidates who have expressed an interest in taking on the position.

Executive Director Hiring

Most readers will know that we lost our previous Executive Director, Holly Million, back in July 2024. We were extremely fortunate to be able to appoint Richard Littauer as interim ED shortly afterwards, who has did an incredible amount for the Foundation on a part time basis last year. Richard continues to serve as our official ED and has been extremely generous in continuing to provide assistance on a voluntary basis. However, since his availability is limited, finding a new permanent ED has been a major focus for us since Holly’s resignation. We advertised for candidates back in September 2024, and since then the ED search committee has been busy reviewing and interviewing candidates. Thanks to this work, we hope to be able to announce a new Executive Director very shortly.

We are immensely grateful to the members of the ED search committee for their contributions: Deb Nicholson, Jonathan Blandford, Julian Sparber, Julian Hofer, Rob McQueen, and Rosanna Yuen. We also owe a huge debt of thanks to Richard.

Programs

“Programs” is the term that gets used for the impactful activities undertaking by non-profits (contrasted with activities like fundraising which are intended to support those programs). The GNOME Foundation has a number of these programs, some of which are established responsibilities, while others are fixed-term projects.

Sovereign Tech Fund

The Foundation has been hosting the ongoing Sovereign Tech Fund-ed development project which has been ongoing since 2023. The management of this work has been handled by the GNOME STF team, which has in recent times been managed by Tobias Bernard and Adrian Vovk. You can read their incredible report on this work, which was published only last week.

The Foundation’s role for this project is primarily as a fiscal host, which means that we are responsible for processing invoices and associated administration. Thibault Martin was working for us as a contractor to do much of this work. However, with STF ramping down, Thibault has passed his responsibilities on to other staff members. Many thanks for your efforts, Thibault!

While most of the STF funded work has now concluded, there is a small amount of remaining funding that is being used to keep one or two developers working.

Alongside the existing STF-funded program, we have also been working on a hosting agreement for a new STF proposal, which is being worked on by Adrian Vovk. This agreement is almost complete and we hope to be able to provide more details soon.

GIMP

The GNOME Foundation is the fiscal host for the GIMP project and this entails regular work for us, mostly around finances and payments. Recently we have been helping out with a grant program that the GIMP project has set up, allowing the GIMP project to make better use of the funds that the Foundation holds for them.

Digital Wellbeing

We are currently about three-quarters of the way through a two year development project focused on digital wellbeing and parental controls. This program has been funded by Endless and is being led by Philip Withnall. We have also been lucky to have assistance on the design side from Sam Hewitt. The new digital wellbeing features that arrived in GNOME 48 were a significant milestone for this project.

The Exec Committee has recently been doing some development planning with Philip for the final phase of this work, which we hope to include in GNOME 49.

Flathub

Flathub continues to be a significant area of interest for the GNOME Foundation. We are currently contracting Bart Piotrowski as the main Flathub sysadmin, thanks to ongoing generous support from Endless. Bart continues to enhance Flathub’s infrastructure as well as proving ongoing support for this hugely successful platform.

In December, we advertised for an additional short-term role to develop the Flathub organisation. Interviews for the role have been concluded and we have selected a candidate who will be starting work in the next few weeks, with the goal of getting the payments and fundraising systems online.

GNOME Project Support

General support for the GNOME project is a core part of the Foundation’s role, and is something which occupies a lot of the Foundation’s time. The activities in each of these areas deserve blog posts of their own, but here’s a quick summary:

• Infrastructure. We continue to support GNOME’s development infrastructure, primarily by paying for Bart’s work in this area. Plenty has been happening behind the scenes to keep our development systems working well. We are grateful for the past and ongoing support of Red Hat including Andrea Veri’s time and server hosting, as well as significant new support from AWS allowing us to move to a cloud-based infastructure.
• Travel. Unfortunately the budget for community travel has been limited this year due to the Foundation’s overall financial situation, but we continue to provide some funding, and GNOME Foundation staff have been working with the travel committee as we approach GUADEC.
• Events. Foundation staff continue to support our events. In December we had a successful GNOME.Asia in Bengaluru, India. Linux App Summit is happening next week in Tiriana, Albania, and preparations for GUADEC 2025 are ongoing. We additionally held a short community consultation around our events strategy back in October, and this is something that the board has had discussions about subsequently.
• Communications. Finally, despite reduced headcount, we continue to devote some staff time to operating GNOME’s social media accounts.

In addition to these ongoing areas of support, there have been additional one off support tasks which the Foundation has taken care of over the past six months. For example, we recently paid for the Google API keys used by Evolution Data Server to be certified.

Administration

Outside of programs, we have been busy with the usual background tasks that are necessary to keep the Foundation operating. That includes maintaining our books, filling in legal paperwork when it’s needed, keeping the board updated about the organisation’s finances, and talking to donors.

Conclusion

So much has been happening in the GNOME Foundation over the past six months, that it has been challenging to fit it all into a single post, and there are many items which I did not have the space to cover. Nevertheless, I hope that this summary provides a useful overview, and goes some way to showing how much has been going on behind the scenes. With no full-time ED and a reduced staff, it has been a challenging period for the Foundation. Nevertheless, I think we’ve managed to keep on top of our existing responsibilities and programs, and hopefully will have more capacity with the additional a new full-time Executive Director very soon.

It should be said that, since Richard reduced his hours at the end of 2024, much of the Foundation’s “executive” work above has fallen to a combination of existing staff and the Executive Committee. It is a large burden for a small team, and I think that it’s fair to say that the current setup is not easy to sustain, nor is it 100% reliable.

We are hopeful that appointing a new ED will help ease our resource pressures. However, we are also very interested in welcoming any additional volunteers who are willing to help. So, if participating in the kinds of activities that I’ve described appeals to you, please contact me. We can easily create new positions for those who think they might be able to have a role in the organisation, and would love to talk about what skills you might be able to bring.

One of the goals of the new GNOME project handbook is to provide effective guidelines for contributors. Most of the guidelines are based on recommendations that GNOME already had, which were then improved and updated. These improvements were based on input from others in the project, as well as by drawing on recommendations from elsewhere.

The best example of this effort was around issue management. Before the handbook, GNOME’s issue management guidelines were seriously out of date, and were incomplete in a number of areas. Now we have shiny new issue management guidelines which are full of good advice and wisdom!

The state of our issue trackers matters. An issue tracker with thousands of open issues is intimidating to a new contributor. Likewise, lots of issues without a clear status or resolution makes it difficult for potential contributors to know what to do. My hope is that, with effective issue management guidelines, GNOME can improve the overall state of its issue trackers.

So what magic sauce does the handbook recommend to turn an out of control and burdensome issue tracker into a source of calm and delight, I hear you ask? The formula is fairly simple:

• Review all incoming issues, and regularly conduct reviews of old issues, in order to weed out reports which are ambiguous, obsolete, duplicates, and so on
• Close issues which haven’t seen activity in over a year
• Apply the “needs design” and “needs info” labels as needed
• Close issues that have been labelled “need info” for 6 weeks
• Issues labelled “needs design” get closed after 1 year of inactivity, like any other
• Recruit contributors to help with issue management

To some readers this is probably controversial advice, and likely conflicts with their existing practice. However, there’s nothing new about these issue management procedures. The current incarnation has been in place since 2009, and some aspects of them are even older. Also, personally speaking, I’m of the view that effective issue management requires taking a strong line (being strong doesn’t mean being impolite, I should add – quite the opposite). From a project perspective, it is more important to keep the issue tracker focused than it is to maintain a database of every single tiny flaw in its software.

The guidelines definitely need some more work. There will undoubtedly be some cases where an issue needs to be kept open despite it being untouched for a year, for example, and we should figure out how to reflect that in the guidelines. I also feel that the existing guidelines could be simplified, to make them easier to read and consume.

I’d be really interested to hear what changes people think are necessary. It is important for the guidelines to be something that maintainers feel that they can realistically implement. The guidelines are not set in stone.

That said, it would also be awesome if more maintainers were to put the current issue management guidelines into practice in their modules. I do think that they represent a good way to get control of an issue tracker, and this could be a really powerful way for us to make GNOME more approachable to new contributors.

I’m a firm believer in the importance of documentation for open source projects, particularly when it comes to onboarding new contributors. To attract and retain contributors, you need good docs.

Those docs aren’t just important for practical information on how to contribute (though that is important). They’re also important when it comes to understanding the more general aspects of a project, like how decisions are made, who the stakeholders are, what the history is, and so on. For new contributors, understanding these aspects of a project is essential to being able to participate. (They are also the aspects of a project that established contributors often take for granted.)

Of course, ensuring that you always have up to date project documentation isn’t easy. This is particularly true for large, long-running projects, where the tendency is for large amounts of documentation to get written and then eventually left to rot. As redundant and inaccurate docs accumulate, they increasingly misdirect and impede contributors.

This characterization has unfortunately has been true for GNOME for some time. For many years, the main source of project documentation has been the wiki and, for a long time, the vast majority of that wiki content has been either inaccurate or redundant. We can only assume that, with so much out of date information floating around, countless hours of have been lost, with existing contributors struggling to find the information they need, and new potential contributors being put off before they have even gotten started.

Enough with the preamble

The poor state of GNOME’s documentation has been something that I’ve wanted to tackle for some time, so it’s with great excitement that I’m happy to announce a new, completely rewritten documentation resource for the project: the GNOME Project Handbook (otherwise known as handbook.gnome.org).

The handbook is a new website whose goal is to provide accessible, well-maintained documentation about how to get stuff done within GNOME. It has a specific scope: it does not provide technical documentation for those using GNOME technologies, nor does it contain user documentation, nor does it attempt to provide public-facing home pages for apps and libraries. What it does contain is the information required to operate as a GNOME contributor.

The fact that handbook.gnome.org is able to have this relatively tight focus is thanks to a collection of other GNOME sites, each of which replaces a role previously played by the wiki. This includes apps.gnome.org, developer.gnome.org, and welcome.gnome.org. Thank you to the creators of those resources!

The handbook site itself is managed like any other GNOME project. There’s a repository that generates the site, issues can be reported, and changes can be proposed through merge requests. The hope is that this will avoid many of the maintenance issues that we previously had with the wiki.

Notable content

The handbook is composed of pages from the wiki, which have largely been rewritten, plus a decent amount of original content. There are some sections which I’m particularly excited about, and want to highlight.

Issue tracker guidelines

GNOME has had issue reporting and triage guidelines for almost two decades. However, it has been many years since they were actively maintained, and they were never updated when GNOME migrated from Bugzilla to GitLab. I think that a lot of contributors have forgotten that they even exist.

The handbook includes a fresh set of issue tracking guidelines, which have been updated for the modern era. They’re based on the old ones from many years ago, but have been substantially revised and expanded. The new guidelines cover how to report an issue, how to review issues for quality and relevance, and policies and best practices for maintainers. One exciting new aspect is guidelines for those who want to get started with issue review as a new contributor.

I’m hopeful that having clear processes and guidelines around issue tracking will have an enabling effect for contributors and maintainers, so they can be more forthright when it comes to issue management, and in so doing get our issues trackers into a better state.

Governance

The handbook has a page on governance! It describes how decisions are made in GNOME, the various roles in the project, who has authority, and how the project works. Us old hands tend to assume this stuff, but for new contributors it’s essential information, and we never documented it before.

How to submit a code change

Amazingly — incredibly! — until this day, GNOME has not documented how to submit a code change to the project. We just left people to figure it out by themselves. This is something that the handbook covers. If you’ve ever wanted to submit a change to GNOME and haven’t known how, give it a read over.

Infrastructure

The infrastructure pages aren’t new, but they were previously causing some confusion and so have been substantially rewritten. The new pages aim to make it really clear which services are available, how developer permissions are managed, and how to get access when you need it.

What next?

It’s still early days for the handbook. Most of the core content is in, but there will be issues and missing pieces. If you spot any problems, there’s an issue tracker. You can also submit merge requests or make suggestions (the project README has more information on this).

The plan is to retire the wiki. An exact time line for this has yet to be set (there will be an announcement when that happens). However, it’s encouraged to consult the handbook rather than the wiki from this point forward and, if you’re continuing to use the wiki for anything, to move that content elsewhere. There’s a migration guide with details about how to do this.

Many thanks to those who have helped with this project, including but not limited to: Jakub Steiner, Andrea Veri, Emmanuele Bassi, Michael Catanzaro, Brage Fuglseth, Florian Muellner, Alexandre Franke, Sebastian Wick, and Kolja Lampe.

The GNOME 46 development cycle started around October last year, and it has been a busy one for my GNOME user experience design work (as they all are). I wanted to share some details of what I’ve been working on, both to provide some insight into what I get up to day to day, and because some of the design work might be interesting to the wider community. This is by no means everything that I’ve been involved with, but rather covers the bigger chunks of work that I’ve spent time on.

Videos

GNOME’s video player has yet to port to GTK 4, and it’s been a long time since it’s received major UX attention. This development cycle I worked on a set of designs for what a refreshed default GNOME video player might look like. These built on previous work from Tobias Bernard and myself.

The new Videos designs don’t have a particular development effort in mind, and are instead intended to provide inspiration and guidance for anyone who might want to work on modernising GNOME’s video playback experience.

The designs themselves aim to be clean and unobtrusive, while retaining the essential features you need from a video player. There’s a familial resemblance to GNOME’s new image viewer and camera apps, particularly with regards to the minimal window chrome.

One feature of the design that I’m particularly happy with is how it manages to scale to different form factors. On a large display the playback controls are constrained, which avoids long pointer travel on super wide displays. When the window size is reduced, the layout updates to optimize for the smaller space. That this is possible is of course thanks to the amazing break points work in libadwaita last cycle.

These designs aren’t 100% complete and we’d need to talk through some issues as part of the development process, but they provide enough guidance for development work to begin.

System Monitor

Another app modernisation effort that I’ve been working on this cycle is for GNOME’s System Monitor app. This was recently ported to GTK 4, which meant that it was a good time to think about where to take the user experience next.

It’s true that there are other resource monitoring apps out there, like Usage, Mission Center, or Resources. However, I thought that it was important for the existing core app to have input from the design team. I also thought that it was important to put time into considering what a modern GNOME resource monitor might look like from a design perspective.

While the designs were created in conversation with the system monitor developers (thank you Robert and Harry!) and I’d love to take them forward in that context, the ideas in the mockups are free for anyone to use and it would be great if any of the other available apps wanted to pick them up.

One of the tricky aspects of the system monitor design is how to accommodate different types of usage. Many users just need a simple way to track down and stop runaway apps and processes. At the same time, the system monitor can also be used by developers in very specific or nuanced ways, such as to look in close detail at a particular process, or to examine multithreading behaviour.

Rather than designing several different apps, the design attempts to reconcile these differing requirements by using disclosure. It starts of simply by default, with a series of small graphs give a high-level overview and allows quickly drilling down to a problem app. However, if you want more fine-grained information, it isn’t hard to get to. For example, to keep a close eye on a particular type of resource, you can expand its chart to get a big view with more detail, or to see how multi-threading is working in a particular process, you can switch to the process view.

Settings

If my work on Videos and System Monitor has largely been speculative, my time on Settings has been anything but. As Felipe recently reported, there has been a lot of great activity around Settings recently, and I’ve been kept busy supporting that work from the design side. A lot of that has involved reviewing merge requests and responding to design questions from developers. However, I’ve also been active in developing and updating various settings designs. This has included:

• Keyboard settings:
  • Updated the add input source design (#574)
  • Finished off the new custom shortcut designs for some (ongoing modernisation work)
  • Various polish fixes (like #2814)
• Region and language settings:
  • Updated the panel mockups
  • Modernised language dialog design (#202)
• Apps settings:
  • Designed banners for when an app isn’t sandboxed (done)
  • Reorganised some of the list rows (#2829)
  • Designs for how to handle the flatpak-spawn permission (!949)
• Mouse & touchpad settings:
  • New click areas setting (done)
  • Updated designs for the test area (almost done)
• Power
  • Updated the style of the charge history chart (#1419)
  • Reorganised the battery charge theshold setting (#2553)
  • Prettier battery level display (#2707)

Another settings area where I particularly concentrated this cycle was location services. This was prompted by a collection of issues that I discovered where people experience their location being determined incorrectly. I was also keen to ensure that location discovery is a good fit for devices that don’t have many ways to detect the location (say if it’s a desktop machine with no Wi-Fi).

This led to a round of design which proposed various things, such as adding a location preview to the panel (#2815) and portal dialog (#115), and some other polish fixes (#2816, #2817). As part of these changes, we’re also moving to rename “Location Services” to “Automatic Device Location”. I’d be interested to hear if anyone has any opinions on that, one way or another.

Conclusion

I hope this post has provided some insight into the kind of work that happens in GNOME design. It needs to be stressed that many of the designs that I’ve shared here are not being actively worked on, and may even never be implemented. That is part of what we do in GNOME design – we chart potential directions which the community may or may not decide to travel down. However, if you would like to help make any of these designs a reality, get in touch – I’d love to talk to you!