In any case, I'd expect to see lots of back-and-forth from people who passionately argue that their issue should be put in the plans, damn it. Not that this would be a new thing.

An option is to create a separate custom field which represents the Linden priority. This could be shown on the advanced tab and use a workflow rule to make it settable only by Linden accounts.

1. Is this for bug fixes, features, or both?

2. As Which has said, what does priority mean, and who decides what the priority for an issue is? There's no way a Resident could meaningfully choose "Small - Not Currently Planned", because they'd have no idea what the plans are.

My assumption, based on the current descriptions of the various priorities, was that it was a "severity" indicator – how badly a bug messes things up, or how much a new feature is needed (in the opinion of the reporter and/or whoever edited the issue). This new description would either mean that all priorities indicate "how likely a Linden will work on it"; or that there are two conflicting definitions of priority, a new one which applies to "small", and the old one which applies to all the others.

Currently the stated definition of small (context help button sez): "Cosmetic problems like misspelt words or misaligned text."

Jacek, I can agree we would be creating 2 subtle definitions of Priority by this change: the old one which applies to the top 4 levels; and a special-case for "Small" which is the equivalent of resolving the issue as "So small as to be Not Currently Planned".

While less than perfect, this allows an issue (determined by Linden to be "Wont Fix") to stay open for votes/discussion... and perhaps change the determination

