|
|
|
I think renaming "Resolved" would cause confusion because we already have "Needs More Info" and "Cannot Reproduce" – I think being able to get email from PJIRA and notify reporters and watchers of actual comment responses would help too.
I'm not sure why "Needs More Info" or "Cannot Reproduce" would prevent changing the "resolved" label? Or is it because they pair badly with my poor replacement suggestions?
 How about "Awaiting Reporters", like "Status: Awaiting Reporters / Reason: Needs more info"? The specific label isn't so important - the core idea is that the label should evoke "LL thinks that it's done all it can right now", not "LL thinks that this has been fixed".
As an aside, I feel like I'm encountering the "bugs are getting resolved without actually being resolved" complaint/misunderstanding more and more often... One mention here: http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/#comment-420825 Ah, I see what you mean – yes, that is puzzling. But within "Needs More Info" and "Cannot Reproduce", there are also times when problems "just go away" and it's unclear how they were fixed, but the original reporter hasn't bothered to check back (also related to
I wonder what is the simplest way to go about this... I just don't want to add another layer of complexity, given what we've explained @ https://jira.secondlife.com/secure/ShowConstantsHelp.jspa Also on a related note, Rob and I updated the descriptions of Priorities... making it more clear Showstoppers (formerly Blockers) are only to be used for HIGHEST-PRIORITY stuff. I also note we haven't really been using "Closed" all that much – do you think it matters?
Internally we close batches of issues after verifying their inclusion in new releases, but I'm not sure that distinction is so important to most people publicly. I think it's probably a good idea to expect residents to confirm that something is fixed, or agree with some different resolution, even if it'd only be for relational purposes. (Maybe it should be "Confirmed" instead of "Closed"?
)
But I feel like it'd be okay if 'resolved' (or 'awaiting reporters' or...) issues are never closed, though... Would there be any problems if things aren't? Maybe I'm still misunderstanding something...? I think part of this is limitations with JIRA's workflow and terminology:
» http://www.atlassian.com/software/jira/docs/v2.6.1/workflow.html and part of it is a need for better education of how the software development process works, for the general public. We can certainly communicate this better. I'm trying to keep terms consistent both internally and externally so they have the same meaning and don't confuse our engineers either; "Confirmed" is not as resolute, nor as standard as "Closed". What I'm hoping in the longer-term is that we add the ability to watch issues, so then, within a comment itself, I, another Linden, or even a Resident can write "We're awaiting more info from you on this, please" or whatever needs to be done to prompt a next action. So many things are context-specific and often, an issue resolution, no matter what word is used, needs to be accompanied by additional reasoning – as you're familiar with "Why did you resolve my issue? It's not fixed!" For now, I'm marking this as "Won't Finish", with the provision that I continue to agree with you that we need to find better ways to clarify issue resolution status. Oops; it seems I forgot that not only liasons like you and Rob are using PJIRA.
Are developers having any trouble with the current setup?
I'm leaving the resolution be and waiting on progress. Since this seems to have just been actually implemented as "Fix Pending"
 , changing resolution from "Won't Finish" to "Fixed"?  Oops, wrong issue; I got a little over-excited.
Reopening to revisit the technical hurdles (instead of duplicating it as a sub-task of
Also, I'll note that I don't think we should adopt a non-standard terminology. In Bugzilla, which Jira is a clone of, resolutions were using for actions like WONTFIX, NEEDSINFO, etc. This set the precedent that is used everywhere now.
We can't rewrite history, and we shouldn't use terms that other developers won't understand. For better or worse, in bug tracking software, resolved is a standard term for an issue that has been returned to a reporter for further action. Sourceforge uses "Pending" instead of "Resolved". I don't think there would be any difficulty using Prokofy's suggestion of "Pending".
In WEB-690 "Limbo" & "Waiting on Reporter" have been suggested as alternatives.
At this time, we have no plans of changing from the standard verbage used in bug tracking.
Sourceforge.net's bug tracking system is "non-standard"? o_O
From my over three decades of experience with software issue tracking systems, there's certainly nothing "standard" about "NEEDINFO" being considered a special case of "RESOLVED".
I'm sure it gives a nice warm feeling to somebody's weekly stats to assert that identifying the need for more information to fix or triage is a "resolution"...but it just ain't so. If that's some internal Linden Research "standard", then the standard is 'way broken, besides betraying some very uncomplementary things about attitudes toward customer service. (Of course, not everybody who flings stuff into pjira is reasonably considered a "customer", but that's another issue.) NEEDINFO is an intermediate state in the process of RESOLVing an issue, not an end state. If you want a RESOLVED - NO RESPONSE FROM REPORTER status after "n" days, that makes sense. After "n" days, of course... It seems like there's still enough demand for this to keep the bug open (in case people change their minds, or even if only to catch further requests).
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Reopened
Normal
WEB-58might somewhat mitigate this problem.