 Hello and welcome to yet another episode of Yes, I'm going to give some examples on why it might seems like GNOME is trying to ignore its users. And to be clear, to some extent, I do think that's true and healthy, actually, which is the whole point of the video. But let's get to the examples first. And then I'm going to talk about also what Kiri is doing instead, and some actual criticism towards GNOME. So lots of stuff. Let's start off from this discussion, which is the icon view sizes. So there has been a refactor on the grid view of Nautilus. And as part of this refactor, some view sizes of the icons were simply removed. And apparently there's one size that prompted a lot of discussion, which you can now see. And it has been a long lasting discussion that was eventually kind of integrated towards the next update of Nautilus, actually. Or there's also this discussion regarding mount points that goes on for quite a while with discussions on how to implement this with eventually a developer just saying, at the end, it comes to the fact on whether it's actually worth it or not implemented. And in my opinion, it isn't. Or take this one from one update to another. It was no longer possible to customize what the power button did, which sounds like an interesting change. And that, again, has sparked a lot of comments that go on and go on and go on with always this discussion on whether it's actually worth it to implement this or not with even a GNOME developer asking, what is the use cases for this, which is an interesting question. Or as a last one, there's this bug that has been in GNOME for ages, which is more of a feature request, actually, which is implementing previews on the file chooser, which has been now implemented and actually has this article goes through nicely. It talks about the fact that the missing piece to actually implement this arrived with a refactor of how the grid for the file chooser was implemented, and that maybe it could have been implemented before as well, but it would have been in a much more hacky way. But of course, there's even more examples that you could do as an example, icons on the desktop, these kind of things. It's all things were some features that previously existed were removed or some long standing feature requests were not implemented. So it is somewhat unsurprising that very often I see people complaining about GNOME, just ignoring users and saying stuff like, you know, my way or the highway. And you know what I'm going to do now? I'm going to present you some examples of KDE doing the same exact thing. The first one is the refactor of the QNFX that recently was done and that took off the desktop cube, which is no longer in KDE. And there has been a lot of requests to actually bring this feature back, which is understandable. And the developers are trying to say, you know, it's not something we're against. It's simply that it requires a fort and nobody has managed to put it in yet. However, it was a feature that was there before. And then one version later later, it wasn't anymore. Or what about myself? Actually, this is just me a couple of videos ago, explaining to you why no, I'm not going to implement a lot of features that were asked for floating panels, such as an option not to deflate the panel or an option to customize the margins around the floating panel, but also the level of transparency of the panel. I'm not going to implement that either through a slider. I mean, and there's even more examples that could be done. So what's up with that? Why are two important open source projects that follow the Linux philosophy, the free and open source philosophy, just ignoring feature quest or taking away existing features or not fixing very long standing bugs? Well, there is an interesting answer in this article, which is written by the Evel Skeleton, which is also a developer for battles and a member of the GNOME Foundation. And what this article explains behind the other things is that, you know, GNOME has a philosophy as a goal as a target and has an idea on how that should be implemented. And it's not just GNOME actually take Linux as an example. If I propose Linux to switch to a microkernel, they're not going to accept that. Linux has its own philosophy and Linux, Torvalds, is quite known for, you know, getting quite hangry when that philosophy is ignored. In the very next example, Kiri does the same thing. If I try to implement in Kiri something that goes against Kiri's philosophy, then that's not going to be implemented either. And this article really explains the fact that yes, project have philosophies and even Kiri is not like they can just accept any feature quest. And if they do see a feature that goes against their philosophy, even an existing one, then that feature is going to be taken off. But it's not that simple is it? Because there are a lot of other factors. This very article talks about why does this happen to GNOME so frequently? And dancers vary between, you know, GNOME is the most used desktop and stuff like that. Personally, I disagree. I think it's pretty obvious that when comparing GNOME to other desktop environments, GNOME is very opinionated, has a philosophy that is much more strict compared to other desktops. And to be clear, I'm a big fan, actually. I do think it's a great philosophy that works very well for, in my opinion, most people and even me, even though I personally prefer Kiri. But at the same time, yes, it's more opinionated. More people are going to complain about that compared to Kiri, even though, yes, you do also get that same things on Kiri as well. Part of what is particularly important in conveying the fact that you're trying to achieve a philosophy, even though users are sometimes asking something different is, you know, actually explaining that. Take this example, which I went through very quickly before, which is the icon sizes. So I presented it as, you know, lots of discussion and that was it. But that wasn't quite it actually. If you go through the comments, there's various posts by GNOME developers explaining the reasons. This is the first one, but there's even more that go more in depth. And they explain the reasons in a way that's pretty understandable. And they even link to parts of the human interface guidelines that GNOME has on how to deal with users. Even more interestingly, inside of this topic, there is a subtopic which had the goal to be more constructive asking for mockups and experiments on how to even better deal with this. And as I said, in the next version of Nautilus, if I understood this correctly, that size was either added back or that was being considered. So in this case, in this particular example, the reaction from GNOME has been pretty good, in my opinion, reading through the comments all that was written by a developer seemed very respectful and very constructive. So thumbs up because here is the most important take, I think. That's very often not easy because users, most users are kind and happy about the project, but there are always a few users who are super noisy and super entitled. Let me get to another article which is called toxicity in open source discussions, which goes through exactly that entitlement. And again, it's not to say that all users are like that, not at all, but if you just take the users that complain about some changes and that actively search for the bug reports to comment there, then there's a lot of these people. And even if you have like the best intentions, what is going to happen as soon as you meet a user that just insults you is that you're going to get angry, maybe insult back the user, maybe just burn out. Getting back to at this point my case study, the icon sizes of GNOME, there is one comment that is particularly interesting to see this, which is this one. It says, first of all, I apologize if any of my comments insulted you. By the way, this is a terrible way to apologize. You don't apologize like this. You never apologize. I apologize if something happened. You apologize that something happened, not here. But anyway, this is a beautiful sentence. No offense, but saying that you were considering to bring back blah blah blah, now you want because of users comments is a little childish. Anyway, good night. And then immediately in the next comment, also what you said about feeding the toxic mindset looks childish. But even if you take the very first comment, it's actually an intentional design change, Facebook. So if you approach developers who hear me out are devolving their free time into doing this kind of things and they do it because they have reasons and they put work and thought and you just make fun of them. Not only that's not going to get you anywhere, obviously, but it makes them even less likely to actually work on this kind of things. And there's a lot of discussions where you can see this kind of things happening. And then the developer just stopped responding. And this is, in my opinion, the exact example of when you should be ignoring users. You have to ignore users at a certain point if you want to preserve your mental health to some extent, because it is full. Seriously, it is incredibly full of users that are overrepresented in bug reports and merge requests that just are 100% convinced they are right, that their developer is stupid, and they just want the developer to do something for free whilst also calling them stupid. And you do have to ignore users like that. But even like it has happened to me many times, if you have a user that is very kind and kindly asks for a feature that is not for the philosophy of the project you're in, you also kind of have to ignore the user request, but not the user themselves and try your best to explain why what they're asking for is not feasible. This is how I try to approach things. And it's seriously hard. Another suggested reading is this one, what it feels like to be an open source maintainer. I'm not an open source maintainer. I don't maintain anything, maybe a bit of the panel, but I don't think I do enough to be a maintainer and it's just the case panel, not much. But I still can relate to some of the things he's saying. As an example, he talks about the fact that there is just so many requests to go through and you often don't have the actual time to go through all of them. It makes various examples of various kind of users that might leave some bug reports and many are in very good intention and will, but don't know how to use a bug report tracker or don't know how to embed the code on or don't know how to provide another stupid example, crash information, which is super important. And then there's all the people who are like intentionally insulting to the developer. And often it's not very easy to be able to walk through that and keep a smile on like seriously. So yes, the philosophy is kind of ignoring users, but also more of a ignoring users that are intentionally harmful and ignoring some user's request that don't go towards the project goal and try to explain them why they don't. That's the whole point. Not to say that I don't not to say that I fully agree with every single decision that GNOME has made. As an example, I would like if they were more open to collaboration within the Linux world, especially in terms of specifications, but also to make a very stupid example. As always, GNOME applications in KDE look very good because there's active effort on making GNOME applications look good and consistent on KDE Plasma. Whereas QT applications on GNOME don't or I don't know, the idea of just ditching the system tray that would require I think some curve in making sure that all of the specs that were previously in the system tray like are still respected because there's like free desktop. But I'm going out of the topic with this one. So this is just what I wanted to say. I know that most users are kind, but the annoying kind of user are overrepresented in the daily life of a developer. So if you ever see a developer who's like not replying in a bug report as kindly as they could have, keep that in mind as far as I know, they're trying their best.