An issue/patch can be "imported" i.e. makes it into LL internal jira - however, it can then sit their indefinitely without anyone within LL acting upon it.

In the case of "fixed internally", it is not clear what the internal processes within LL are - it can be 2-3 months before a "fixed internally" issue makes it into release (floating text not displaying on non-root prims being an issue which spent a very long time as "fixed internally" before it actually got fixed in release). Some "fixed internally" issues seem to get lost, and it take a few prods (e.g. re-opening the issue on here) before they make it into release.

As Matthew Dowd points out, an "internally resolved" issue has no status. If there are Lindens disagreeing about it (as we have seen sometimes on issues here) then we can expect that one Linden may simply not prevail. Or no Linden may find it a priority.

Therefore the status of "fixed internally" while interesting should never be used to mark an issue RESOLVED and stop its votes until it truly is resolved.

Linking to WEB-194.

http://nicholaz-beresford.blogspot.com/2007/11/long-road-behind-long-road-ahead.html

The part that is relevant to this discussion, I think, is that residents tend to focus upon their experience right now and become frustrated when fixes are delayed a long time, especially when perceived problems are grouped together to be fixed as part of a bigger project.

/me gazes deeply into his crystal ball ... the mists part briefly ... I see ... a ... "Fix" ... no wait it's getting clearer ... I see a .... "Won't Fix" in your near future.

We need to be able to communicate both when an issue has been addressed in the codebase (fixed internally), and when the fix for an issue has been shipped. The former is needed as a signal to developers that no more dev work should be required on the issue, so that non-Linden developers don't waste their time trying to fix an issue that someone already addressed. The latter is needed to signal that "yes, it's truly fixed in a way that you can see for yourself".

We discussed this at the last open source meeting:
https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-11-29

Abbreviated transcript follows:

1. [14:34] Rob Linden: ok, how is this for a process
2. [14:35] Rob Linden: we make sure that any time something gets marked "fixed internally" has a branch and a rev on it
3. [14:35] Rob Linden: that branch may not mean anything to most people, but....
4. [14:36] Rob Linden: we then endeavor to keep the list of branches up to date on the wiki for at least the branches referred to in PJIRA
5. [14:36] Rob Linden: I don't think that we can do that for ALL branches, because there are branches in there which are still confidential work
6. [14:54] Rob Linden: I think we've got something that will help keep really tech savvy people up to date
7. [14:54] Rob Linden: ...but will be utterly baffling to everyone else

We're hoping on community help to spread the word beyond that. However, we can revisit if it isn't panning out.

I can't make any promises that we'll make this work as described, because I can't commit to it myself and I don't have minions to delegate it to, but we'll see what we can pull together.

Note: the reason we're considering making a change here has nothing to do with voting. Voting on issues that we've already fixed is of relatively little value. There's a very small chance that if something is really popular, it gets moved to the front of the line, but that would be rare. Generally speaking, moving things to the front of the line short circuits testing, which is a highly risky thing to do.

OK, voting is not likely to push things through, unless of course the votes skyrocket. But at least it keeps a casual victim happy.

For the pending state, I think issues with Critical or Showstopper priority should be updated once a week or two with a short comment on progress, like "we need to test it more", or "this is ready for the next restart", or "awaiting next release", to give the anxious Residents a good feeling. And a chance to ping back so pain issues are not forgotten. SVC-930 was a good candidate for a regular status update.

Ideally, when developer fixes something, he (or the lead engineer, I don't know how that works in LL) would add a one liner roughly telling us where or what was fixed. During the pending state, an issue would be updated regularly, and hopefully a final confirmation would be added when QA verifies it in the RC.

I understand this is additional work, especially with juggling two jiras, but I think it would make everyone happier. Of course the community would need to keep the priority levels down, or this can never work. But anyway it would not be a firm rule. This would be for the issues where LL concurs with the priority.

Maybe you might like to have a new status: Resolution In Progress. That way, when it has all filtered through, you can use Resolved. And it will aid in all those posts that appear on the blog that are "Resolved", and then an hour later you say "Er, it's not doing what is expected, and is borked again." They would still be in progress, but people know you are working on it.

That way they would not waste yet more time, money and objects disappearing on something you say is "fixed" when it ain't.

This is probably going to screw up sljirastats.com, so Im giving Gigs the heads up now. Also, I need to run this by Aric and others.