Technology General

[#1]

If you've been following these blogs, you've seen that we're making some major changes to how we work. In short: we're aiming to fix more bugs, faster, with more visible process. And if we're aiming to fix more bugs, we should fix our bug-tracking. But first, a quick introduction for those new to the topic.

What is the Second Life Bug-Tracker?

At Linden Lab we use the JIRA bug-tracking software from Atlassian to collect, organise and track bugs for fixing. Residents can file new bugs for our attention at jira.secondlife.com . Our engineering teams review submitted bugs and prioritise them for fixing in a process known as triage.

What kinds of bugs go into the bug-tracker?

This is a topic that confuses a lot of people, so here's a handy guide: If you've got a sudden problem that's affecting you, and you're not sure whether it's related to your account or your software, then please go to Support, not the bug-tracker. Our Support folks can help diagnose the problem and may be able to fix it quickly. If the problem is obviously a software defect that may be affecting a large number of people, it goes in the bug-tracker. So, a problem like "I can't log in and I don't know why" is a Support issue. A problem like "The 'Build' button flips upside-down whenever there's a hippo on the screen" is a bug.

That's what our bug-tracker's about. However, there's a lot about its current setup, and the way we use it, that we want to change and improve. Here are our priorities:

Triage, prioritise and fix more bugs, more effectively

Top of the list, because that's what bug-tracking's for.

A better experience for those who want to use JIRA

The current UI leaves a lot of room for improvement. We want  Fast and Easy. (Fun may be a tall order, but we're open to suggestions.)

A simpler experience for those who don't

JIRA is a powerful and complex tool for those who want to go deep into the software development process. These people are in the minority. The default method of bug reporting should be far less intimidating and directly integrated into our customer support process.

More project transparency

Project teams that work in the open, such as , should have project management tools that those outside the Lab can follow. Everyone should be able to see the state of the current sprint, the arrangement of the project's backlog and the items that are scheduled against each upcoming release.

Better progress notification

Issue statuses have frequently not reflected the progress we're making internally. This needs to improve so that our customers can see us responding to their bug reports.

One JIRA for all

Up until now we've maintained two separate bug-trackers, external and internal, and we've imported issues between them. It's not worked that well; among other things, it's caused the issue status problem above. The two bug-trackers will be merged into one. (This won't mean that all our work will be publicly-visible; some types of issues, such as security or customer-support-related issues, need to be kept internal.)

Easier issue workflow

The workflow stages through which a bug moves should better reflect our working process. Issue statuses and resolutions will have clearer names. For example, "Needs More Info" is not a resolution; it's an intermediate state waiting on action from the reporter.

Now that we've listed our priorities, here's how we're going to address them.

Tomorrow morning we'll roll out some changes to the default workflow used in our main projects. Some status and resolution names will change, and issues which have status changes will be updated. For a full description of the changes we're making, see this wiki page. The rollout will require some downtime, which will be tracked on the Second Life status blog.

In September, we'll be migrating our JIRA setup to new hosting and upgrading to the latest version. With JIRA 4.1, we'll get an interface that's easier to read, faster to navigate, and more responsive. We'll also be installing Greenhopper, the Scrum management tool for JIRA, which open projects such as Snowstorm can use to publish backlogs and organise sprints. JIRA will no longer have a login screen separate from the main secondlife.com site; logging into one also logs you into the other. This migration is planned for September 6th and will likely take most of the day, during which the bug-tracker will be read-only; you'll be able to look at issues, but not add or change them. If all goes to plan, the new system will be live on September 7th.

There'll still be work to do after this. Migrating internal work to the new JIRA will take a while. Some workflows or other processes will likely need tweaking as we settle in. On top of that, there's the ongoing process of helping our engineering teams be more transparent and responsive in their daily work while still giving them time to get the engineering done.

Down the road, we are looking to integrate our support case system and JIRA.  This integration will allow Support to associate bug-related support cases with open JIRA issues.  The resident who submitted the case will be able to click through to the JIRA issue, and their case will automatically be updated as the JIRA status changes. We're also looking at ways of making bug reporting easier for everyone so that only those who want to navigate JIRA do so.

The proof of the bug-tracker, of course, is in the bug fixing.  It's also in the two-way communication that enables you to see what we're working on, and tell us about other things we should be looking at.  We deeply appreciate the effort you put in to filing detailed bug reports and we work to reward that effort with higher-quality software.  Along the way, we want to keep all of you up-to-date on what we're doing with those reports and why we're doing it.

We thank everyone who has contributed to our bug-tracker so far; it's been incredibly valuable. You'll be hearing more from us, in many more ways, soon.

[#2]

Whats the jira for that work?

(j/k)

: P

[#3]

Having tried to use the JIRA to submit a feature request to the Snowstorm Project, I started a thread detailing the process step by step.

Here's the link to that thread: http://blogs.secondlife.com/message/365522#365522

In short, return to the KISS principle.

[#4]

Good news about the link between JIRA and Scrum especially wrt Snowstorm - should make it all feel a lot more joined up.

[#5]

Many thanks for that, Ravin, and sorry that the process was so arduous. Several of the points you raise are being addressed, and the suggestion at the bottom of your post is a great one. I'll talk to the Snowstorm team and we'll look into it.

[#6]

Bravo! All things that have needed fixing for ages, especially the internal/PJIRA split.  

[#7]

That quick process could be incorporated into the Dashboard.

Add a "Go To Jira Button" then a short and simple series of pages. Each page has at the top a short simple description of what information you want, one or two drop down menus or text boxes, a final review page, back buttons all the way through and a final submit button.

[#8]

I'd love if there was a separate "user discussion" tab where all the user comments and such would go, and dev responses to that type of discussion. And then a "Progress notes" tab, or something like that, where the developers' progress notes would go. As it is now, all the whitenoise get mixed with the valuable information, which makes it hard to read the Jiras.

In the pjira, some really important comments from the devs about an issue's progress easily get lost in all the other talk.

Also, will anyone still be able to change status and priority on the issues, or will you lock that down a bit? The priority wars and such in the pjira also adds to the whitenoise.

[#9]

This all sounds very promising, and I am looking forward to seeing these improvements.

One thing I would like to see. - Four major categories that should be in the JIRA, and searchable, and able to be acted on. :

• Bugs - This goes without saying. If a function is broken, such as "When I click to rez a cube, it rezzes a torus, WTF?", those need to get triaged and fixed ASAP. - Highest priority.
  
• Changes - Many things go into the JIRA that are not exactly a bug, but rather are a dissatisfaction with how something is functioning, or how a function has been changed. If someone reports "Until that last update, we could post 1024 characters of text in text chat, and now we can only post 128 characters.", that is a serious loss of functionality. It may be "how you designed it", but if your customers disagree with the loss of functionality, the issue should be remediated on almost as high a priority as bugs. This isn't a "new feature request" - it's "We could do this before you changed things! Fix what you broke!". UI changes come here as well, like the demand for the sidebar in 2.x to have the option to slide over the virtual world, instead of body-slamming it to one side, or requests to restore the ability to resize inventory views, or to look at multiple profiles at once.
  
• Requests / New Features - The JIRA is quite suitable for submitting requests for things the client or server have never done before. Things like the requests that led to multiple attachment points, or a request to tag all minors visibly in all transactions, and make that tag script-accessible. Some of these may be "well, when we have the resources, that would be nice to add", but these still need triage to prioritise the things that are critical - like "Now that minors are on the adult grid, we need to be able to identify them!".
  
• Support resolutions - Stop reinventing the wheel! Your support people have a database of past resolution efforts, that they refer to when someone calls with a problem. They don't start all over from scratch when someone clearly just needs to clear their cookies and flush their cache. All of those "If the user reports this symptom, try these steps." sets of symptoms and proven resolutions should be accessible and searchable by users. And there should be a way for us to give feedback, such as "But that only works for Windows, not Mac!", or "It's much more likely that these steps will resolve that issue...". Note that this isn't where to seek support, but rather a place to check before calling support, to see of there is a ready solution to a common problem that matches your need. This is also a place where your users can ADD to the value of that data, by suggesting other tips and solutions and work-arounds that they have found. (Resident-contributed content should be validated, but will most often be better info than the help desk has, because we actually use the product!
  

But the biggest improvement needed isn't anything to do with the structure or function of the JIRA system. The biggest improvement needs to be in the responses that Linden Lab gives to the issues that are reported.

When hundreds, or even thousands, of your customers report a bug or vote for an issue to be fixed, or demand that a change be reverted, it is unacceptable to simply blow it off as 'won't fix', or to just close it without remediation. Saying "oh, but that is the way we designed it", isn't acceptable, when a large number of your customers see 'the way you designed it' as broken. If you want to fix your process for fixing things, the most important step is admitting that your past efforts are not always going to be perfect and correct, and that you may have made a mistake in 'how you designed it'.

[#10]

Alx: We've been wondering about ways to highlight developer comments, especially since they're the ones that everyone wants to find. The tab suggestion is a great one. We could also do highlighting of developer comments in the main comments tab, though if I understand your suggestion correctly, it's about providing two areas for developer comments. We're trying to limit the number of customisations, but a quick and easy solution here would help everyone.

As for who has access to changing status and priority, that's something we might tweak as we go.

[#11]

Yes, it's about still providing that "free for all" discussion area (which I feel is important), where more unstructured discussions can happen (where the devs might also take part), but also keeping some info more structured, for announcement/discussions/comments from/between the people that actually have some power/knowledge about what will happen to the issue.

One way to do it might just be to put a forum tab in each issue, that  uses this blog software for a discussion, and keeping the actual Jira  comments only for devs...

Marking the devs' comments in the unstructured tab would probably be great (something I miss in this blog software too. It should mark all the Linden comments in some other color).

[#12]

Woot!  =D

I dip into the PJIRA *often*, it's tremendously helpful in finding out if something weird I just saw is "just me" or something more widespread.  (often, it's just me. )

These changes sound great and I'm very much looking forward to seeing them in action! =)

Yay!

[#13]

Ceera: Of the four categories you describe, the first three are normally implemented as the "Bug", "Enhancement" and "New Feature" issue types in default JIRA installations. We don't currently have an "Enhancement" type, but I'm not ruling it out for the future. The other two can be specified in the issue type field of a JIRA search right now.

"Support resolutions" - absolutely agree, and this is something we're working on right now. SL Answers was an early attempt at this but we need something more effective. Also, it needs to be part of the Support pipeline, not JIRA - we want to catch and solve this customer's problem before they get anywhere near JIRA.

Finally, yes: It's better to give the bigger issues more of an explanation when resolved without a fix. Customers need reassurance that their issues are being given proper consideration. However, there's a time balance to keep in mind: there can be lots of different issues that need triage, and we can't go into long discussions about all of them. Sometimes we provide an explanation and some customers don't accept it. That's fair enough, we can't always agree on the right solution, but there's only so much time we can spend arguing.

We all want to make Second Life better, and we're humans who sometimes make mistakes in the ways we choose to do that. We've made plenty of mistakes in the past, because it's almost impossible to get this far with this unique and complex a service without them. If a suggested fix is something we see as clearly better, and it's a fix we're capable of implementing within our various time and resource constraints, we have no problem in admitting that the first solution was wrong. We've done that plenty of times in the past. That's why Snowstorm is about opening up Viewer development to more input, some of which may well result in reverting some of the Viewer 2 design decisions - we're open to that. We may still decide against certain strongly-argued fixes, but it's definitely preferable to give more insight into the decision.

[#14]

Marking the devs' comments in the unstructured tab would probably be great (something I miss in this blog software too. It should mark all the Linden comments in some other color).

It does! Comments from Lindens have a green background.

[#15]

Whats the jira for that work?
(j/k)
: P

You can't see it - it's on the new JIRA. We used the new "Time Paradox" plugin. ;-)

[#16]

The obvious danger, of course, is that if people learn that Linden's actually reply and answer questions on the new JIRA... it's going to be deluged with the usual "You suck! Get a Life!  Why can't you just FIX SL?" junk. =)

Hopefully you will be ruthlessly draconian in stamping out "Certain Issues" with:

• "This issue has been closed due to its hostile content.  Being confrontational makes it difficult for us to understand and help you.  For best results, please use more neutral language when updating the JIRA. "

Maybe in addition to "Bug", "Enhancment", "New Feature" add "Tantrums"  (I'm sure a lot of mine will end up there.)   That'll give people some place to complain, without the pressure on you to actually fix anything.

--

la la laaaa laa laaa... I can't hear you when you're typing in that tone of voice ... la laaa laaaaaaa!!!

[#17]

Oh, has that been changed? It used to only mark the one that made the original post (in this thread, that would be you. )

ETA: Checked in another thread, and indeed, it does mark all Linden posts with a green-tinted background these days. Maybe it always did, and I didn't notice the slight color change. Would be nice with a slightly stronger color, though -- it's not really obvious as is.

[#18]

Yoz: "If you've got a sudden problem that's affecting you, and you're not sure  whether it's related to your account or your software, then please go  to Support, not the bug-tracker."

'Scuse me for bustin' chops on this Yoz, but are you talking about the same "support" system where we file a ticket, and either never hear a word... or receive an email six weeks later that says, "We're sorry we took so long to get back to you on this.  Do you still need help with this issue?"

Is it the same "support" staff that does so even if the ticket is something like "I can't log in any longer" or "Half my inventory is missing"... that Support system?   ; )

That noted... a new JIRA system is a welcome announcement.  But I'm going to withhold my judgment until I see it roll out because while I can't imagine a JIRA that is more user-unfriendly and cumbersome... I've come to realize that LL has a gift for turning merely cumbersome into a nightmare of code and even worse UI.

So we'll await this roll-out as we awaited the rollout of viewer 2.0... but perhaps not so eagerly this time. We'll see if Linden Lab actually produces a good product on this one, or if it's another design/coding nightmare created without discussing issues with the customers in any manner whatsoever.

Not meaning to be trite or mean; just laying it out there.  After watching what you folks did to the SL Market and Viewer 2... I'm not going to hold my breath in anticipation of a new JIRA system.  I hope it works well and maybe this time it will.  But our trust in the expected viability of such products has greatly diminished.

No offense intended.  Just being honest and providing truthful customer feedback.

Now that said, I am rather impressed with how you personally took the time to answer some necessarily lengthy comments point by point.   That's a rare treat to see from Linden Lab... and is in my book what separates the pros from the grunts. : )

[#19]

Pshaw... I slip out for a bit of time away and someone let's Wayfinder sneak back in when I'm not on guard?  Who's running this place?! ;-)

Seriously though, nice to see you snarking around again. =)

[#20]

Yoz,

I'll believe you're changing the JIRA -- and more to the point, the JIRA culture that is not conducive to effective governance -- when you unban me (and others) arbitrarily and speciously banned on false "speech offenses".

When I reported a bug concerning the destruction of objects by group members without permissions putting objects in share and returning them from parcels in violation of the design intention for group owner determination of deeding rights for objects, I was hounded out of the JIRA because certain Lindens and friends didn't like the implications for private property protection versus collectivization and collective builds in this bug find. A Linden who actually coded it admitted that it was a flaw in the design. But fanatics stuck to their guns saying it was "expected behaviour".

That really stubborn and persistent insistence on changing what people rightly find as bugs into "requested features we don't do" is anti-science. It's Lysenkoism.

And the mob injustice done to feature requests that don't fit with hacker culture that are about protecting business and property rights in SL is atrocious. There was a huge uproar when some copyleftists decided to advance their agenda by insisting on the ability to create blanket open permissions and set this to a default. Lindens tendentiously joined this. Interestingly, they never finished this despite pledging to do so. Good! Because it would open up the door to "liberating" all the content forcibly in SL and we don't need that.

If you want genuine feedback and genuine helpful features by thoughtful people, and bugs that are reproduced by people filled with concern and care for Second Life, you need to get rid of this outdated censorial mode from the Dark Ages. It's anti-modern. There are conflicting groups with conflicting interests in SL. You cannot wish away this fact. So it has to be managed equitably and fairly by a JIRA that allows people to make their case without fear or favour.

My appeal of this ban has hung for more than a year without action.

Open up your browser in 1.23. Note what it says in ABOUT SECOND LIFE. It says Second Life is brought to you by Philip Linden and.......Prokofy Neva.

Why? Because I've contributed many important *policy* proposals that became features that were implemented (ad farms and the right not to have your JIRA close arbitrarily to stop voting) and also contributed bugs (like the fact that objects named "Linden" could be muted).

It's a disgrace to Linden Lab that a paying customer like this is banned from the feedback channels. Systems that block feedback end up failing.

[#21]

The obvious danger, of course, is that if people learn that Linden's actually reply and answer questions on the new JIRA... it's going to be deluged with the usual "You suck! Get a Life!  Why can't you just FIX SL?" junk. =)

Ha! Yes, there is that possibility, but we're trying to be optimistic about the signal-to-noise ratio. :-)

[#22]

On various channels I have supported openness. Jira is the best tool for that when it comes to backlogs and bugs and I welcome any improvement on that. I request an easy to navigate menu structure so that bugs can be dropped easy. I request LL involvement in linking and finding doubles removing the need for the user to search and wonder (better a few doubles as one missed). I want to see an open structure so that everybody can find their bugs and requests, some metrics to see status and reports.

I don't agree with some solutions, something very demotivating and off-putting. If an issue can't be resolved, state it can't be resolved with some sort of motivation. Expected behavior isn't always the requested behavior.

The seperate log-in has proved to be quite usefull during some recent block in between the ISP and LL when only Jira could be reached. Please reconsider merging the log-in.

I would welcome a seperate comment area for the less-relevant chatter and ranting so that relevant comments are easy identifyable. With making Jira more accessable to the wider public that could be very usefull. Perhaps give the OP some moderation powers to maintain the comments.

Merging Support with Jira would be great provided attention is given to privacy info. I once had a search for a specific person causing Search to choke, would have been a bad idea to have that in Jira as such.

Thank you Yoz for your efforts.

[#23]

Now that said, I am rather impressed with how you personally took the time to answer some necessarily lengthy comments point by point.   That's a rare treat to see from Linden Lab... and is in my book what separates the pros from the grunts. : )

Thanks! But it's easy when you're dealing with ten mostly-positive comments, as opposed to a couple of hundred that are all over the mood spectrum...

Regarding Support, I hear your frustration. The work detailed in this post is part of an ongoing effort to have each customer request handled by the team and system that's best suited to it. In the comments above, Ceera and I talked about how what's also needed - and what we're already working on - is to catch and answer common questions before a Support staffer has to deal with them, so they can instead spend more time on requests requiring action. Ideally, the support requests that often end up in JIRA will go into the Support flow and be matched with existing answers, and this will also lighten the load on developer triages. In other words, we're working on making Support more efficient at answering tickets, and this is all related work.

As for withholding your judgement, I hear that as well and hope we can earn your trust. Improving our quality processes is a big part of that, and it's why we're doing this.

[#24]

I second the notion to unban Prokofy Neva from the Pjira. 

Yoz, I completely agree with Prok on this issue.  He should not have been banned from the Pjira.

If we are going to have a better Pjira, then let us also commence with better policies in regards to customers providing feedback.  A cooling off period is certainly better than a permaban to handle heated situations.

One of the biggest issues with Linden Lab policies about banning is that the customer is often treated like an underage gamer in a MMO... whilst LL wants us to think of SL as a platform in which to conduct business, education and social networking.  Even if roleplay can exist or games are developed within the platform, SL is not a game.  Linden Lab needs to stop setting double standards.  We are either a game or we are not.  There must be equally applied rules across the grid, no selective enforcement of the TOS. 

Outside these digital walls, we have disagreements in the work place and community both.. it is not unusual.  I'm sure even amoungst the ranks of the Labbies, you have your own quarrels.  Do you ban one another for articulating a difference of opinion or providing honest feedback?  Yet you want something less from your customers?

[#25]

I'm not against adding fun, but....

Hudson: Is this gonna be a standup fight, sir, or another bughunt? 
Gorman: All we know is that there's still no contact with the colony, and that a xenomorph may be involved. 
Frost: Excuse me sir, a-a what? 
Gorman: A xenomorph. 
Hicks: It's a bughunt.

I guess it all depends what you mean by "fun"

[#26]

PJIRA is ever so much more interesting with you in the mix...

I mean seriously.. who else comes up awesome comments like:

"I'm voting strenuously AGAINST this bad idea because it is merely a tiny sectarian effort to smuggle in the copyleftist agenda." - Prokofy Neva

My only stipulation, Prok, is that you must be limit yourself to typing with ONE FINGER while using PJIRA, so that the rest of us have half a chance to keep up with your devilish pace.  ;-)

[#27]

Sounds sort of neat. I don't use the jira because I log in very little. But I would like to add you could make it a bit fun by using graphics of linden avatars attacking little bug icons! Just a silly thought.

[#28]

LOL Hi Jopsy.  Great to see you're still around and kickin'!  : )

[#29]

Jopsy: ""I'm  voting strenuously AGAINST this bad idea because it is merely a tiny  sectarian effort to smuggle in the copyleftist agenda." - Prokofy Neva"

LOL.  I hope Prok takes your post with the humor it's intended.  Prok and I have had our moments of disagreement (and even online wars) but I'll say this: sometimes she nails the issue right on the head.  I've even found some of her most outrageous rants to be at times lucid statements of reality (such as the quote you just mentioned).  Prok and I are by no means "fans" of each other, but I think Prok likely has more of a deep-core handle on the SL experience than many LL managers.   Her wording may not always be to LL's liking (neither is mine for that matter... I'm pretty frank on these forums)... but there are often gems of reality in there that LL would do well to heed.  Prok was at SLCC (I wasn't able to be there)... which all disagreements aside, is something which gives indication of her great enthusiasm for Second Life.  (I even have a Prok quote on the Elf Clan website, believe it or not.  Yeah.. I know, I know...) ;D

[#30]

Vryl: "I second the notion to unban Prokofy Neva from the Pjira... Outside  these digital walls, we have disagreements in the work place and  community both.. it is not unusual.  I'm sure even amoungst the ranks of  the Labbies, you have your own quarrels.  Do you ban one another for  articulating a difference of opinion or providing honest feedback?  Yet  you want something less from your customers?"

I'm actually going to do the unexpected and agree:  unban Prok from the JIRA (with of course, the recognition by all of us that the JIRA is a professional tool... and to limit our more severe ranting to forums and blogs).

[#31]

Yoz: "As for  withholding your judgement, I hear that as well and hope we can earn  your trust. Improving our quality processes is a big part of that, and  it's why we're doing this."

You rock Yoz.  If this proves out in the pudding, it's a step in the right direction.  (Still withholding judgement... but hopeful...) ; )

[#32]

Prok: "when you unban me (and others) arbitrarily and speciously banned on false "speech offenses"... It's a  disgrace to Linden Lab that a paying customer like this is banned from  the feedback channels. Systems that block feedback end up failing."

I'm glad you brought that up Prok, because that touches on some main issues that need to be addressed in the JIRA (one of which someone brought out earlier):

1. Banning customers for simply speaking their mind

2. Treating JIRA like a "tech-ruled" system rather than a customer report base

3. Abuse of the JIRA system by antagonistic people (and I don't mean Prok)

4. Abuse of the "priority" level (an item that imo should be the perrogative of only the OP or a Linden)

Real account:  Quite some time ago, I posted a significant issue on the JIRA system... an issue that later was proved to be extremely valid (after several years Linden Lab discovered that yup, durn, the customers were right on this one... something that is happening with increasing frequency lately).

There were many other members who chimed in agreeing with the report.  But there was ONE user who personally felt the matter wasn't the "showstopper" level I had assigned it... and based on his sole opinion, changed it.   Someone else changed it back, telling him it most certainly was a showstopper issue.   He stubbornly changed it back.  Someone else changed it back to showstopper and told him to keep his grubby hands off.   He stubbornly changed it back yet again, ignoring what all the other users were saying and blatantly attempting to enforce his opinion on everyone else.

What resulted was a mini JIRA-war in which people complained to LL about such activity (with no response).  Lacking response, these people expressed verbal outrage at this person for basically "griefing" the JIRA (the guy was basically an uber-arrogant bonehead, not a griefer, but the results were the same).

Finally Linden Lab did step in... and their response was to move the entire JIRA to a forum and ban the majority of the respondents there from the JIRA!   (Unbelievable).   To make matters worse, the one person who didn't get banned was the clown who started the trouble in the first place!

As Prok experienced, appealing to Linden Lab to a ban of any kind is like talking to a brick wall.  I sent a 9-page certified letter to the company detailing the entire issue... to which they didn't even have the courtesy to respond (for almost a year).   Finally, I managed to speak to a Linden who had a little more common sense and managed to get the decision reversed... but I would bet to this day that several of the people who were involved in that issue are still banned from the JIRA system.

Forgive me for being blunt:  that is inexcusable management.

(Sad to say, I was seeing the exact same kind of attitude in administration of Xstreet abuses since it changed management.  I did file a JIRA on that... and to my surprise Linden Lab responded almost immediately with a fix on the new market in the form of a "comments flag" button.  So apparently this issue is known and recognized-- and my two-thumbs-up to LL for hopping right on that one).

Okay, that's the long story kept long.   For the other issues:

JIRA is the only avenue where customers can come report issues on Second Life.  Customers are not techs.  They don't always know how to create replicable examples of issues.  They don't always know the technical terms, or even how something is supposed to work... they just know that in their experience, it doesn't seem to work.

A business reality:  It is not the obligation of the customers to bow to the whims of JIRA administrators when reporting a bug.  It is their right, as customers, to report any bug, at any time, with the expectation of having that bug report examined for validity.   Customers should not have to jump through hoops to simply report a bug... which has been the primary complaint about the JIRA system.

Further... it should be understood by Linden Lab and JIRA administrators that it is expected when some customers come to JIRA, they are frustrated and upset and even angry... because something they need to work isn't working.   So on the "rare" occasion ; ) a customer pops up and says "This hasn't worked forever what is wrong with you people at Linden Lab I am sick and tired of this nonsense!".... it falls to Linden Lab to be sympathetic... ignore the anger and bile... and examine what the customer is reporting.  Professional businesses realize customers do get upset... and while it is the most difficult thing in the world to keep one's cool when being yelled at... such is essential-- especially in a "complaints department"... which is basically what JIRA is.  "This doesn't work".

So I would encourage Linden Lab to listen to what Prok says here, and what I've said, and what others have been saying for years... and change not only the JIRA itself (hopefully for the better)... but also the attitude in which JIRA is viewed by support staff.  "Banning" people from JIRA because they are upset (even if they're upset at LL employees) is extremely abusive company policy.  That is just adding fuel to the fire.

One thing I have always liked about Linden Lab, all other issues aside, is the company's extremely thick skin when it comes to forums and blog responses.  This imo, is Linden Lab's shining point-- and should be extended to the JIRA as well.  Yes, perhaps JIRA should be a bit more moderated (flag buttons on comments could come in handy, as has been recently implemented on SL Marketplace), but the concept is valid:  be prepared for customer ire.  It comes with the territory.  Resist the urge to be heavy handed.  Realize that JIRA isn't for the benefit and convenience of the techs... it's should be for the benefit and convenience of the customers.

[#33]

Some of you have asked me whether this means I'll be doing video tutorials for the new Issue/Bug Tracker AKA "PJIRA" (using consistent terms that are broadly accessible matters). I know many Resis found the visual sequencing of the previous vidtuts useful.

The answer is YES, I'm getting up to speed on the new system this week with Sue Linden's help... stay tuned!

Also, on the note of whether we can make bug-reporting fun, I know that for those who have a PAIN typing out step-by-step, I highly encourage getting screencasting software like Jing Project and showing a video bug repro. Saves time and also can communicate a lot more effectively, since it's like watching over your shoulder.

Related to what Yoz said, being able to both (1) clarify what each tool is for and (2) link them (so people looking in the wrong place have a smooth trip to the right place, as is the case with support issue) is ongoing and important...

[#34]

Ha! Yes, there is that possibility, but we're trying to be optimistic about the signal-to-noise ratio. :-)

The User Stories are the best tool in the toolkit for many things. This can be expanded and modified across many areas of user feedback. It still takes moderation, but it does set the pace ... keep feedback factual, instance based, personal experience, one per customer where applicable.

It's a gem.

[#35]

The changes sound good. Especially merging the two existing JIRAs, and making it more user-friendly. However, the real proof will be if customer issues get addressed in a timely fashion. Only time will tell on this.

My biggest concern is that it appears LL is moving toward a system that excludes the customer, in favor of the Open Source Developers. You have your Sprint List, but It's not very transparent as to HOW things make it onto that list. If it's simply whatever OS people want, you're letting your customers down in a big way.

[#36]

Yoz, lots of good stuff here.  But the thing that most strikes me is how daring it is of LL to merge the customer issue tracker (pjira) with your own internal tracker.  I've never seen that done, and it willl be fascinating to watch.  I'm curious as to whether you've spoken to other Atlassian customers who've tried that!

One thing that may help with this transition is for Torley or someone to find a way to set expectations as to what will happen when you create an issue in the Jira.  I think it's very reasonable for newcomers toJira to think that if a legitimate bug is filed, it will be fixed.  But if new features are ever added to a product, it is impossible to fix every bug.  Jira TRACKS bugs; it does not guarantee that they will be fixed.

I personally have two wishes:

1.  I hope you find a way to systematically link each feature request with a Discussion area (or even just Discussion thread) dedicated to them.  Productive discussion of new features cannot happen in the constrained context of a Jira report - it needs to be more free-flowing.  (Perhaps this is related to the User Stories concept, but I don't think so.).   I think the lack of such an area is one thing that causes distress to users who, like Prok, often want to float new ideas for discussion, or who want to "vote negative" on features.  I love Jira and have used it for issue tracking for years - but issue trackers are just not suited to extended discussions.

2.  If a feature is working as designed BUT users are writing up massive  numbers of reports, the issues should be converted to a documentation issue or the design should be reconsidered (new feature request).  It should not simply be closed. I know that the residents who devote time to grooming Jira are acting from selfless impulses, but they have been known to systematically quash emerging problem reports that LL actually NEEDS to see.

[#37]

I'm stunningly uninterested in seeing anybody unbanned from JIRA who still believes that it's for doing "governance".

It isn't. Get over it. No mater what you think you were told at the time it was originally rolled out.

But beyond that...

I'm vastly heartened that the new JIRA will at least be *capable* of being a two-way communications medium between the Linden devs and their customers. I can't possibly overstate how frustrating it is to raise an issue and have no idea what's going on on the other side of the wall.

In the past, something had to be *huge* to motivate Linden devs to double-post their progress to *two* issue trackers. The new approach at least will make it *possible*  for information to flow both ways.

This matters a lot.

Another suggestion: at at least some level in the support chain (and I've been a manager involved in developing and using customer issue tracking systems), don;t overlook the advantage to having your support personel trained in searching JIRA and creating their own JIRA issues on behalf of customers who aren't really schooled in diagnosing and formally describing software problems..  

If you do this, I think you'll be stunned at the increased quality of issues raised. Having "go file a JIRA" be an acceptable resolution of a support call when the customer is clearly unprepared to do so may make the support queue numbers look good, but you create another expensive problem on the other end when JIRA gets so full of crap issues that nobody can find duplicates or identify trending failure modes.  

[#38]

The concept of "editing war" should not even pertain. Closing shouldn't happen, and if there is disagreement about whether something is a showstopper or not, let people go back and forth as many time as they need to, each time citing their reasoning, and let it go. It harms no one if a status is changed 100 times or 1,000 times. People changing it back out of malice will quickly come to feel the heat of the rest of the community -- and by that I don't mean the "commuuuuunity" of precious coders, I mean everybody in SL who bothers.

For on, *it should not be possible to close a JIRA that you yourself have contributed*.

That's why I fought the very long and protracted battle of WEB-382 -- and won, or so I thought. Lindens opposed me, as did Linden fanboyz -- but then inexplicably, WorkingonIt came along and it was a "do" and then a "finished".

But...all that happened is that "resolved" which didn't really mean really finished (it was a Lab stop-gap) became the new "closed" that stopped voting.

The aggressiveness with which the JIRA jihadists want to close and change status of other people's constributions has to stop if this is to be a viable mechanism. Most of the heated verbal wars come because other people are trying to silence people's requests for features or interpretation of bugs and their seriousness -- and it needs to stop. Again, shield your eyes if the status put on a bug somehow bothers you and move on.

[#39]

It is for doing governance, and I'm stunningly uninterested in people who continue to think it's for their own clique's totalitarian cult. It's not.

The era when coders are the exclusive controllers of code is over.

Governance is exactly what is involved in suggesting features and flagging the importance of bugs or validating that they are indeed bugs.

[#40]

Okay.. .this is my THIRD time attempting to reply to this post... the blog ATE the other two and I forgot to put it in my copy buffer before saving it. GRRRRRR.

Jopsy: ""I'm  voting strenuously AGAINST this bad idea because it is merely a tiny  sectarian effort to smuggle in the copyleftist agenda." - Prokofy Neva"

LOL.  I hope Prok takes your post with the humor it's intended. -- wayfinder.

It is mostly intended to be good-natured ribbing... with a small barb of heart-felt criticism.

The issue I quoted from was over customizable default next-owner permissions.  This is something that people who create a fair degree of full perm content for teaching (among other) purposes, would really enjoy having.  I am one of those people that would have loved having this feature.

There was a very strong and legitimate objection to this proposed feature... People would forget, and then accidentally release their pay-for content too permissively.   That kind of mistake is nearly impossible to undo and it can be rather costly to a content creator.   Better to be overly protective and undo it than overly permissive and...  screwed.

But Prok resorted to the kinds of tactics we see in RL governance all too often.  She called into question the character, agenda and affiliations of the people that supported the request.   Eyes were rolled and the very legitimate technical aspect to her concern... well, it seemed like it just got lost in the noise.

Yes, I'm certainly happy to have a bit of heated debate in PJIRA, even if it occasionally gets personal and non-technical.  It livens things up a bit and keeps people motivated.... within reason. =)

[#41]

There is, of course, a simple solution.

And that is to follow my suggestion to separate the JIRA into bugs and features and put back the Feature Voter which worked absolutely fine until Angel Fluffy vandalized it and Torley Linden stealthily killed it.

The Feature Voter had, as one of its required steps, that you first put up a discussion on the forums. *First* discuss, and then put a link to that discussion. That was a good disciplinary measure as it helped remove duplications and got people to just think through the steps better.

[#42]

"and if there is disagreement about whether something is a showstopper or not, let people go back and forth as many time as they need to," -- Prokofy

Obviously we need clearer definitions of the priority categories so that this kind of argument is less a matter of opinion and more a matter of definition.

Personally, I wouldn't mind having it so only the requester can edit the priority of their own issue... and LL should have a separate priority that none of us can edit. (and left blank until someone at LL sets it)

"I think this button being too close to that button is a SHOW STOPPER" -- Joe Resident

"We think this is a low priority issue" -- Joe Linden

Others can use the comments to try to pursuade the requestor or LL to adjust how they feel about the priority of the issue.

Totally agree with the only-owner and LL can close an issue stance.  Absolutely.

[#43]

AGREED - nobody other than the issue creator and LL should be able to close an issue or change its priority. Other people can recommend such changes in comments but not to make the changes. This in itself would eliminate much of the JIRA warring.

AGREED - people should not be banned from JIRA.

However, some JIRA entries have a very poor signal to noise ratio, which has the undesirable outcome of making it either impossible or a huge timewaster for LL to determine what needs to be done to fix the issue. It would be good if there was some way to mark comments as useful or otherwise, so that the reader could hide the less useful comments and increase the signal.

AGREED - Trouble tickets are currently worse than useless. A concierge level member can at least use live chat (although this sometimes results in being told to raise a ticket which then goes un-answered for weeks). Non concierge level users can have issues preventing access to SL and receive no acknowledgement or resolution to tickets for days or weeks. We need some standards for time to respond to trouble tickets, triaged by the effect they are having on the user. Unable to log on or user id hijacked by another user should get immediate response.

AGREED - provide a way to create user stories for Snowstorm. Thanks Ravin for writing out the sequence of steps that got nowhere.

[#44]

That really stubborn and persistent insistence on changing what people rightly find as bugs into "requested features we don't do" is anti-science.

Software is not science, it is engineering.  Here, you are up against the software engineering industry's definition of the word "bug".  Your insistence on trying to redefine it is making you look strangely foolish, for someone so articulate.  If software is not behaving as the designer intended, it has a bug.  If software is behaving as intended, but the intention is not useful, that is not a bug.  It is a flaw in the feature definition, and the feature must be redefined in order to make it useful.  That redefinition is conventionally done via a "new feature" request.  LL is right in line with accepted practice.

There was a huge uproar when some copyleftists decided to advance their agenda by insisting on the ability to create blanket open permissions and set this to a default. 

Again, "copyleft" has an actual definition.  It is a type of IP license used to ensure that products which derive from freely available products (in the case of software, open source products) are also freely available.  (That is a simplification, but it actually broadens the definition rather than narrowing it; see http://en.wikipedia.org/wiki/Copyleft).  SL offers no permission inheritance scheme analogous to 'copyleft' licensing - nor was that at issue in the uproar you cite.

I mention this because you have often implied that open source advocates are evil - some sort of destructive grouop covertly intent on IP theft.  This conflation of two very different groups of people has always been distressing to me, and I think to many others.

[#45]

something of interest here is that they are "pruning" existing bugs.  Which was not mentioned here.  So If you have bugs that you concider important, insure they have been updated to indicaet they are still happening with the current viewer or server or any other category.  And if they have already closed them, complain.

[#46]

uh-oh.

That sounds an awful lot like what happened to the old Feature Voter on the old forums. Angel Fluffy was allowed to "prune" them, which meant he took out features he didn't like. Then Torley killed the entire thing off.

What really needs to be done is for some independent thinker to buy the JIRA software from the JIRA people, and possibly trying to convince them to give up their geeky doctrine that "you can't vote no" (they don't have this feature incorporated in their basic software, either), and then running it independently outside of the entire Second Life/Linden Lab/fan circuit fandango. As an independent mirror.

That would be incredibly interesting.

[#47]

Er, no, I didn't resort to any "tactics". Perhaps you assume that everybody commenting on public forums behaves like the people you hang out with on Sluniverse.com with various manipulative agendas, alts. etc.

I pointed out that the original poster and the original post outside of LL was in a setting that was lauding Electric Frontier Foundation and in a publication that takes the view that liberating content is the way to go and copyright is obsolete, and therefore it was part of an effort -- which EFF has repeatedly been part of -- to attack SL's light DRM and attack it's couplying of IP and commerce. And I'm right about that. It was.

Just because it's a "builder's boon' to a few people who want to fill a lot of boxes all at once with freebies "for the good of mankind" doesn't mean that it should be imposed on the world -- especially a world where people make their living by having IP tied to sales. There were very, very few builders on that JIRA. Those with the obvious liberation agenda were the ones pushing it.

Note that the Lindens didn't do it.

Do you know, on opensource dev you even find people wanting to put in a function to liberate perms even of everything already out in the world on a sim, or inside inventory still. It's endless, the pressure of the technocommunist agenda on SL.

Philip made it clear at SLCC that any copying of inventory to other grids will be done only of one's own creations. Educators and opensource advocates kept hammering and chipping away at this however and wanted to kill it.

Having this debate -- the degree to which Second Life should become a Stallmanite playground or a Randian regime or something in between with balance *is ok*. And it's important that those in the debate not hide their agendas and pretend their views are different than they are, or are only "technical" or are only "helpful" or are only "constructive" and that everyone else is "destructive".

There's no such thing as a non-political bug. Every single bug in Second Life is all about politics.

[#48]

I've never seen that done, and it willl be fascinating to watch.

I'm already seeing a very disturbing tendency on this front.

There are certain JIRAs people filed back even in February 2010. They wanted, oh, the chat chiclets to go away and become tabs. Or they wanted detachable menus to come off that sidebar thing in Viewer 2.0.

They made their case, outlined plans for it, collected a 120 votes on the case of the sidebar and...nothing.

Now that the Lindens are having their....perestroika...shall we say...they are coming along and putting in these fake things called "User Stories" on to the JIRA, signed not by people as individuals, not residents, but "The Snowcrash Team".

And then they proceed to put...the same JIRA that an individual had put before on exactly the same thing. So of course some one, usually someone rather braver, puts "duplicate".

And THAT is what I see happening. The Lindens will basically put up on the now-merged JIRA what they are willing to do as a kind of window on what they were doing. It will collect votes, or not. But it will basically become "where it's at". It will be hard for any non-team contribution to fight its way through, without, of course, putting the fix in by going to the office hours and chatting in the IRC channels and all that jazz.

I thought at first that the new merged JIRA would become an impossible hair-shirt for the Lindens. I thought it would set them up for impossible situations where mobs clamoured for action on...rendering of avatar foot shadows or something, um, vital like that.

Then I realized they'll play this like they've always played the BigListofThingstoDo (they're one-time system), the Love Machine, etc. -- with fake transparency.

I've probably said too much.

[#49]

Um, no.

What happens is that these "scientists" are ideologues, like Lysenko. And even if you're going to curiously say engineering is somehow less precise than science (!) it's not about imposing wishful thinking on a design, it's precisely about finding a flaw in the design, not working according to the higher-level rules. Full stop.

And they refuse to acknowledge something is broken or a design flaw if it doesn't fit some certain ideology they have.

If the group tool rules say that if I as owner *did not* give someone the right to deed an object and did *not* give them the right to return from the parcel *group-set prims* by not checking off the boxes on those group roles, and if they can go up to an object some other member in the group put in "share" and return it from the parcel *and destroy it* if it is no-copy *anyway* even though they are not supposed to have that power, *there is a bug*. It's *a broken thing*. It is wrong. It is *profoundly* wrong. Even the man who coded it admits that; that other Lindens can't admit it is very, very disturbing.

If you are a Linden or hacker saying "but I want to be able to return prims in a group build which is in share"  and therefore you write "expected behavior" and close the bug and call it a "feature request," then they are trying to impose a cultural and political spin on a set of rules. That's really scary. That's really *wrong*.

They are substituting the needs of their little edgecase for the whole public interest and undermining the rule of law.

Most people don't work on group builds and even communities don't put everything into share because...griefers get at it and put malicious scripts in it or break it up if the group is open or if they turn rogue.

This is all common sense and logic and defying it on the JIRA only highlights the unscientific problem at the heart of the "Lab".

Copyleftism is always and everywhere an ideological term, and the very notion of that license itself springs from a certain leftist ideology.

And indeed, in that JIRA, the notion that we had to have inflicted on the world dynamics and economy a blanket default permissions *requiring server-side code changes* was really disturbing. It was not a use case needed by any but the ideological few that want to run the GNU sandbox sort of stuff. Second Life passed that phase in 2003.

Be distressed though you may, the Emerald story ought to give you more reason than not to wonder if I am right in my critique of the opensource movement.

In any event, the JIRA should not be jerked to the extremes of this collectivist "free everything" ethos in a world premised on the notion of private property, i.e. server code, land metaphor on the server rentals, etc. Some Lindens know which side their bread is buttered.

[#50]

• Having this debate -- the degree to which Second Life should become a Stallmanite playground or a Randian regime or something in between with balance *is ok*. -- Prokofy

Agreed.  I'm not sure if PJIRA is the right place for that debate... but the debate itself is definitely good.  (Especially when it includes consideration like "Can both models co-exist in SL successfully at the same time."  But I digress. =)

• And it's important that those in the debate not hide their agendas and pretend their views are different than they are, or are only "technical" or are only "helpful" or are only "constructive" and that everyone else is "destructive". -- Prokofy

Agreed.  False pretenses and deception are unethical, distracting and counter productive.  They certainly have no place in a discussion over technical merit.  

But I can't assume that people will automatically understand my agenda if it goes unsaid... and I wouldn't want anyone accuse me of lying by omission... so how should I comport myself in the jira... Should I preface my comments with something like: 

• "Hi, my name is Jopsy Pendragon,  I'm a VAS (value added supplier).  My not so secret agenda is to improve SL's permissions system so that my component creations will be better protected from unlicensed re-marketing by the customers of my customers.   My ideology includes bits and pieces from Cynicism, Skepticism, Scientism, Egalitarianism with a dash of Kierkegaard-ism.... I may have been a technocrat in the past but I'm over it, my political leanings are ... I'm here to announce my support for this feature enhancement request pertaining to inventory search improvements.... "

Any bit of which could endear (or alienate) me from the Linden who reviews my report, and unfairly affect whether or not they take action or not.

And is it fair for someone else to 'volunteer' information about me that might arbitrarily improve or dash the chances of my issue getting addressed by Linden Lab?

I would assume that you, of all people (considering how you so vociferously decried the ?undemocratic? influence of the FIC), would object to anyone resorting to tactics that unduly influence the success or failure of various issues, especially when they directly affect the programmatical code which acts as our first layer of governance.

Sure, yes, it's okay to use PJIRA to wage war on competing property paradigms that are likely to pose a risk to our investments in Second Life.  That is definitely part of the political governance PJIRA deal. 

I just think that 'labelling people' in a PJIRA debate ends up unfairly cheating the process.

And yes, I still have a wee bit of idealism left in me.  I so very much want to believe that issues usually succeed or fail based on their merits for Second Life and LL's return on investment.  Nothing's perfect I know, but I still choose to be an optimist in this regard.

====================

• There's no such thing as a non-political bug. Every single bug in Second Life is all about politics. -- Prokofy

Noo!  Argh!!!  Absolute statements trigger my obsessive compulsive need to find a counter example to prove it false! 

Here's a bug --> https://jira.secondlife.com/browse/SVC-5399

How on earth is it it is "all about politics".   (Keeping in mind that it would still be a bug even had it not been reported.)  =)

(yes I know this blog is probably not the best venue for this discussion... but, dangit, I can't help myself. =)

[#51]

Prok: "The  concept of "editing war" should not even pertain. Closing shouldn't  happen, and if there is disagreement about whether something is a  showstopper or not, let people go back and forth as many time as they  need to, each time citing their reasoning, and let it go. It harms no  one if a status is changed 100 times or 1,000 times...."

"The aggressiveness with which  the JIRA jihadists want to close and change status of other people's  constributions has to stop if this is to be a viable mechanism. Most of  the heated verbal wars come because other people are trying to silence  people's requests for features or interpretation of bugs and their  seriousness -- and it needs to stop."

I find these two comments... in the same post... contradictory.  So I'll simply re-state my original position:

No one but the original poster and Linden Lab should have the right to change a project status.  Removing that ability for other users will eliminate a lot of the "JIRA wars" that happen because some heavy-handed, self-appointed "JIRA policeman" decides to impose his personal opinion over the opinion of the original poster.

The status of a project is an indication of how important this item is to the OP.  If Linden Lab disagrees, they can change such themselves.  It is the right of no other user to try to enforce their personal opinions on the issue.  This is akin to a non-moderator being able to edit someone else's post on a forum or blog; doing so would create extreme chaos... such as we have seen from time to time on the JIRA.  This needs corrected.

There are people who are better acquainted with the JIRA whom Linden Lab might assign as assistant-moderators.  They  should (as in pro-quality forums) be listed as moderators and could help  with such issues.  But one user thinking his/her personal opinion of  report status is more valid than the OPs?  No.  Chaos rarely brings  benefit, and open anarchy is not a path to peace and harmony.   Traditionally, leaving people to "police" themselves does not work...  especially in an environment where griefers can wield their keyboards  with anonymity... and simply harass others to fury.  JIRA as a tool, should not allow such intentionally-harassing activity as I witnessed by that user on the occasion described.