[Improving our Lines of Communication with the Community]

Wait, so… why not add the ability to vote against something, instead of removing voting altogether?

For several reasons:

Firstly, this doesn't address Oz's original point about the relative insignificance of even high vote counts compared to the size of the user base overall. It's usually a small enough number that it's easy to game. In terms of data we use to make a decision, vote counts are among the least helpful stats.

Secondly, and more importantly, it's because the decision-making around a huge number of JIRA issues is more complex than simply "yes" or "no".

We often find that solutions to an issue requires more design work than us just saying "OK!". (Examples: Which of these potential solutions is best? If we choose this solution, who's negatively affected? Is this a symptom of a wider or different issue?) Issues rarely have one simple route to resolution that requires no further discussion, so simple "yes/no" votes are pretty much useless. What we need are customers who will represent interested parties in helping us reach the best solution by providing constructive answers and arguments.

The count of Watchers is useful to us in terms of guaging the number of  people so affected by the issue that they're staying in the conversation  around it; this helps us judge which issues are "hottest", but doesn't  allow the system to be gamed towards a specific resolution. It also shows us that we have more people willing to help us design a solution.

[Making Strides to Improve our Customer Support Services]

Premium accounts do not lose their inventory if they are delinquent and non-paid for several months.

Really? When did that change? Where is that documented, in writing?

 

This was a problem that was fixed over a year ago, and documented here.

[Introducing the new JIRA]

Further to previous discussion and requests, the link colours have now been changed: Nav bar links are white, and main body links are a much darker green. Let us know how it looks! As with most of the JIRA work going on, thanks go to our fabulous JIRA Mistress, Sue.

[Introducing the new JIRA]

Edit #3:  I am consistently getting Javascript errors when attempting to vote on issues, and thus cannot. (For the record, I'm using Opera 10.62 Build 3500.)

I'm not sure why that is, but if I had to take a wild guess I'd suspect Opera rather than JIRA in this case. It's possible that a later Opera version may fix it.

Meanwhile, note that there are (at least) two different ways of registering a vote: Either click the checkmark next to the vote count on the right hand side, or choose the "Add Vote" item under the "More Actions" menu button. It's very possible that neither works for you in Opera, but it's worth a shot.

[Introducing the new JIRA]

Erm, I didn't enter Jira, I entered Red Hat Linux Test page at https://jira.secondlife.com/.. hehe.. You need to bang some harder Yoz.

Yoz banged on something. It's fixed now. Ty Yoz. Looks cool! Ty Torley for the amzing Jira tuts!

It wasn't me who did the banging in this case, but I'll pass it on.

[Introducing the new JIRA]

Best of all, my bookmarks to specific issues now take me to ... the dashboard! Very helpful! Especially when the issue I bookmarked isn't on it! Awesome.

Ah, this may be the problem you're experiencing - the first page view of a session will redirect you to the dashboard, but all later links in that session should work. Fix in progress.

[Introducing the new JIRA]

Thanks for pointing that issue out - I've marked it Released (which is the new "Resolved - Fixed"). (Edited to clarify: "Fixed" is still a resolution, and applies here. "Released" is the workflow action and status.)

For the moment we're limiting the ability to resolve issues, but we may open it up wider in the future.

[Introducing the new JIRA]

How do I get back a list of issues I've voted on?

Try this query.

[Introducing the new JIRA]

"Released" is now "resolved?" Really? What IS is with you people and changing things that don't need changing? How does "released" make sense with a bug in something that's already released? You don't release a bug, you resolve a bug. You release a bug fix, and just because a fix is in doesn't mean it's been released, does it? Why add confusion to an already fairly complex thing? WHY?

I didn't explain this very well the first time, so let me clarify: There are multiple resolution types for issues, and always have been; examples are "Fixed", "Cannot Reproduce", "Duplicate" etc. So "Resolved" is still there, and means exactly what it did before. "Fixed" is still there too. What we've done is change the arrangement of statuses and resolutions. Choosing the "Released" action sets the status to "Released" and the resolution to "Fixed". For more information, take a look at this wiki page. These changes were driven by problems with the existing workflow; we're not just shuffling this stuff around for the sake of it.

The old JIRA had a very business-like look to it. This looks like ... well, the rest of the web properties. Not business-like. More, social-networky-like, except harder to read. Not everything needs this goofy green and ultra-thin font, you know.

I'll see what we can do about the light green links on a white background (both on JIRA and elsewhere). As for the font weight, it's standard, though the point size is a little bigger.

Changed the emails too? Now I get to change my filters? Thanks! Not.

Nope, it was a temporary glitch and is now back to previous settings. See my comment above.

Best of all, my bookmarks to specific issues now take me to ... the dashboard! Very helpful! Especially when the issue I bookmarked isn't on it! Awesome.

We try to ensure that all existing inbound issue links continue to work. I thought we had this covered, but if you have a repro example, we'll take a look.

I'm NOT A FAN, Yoz. I don't mean you, I think you're alright   ... but these cosmetic changes were unnecessary, and are not an improvement. Can't you guys ever accept that when something isn't broke, you don't need to "fix" it?

As said above and previously, we've made these changes to bring about multiple improvements, many of which had been long-requested both internally and externally. The major changes are part of JIRA 4.1, an upgrade that was necessary for much of what we're doing to improve our bug-fixing efficiency. The new UI is faster and cleaner; certainly, the new UI and keyboard shortcuts make a big speed difference when working with issues. Bear in mind the #1 reason why we're doing this: we want to fix more bugs faster and more transparently. This is far from the only work that needs to happen for that, but it's a big step towards it.

[Introducing the new JIRA]

Yoz, is there a way to set the subject of the email notifications back to instead of ? I adjusted my mail filters but now also offline notifications like group notices land in my JIRA folder...

Whoops, sorry about that - fixed! All emails will have a subject prefix of from now.

[Introducing the new JIRA]

From sl.com, to help=>issue tracker, Wiki issue tracker=> link to the Jira (i.e. the normal path for us)

Next a big and huuge ultra mega warning from Firefox that I'm enterering an insecure connection. That's new for me. Have to click on I understand risks, and add exception to continue. It doesnt trust the certificate, it belongs to another website?

Erm, I didn't enter Jira, I entered Red Hat Linux Test page at https://jira.secondlife.com/.. hehe.. You need to bang some harder Yoz.

Sorry about that - we had a problem where the HTTPS service was using a bad cert. It's fixed now, and both HTTP and HTTPS should work fine.

[Introducing the new JIRA]

First thing I noticed when clicking the link to the new Jira is a redirect page. Had to click another link either to go back or go on to the Jira. HUH?

Whoops - sorry about that. My fault when copying links around to create this blog post. Fixed.

What the heck does Agile mean anyway?? Are people who don't read the blogs expected to know where to go to find the information contained in there?

That could probably be named better - I'll see what we can do.

[Check here if you want more options]

If you (and LL) want to take one BIG step towards gaining trust, continuity and respect I would suggest you do the following:

1) Download all TPVs and make a list of the features they have.

