secondlife / jira-archive

2 stars 0 forks source link

[BUG-6617] JIRA tickets should not be marked as resolved when accepted or triaged. #14457

Open sl-service-account opened 10 years ago

sl-service-account commented 10 years ago

How would you like the feature to work?

JIRA tickets really should not be marked as resolved until they are fixed in the SL system, or declined.

Why is this feature important to you? How would it benefit the community?

When tickets are marked as resolved, there is no further way to continue communication on that ticket. The ticket becomes locked, (to all accept the reporter, maybe, even if it's marked public?) and there is no way for the users to continue to provide helpful troubleshooting information, or state that the bug has been fixed. Also, there should be ongoing communication between the developer and the user to confirm that the bug has actually been fixed when a patch has been put in place. Sometimes patches are put in place that simply don't do the job, and there is no way to inform the developers without opening a brand new ticket. It also displays a false sense of accomplishment as marking a ticket as resolved also is reflected on JIRA graphs and "recently resolved" ticket listings, when no real issue has been resolved.

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-6617 | | Summary | JIRA tickets should not be marked as resolved when accepted or triaged. | | Type | New Feature Request | | Priority | Unset | | Status | Been Triaged | | Resolution | Triaged | | Reporter | Callak Skytower (callak.skytower) | | Created at | 2014-07-08T12:28:46Z | | Updated at | 2014-07-09T18:20:21Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2014-07-08T10:54:53.340-0500', 'How would you like the feature to work?': 'JIRA tickets really should not be marked as resolved until they are fixed in the SL system.', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "When tickets are marked as resolved, there is no further way to continue communication on that ticket. The ticket becomes locked, and there is no way for the user to continue to provide helpful troubleshooting information, or state that the bug has been fixed. Also, there should be ongoing communication between the developer and the user to confirm that the bug has actually been fixed when a patch has been put in place. Sometimes patches are put in place that simply don't do the job, and there is no way to inform the developers without opening a brand new ticket.", } ```
sl-service-account commented 10 years ago

Callak Skytower commented at 2014-07-08T15:43:58Z, updated at 2014-07-08T15:44:40Z

I thought perhaps I should provide a further explanation of the problem. I have a reported bug BUG-5607, that was allready reported under BUG-5380, and I was directed there and my ticket closed and locked. However, this previous ticket appears to be locked so I cannot provide any further input on my problem.

I have also created ticket BUG-4427 that was changed to accepted status as well as dismissed as resolved as "accepted" on 12/Nov/13. This does not make any sense to me as a user. Accepted does not mean it has been resolved. This SERIOUS problem still exists, and I have not been able to obtain any information on its progress. Last time I checked with Nyx in an in world meeting, no one had touched the issue. Is this because it is "resolved" in the system, or some other reason?

sl-service-account commented 10 years ago

Whirly Fizzle commented at 2014-07-08T15:54:53Z

BUG-5380 is marked as accepted, which means a Linden has verified it is a bug and imported it to one of their internal JIRA projects. If you look under the History for issue BUG-5380, you can see the internal issue for this bug is MAINT-3840. Once an issue is imported, it's a black hole for us. We only know it is fixed if MAINT-3840 is listed in the release notes for a viewer release.

BUG-4427 was also verified by a Linden and Accepted and imported to their internal JIRA as MAINT-3438. Again, we can only know when this issue is fixed when MAINT-3438 appears in the resolved issues on a viewers release notes.

You should be able to comment on issue BUG-4427 still because you are the reporter of this issue.

sl-service-account commented 10 years ago

Callak Skytower commented at 2014-07-08T16:15:27Z, updated at 2014-07-08T16:16:26Z

Thank you for some explanation Whirly, but I still find it frustrating that we are kept dark on progress. Some of these issues are really drawing out, and I'm personally getting frustrated. I'm trying to find out why things are going as slowly as they are. It's been 8 months since BUG-4427 was accepted, and last time I checked with Nyx, he reported that it handn't even been started on. That was probably five months ago. I plan to be at the in world meeting to check up again next monday. I do have another question though- does LL ever report back on the original ticket when their internal ticket has been resolved? I have yet to see this anywhere.

sl-service-account commented 10 years ago

Whirly Fizzle commented at 2014-07-08T16:29:12Z, updated at 2014-07-08T16:34:56Z

Does LL ever report back on the original ticket when their internal ticket has been resolved? Sometimes but not usually.

It is possible to track what has been fixed in the LL repositories yourself and to keep tabs on which project viewer or RC they are in and when the fixes make it into the latest current default release viewer, but its quite time consuming. It would be really helpful and time saving for us if the Linden Robot left a comment on issues in BUG when a fix had been commited to a repository. This does still happen for STORM issues.

But anyway - if you want to track fixes yourself, go to https://bitbucket.org/lindenlab and put a watch on all currently active bitbucket repositories in this list (include a watch for all pull requests, all forks and all commits). Also go to https://bitbucket.org/lindenlab/profile/members and "follow" everyone in this list. That way you will pretty much see all fixes drop into the repos that youre allowed to see and be notified when a new fork is made so you can add a watch onto this fork too. Most commits give the MAINT issue rather then the BUG issue, but with a bit of googling or cross referencing with the Firestorm JIRA (we tag all bugs we share with both the BUG and MAINT issue) you can find the BUG report if it isnt obvious from the title of the commit. Hope that helps a bit ;)

ETA: All viewer release notes (which have a resolved issues section) can be found here: http://wiki.secondlife.com/wiki/Category:Release_Notes

sl-service-account commented 10 years ago

Whirly Fizzle commented at 2014-07-08T16:44:26Z

I plan to be at the in world meeting to check up again next monday Nyx's Monday usergroup has disbanded.

User Groups still running are listed here: http://wiki.secondlife.com/wiki/Linden_Lab_Official:User_Groups

sl-service-account commented 10 years ago

Alexa Linden commented at 2014-07-09T18:20:22Z

Thank you for your suggestion.