A place for a "Known Issues List" of the current stable release of Vivaldi
-
First of all, it's good to see the new forums being finally polished and sorted out (special thanks to @steinar, @gaelle and others working "behind the scene", for their hard work). But let's get to the point.
As the title says, I wish for an easy-to-find place, which would contain the list of all the bugs and issues that has been reported for the current stable release of Vivaldi.
*
WHY
The purpose of this would be to avoid wasting people's time on reporting (and on reading those reports by the Vivaldi team) bugs and issues that has already been reported or are known Vivaldi or Chromium**
bugs.HOW
It could be made in a form of a forum post. For example: one post for each stable release in a closed, pinned thread, edited only by admins. Or one thread for every stable release, but only the thread for the current release should be pinned on the forums (it could be either closed or opened for users posts). You could also create a dedicated page on Vivaldi.net for the Known Issues List. Or you could add this somewhere on your team blog. Or you could come up with a better idea for this.
The status of each issue (it's been fixed in one of the snapshots / it's currently being worked on / it's gonna be fixed in the future / it's a Chromium bug etc.) would be a very useful information on such list.REQUIREMENTS
- It has to be easy to find. It has to be linked in at least three places:
a. The Bug Report page,
b. The blog entry about the corresponding Vivaldi release,
c. The forums (in the main Vivaldi Browser category or another applicable place). - It has to be frequently updated.
- Each entry on the list should have its status (fixed, not fixed, etc.).
OTHER REASONS
Right now if you want to find out whether a certain bug has already been fixed, you have to install the latest snapshot. That could be inconvenient - you can mess up your profile and not everyone is happy about installing another instance of the same software on their computer. Also, due to many regressions happening along the way, that method might be unreliable.
You can search through the team blog, but since there is no built-in search functionality and navigating through that blog is quite harsh, that option is also unacceptable. It doesn't meet the 1st requirement.
You can search through the forums, but often there is no information on whether a certain bug has been properly reported and whether someone is already working on it or not. It doesn't meet the 1st requirement anyway. Moreover, some issues are never reported on the forums...Forgive me for making such a long post, I just wanted to give a detailed information about this idea. I wonder what everyone else is thinking?
*
I think that making such list for every snapshot could be too time-consuming.
**
Only the most common ones, as adding the whole list of Chromium bugs could be another waste of time (and space). - It has to be easy to find. It has to be linked in at least three places:
-
What you want it's called a bug report tracker and it's not public
It's their decision to be "spammed" with duplicates... and I'm going to keep sending new bug reports if a bug isn't fixed every few months basically because I forgot I already had send it.
-
Well, I understand that they might not want their entire bug reports database to be available to the public for various reasons. What I'd like to see is a list of the most common ones. I'd really appreciate any kind of information on whether the bug that drives me insane (hypothetically) is gonna be fixed in the next release or whether I'm gonna go mad before they'll even notice it...
-
@pafflick said in A place for a "Known Issues List" of the current stable release of Vivaldi:
Well, I understand that they might not want their entire bug reports database to be available to the public for various reasons. What I'd like to see is a list of the most common ones. I'd really appreciate any kind of information on whether the bug that drives me insane (hypothetically) is gonna be fixed in the next release or whether I'm gonna go mad before they'll even notice it...
A list of reported bugs may be helpful to reduce duplication, but when you then ask for a list of bugs with "expected fix" indications, that is a different "can of worms".
Realistically, these would be two separate lists- All reported bugs after a stable release.
- A list of bugs which will be fixed in next stable release.
Not all of list 1) would be in list 2)
-
@TbGbe No need to create separate lists, it could be done just the way I described it in the first post. The only thing to polish here is to decide which bugs should be added to the list. I'd go for the most common ones, as adding the whole library of reported bugs and keeping them up to date would probably require hiring another team of workers.
It should be easy to organize and easy to read, so only a brief status for each bug and only the most common ones should make it to the list. It's doable! -
@pafflick - The developers and moderators have a LOT to do without curating and maintaining a public known bug list. Any user or group of users who wishes to do so, however, is welcome. There is nothing to stop you.
-
@Ayespy said in A place for a "Known Issues List" of the current stable release of Vivaldi:
There is nothing to stop you.
Except for the lack of any information about the reported bugs.
-
@pafflick said in A place for a "Known Issues List" of the current stable release of Vivaldi:
@Ayespy said in A place for a "Known Issues List" of the current stable release of Vivaldi:
There is nothing to stop you.
Except for the lack of any information about the reported bugs.
Every bug that is in the bug tracker has also been mentioned in the forums. If you open a topic "known bugs in 1.5," then anyone may post a bug they know of in 1.5. Once 1.6 is released, the 1.5 topic can be closed and a 1.6 topic can be opened. This is done for feature requests. It prevents a topic thousands of posts long which no one can read, and retires mentions of bugs/feature requests which are no longer relevant.
For instance, "drag tab to new window" would no longer be a feature request for 1.5.
There used to be a browser bug thread. It became too long to read. If there were a per-release browser bug thread, it could be kept manageable.
But no one will make you do it.
-
@Ayespy you just basically repeated my words:
@pafflick said in A place for a "Known Issues List" of the current stable release of Vivaldi:
(...) one post for each stable release in a closed, pinned thread, edited only by admins. Or one thread for every stable release (...)
However, I'm not asking HOW it should be done, I'm pointing out the fact that there is no official source of information about the bugs (available to the public) and - especially - whether they're being worked on or whether they've been put aside for another generation of Vivaldi developers to come...
-
@pafflick No, you're right. That is not public, nor will it be.
-
-
@pafflick - Don't hold your breath. The founder of this company has not had an open bug tracker in 22 years of running tech companies. At the same time, he has run some of the most publicly-engaged companies ever.
I won't debate whether open or closed is best. I will only point out if anyone likes what he and his teams have done, they have always done it by inviting feedback as to what the public wants, but never allowing anyone to pressure them as to how, where, or in what order to do it. Jon's companies have always produced a product that reflected the desires of his target public. They have always produced them in a WAY that reflects the personalities and unique talents of his team. And part of his philosophy is to work his team on a loose rein.
No one (but Jon) has ever pressured the team as to what they should be doing instead of what they are doing, because no one else knows what they are doing. No one knows what challenges they are facing, but them. They are largely allowed to choose which challenges to face, in what order, and how to face them, so long as the overall goal remains in view. That's how it has been and how it is likely to remain.
-
@Ayespy I think you somehow managed to miss that part:
@pafflick said in A place for a "Known Issues List" of the current stable release of Vivaldi:
What I'd like to see is a list of the most common ones.
In my opinion they should either make such brief list of the known issues (and keep us up to date, which ones are being fixed now), or stop asking the users to check the teamblog or forums to see if the issue that they're dealing with has been reported already. Why would anyone want to waste their time to do so, if the devs didn't make any effort to provide an easy to find place with a list of issues that thy're currently working on?
And how is providing such a list going to make people pressure them to fix this or that? Isn't it the other way around? I'd say that people will pressure them more, when they have no idea whether the dev team know about the bug, care about it or is working on a fix. If they know that the issue is reported and the dev team is working on a fix, they'll more likely give up on making a bug report, which could only save their and the dev team's time. And if someone is impatient, they'll make pressure anyway. That's a poor excuse.
Besides, how does one make a pressure on a company? Did somebody called the devs on their private phone numbers in the middle of the night or did somebody sent them threat messages?
-
@pafflick - as I said, I will not argue this. The answer to the majority of your questions is: "Have you seen the internet?"
-
I've seen the internet. Works for github projects as large as bootstrap (the most popular one) that have 100K+ of "stars/favourites", with 13K+ issues:
https://github.com/twbs/bootstrapBut I'll concede that github has a slightly higher barrier of entry. Maybe that's what an open bug tracker should do? More requisites for it?
-
@Ayespy Yes, and that's why I am questioning the most improbable scenarios, that seem to be taken straight out from the "fairy tale" category. Something like making pressure because of a public "known issues" list...
As if the "old" Opera community have ever forced Opera Software to recreate some of the unique Opera features (like the built-in e-mail client) in the new version of their browser, simply by pressuring them on the forums and social media...
BTW. Fun fact: if you google the phrase "known issues", you will get a pretty impressive list of companies (many of them exceeding Vivaldi Technologies in size, resources, popularity etc. - sometimes even multiple times) that apparently are unaware of the dangers of making a public "known issues" list. Those must be under a real pressure! They're like on the verge of closing any minute now...
Seriously though, what should be stopping any reputable company from creating something like this? It's an example of a nice, user-friendly "bug tracker mini", that surely isn't that much of a burden for its developers. A demand for such a feature shouldn't be surprising, since the software it concerns is being constantly released with multiple issues, bugs (more or less significant) and half-baked features, which - as much as expected in this early stage of development - are still very inconvenient.
The basic message here is: "help us help you". I don't think it's asking for too much... Do you? -
@pafflick said in A place for a "Known Issues List" of the current stable release of Vivaldi:
I don't think it's asking for too much... Do you?
I don't think anything about it one way for the other. This issue has been litigated for 20 years, by far better men (and women) than I, with no change in policy. I therefore consider it a pointless subject to flog.
-
@Ayespy said in A place for a "Known Issues List" of the current stable release of Vivaldi:
..., by far better men (and women) than I, ....
Teehee, yay!!
-
@Gwen-Dragon I'm thinking about some not-too-complicated process, like
// the bug needs to be properly indexed in the database first function CheckBugsDatabase("SomethingDoesn'tWork") { var TheBug = get BugReport("SomethingDoesn'tWork"); var duplicates = CheckForDuplicatedReports(TheBug); // checking if it was already reported if (duplicates>"x") { // if it was reported at least "x" times var bugData = getBugBasicData(TheBug); // get the basic info about the bug exportToTheList(bugData); // send it to the "known issues" list } else if (duplicates==0) { // if it wasn't already reported saveToBugReportsDatabase(TheBug); // just save it to the database } } // this is just a primitive example of how it could be done, it's not an actual code
This is pretty much how I imagine those companies doing their "known issues" lists. I mean, it's obviously doable. "Where there's a will, there's a way"...
@Gwen-Dragon said in A place for a "Known Issues List" of the current stable release of Vivaldi:
(...) It is not a easy-to-do-i-5-minutes job to filter information which should not go into public. (...)
I think that the "reported x times" condition is good enough for that matter. If an issue has been reported at least several times, there's a pretty good chance that it's already been made public somewhere on the forums or on the team blog.
But they can always decide not to publish a certain bug report - despite it's being reported frequently - for any reason. And they should obviously publish only the most important (from a user's perspective) information about the bug (like what it causes and whether it's fixed already or not just yet), not the whole report and technical data (especially if it's a security flaw or something like that).@Gwen-Dragon said in A place for a "Known Issues List" of the current stable release of Vivaldi:
(...) that all this public list would bind too much human power which would be better invested in more features and bug fixing.
... and managing duplicated bug reports.
PS. By talking about "thousands" of bugs, you look to me like an optimist.
-
-
Thanks for your request, but as this is an old request with few votes, it is going to be archived now.
-