Stop blaming the merchants for Linden Lab problems. You want to quit your job because the boss messes things up? If the sellers stopped selling every time Second Life had inventory loss problems, the whole grid would have been without merchandise for about well… four years now.

That said, since inventory is a database issue and Second Life now is four years old, this problem is gettting really really old and irritating. People spend hard cash on inventory only to have it destroyed on a daily basis. Someone at LL needs to get their heads out of their backsides and take care of the inventory loss problem… as well as a whole bunch of ancient, major bugs that have never been corrected.

OK, not so brief —

I apologize and realistically am aware that the following points don’t cover *everything*, which is why there’s always more to come. But I wanted to show my appreciation for you taking the time to read and say something:

* Those of you who want custom charts & stats (e.g., issue priorities), first off, I’d recommend learning to find and filter issues in the Issue Tracker yourself. That gives you the power to sift through data as *you* see fit. You may be overwhelmed at first, but stay with it. Look what happened to me. Then, you can export data in XML, and take queries to build into charts, be they functional, pretty, or both.

* Apple iWorks’ Keynote is REALLY nice to make charts with. It’s what I used, for those of you wondering.

* We don’t have a Mac-specific component in the Issue Tracker, but you CAN do a quick search = “mac”, “linux”, or other platform or OS-specific info. Many Mac bugs are preceded by “Mac” in their summaries. As noted, Dan Linden’s keeping tabs on top Mac crashes too.

* Notice how I didn’t impose my own interpretation of the data? This was purposefully done to let you draw your own conclusions, and examine context for yourself. One thing for sure, it doesn’t necessarily mean we have “lots of new bugs that never existed before” — more likely, as I’ve witnessed firsthand, higher usage of the Issue Tracker means that Residents are entering bugs that’ve pained them for awhile but they just got around to it now. While there isn’t an easy way to determine that, look at the “Linden Lab Internal ID” field for Issue Tracker bugs linked to our internal system: the lower an SL-XXX number, the older a bug was known by us, relatively speaking. There are a number of ways we can trend this, and you’re welcome to discuss with me further at my inworld Office Hours (link in original post).

* I have no professional clue about PR (?!). What the !@#$ is PR? I know the “definition”, but I don’t get it. I’m enthusiastic and well-mannered and hate to see people in pain, whether it’s emotional anguish or physical suffering. I’m happy I have the honor of communicating with you — better than dead radio silence.

* Bugs fixed by CREATION DATE and UPDATED DATE are two different ways of looking at the same resolved bugs. *However*, as I mentioned, I’d love to simplify and sort by “resolved date”, but there’s not a readily-available way to do that in JIRA.

* Yes, JIRA can be slow and hard to use. But this is in part due to all the details we need to keep track of. Not to say it can’t be done better, but there are seemingly not a lot of contenders in this market… if you know lots of about elegant bug tracking and issue resolution, please email me, torley at lindenlab dot com. Would love to learn from your experiences. I’m familiar with a few others, like Trac (which is used @ http://colloquy.info/).

* Re: “THESE GUYS RULE! WHY DON’T YOU HIRE THEM!??” Is Linden Lab hiring open source contributors who’re interested in working here? Heck yes we are! Understandably, I can’t reveal details of some potential hirees-in-progress, but some, like Soft (SLDev superstar!), have become Lindens. If you feel this means *you*, please go ahead and send us your resume via http://lindenlab.com/employment Always a good idea to attend related Office Hours, e.g., Rob’s bug triages, so we better understand who you are.

So, I take what I’ve learned here today from you, humble myself before the crowd, and shall continue on and give you more updates in the future. Stagnation will slay us all, thus, the last few releases have seen a lot of bug fixes. Whenever possible, we’ll link ‘em to Issue Tracker #s so you can view more details at your own convenience. It sure beats the days of vaguely referring to “that attachment bug”, and we’ve got a lot to improve on.

Moreso than anything — please do remember what I said about being observant, and as a consequence of that, doing next actions. You can make a positive difference here, benefit yourself and your community in the process, and I say this only because I’ve lived it. =^_^=

With each new, (we’ll be down from 7 - 12, I promise Wednesday builds), we see more bugs, some of the same exsposing their ugly heads from a previous build and Gee, we’ll get it fixed real soon, but make sure to keep payin and non-game playin.

Someone I know is selling 6 of her 7 sims for this reason. I wont be oredering another until I see actual stability for both front and back end.

Your friend at Microsoft is evidently not a programmer. A Patch usually is fixing broken code so that it does work correctly. You only have to create a workaround patch IF you do not have access to fix where the real problem is occuring.

the most disconcerting area of defects are the defects that were previously fixed being returned to production this week. that has nothing to do with the jira.

Er yes we do: “* This doesn’t mean bugs fixed per month, but bugs reported within a given month that are now fixed.”

So, 146 bugs reported in January, of which 71 have now been fixed, just under 50% during the last five months.
and

“** The date an issue last had any changes made, such as if it was resolved, but also if was reopened, linked to another issue, a comment was made on it, etc.”

So for January, there are 17 of those. In other words, out of that 71, they fixed 17 that month properly, or at least they have not been reopened etc since. That’s assuming of course that none of these fixes mentioned are historically older than those reported, in which case the performance level is actually lower.

But I do agree with the priorities. Also, although it is a bit meanlingless, an average time to fix a bug might be useful. It would be a measure if things are getting faster or slower, but it would give an average time to wait before us whiners should then start giving Linden a good kicking.