4 ms·

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 th

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"??

md8z 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      > 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.
      - esarbe 5y ago
        > 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%5B%5D=4.+Newcomers https://gitlab.gnome.org/GNOME/evolution/-/issues?label_name...
esarbe 5y ago
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-changes-the-research/ https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...

md8z 5y ago

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 5y ago
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 5y ago
  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 5y ago
    > 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.
    - esarbe 5y ago
      > 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%5B%5D=4.+Newcomers https://gitlab.gnome.org/GNOME/evolution/-/issues?label_name...

esarbe 5y ago

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-changes-the-research/ https://blogs.gnome.org/shell-dev/2021/02/15/shell-ux-change...