In retrospect I can imagine people saying "What the f*** does 'Limbo' mean (in this situation)?" But I think this situation would quickly resolve itself.

Renaming "Resolved" to "Limbo" or "Waiting On Reporter" is a good solution too.

For those JIRA-nuts out there, CAN we change the name of the "Resolved" label?

I don't like "Pending", because it could imply that it's pending action on LL's part, rather than the reporter's.

Can you point to specific cases where you think this would have helped, and where user education is not the appropriate remedy?

• WEB-382 - This entire issue was created because Prokofy didn't understand that "Resolved" is not the same thing as "Closed and buried".
• Awhile back we had some wag who created an "advocacy" group and posted ads on issues that were marked (properly) as "Resolved", saying that SL citizens should not "subvert our JIRA process by closing issues".
• WEB-679 shows how hard it is to explain the meaning of "Resolved" to people who aren't experienced with the industry standards practices. Note that the issue reporter says that the issue guidelines are way too much information and not helpful for a non-programmer, so the explanation in the guidelines is not sufficient.
• WEB-247 - Note Celierra's first comment remarking on the confusing difference between how "[Resolved]" is used on the blog and how "Resolved" is used here.

There are MANY times when I've resolved an issue (properly), asking for more information or as a duplicate, and gotten a snarky lashback from the reporter that I shouldn't "close" their issue. Prokofy is only the most prominent example. Just like the priority thing, the word "Resolved" sets some of us up for pain when we try to help.

I think this is another example of the problems we're having with the ambiguous target audience of this JIRA. Worrying about changing "Resolved" away from the industry standard practice makes sense, but that implies that this JIRA is only targeted toward those in the computer programming industry. On the other hand, the blog and the "public issue tracker" menu option in the client directly encourage users to report their issues directly here. That means we're dealing with far more people than just programmers, and this is often the first issue tracker they'll ever have seen. Industry standards don't help if someone's not in the industry, and the issue posting guidelines aimed at computer programmers don't help because their eyes glaze over... so they fall back on their understanding of the definition of the word "Resolved", which sounds a lot like "never going to be addressed again".

I don't think user education is a proper remedy, at least not as it stands. Even if you completely rewrite the issue posting guidelines to make them accessible to non-programmers, the simple fact is that most users will not read documentation before they jump into a system. The system needs to be self-explanatory enough to handle that, and in cases where terms are easily misconstrued by those who haven't read the instructions, people are bound to be confused.

MISC-1350 and MISC-1352 - DR Dahlgren got upset by Harleen "closing" the issues (actually resolving), and ended up closing them himself. Harleen even tried to reason with DR and explain how things work, but that didn't seem to help. I tried to explain things in MISC-1352 after the fact, but in retrospect, I may have just frustrated him more.

In theory, the "Resolved" and "Closed" labels and the system of letting all users help sort through issues make a lot of sense. In practice, we have frequent explosions like this one, and the JIRA ends up probably permanently losing another potentially valuable contributor. Education won't cut it. We have to fix the JIRA in reaction to how it's being used and the pitfalls we're seeing in practice, rather than continue to hope that people will understand the theory of how it's supposed to operate.

We really need help here, LL. The way the JIRA is set up right now, regulars who are trying to help as you've requested are set up to take the brunt of users' ire.

WEB-702

As Lex has noticed many are confused by the jargon used here, and I can understand why they are. Think about the way you are treated when you call up your ISP or phone company at your home, when that support "specialist" is done with your call they will mark the issue with a resolution and as far as that person is concerned the issue is resolved to them. In some cases the resolution is satisfactory, in others it is not. But as a customer when you have a problem, and you report the problem, you don't see it marked as resolved at the end of that call. To you it isn't resolved in your mind because it isn't yet fixed until you know that someone has looked at it and decided if it is indeed a problem and what course of action to take regardless. Customers want an openness of what steps were taken on their issue.

I used to work in a call center for a cell phone provider, and when I sent a customer with a handset problem to a store for replacement or warranty service the issue was resolved according to the company, but to the customer it isn't until they have the new or fixed equipment.

The point is we are dealing with customers here, to them resolved means something totally different. And as far as reporting issues using the PJira goes it is a hassle to many users. Many will deal with a bothersome bug rather than report it as it stands now. If the client was again given the ability to send the bug reports to QA or worst case directly to PJira we could have a better way of solving the issues, environment statistics would be filled out in a uniform manner by the client (which already examines hardware and OS anyway to determine defaulted settings), trending data could be uncovered that isn't right now (Is this issue experienced by just one user, certain OS types, Certain video or audio hardware...?), and the process more streamlined. Most users wouldn't mind the email that would say that someone commented on their issue, and many would see that as their issue being worked on (or actively ignored in some cases). If an issue was a dupe of another then they could receive an email saying that and get a link that would allow them to automatically watch the parent issue.

Lets try to streamline this a bit, make it more friendly to the end-user and not just those of us with a technical background. Techies can translate for the end-user, but the end-user would have to learn our jargon to be able to communicate as we ask them to now, and that is something most don't want to, or will not do. Translating and improving access to the end-user is an industry standard as well, it s called "user-friendliness" and right now the bug reporting in SL is anything but user-friendly.

As such I am in favor of the proposal in WEB-702