Just for your information https://bugs.kde.org/show_bug.cgi?id=75324, i.e KIO + fuse the missing feature is being worked on fortunately :
https://feverfew.home.blog/2019/06/11/kiofuse-32-bit-support/
Here we have a student devoting a whole project for this through the GSoc.

Yes, Meven, I know the news about the issue, cause I'm subscribed to that forum and reported several times the big problems related with this bug to work everyday with remote files (https://bugs.kde.org/show_bug.cgi?id=75324#c86). But I don't understand the neccesity to work on 32bit support when most of distros are dropping 32 bits versions ... how it will fix the problem? Is this the correct way? Maybe I'm lost, but I understand the priority is not 32bit compatibility, but solve the issue and then look for compatibility tasks.

But I can be wrong, of course

KDE support 32bits, so this was a point to care of for the KIOFuse project but it is not significant work anyway it seems.
Distros do what they want but since KDE is upstream, it is best not to force their hands and ultimately give users the choice.

https://feverfew.home.blog/2019/05/16/kiofuse-gsoc-2019/ gives you a better overview of the project goals.

Thank you for the link. That seems that it finally solve a really big problem for users like me, that bet for KDE in business environments. I'm looking forward for good news after summer!!

Best regards

This seems largely a duplicate of T11080: KDE for Big Enterprises since that also proposes making KDE software more business-ready and locally mounting Samba shares (etc).

Not exactly duplicate, but better expressed for sure. He talks about LDAP and password expiry support that I forgot to mention here, but it's another "should be resolved years ago" issue, cause it's another headache for corporation users. But he doesn't mention about recover the ability to place autohidden panel among two monitors functionality as it was working previously to Plasma, cause it's a productivity enhance for users working with multiple monitors. He doesn't mention Active Directory authentication neither.
I forgot to mention other business productivity KDE applications that are really underrated, as "Knotes", that is very useful in LAN environments and compatible with the outdated ATnotes (Windows). I suggested in kde forum some improvement for KNotes ... but no one says nothing at respect .... that's why lastly I'm pessimist about KDE. Sometimes I even don't have any response despite I take time to write about bugs or improvements, and begin to ask me if I should better give up and forgot headaches returning to other "popular" operating system

I changed the task description and put it less specific and more general. This is so it can address the underlying situations that possibly leaded to stagnating bugs/problems lingering for many years.

I hope it is better expressed.
Other examples could be added, but I think we must approach this in a more macro than micro point of focus.

One problem I see here is that "important long term problems" means something different to everyone who reads it. I think you need to be more specific or else this will become a "fix all the things" task that's impossible to achieve (if we had the resources to fix everything, we wouldn't need to set goals for prioritizing where to spend our limited resources).

I agree, the title needs to be reviewed.

Perhaps it's in the prioritizing/insufficient workforce/insufficient incentive that some "problems", "bugs" or "important missing feature" gets drop out. More like a restructuring of the process of bug/feature tracking/priorizing, that can be a sub task of T11051 ?

So you think we should prioritize better prioritization? :)

I'm still not really clear what this is all about. which issues do you feel got dropped on the floor? Two are listed in the Description section, one of which is actually in progress and a subtask of T11080, and the other is a fairly random-seeming bug.

In T11068#188890, @jrioux wrote:

I changed the task description and put it less specific and more general. This is so it can address the underlying situations that possibly leaded to stagnating bugs/problems lingering for many years.

I hope it is better expressed.
Other examples could be added, but I think we must approach this in a more macro than micro point of focus.

I would not be able to express it better, thank you

The problem is that the proposal doesn't tell us how we should prioritise differently. Because people have different experiences (broadly speaking) they will think different things should be prioritised so with setting the goals we are already trying to have a discussion on what we want to prioritise. So just saying "prioritise the things that are good" is too vague because good means different things to different people.

The way I wrote it, it's more about the relation between the user community and the developers than the prioritizing. It's not about how we should prioritize, but how to organize the information so the developers can have a global vision of what are the needs of the users as well as which bugs are affecting them and if possible in what proportion and gravity.

I just did a quick check for "yakuake" on bugs.kde.org. It's list 253 bugs. I don't see a way to keep track of those bugs, as some 2011 bugs are still opened and unanswered. Some are not really bugs, but no tags are being added to mark them as feature request.

So I'd recommend to focus on trying to answer the questions 1-13 and see where we could optimize the process of bug submitting, tracking (& summarizing), discussing and solving.

I think that is very valuable and i like your response, it's well articulated and I understand what the main focus is.

Do you think this can be merged with this proposal: T11051

In the two cases I related, it's easy to know what to prioritize. Any issue that make user to lost information, and what it's worst, without the user knowledge, is an high priority problem. Is the case of the bug 75324. User can compare two PHP files content with, for example, MELT. One file is on an FTP service and another one in a SMB folder. User can make changes on both and save them, thinking the changes are saved .... but his changes are lost, cause Plasma silently copied the remote files to "/tmp" folder and the changes are only stored there. Any time user is using non-KDE applications, is in risk of loosing data thinking that each time he saves files in remote folders (FTP, FISH, SMB ...) the things are going well, but not.

@lavender I do think this can be merged with T11051 or better be a subtask of it.

T11051 is quite ambitious and should be addressing this as well as many other things. I do believe that both of them are important for KDE's future.

"Focus on issues that cause user data loss" is a more actionable goal, but we actually don't have a lot of those, and they are already prioritized very highly. 75324 in fact in progress right now. If and when that issue gets done, what's left?

That subject is perfect for the KIO-fuse access to remote files, but for Plasma panels between monitor bug is just a "productivity" problem. Something that worked fine, were broken in Plasma.

I could suggest another issue, that really don't know if have been related in bugs, but as a professional user in a LAN where I access to remote folders, KDE (and now Plasma) is a headache when a remote folder is not accessible. For example, I have opened in Dolphin a remote folder (NFS or SMB shared, there is no difference) and then, the remote folder is not available (for maintenance, or the server or PC is down, etc). If I have the autohide option in my Plasma panel where the "Task manager" widget is placed and I access to Dolphin to try to access that folder, the panel remains unhidden and many times all desktop "Graphic elements" added freezed till 2 or 3 minutes passed. This is a behavior that come from KDE pre-Plasma and is a productivity issue. I consider Plasma should not have this kind of error in 2019 if KDE wants to be a serious desktop for business.

I could understand your point of view, maybe as developer. As an affected user by mentioned issues and considering one of them is causing lost of data, the relativity of his importance doesn't exist. Yes, I know someone is fixing the FUSE mounts problem, but I put it here as an example of a "long term" unresolved critical bug that is despairing me and others for years. I even tried to blame my distro and take the time to try with another distros using KDE or even Gnome, to finally discover that it's more a Gnome-KDE-FUSE inconpatibility. Many users lost their time in KDE bugs forum asking for a fix ... so I thought this place will be a good place to draw attention to these situations.

I bet there are more cases like that, that I don't know cause I'm affected or simply, I found out a workaround to live with the problem (like the case of non-discoverable samba shared resources) or the Baloo problem that I suffer some years before. But the worst it's to pray for a solution as an user and however feeling the response is not considered critical (as the FUSE mounts) or even some developer reply "That never worked that way" (as someone answered respect the multimonitor feature).

Anyway, thank you for you attention in this closed thread

Best regards

I understand your frustration. Again, the problem is that one person's "critical long term issue" is another person's "meh, doesn't affect me, I don't care". The point of the goal proposals is to determine which of these kinds of issues we should prioritize. :)