asked 2014-01-07 10:57:17 +0300
This site is not a bugtracker and should not used as such (no features like bug duplicates, etc.)
There should be a community bugtracker for that. This should only be used for exhancements proposals, general questions, etc. but _NOT_ for reporting bugs.
answered 2014-02-03 23:40:19 +0300
This is NOT an answer, but since comment section doesn't allow more than 500 lines, it is posted as an answer.
What I would like to see in a bug tracker? Everything and anything.
If someone ended up spending several months on a change that increased the phone responsiveness by 0.001%, I would like to know about it.
If someone spent several weeks implementing a new functionality that doesn't directly impact an end user but will allow Jolla developers to do something with it, I would like to know about it.
Things that directly impact the end user, things that indirectly impact the end user, things that impact only developers, things that no one will see, things that were perspective at start but then ditched for some reason, ...
Or simply, everything.
Why?
For starters, the more open source it becomes, if there is a problem someone could solve, I don't think anyone would feel comfortable spending hours/days/weeks/months fixing a problem, just to find out that it was all in vain because Jolla developers were actually working on it.
More importantly, for end user.
Visibility of what is being worked on makes expectations more realistic, keeps the excitement up and lowers the disappointment.
Imagination runs wild. Everyone will expect everything, new apps, new fixes, better battery life, faster OS, ... And the longer we have to wait, the more we will expect.
With a proper bug tracker, at any point, users would be able to see what is actually being worked on, so they know what they can expect in the next update. If it is a core functionality... fine, if it is something that will interact with the user, that's fine too, but users would know what they waited week/month/months for.
Yes, everything that is being worked on, doesn't necessarily ends up being completed in time to be included in the next update. But at least, the user will know that it is being worked on, and that there is a higher possibility of it being introduced in the next update.
Also, if something isn't being worked on at the moment due to the different priorities, someone could be disappointed about it at start, but the more bugs/features are implemented, higher on the list their bug/feature will be. Additionally, same user would know not to expect it in this update.
The way it works now, it doesn't matter if there is a change log that states that something was improved or fixed, because, someone waited a month or two for a specific feature/fix that wasn't delivered. Not only that, but there is no information or indication that anyone even started working on it, or which item in queue it is? Next update? Update after that? Ten years?
Who knows, maybe Jolla staff did a lot of work that will be more visible in the next update, but considering that this update brought more bugs than it solved, to me it more feels like "So you want to tell me you spent {insert a number} months to implement a few additional check-boxes?"
Considering the state of the OS, amounts of bugs, amount of out of the box features we got used to in other smart-phones that are "missing" here, I think this is more necessary now than it will be later when "basic" functionality starts working as intended.
Thank you, Ranko
Yep, agree for the most part. Only, consider that the end-users are usually not devs and do not think in terms of bugs, confirmations and fixes, but they want a single-point-of-accesss to help them when they encounter problems and issues in using the product. Jolla Care Kbowledge base reachable by the forum and email serves that function, but partly only. It is missing a crucial feature of not being public enough, users don't see what's hapoening with other users. Thus there is Together where we all see all issues/wishes and can even provide anserws to them. But this is not a good forum to track how issues and features are handled and the relation of current situation and the roadmap is unclear. For this a light-weight service request system could be introduced that wouldn't be just a Q/A-forum but not that tecjnical as bug-tracker. In thr spirit of ITSM the service request portal could provide users with private views to their own requests, shared views to issues made public (as in here), and the dev views (both external and internal) to setvice tickets, their life-cycles, resolutions, root causes, and statistics as all bug/issue-tracker systems do. To kick-start this a slight sift of thinking should be made in direction of realizing that mobile trch conpany is providing a service to their customers and not only a product. Service thinking also is the way to integrate customer-side to in-house and 3rd-party development and community intiatives. So, lets start to talk about service requests, and resololutions to.them, and service development practices (SW-dev etc) to achive in this. Update: should probably convert this to an Answer, or something .. ;)
foss4ever ( 2014-02-04 03:09:36 +0300 )editanswered 2014-07-20 13:02:20 +0300
"This site is not a bugtracker and should not used as such (no features like bug duplicates, etc.)"
IN OPPOSITE, I think it is possible to use TJC as a full working public bugtracker by defining clear rules for how the bugs are reported and by who they are tracked. What supports this idea:
Current situation with bug tracking
As this question, in its current form, seems to support the idea of not using TJC as a bugtracker, I'm opening up a new question with the opposite goal if this answer is supported. In there we could offer possible solutions for how TJC could be used as a working bugtracker.
Asked: 2014-01-07 10:57:17 +0300
Seen: 1,259 times
Last updated: Jul 20 '14
In fact, the tag 'bug' is meant for this purpose. I personally think this is more friendly and proper than a bugzilla.
Stskeeps ( 2014-01-07 12:06:56 +0300 )edit@Stskeeps: I agree with you, but to the developer point of view, a real bugtracker is more efficient, no? And I think that there will be less bug reports than without "together".
Edit: I've just reed you profile, and you certainly know better than us what Jolla prefer to report bugs ;-)
TeHeR ( 2014-01-07 12:25:09 +0300 )editbefore an 'answer' can I ask what kind of bugs you mean? Product usability issues and missing features? More technical issues like: Issues with the Silica API and app development bugs? Bugs in the middleware (like ssu)? Bugs in the core (like connman, systemd)?
lbt ( 2014-01-07 12:39:33 +0300 )editI was primarily thinking about usability bugs, i.e. the final usability problem that is the consequence of a bug somewhere in the stack.
I don't like this as a bugtracker, because it is by nature not a bugtracker but a FAQ engine, and therefore lacks even the basic functionality of it.
vbmithr ( 2014-01-09 11:16:11 +0300 )editAnd obviously there is no follow-up to bug reports, like its resolution. No way to now if work is ongoing, the status, etc. Put it another way, I'd like users to have a more direct access to the real bugtrackers that certainly exists.
vbmithr ( 2014-01-09 11:18:49 +0300 )edit