A lot of community members here, including myself, report a lot of bugs in Salfish for Jolla to consider and fix. Some bugs are really minor and could be safely left unfixed without affecting functionality too much. Others are complete whoppers which need to be fixed as soon as possible. I appreciate that, with limited resources, Jolla cannot fix all of them - either immediately or at all. However it would help the community to help Jolla if the bug reporting template had the ability to set a priority against each bug we report according to a category, for example: RED = major bug, serious security flaw, or problem stops app or function from working either substantially or at all, no workaround available; AMBER = major inconvenience, app or function still works but important app function or part does not work as intended, workaround available but inconvenient; GREEN = minor functionality issue, workaround available, can live with it in the short to medium term; BLUE = UI Design issue, no functionality impairment but inconsistency in design element or design results in inconvenient way of doing things.
No.
Itās just not good practice to let priorities be assigned by reporters.
Users will always consider their report to be most critical, while the real priority will depend on more factors than the assessment of the reporter.
Agreed, it will just create more problems and friction than it relieves.
What would be nice is if Jolla would add priorities, or even simply mark bugs as seen. Didnāt āTracked by Jollaā get carried over from TJC as a concept? Havenāt seen it in a while.
Another thing that could help if if there was somewhere to move non-bugs that turns out to be app-related, user inflicted etc, but warrants troubleshooting in the community. (As opposed to OS/core bugs which stay, and pure opinions which i guess can become feature requests or go to general)
Not if they have to assign a priority according to an objective set of critera, an example of which I suggested. Users do this all the time in industry, but of course it doesnāt stop Jolla from reviewing the user set priority and changing it if they see fit. I used to, amongst other things, run IT helpdesks for a living and this was common practice.
This would be very good. The community puts in a whole lot of (free) work in testing and reporting bugs but there is little or no feedback from Jolla as to (a) whether they consider the community reports as valid bugs, (b) what, if anything, they intend to do with them, or Ā© as you say, whether theyāve even seen the reports. At the moment community bug reports seem to disappear down a big black hole for months or, in some cases, years, without anything being heard until they pop up as being addressed (or not) in a new release notice. Community communication is everything if you want good community collaborationā¦
Misconception might be that this is a forum and not a bugtracker. Forums are mostly for all kinds of communication, including bugreports.
Since Jolla is short on staff, I can imagine keeping things as simple as possible might be good. So yes, āTracked by Jollaā might be a good thing and I donāt desire more. Well, I could 
but dreams are good to have.
On the even more constructive side of thingsā¦ it would be neat to know if there was anything people reporting bugs, and/or the rest of the community could do to make them easier to pick up.
I try to ask obvious questions when i see something that could do with some more info, but probably there are more things that could be done.
Educating people on what āregressionā means, seems to be one thing. I see many actual regressions saying ānoā, and often many non-regressions donāt seem to feel the extra burden of evidence from the fact that it never worked (could it be intentional/architectural, impossible, or a feature request in disguise).
It does. Consumer users will not know what this means in software development terms. But need to be careful. Iām also contributing to a thread where I have reported a bug concerning a failure in the browser to work properly with pop-up cookie dialog boxes. For the regression question in the bug report I said āYesā because, from my perspective, I had never experienced this issue on previous versions. But then later on in the thread another contributor said this was a long standing problem that had never been fixed - so I should have said āNoā to the questionā¦ I came to Sailfish on the SFOS 2 to 3 change, and I guess I just never used SFOS 3 on any website where this problem occurred. Perhaps you will argue that I should have searched the forums to find out if this problem had happened before - and maybe I should have ā¦ but I didnāt because (a) its not easy because people use different language to describe the same thing, and (b) I didnāt have the time. So, it is what it isā¦
Although in that particular case it doesnāt really matter, because it is an issue in either case. Consider the additional burden of evidence fulfilled.
And even if it had been a undisputable regression, itās not like the update of the browser engine will be reverted just to address that one websiteā¦ The benefits far outweigh the problems.
Slight OT: The problem here is that it is suuuper complicated to fix probably. I remember one such report where it works on Xperia 10 and not on XA2, simply due to the difference in screen size/shape.
As others said this isnāt realistic, Iād add outside custom development where the reporter is a designated representative of the sole customer (and even in those scenarios most if not all reports tend to get highest priority, severity, everything).
The best you can do in a 1:N distribution like with Sailfish is to let users vote on bugs and use that to inform your prioritization of work (note: does not mean fixes will be published in that order).