Whereas currently Lindens may resolve an issue, only to have it reopened-- therefore clouding the filters of items actively under consideration (and eliminating the indicator/history of Linden Lab's last determination.) The hope of this change is to reduce a Resident's need to re-open, by retaining the ability to vote and appear on filters (at the bottom).

Perhaps this is too imperfect to work?

And no matter what, the stubborn will change their pet items back to the way they want it to be.

But as a whole, I think the intended concept is sound.

Also, "Small - Not Currently Planned" sounds a bit strange when applied to (small) bugs. I hope nobody at LL plans bugs, but rather what to do when they emerge and how to avoid them. I'd suggest something like "Small - Not urgent at all" which would go with bug reports as well as with feature requests.

Given that there are X-thousand issues created with the understanding that the current "priority" field means "severity", I don't think we'd want to pull a switcher-oo and relabel "Priority" -> "Severity" and "[New Field]" -> "Priority". Hilarity and confusion ensues.

Ideally, we could think up a meaningful name for the new field, and leave "Priority" the same. Or if they both changed to be more accurate, say, "Issue Severity" and "Internal Priority" (or "Linden Priority"), people could figure it out pretty easily. Especially if "Internal Priority" was only settable by Lindens.

If I understand this correctly, you mean to say, "Yeah, we know that's a bug, but we're not going to fix it. Anyone with extra time on their hands can have a shot at it." Right now, the "Won't Finish" Resolution only applies to Closed issues and means "You think that's a bug, but we think it's unsupported." Would it be possible to give a "Won't Finish" Resolution to an Open issue? That would make the intention pretty clear.

I agree with the poster on the mailing list that mentioned that "someday maybe" is actually less harsh than "not currently planned". But neither are very good. "Nice to have" is better than either of those, I think. Maybe "Small / Nice to Have", or "Low / Nice to Have", or some-such.

A little background as to why such a modest change. Any bigger changes would require updates to our importer, and I'm trying to avoid making a lot of changes to that code, since it's a pain to test (we don't have a non-production environment to test with).

So, I get that there's a desire for a larger change, but we'd like to roll something out quickly and move on. If someone wants to file a separate issue for more drastic changes here, they are welcome. I can understand the desire to want to separate out priority according to the reporter (and community) from priority according to Linden, but implementing that change is more of a pain that you might realize. Not that I'm taking that option completely off the table, but merely pointing out that there's further reason (besides Celierra's previous comment) to make that a separate discussion.

Does "Low (nice to have)" make sense as a priority label? We could just use "Low" or "Small", and merely communicate what the meaning of that label is on the issue posting guidelines page

My understanding of THIS JIRA's priority is a classification of an issue, based on a predefined set of objective criteria. At this moment, the criteria primarily considers the types of mischief the issue makes. I believe some Linden said on some bug triage that the priority assigned on PJIRA is unrelated to the priority of the bug fix. The bug fix priority is assigned by the triage. I have never heard that the priority affects the order of the Linden resource that is allocated to the issue.

I have no strong objection if you Lindens are changing the meaning of the priority field. However, if you do so, we need to re-evaluate the bug fix priority of the open issues.

For the name, I'm not confortable to use such positive words like "nice" for the class of issues that Lindens will never allocate their resource. Such a wording is a sort of eyewash, IMHO. I believe we should use more explicit wording, i.e., "Lindens will never take care this" or "Lindens neglect this".

First, look at this quick search I did for "small" priority issues, resolved as "Fixed", ordered by number of votes:
http://jira.secondlife.com/secure/IssueNavigator.jspa?reset=true&&resolution=1&priority=5&sorter/field=issuekey&sorter/order=DESC&sorter/field=votes&sorter/order=DESC

Also, check out VWR-1609 and VWR-1281, two issues I reported that I set to "Small" based on my interpretation of the issue priority guidelines. Apparently they were important enough to fix. I've seen plenty of bugs that would fit the description of "Cosmetic problems like misspelt words or misaligned text." but nevertheless are pretty annoying. If you're going to relabel "Small", it would be a good idea to revisit the rest of the priority descriptions while you're at it to make them more clear. We have a lot of arguments/flames on this JIRA related to priorities.

That's the other thing: if you're going to do this, then people will do everything they can to avoid having their issue set to this priority. As it is now, people very often label their issues as "Showstopper" if it only stops their show. Trying to lower the priority of someone's issues often results in getting flamed. If someone re-raises the priority after I lower it, I walk away (unless it's my issue), because I don't like getting castigated just for trying to help.

What I'm saying is that priorities are essentially useless as they stand, because people don't read the guidelines and they don't understand what they're for. I think we could gain a lot of order by making the "priority" field only editable by Lindens, and have Lindens actively classify every new issue that enters the JIRA, perhaps at the triage. If someone is upset enough by an issue to report it, they clearly think the issue is important enough to be fixed, and they don't want to see someone set it to "Low - Won't be fixed in your lifetime". If they have the ability to change the priority, they will, and then the priority on this JIRA will simply not reflect reality and will be useless.

I truly would welcome a feature proposal for "Linden Priority" to be filed, linked to this issue, and assigned to me. I would like to more thoroughly explore how to make life easier for Lex and others who are helping us out with tidying up, and if separate fields would truly do the trick, we should explore that.

Besides which, working on the same project all the time is BORING, Lindens should be going around grabbing the occasional small issues to give themselves variety. There are lots of tiny, easy to implement things that wouldn't tax a programmer much at all and could probably be done in an hour (plus testing) but would save immeasurable amounts of frustration for residents.

As such I vote against this. This isn't something you can just arbitrarily give a description to, every issue is different; some sound small but are incredibly complex, others are desperately needed but easy to fix.

There's a constant problem with closures, as I've indicated with other comments, and on the SL Dev list, there are people who want to be able to go around and "clean up" all the time out of a sense of "ordnung" or symmetry. I don't want the Lindens signalling a matter as "low priority" to give aid and sustenance to those janitorial crews.

Low priority for Linden Lab might become high priority for a competitor and in the climate where LL says it will open source the software someday, the governance of the Metaverse can't be predicated on the priorities of one company and its select janitors.

Pretty much EVERYTHING on the JIRA is "nice to have", but some things are more nice to have, so nice in fact that 200+ people are willing to vote on them as in the case of VWR-489 which was (before I changed it) set to this new "nice to have" foolishness.

The JIRA is difficult enough for a lot of people to use properly, please change this back, or drastically re-work the priority field!

For features I've been using priority to indicate the importance of a feature and/or the difficulty in implementing it. IMO separate fields for these things (importance/cost) would be far more beneficial than a silly change to a fairly useless priority field, especially if it's to be treated with such a cavalier attitude!

With an "Importance" and "Complexity" field you could create balances that better reflect LL's stance on resolving issues.

For example, an issue with high importance but any complexity will be actioned quickly, unless it's complexity is prohibitively high in which case alternatives will be looked for.
An issue with high complexity but low importance will be ignored almost outright until complexity issues can be addressed, or value can be proven.
An issue whose complexity matches its importance can be considered as less important issues that are easy to implement are okay, as are important issues that are more complex to implement.

Or even if "Linden priority" were to somehow imply that "nice to have" issues will eventually be actioned. Currently we have a lot of good issues that are just floating around and have been for a long time now, that while not critical do also deserve to be implemented at some point. The JIRA becomes pointless if the only things that are ever implemented are Showstopper or Critical, while everything else is pretty much ignored in favour of whatever LL comes up with instead.

While that's being explored, would it be feasible to make "nice to have" be a new priority level? My main argument for this would be that there are existing issues which were filed as "small" priority under the old definition. I suppose another alternative would be to go through every existing issue and re-evaluate its priority to decide whether it's now closer to "Low" or "Normal". (An initial search brought up 326 issues, though, so it would take a good bit of effort to do that. Not to mention the risk of offending the reporters by changing the priority without their input.)

So....I've added a sixth priority level "Nice to have", and changed the previous "Low" to something similar to the old definition.