So I have been thinking of looking for bad UX designs that exists on KDE plasma which may have been gone under the radar and could be improved and I think a fixed place where we can post and discuss these would be great. Yes I can post it on reddit, I can post it on the specific application code repository, yes I can also create a post here and many people are doing it and have already done but I think just having a separate category related to design related posts would be much more helpful to bring these to attention.
I think this site would be really good place for this. I am aware of the matrix group for design and hig but a more “informal” place which can be used easily not just developer but also user would be a good thing.
I have seen many similar posts where everyone says “yeah this needs to be fixed” but I simply forget about that post.
I guess that would also work but I think it can pollute this category. There are a lot of mismatch in UI I can find out in many apps if I just look in little hard. Most are not necessarily bad enough or big enough to create a new post under brainstorm.
Hi - for what it’s worth, if there’s a clear UX problem in a KDE application, that sounds like something worthy of a ticket in the KDE Bugtracking System: Get Involved/Issue Reporting - KDE Community Wiki
User reports submitted through that channel can be triaged for developer review and action. Posts on Discuss aren’t systematically reviewed or tracked by bug triagers or developers, so I’d just be concerned about folks channeling their energy toward a mechanism that may be less likely to result in tangible contributions.
If a specific situation isn’t clear, but there’s a need for discussion about how some KDE software should look and feel, that sounds like a topic for the Visual Design Group: Get Involved/design - KDE Community Wiki
If things like mismatches in UI is something that should be reported directly on the bugtracking system, the problem with adding the category as a subcategory of Brainstorm is solved. I also see the majority of these discussions about UI/UX in Brainstorm itself, because they actually are suggestions to brainstorm, therefore they are actually already polluting the category; creating a subcategory could be a great way to organize them without moving them in another logical space.
Yes. That is true but bug report are not user friendly. Also majority of people as in users are not going to file one or are going to look into it. I don’t think it would be ideal to assume that.
Having just a subcategory under brainstorm would already help creating a fixed place where these can be discussed about.
At the very least it would be a place where it can be categorised and stored where it can be found easily. It would reduce a barrier to reporting issue at the very least.
I totally agree that in cases like “this dialog’s layout doesn’t feel intuitive”, topics here on Discuss are well-suited for folks putting ideas out there, finding alternative approaches, and all of that in a low-friction environment.
At some point, though, those discussions have to produce something actionable for anything to ever be done about it. My main worry is that folks would pile into such topics expecting that “somebody” is monitoring the outcome and building something as a result - but that’s not (generally) the KDE development workflow, so folks may then become frustrated feeling as if their feedback isn’t being heard.
I think you hit the nail on the head here - you’re 100% correct to want to solve that. Message forum posts just don’t seem to make good task tracking mechanisms, though, so I would worry that a distinct category wouldn’t really solve the core issue.
Perhaps the challenge is, how do we make sure that good, constructive design discussions here result in at least one of:
A participant synthesizing the outcome into an actionable bug report
A clear issue being presented to the Visual Design Group for debate and alignment
I think you have said everything I wanted to say. My initial thought was just to have a place where user can also give some amount of input but what you said is very true if the discussion can’t actually lead to a proper action that is basically waste of time if everyone forgets about it.
I do have an idea about making an existing discussion into a bug report of a merge request: I don’t know much about this website but since there are plugins we can create a plugin which on this kind of topics highlight whether a bug report or a merge request is linked or not? I know there is phabricator with similar features but this doesn’t need to be that complicated. Just a button which links to bug report or merge request and maybe some extra info like whether it is being worked on or not.
Simply just a connection between two already existing infrastructure where one can easily go to without having to search for that bug whether it already exist or not. We can keep this infrastructure as higher level user facing discussion and as usual bugzilla or source repository for developer discussion.
Not a perfect solution but again it can lower the barrier for someone to actually initiate it. Starting and finishing the thing are the hardest part of any project I have worked on (by my very limited life experience )
Hmm, there is a little bit of assistance built-in to Discourse that could be used, perhaps? For example, if you paste a link to a specific ticket in the KDE Bugtracking System into your post, it gets formatted nicely with the Bugzilla ID and title: 502486 – Shortcut for Display Configuration does not work anymore
And, in the Help category, a post can be marked as a “Solution” - that links and embeds it at the top of that topic, and also marks the topic in the list with a checkmark to indicate that the creator’s issue has been addressed. Perhaps Brainstorm topics could have something similar, used when an idea has turned from discussion into an action? In that case, the “solution” post could be the one that contains a link to the resulting bug report, feature request, VDG GitLab issue, merge request, etc.?
this is what i was thinking, but the brainstorm area doesn’t get a “solution” button.
perhaps that could be added, but there might need to be some changes to who is allowed to hit the solution button… if it’s just the OP and they wander off after getting the ball rolling, then someone else needs to hit the button.
it probably should be whoever actually makes the bug report… some how they could be passed “OP” status so the button appears on their UI.
But on the other hand, the (volunteer) developers don’t always keep up with user forums, and might well never know about a post.
Yes, it is an unsolvable dilemma, there are no good bug reporting systems, at least none that I have ever come across, and developers seem to dislike user forums as much as users dislike bug trackers.
So, yes we may need a special section, or at least a good set of tags that devs and interested user cans use to help filter for this content., but we also need to be willing and able to file bug reports sometimes, like it or not.
My suggestion here would be to use gitlab issues in the vdg group. Discuss is good but discuss is not followed by a lot of people and doesn’t always reach the right developers to work on something.
I suppose asking developers to use the forum is a gate to disaster: bug trackers exists for a reason. But we could close the gap having people wander the forum answering discussions to explain how to make it actionable: explaining how to look for duplicates in the bug tracking system, showing how to create a ticket and posting the necessary links, or summarizing themselves long discussions into more manageable descriptions — more useful for a bug tracking system —, or even creating the bug reports themselves. At that point, it does not matter which bug tracking system is in use — it could well be Gitlab issues @Anditosan — because the important thing is having a centralized guide on how to report bugs for all components and people available to connect Discuss discussions to such knowledge base.
For what it’s worth - I think the Get Involved - KDE Community Wiki page is intended to be that launching point for folks looking to contribute something, whether that’s a bug report, a new idea, or helping support others in the community
I think this answers the problem about the connection between the forum and bug tracking systems, that is not using the forum like a bug tracking system but being able to make threads more actionable.
We could still decide if creating a new category (I say: subcategory) to make a bit of order in the Brainstorm category.
Here are some thoughts from someone who has never participated in FOSS projects before so I’m kind of an outsider.
I truly appreciate the effort of guiding everyone to the proper place but the guidelines feel like overcompartmentalization.
While compartmentalizing discussion in some way is often necessary in larger communities, overcompartmentalization can lead to analysis paralysis.
For example, if Matrix / IRC is for short, goal-driven discussions, how much do I need to plan beforehand in order to participate on a platform that’s meant for real-time chatrooms? IRC culture especially is known for sprawling discussions involving free association and stream of consciousness.
I quickly begin to doubt myself. Should I be using the email list instead since it mentions open-ended discussions?
This is somewhat similar to what I’ve witnessed on some Discord servers, where the admins have a need to keep things extremely compartmentalized. They might come up with intricate server structures including themed channels and channel groups, forums, and extensive guidelines or even rules on how to choose where to post.
And then people start backseat moderating each other, scolding each other for breaking the rules of compartmentalization, some of them unwritten. At this point, the admins often either double down on their demands and start banning instead of scolding, or realize their mistakes and form a more user-friendly model.
I know that KDE has been around for a long time. And I don’t pretend to know how the culture inside KDE is nor how it has changed throughout the years.
But simplifying the onboarding (if you can call it that) of new contributors as much as possible is crucial to lowering the barrier of entry.
I see the Matrix section you’re referring to - maybe that should have “…except for the New Contributors and Off-Topic rooms…” added to the sentence about expecting actionable tasks to come out of discussions?
Instead of convoluting the instructions even further, you could simply state that Matrix / IRC is a place to both hang out and have short, goal-driven discussions.
The rest can be sorted out with Matrix room layout and an onboarding process (eg. a welcome message or a welcome room).
Maybe this could lower the barrier of entry for those who prefer real-time discussion and want to get to know people but don’t have anything “goal-driven” in their mind at the moment?
I had several issues with blue-devil and pulse-audio utilities. My KDE bug reports were all closed as non-issues, despite my device’s sound not working. I didn’t have these issues in Linux-Lite running a lite desktop XFCE, but nothing worked on any Plasma desktop. I saw several other users complaining it didn’t work and several complaints about faulty firmware. When I tried to offer a hardware work around using a dongle I was accused of posting spam cos I bad mouthed KDE software. There should be another place to post an errand . Text books have methods for reporting errors so software should also beside a bug report that will get silenced because someone doesn’t agree with you.
Here are some best practices for reporting errors:
Describe the Issue. Clearly describe what the system is doing incorrectly. …
Expected Behavior. State what you expect the system to do. …
Steps to Reproduce. Provide the steps to reproduce the issue if applicable. …
Environment Details. …
Include Screenshots/Logs. etc
this works for textbooks and should work for code too. In addition any know work-around (fixes) should be allowed too. Many times I was unable to resolve a bug so I just deleted the application or used an alternative.
This is a bit of an aside to the topic of UX feedback, but just to note there - a full operating system has lots of layers of individual components, assembled together by distributions.
Without seeing the bug reports that you’re mentioning, I’d guess that while they were indeed about actual issues on your device, they might have root causes in software that’s not provided by KDE projects - in which case, issues would need reported to the developers of those relevant components.
)