Feedback on closing feature request
-
@Ayespy I don't care what are the limitations tbh, I don't even care that much about the time needed to fix it but marking requests as done means they are done, not half assed, honestly I think that cutting corners to deliver anything and then having to spend extra time fixing it is just a waste of resources, at least until all core functionality lands. Well I mean, people who daily use Chrome won't complain, but for ones coming from Opera and Firefox this is a dealbreaker.
@LonM said in Customisable Toolbars:
In my mind, this feature request wont be "complete" until every toolbar is a valid drop target and every button is draggable (a la classic opera). Heck, in classic opera, even non-buttons like the zoom control were draggable.
this is my main concern now, literally yesterday I checked how long it takes to implement configurable rockers and I believe its around 4.5 years since they appeared first time, if toolbars take the same amount of time because "it's done already, what's your problem?" V will never shine
Mod edit: topic forked from here
-
@zakius Yeah - my comment was unrelated to the marking and closing of the thread, which was done after my comment by someone other than myself.
-
@zakius said in Customisable Toolbars:
this is my main concern now, literally yesterday I checked how long it takes to implement configurable rockers and I believe its around 4.5 years since they appeared first time, if toolbars take the same amount of time because "it's done already, what's your problem?" V will never shine
I did a quick search and the request I found for configurable rockers only has 2 up votes. It is clearly not a feature most people find important, so it makes sense that the devs haven't spent time on it.
-
@Komposten Actually Customize Rocker Gestures has
1920 up-votes, but that is still not a lot compared to many other more popular requests. -
@Komposten it's part of mouse gestures so as long as it isn't done mouse gestures aren't done
and with all that framework they already have for gestures and rockers adding 2 more fields using only already existing blocks isn't rocket science and it would simply make more sense to just do everything at once than to hardcode these two and leave like that for years. And most of people probably don't know how convenient rockers can get, only people who spent some time to configure them in another browser know what they miss hence low trafficMy point stands: it's not finished until it is finished, no matter if we are talking toolbars, gestures or poor extensions inherited from Chromium, I am unhappy waiting but that's okay. But I am really annoyed when someone claims feature is implemented when it clearly isn't
-
@zakius As explained earlier, the previous topic was tagged as DONE because most of it was done.
Topics with multiple feature requests cause problems because no one knows which of several features have been upvoted.
Conflating rocker gestures with mouse gestures will cause similar issues. They are different things. Users can enable rocker gestures without enabling mouse gestures, or vice versa.
In Opera 12.18 they are both configured on the same dialogue, but that is not the case for Vivaldi. Currently there is no UI for configuring rocker gestures — it is all or none.
-
@Pesala toolbars are not configurable, only small parts of single toolbar are configurable within certain artificial constrains so it is clearly not done, rockers are part of mouse gestures as these are performed with mouse after all (unless you want to generalize further and put both hotkeys, chords, mouse gestures, rockers and any combination of these together, that would also make sense actually)
it's a matter of perspective and I hope you as a person can at least see my point even if Vivaldi as a whole project doesn't
-
@zakius said in Customisable Toolbars:
I hope you as a person can at least see my point even if Vivaldi as a whole project doesn't
All I see is someone who is miffed because his topic was closed. The reason was given, but you cannot accept it. The Vivaldi team know that there is still more to be done before the toolbars are as customisable as they are in Opera 12.18.
-
@Pesala there is no reason to mark it as done when it is not done, it really is that simple
and once again: it wasn't "multiple requests" but detailed request made this way specifically to avoid misunderstandings and incomplete implementations
-
I see you still refuse to admit being in the wrong @gaelle
-
@zakius it's not about being in the wrong, I'm going to copy here what I wrote you in our private chat:
We're still a small team with limited manpower to implement all incoming requests. So for big features as this one that requires a lot of work we can either implement it partially and release it or we can wait to have it fully knowing that it will need to be improved in any case as it's part of how IT development works. We prefer to release often features so that users like you can already get a feel for it and share some feedback to us and continue to improve it along the way.
As always we thank you for your understanding and wish you a Happy holiday season.
-
@zakius The portions of toolbar configurability which are still not present should be filed as a new feature request or requests. What's done is done. What's not done, that you are still waiting to see, should be filed for as a new request or requests. Do you want to drag buttons to panel? A request. Do you want to move toolbars to more locations (like above or below companion bars, or to the side for bookmarks bar, for instance)? A request. Do you want to place buttons between the addressfield and the searchfield? A request. Do you want to be able to place the settings gear on the address bar? A request. Etc. Break it up into functions that can be implemented one at a time, and then they can be checked off as they appear.
In the meantime, I find this kind of cool...
-
@gaelle it doesn't have anything to do with being a small team, it's about truth and honesty
if you need more time it's fine, take as much time as you have to to polish upcoming features, just be honest about it, it isn't implemented yet so don't mark it as done, as internal tracker is internal I have no idea if it's still in works or stuck in backlog with noone caring about it, but the actual state (in progress, planned for X.X, stalled until further notice) should be used, not "done"@Ayespy I don't need new requests, just reopening of one that already lists everything that is missing specifically to avoid misunderstandings
-
@zakius said in Feedback on closing feature request:
it's about truth and honesty
To be honest, you're being a pedant. The feature request was closed and a new one was opened. Vote for that, or add a comment, or start a new thread if it does not cover everything, e.g. moving toolbars to any side of the window.
-
@zakius "Lists everything" is a violation of the feature request category. One request per thread. Bundling fifty requirements under a single ask doe not make it a single feature. It's why the first request was closed and more will be opened. The first was too detailed and complex to be treated as a single request.
-
@Ayespy it was a single request: configurable toolbar
detailed to avoid confusion and issues like this one (claiming it is done despite not being done properly, but without it being detailed enough it could be just an oversight so I decided to list everything that is required to consider the feature implemented)surely it's a big task and it needs proper management, but that consists of subtasks assigned to different milestones, not marking main task as done as soon as you ship anything even remotely related to the main task
possibly tasks of this scale should even get own boards to allow proper discussion about details of their subtasks, how some rely on others etc.
overall there's way too little communication between general audience and dev team, we see frequent PR stunts, patch notes but have no idea what's going on at all, what are your plans, hopes and wishes
possibly you already noticed I am persistent when I care about somethig
I can take care of some issues myself, use some workarounds and don't pester people more than needed, I am grateful for great tools I use everyday and even willing to pay for them (I'd gladly pay subscription fee for a complete browser if that would guarantee me a peace of mind, you know, it's been over 6 years since Operas tragic death and over 2 years since Firefox shared the sad fate)I don't want out future to be dark, dystopian world with just chromium clones ruling over it and every old usable browser actively hunted by webapp makers and bending under the weight of their unoptimized code and polyfills
but is there any hope left if we can't even agree that feature isn't implemented until it is implemented?
-
@zakius My last comment on this:
By that standard, a "feature" could be "customizable browser" and it would never be complete. You set up standards for what it means, they are never met because the developers, not you, are designing the browser. Customizable means something different to you than it does to them, and to the available tech. And while they solicit and welcome suggestions, they are not dictated to by the users.
While "configurable toolbars" are a step back from this, it's the same concept. You have decided what a configurable toolbar is, and seek to dictate that the developers follow your standard, and not do something else. While you are free to suggest it and even agitate on its behalf, you are not free to castigate the team for having a different idea as to how to proceed. If they have done what they are going to do on a request, then you need to file additional/different requests.
That's why a list of "standards" is, instead, broken down into multiple "asks." This is, in fact, how the Sopranos interact with the team when giving feedback on, say, M3. One single feature or behavior we would like to see, one entry into Jira. If part of a Jira entry could be solved but not another at a particular time, then it needed to be two entries. We do it this way because we seek to make definable progress. The ultimate consequence of seeking to dictate in too much complex detail to the team, is that one is ignored. As I said, my last comment on this.
-
no matter what is your reasoning this request isn't implemented so marking it as done is a lie
it is pretty big, sure, but it doesn't matter you should lie about it like that, if needed mark it as in progress, close and observe smaller sub-tasks, but don't mark not-done feature as done intentionally
there are multiple instances of this behavior: mouse gestures, but rockers are not configurable, middle click on tab bar but it doesn't work on the most common, default setup
closing to help maintain big tasks doesn't require you to mark them as done when they aren't
Jira is good at handling this, forum is not, but it can be handled in more honest way -
-