[md8z]

That is a misconception. The GNOME designers I have seen are not making decisions at random or removing things because they can, there actually is data and research to back up what they are doing. If you are a designer and are interested to know more then it would benefit to talk to them and ask them for their reasons, and then maybe you could contribute meaningfully from that angle. If there is something you think they missed, and you have the data to back it up (i.e. real usage data over long periods of time from large groups of users), then I think that would be helpful.

[alpanka]

How can you do UX design based on data, but without a proper feedback channel and at least some AB testing?

Most gnome users seem to use extensions that let them revert back to the old ways things were working. How about that as "real usage data"??

[esarbe]

Gnome does regular UX testing[0].

There's no 'feedback' channel (other than, you know, the regular feedback channels of matrix, gitlab. They exist.) because that tends to skew the data because of self-selection.

A/B testing is only possible when you can do randomized trials. I do think that randomly switching between competing implementations of a feature could be somewhat confusing for desktop users and create a big kerfuffle. It's easy with constantly-changing websites - people expect a website to change. On the desktop, change is seldomly appreciated.

[0] https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...

[md8z]

I don't think they have quite enough resources to do AB testing, it seems that needs a pretty big group of people doing it over a long period of time. AFAIK they are only able to do smaller targeted studies.

I'm not sure what you mean they don't have a proper feedback channel. They have all the same ones as most other open source projects: an issue tracker, a chat room, a forum, etc.

[sph]

Doing targeted studies among themselves is pretty much like developing in a ivory tower.

I've been following GNOME development for years, and recently getting interested in seeing how KDE handles things behind the scenes, and it's hard to miss the fact that the most prolific GNOME developers are the same 3 or 4 faces that have a really hard attitude against any type of discussion around their changes. I won't name names, but most issues on their Gitlab around any major change usually devolve into one of them saying "we're volunteers, send a merge request is you want it different". Ignoring the fact that most of their projects have opened and unanswered merge requests in the dozens. And hundreds of unanswered issues and even more on their old bugzilla.

The "volunteer" excuse is the most common passive aggressive response in the open source community, to hide behind when there's actually no real interest in entertaining different point of views or alternative suggestions.

So yeah, development is done in public, but they are set on their ways, dislike outside input and tend to get really rude and curt if you disagree with their idea. There are countless examples that pretty much anyone in the Linux community knows about.

I actually have no real qualms with the direction GNOME is going, but they are the reason I've never contributed to the project. They are a fickle and hard to please bunch, unless you're part of the internal clique.

[md8z]

I really don't agree with any of what you said. I have never been part of any internal clique and I've gotten patches in. The "examples" that I have seen posted around are bugs that get posted to hostile places like certain subreddits which then go and brigade the bug tracker which pisses everyone off. If you're having problems influencing people then you may have to get to know them first and learn what motivates them, it doesn't really make sense to skip this step and then sit on the sidelines complaining that nobody is listening to you or spending their time looking at your patch. If you cannot convincingly explain how your patch is going to help upstream then you have already failed, and that's the way it is with every open source project I've ever seen. It's a collaboration, it's not just dumping code over the wall.

I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help. I'm sure you can think of other ways to help out there if you're really motivated.

[sph]

> I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help.

So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them.

Pray tell me, how does one contribute to GNOME?

And I maintain that hiding behind "I'm just a volunteer, I don't have time for that shit" is an excuse, and a bad one. There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere.

[md8z]

"So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them."

Please avoid this hyperbole. If you actually look, there are plenty of examples of changes being accepted. But you have to play ball with them, like I said you can't just throw code over the wall and you can't just barge in and start trying to pick a fight with someone about the design.

"There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere."

If you have advice from those projects on how to improve process to make it easier to do it then please mention that. But otherwise I really don't know what you mean, I have had issues and merge requests ignored/declined in basically every open source project I've ever contributed to.

[esarbe]

> Pray tell me, how does one contribute to GNOME?

The same way you contribute to all other Free/Open Source project:

1) Make yourself useful and demonstrate that you are able. Start by fixing [Newcomers] bugs, participate in the Matrix chat and get to know people

2) Start influencing the direction of Gnome by participating in the design and contribute to larger, architectural issues

3) Get elected to the foundation leaderboard and become a decision maker

That's about it. Three easy steps. You can start here:

https://gitlab.gnome.org/GNOME/evolution/-/issues?label_name...

[TingPing]

The studies are obviously done with external groups like College students.

[ekianjo]

> there actually is data and research to back up what they are doing.

Oh really? There was data to back up that users wanted to start their desktop in Overview mode instead of the usual desktop? I'd be SUPER interested to see what kind of bullshit data was used, if this data ever exists. Right after this happened people created an extension to backtrack on this and this is one of the most popular extensions on GNOME extensions.

[aiilns]

From all the questionable design choices you argue about a good one. Starting in an empty space means you go to the overview to launch an app (unless you have hot-keys to launch apps which I think GNOME doesn't have configured by default).

So it both saves you a click/gesture and it allows for new users to understand what's going on.

[curt15]

My pet peeve is the recent move of the dash to the bottom of the screen, thus requiring users to first move their mouse all the way to the top left corner, then all the way to the bottom just to switch apps.

[esarbe]

I cope by not taking my hands off the keyboard and launching apps by hitting <Meta> followed by the application name. You can switch apps by <Alt>+<Tab> and <Alt><Shift>+<Tab>.

[md8z]

Yes, there was data to decide that, you should ask them nicely on the proper channel if you want more info. Please avoid dismissing things as "bullshit", that's rude and it doesn't help the discussion. If you have any additional data to the contrary, then now would be the time to present it. AFAIK extensions are considered as a data point but are not the only one, any time there is a design change there tends to be an extension that reverts it so it's not much of a reliable thing.

[webmaven]

> Yes, there was data to decide that, you should ask them nicely on the proper channel if you want more info.

I'm all for asking politely if you're going to ask at all, but... why should asking even be necessary? Why not just post the justifying data by default? That seems like less work than "data available upon request if you ask nicely."

[esarbe]

I guess the reason that they don't just post the justifying data is that ... they actually posted the justifying data[0].

google: gnome ux research

[0] https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...

[irishsultan]

That post very explicitly states that it does not in fact include the data for privacy reasons. Privacy seems like a good justification to not release the raw data, but claiming that data is available is wrong based on that post.

In particular I see nothing about starting in Overview mode (the original question about data was about that), although maybe I'm missing something not being familiar with recent Gnome releases.

[md8z]

Well there is no marketing department, so AFAIK the designers have to balance doing blogs and press releases with all their other work which is not easy to do. It is a non-zero amount of work to explain it. If you just want to have a quick conversation about it and are interested to get involved with design then I think it would be faster to do that than trying to get them to write an entire blog article or something.

[TingPing]

Yes there was lots of data in favor of that actually.