A place for a "Known Issues List" of the current stable release of Vivaldi
-
@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.
-