[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...

[voakbasda]

This plan is laughable. The number of people that could actually do this is limited. It’s like saying that participating in government will help change it. No, participation leads to complicity. It won’t change anything.

[sph]

"Three easy steps". So, if I want to fix X or at least drive the discussion forward, I need to do menial jobs for 5 years, make a name for myself before I'm allowed to tackle X? How are we surprised nobody contributes to Linux desktop software?

> participate in the Matrix chat and get to know people

I'm a software engineer, your plan is teaching me how to get into politics. I understand that knowing people is important, but sounds to me that knowing people is the most important thing in the Linux desktop business. Not the type of environment I'd thrive on nor I'm interested in participating in. Sounds to me this version of "open-source collaboration" is just looking for politicians that put the effort to enter and fit into tight-knit, closed groups, not an open-air bazaar of people brainstorming and improving code.

[TingPing]

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