2) Extract all viewer related jiras.

3) Make from this a list on which everything from the above is mentioned (save the impossible ones).

Please see the Snowstorm project backlog, because it's made (and still being made) by doing the above. That backlog is what the Snowstorm team has already started working through.

[Check here if you want more options]

The V2 UI is what drives the most away, the sidebar is for many users a just terrible thing, its big, uncharming, all is pressed into, the functions are harder to use, and so on.

This is why one of the first bits of work that Snowstorm took on was to make the sidebar detachable, and give users more control over how it's arranged and used. That work is nearly done, and you'll see the results very soon.

Snowstorm has plenty of work lined up based on the feedback we've been hearing from customers, and the successful features of other viewers - take a look at the project backlog to see what's coming. (Note that the main chunk of the backlog - below the first 7 lines - is not arranged in any kind of chronological order.)

[Check here if you want more options]

Your saying that by ignoring the changes your customers want, it will be quicker and easier to get through QA, and that will mean you being more responsive to your customers... yet how can you be responisive to your customers if your ignoring them in the first place, just so you can make QA quicker and easier???

That's not what I meant at all; sorry if it was confusing.

We don't want to ignore the changes that customers want, just the opposite: we want to make more customer-requested changes, and faster. Helping QA to be as fast and easy as possible is both a vital part of achieving that, and vital to ensure that changes don't introduce new bugs.

[Check here if you want more options]

Naturally, there needs to be a good ballance. But if there are doubts, customer satisfaction should win.

I absolutely agree. What I'm talking about is the part leading up to the doubts: is the requested change worthwhile? Like most work, this is a costs-versus-benefits judgement: The costs are the time and money spent on designing, developing, testing and maintaining a change; the benefit is (amongst others) the increased customer satisfaction.

What I was trying to say was that testing and maintenance are a far higher cost than many people think, and if we can bring those costs down, we make it much easier and quicker to make the changes that people are asking for. The way we bring those costs down are by making those changes in a way that adds as little complexity as possible. I'm not raising QA cost as an issue because we're lazy; it's because we want to be able to do more of what people are asking for.

It's off topic here, but from some of the JIRA comments from the Marketplace team I got the impression their primary goal was to write as little code as possible. Generally speaking, if thousands of users suffer because one programmer made his life easier, there's something wrong. Don't let that happen with Snowstorm, please.

If the goal of the Marketplace team was really to write as little code as possible, we wouldn't have a Marketplace; we'd have a Desktop Tower Defense high-score table. The goal of the Marketplace team, like any good software engineering team, is to write as little code as possible to meet the project requirements. These requirements may change as time goes on, and as feedback comes in. (Pretty much every bug report can be categorised as either "This code isn't meeting this requirement" or "Please change the list of requirements") But "less code" is a vital tactic in software development. Less code* means less complexity, less friction for making changes, easier test coverage, and fewer hiding places for bugs.

* "Less code" has an implicit "written sensibly" after it, to fend off the inevitable arguments.

[Check here if you want more options]

Your primary goal should be customer satisfaction, not making code maintenance/testing easier.

The former gets a lot easier with the latter.

Right now, we're hearing that folks want a lot of code changes to v2, ranging from the behaviour of the sidebar to chat focus to attachment behaviour, etc. etc. etc.  Every code change we make needs to go through QA. The easier and more reliably we can QA our code, faster we can iterate, and the lower the probability that those changes will introduce new bugs. This means more responsiveness to customer requests and higher satisfaction.