Ideas to improve bug investigations by the community?
-
I see lots of discussion threads ending in a bug number, rarely a soprano adds that they confirmed it internally. But normally (I guess) the reported bug is just added to the pile of unconfirmed bugs waiting for someone to find and try to reproduce it.
When I look at the "what's my bug status" thread and see how many bugs are "unconfirmed", I wonder if non-soprano community members like myself can work together more to support the investigation phase of a bug to get it confirmed and properly described.
Ideally Devs could then spend less time understanding and reproducing bugs and instead spend more time fixing them. Sopranos could spend more time testing fixes in internal builds instead of reproducing and confirming existing bugs in publicly released builds. (Please note that I don't want this thread to be about changing the overall system. It's about us community members collaborating better)
One thought I have is to ask each other to reproduce a bug with a given recipe, which may lead to better descriptions before the bug is filed. (Thread status "to reproduce"?). Another thought I have is that devs and sopranos could "outsource" investigating some interesting but elusive bugs to the community.
I think this community is doing great supporting users that have some issue with Vivaldi. What can we do to support the devs and sopranos more?
-
@wildente said in Ideas to improve bug investigations by the community?:
When I look at the "what's my bug status" thread and see how many bugs are "unconfirmed", I wonder if non-soprano community members like myself can work together more to support the investigation phase of a bug to get it confirmed and properly described.
I'm guessing that would be the "trigger", but users would need to be referred to the existing thread describing the problem (if there is one)!?
Of course, this assumes those willing to investigate somehow "missed" the thread discussion initially.Unfortunately, it seems that more and more bugs are reported without any thread discussion. With only a bug title to go off, in most cases, there is little we could do.
-
@wildente In my opinion no one should be able to report bugs directly. At what desktop bug number are we now, 80000? Anyway, it’s a ridiculous amount. The help sites even state that all problems/issues should be first posted on the forum, but no one really seems to do that. And if they do they don’t wait for someone to confirm it. So the workflow should look something like this:
- Post bug on the forum after checking for duplicates
- Users see it and try to confirm it
- One or more users manage to reproduce on clean profile
- Bug is reported to tracker
Far fewer bugs reach devs and these bugs have a better chance to get fixed and won’t disappear in an ocean of other issues.
-
@tbgbe said in Ideas to improve bug investigations by the community?:
Unfortunately, it seems that more and more bugs are reported without any thread discussion
Exactly right. And those that have a discussion ususally do not show the precise recipe to make it easy for others to reproduce the bug and chime in to say they can confirm it. Many threads are just a conversation that ends in an idea what the bug is about.
I will make the claim that the majority of bugs reported by people with out access to the bug tracker are the more active members of this community. I'm willing to invest a little more time making your and my bug reports easier to work with if it helps getting them fixed faster.
-
@luetage said in Ideas to improve bug investigations by the community?:
disappear in an ocean of other issues.
You mean a Tsunami(Z) of issues
They (developers) could start by making the issue tracker public. Read-only obviously. This has already been discussed to death before of course so I doubt anything will happen. But surely something can be done in Jira to make issue descriptions readable while still keeping any internal discussions private.
-
@luetage said in Ideas to improve bug investigations by the community?:
One or more users manage to reproduce on clean profile
absolutely right. if folks in the community fail to reproduce a bug, we can't expect the devs to be able to (I am probably a regular offender in this regard).
For Mail and calendar we need to find a solution though. I'm finding quite a lot of funky issues with my mail accounts that I can reproduce on several PCs and OSs, but without access to my mail servers, you won't be able to reproduce it. Not sure how this can be improved.
-
@pathduck If the issue tracker was closed to outside reporting, everyone would be forced to report to the forum. Therefore there would be no need for a public tracker, because the bugs getting reported by the community would be here for everyone to see. At the moment we have the worst of both solutions: Everyone can report but few can see. The opposite would make more sense.
-
@luetage True. But Jira (the tool they use) is a very powerful tool and again I'm sure something can be done there to allow it to become public.
I've worked with Jira and similar tools before. What could be done to avoid users having to see lengthy and very techy internal discussions is to create a duplicate issue on a separate "space" (can't remember the nomenclature), and then use that for discussion. When there was a solution the public issue would be updated with the necessary information, or just set as "Resolved".
A couple of extra steps for support but keeps internal and public information separate.
-
@pathduck said in Ideas to improve bug investigations by the community?:
to create a duplicate issue on a separate "space" (can't remember the nomenclature), and then use that for discussion
In JIRA it's "project", spaces are in Confluence
But if you create a copy discussion thread, what is the benefit of doing it in JIRA over having the same discussion here in the forum? Moving all bug discussion to JIRA would rather reduce the number of folks that contribute, and you end up with three discussions about the same issue: JIRA internal, JIRA open, and the forum will certainly stay.
@luetage I tend to your proposal of closing the bug tracker, but then how would I report sth that contains some personal information? I think the setuo of forum, open reporting, closed tracking is OK. We just need to act where we can as if we could only submit the bug when it is confirmed with a good recipe by the community.
To those with access, would that actually help much?
-
@wildente said in Ideas to improve bug investigations by the community?:
But if you create a copy discussion thread, what is the benefit of doing it in JIRA over having the same discussion here in the forum?
Because the Jira would be a searchable index of all reported bugs. While on the forum only the ones where the user has actually cared to post the VB is searchable.
Moving all bug discussion to JIRA would rather reduce the number of folks that contribute, and you end up with three discussions about the same issue
No - the public Jira would be read-only. No discussion, just for finding existing bugs, their status and most importantly - avoiding duplicate reports. Vivaldi team and internal testers/sopranos still discuss like before on the internal project issues.
-
There are some delays in getting bugs confirmed in the bug tracker that I don't understand - these are bugs that are super easy to confirm, but the issue isn't even that they're getting marked as "Cannot Reproduce" or "Invalid", it's that their status stays as "Unconfirmed" long after they have been reported in the forum multiple times. Here's an example:
(VB-80672) Under Menu Customization > Notes List, "Edit" does not appear in context menu despite being present in Settings
Steps to reproduce:
- In Settings, go to Menu Customization > Notes List and check that there is an entry "Edit" under Content there. (If one has previously removed it, add one back.)
- Open Notes panel and right click on a note in the list. Note that no "Edit" entry shows up (before v4.0 there used to be an entry saying "Edit in Notes Manager".)
I reported this on 13 June; it was also mentioned by two other users on the forum:
- https://forum.vivaldi.net/topic/62472/4-0-2312-25-opening-notes-manager (I confirmed the bug on the forum and reported it since the other user hadn't realised that it was a bug.)
- https://forum.vivaldi.net/topic/63291/open-notes-manager-from-note-panel-not
but as of last week when I enquired in the bug status thread its status was still Unconfirmed.
Here's another bug reported on 24 November last year whose status is still Unconfirmed and I can't figure out why for the life of me:
(VB-74561) Renaming menu items makes context command text no longer context dependent
Steps to reproduce:
- Pull an unrenamed "Bookmark tab" command into the Tab Context Menu.
- Select two tabs, right click on them and see that the unrenamed "Bookmark tab" command shows up as "Bookmark 2 Tabs"
- Rename the "Bookmark tab" command, e.g. by putting an emoji in front.
- Select two tabs again, right click on them and see that the renamed "Bookmark tab command" now shows up with the emoji in front and with text "Bookmark Tab".
Expected behaviour:
Expected that there be a way to preserve context-dependent context command text (e.g. number of tabs if multiple tabs are selected). The above is just an example; I suppose that there are other context commands with the same issue. On one hand, I understand why the text remains fixed after being renamed at present; on the other hand, there should be a way to rename the command while still preserving the context-dependent part.I would accept it if the devs decided to label this bug as Invalid, but there's no reason why it should still remain Unconfirmed after all this time...
-
@pathduck The user couldn’t post the VB, because they wouldn’t be able to report it. But the one reporting it could add the VB after reporting. Then it would be clear which bugs have been entered and which haven’t. And yeah, I kinda agree with you, there’s a reason Jira is in use, but let’s be honest, how many users would be able to navigate it? Nothing would change, people would still report unconfirmed and/or duplicate bug reports directly to the tracker.
@WildEnte Regarding personal info there should be special channels I reckon. And there still would have to be a way to report security issues separately, because these shouldn’t be posted publicly. But no, I don’t think the current system could ever improve. A handful of users deciding to better their ways won’t change anything. You gotta alter the rules of the game for the playstyle to change ^^
-
@luetage said in Ideas to improve bug investigations by the community?:
But the one reporting it could add the VB after reporting.
So you're suggesting that some forum regulars have access to the Jira, then try to gather all necessary information from often very uninformative users, and then do the task of actually making a bug report itself?
Hey, I like helping people to help themselves, but I'm not about to go around writing up detailed bug reports for issues I have no interest in following up anyway... sorry
-
@pathduck I never suggested that. Only devs and sopranos would be able to report. But only well written and confirmed bug reports from the forum would ever get tracked. If the reporter on forum did a bad job and no one shows interest, it will never be confirmed, just like it is now, with the difference it doesn’t end up in the tracker. The forum would act as the big filter and it would teach/force users to write proper reports, so other users can easily confirm it and as a result get their pet bugs into the tracker. Anyway, I can’t claim I know what’s best. I wonder whether this was under consideration at any point in time though.
-
@valiowk said in Ideas to improve bug investigations by the community?:
it should still remain Unconfirmed after all this time
Because we internal testers can not test all bugs we get reported. We get so many reports that some bugs slip thru.
Some reports are very good to test, some have no good description, lack of information and some reports are misused to get "personal" support.Bug hunting is hard work and with a small team not as easy as users might think.
-
@valiowk You got a confirmation that the issue could be reproduced.
-
@doctorg Yes, thank you. Would it help in future if we include a link to a forum thread by another user confirming that they encounter the same bug?
-
@valiowk said in Ideas to improve bug investigations by the community?:
Would it help in future if we include a link to a forum thread by another user confirming that they encounter the same bug?
That is always a good idea to add in a report.
The more information internal testers get, better bug hunt can be done. -
This is not enough to tell users how to write a report?:
-
As someone with 20 years testing experience (before joining old Opera I was a tester for Linux Mandrake) ... well, first it may take time for me to realize something is a bug and not just some network hiccup or other one-time event. It was 2 weeks later that I reported a bug causing a Spider app on my tablet to either lock-up or crash; by that time I'd already tried all their recommended fixes (clearing data, reinstalling, rebooting the tablet, etc.) before they even suggested them. I don't report bugs unless I'm sure there is nothing I can do to fix it.
In the case of something like Vivaldi, my next step is to ask someone to try to reproduce it. For bugs in internal builds I'll ask on the mailing list; for bugs in public builds I'll ask in the forums. Only after all that do I file a bug report, and I include a link to the thread (if applicable) so they can see it's been confirmed. Alternatively if I'm reporting a bug someone else posted in the forum I'll include the thread there so they can find the original report.
That still leaves the problem of duplicates - it is not unusual for me to check back on a bug I reported and see it marked as a duplicate where 10 other people reported it. Yikes!