Yoz Linden

Curious Hazelnut wrote: 2) The editor built into viewer 2 still doesn't line up the cursor with the text you are editing properly on large files. This is very common for scripts and when writing instructions for new products. It is a huge problem when trying to edit what has already been written. This sounds like a nasty bug in our editor - do you know of a JIRA issue for it? In the meantime, there are some useful workarounds. As Hitomi said, you can now use external text editors to edit LSL scripts. If you have the "Advanced" menu enabled, hit "Show Debug Settings" then set the externalEditor setting to a command line for invoking your editor application of choice - for example, here's a command line for a non-existent Windows editor: C:\Program Files\JoannaLumleyEdit\joanna.exe "%s" (Note the "%s" at the end, in which the temporary script file is passed to the editor.) Now, when you open a script to edit, the viewer's editor window will have a new Edit button at the bottom. Clicking this button will download the script to a local temporary file and open your chosen external editor app. Every time this file is saved by your editor, the Viewer will notice and put the results back in the viewer's editor. I hope this solution makes things easier!

We decided to reconfigure the Viewer 2 forum setup, and in order to get it going quickly, didn't move and reorganise old posts from the old system. However, please feel free to criticise Viewer 2 as much as you like, as long as you stick to the forum guidelines while doing it. Also, speaking on behalf of the Viewer 2 team - which I'm not really a member of - making criticisms in a constructive manner will improve their chances of being addressed. Alternatively, go for comedy value. ("My Viewer 2 walks into a bar...")

We previously had consistency and security issues with people referencing external image URLs in posts. As such, any images to be included have to be uploaded to the site. Fortunately, it's pretty easy - just hit the "Insert/Edit Image" button in the edit toolbar, which will pop up a form that allows you to either upload an image or reuse a previously-updaded one.

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.

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.

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.

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.

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.

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.

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.

How do I get back a list of issues I've voted on? Try this query.

"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.

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.

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.

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.

As we described a little while ago, we're taking some major steps to improve our bug-tracker, jira.secondlife.com. We're making it faster and easier to use, more revealing of our ongoing engineering work, and - most importantly - better at helping us find and fix bugs. Today we completed the largest single milestone on our bug-tracking roadmap: the upgrade to JIRA 4.1. This was more than just a simple upgrade: as well as all the improvements that JIRA 4.1 brings, we've moved to new, more powerful hosting infrastructure. We've integrated the same login system used by the rest of secondlife.com. And we've installed the Greenhopper project management plugin so that open projects, such as Snowstorm, can expose far more of their roadmaps and schedules. It'll take a few days for the first projects to make their Greenhopper pages available, but once a project has one, you can get to it through the "Agile" item on the navigation bar. If you're interested in our bug-tracking process or already contribute to it, please go take a look. We hope you'll find it significantly better than what we had before. However, there are still tweaks to be done and problems to be fixed. If you find anything in the new setup that doesn't work as it should, you can file an issue about the bug-tracker in the bug-tracker, specifically in the WEB project, jira.secondlife.com component. (Using the bug-tracker to report on itself may seem dangerously recursive, but don't worry; we've hardly ever caused any wormholes in the space-time continuum.) One more thing, for JIRA regulars: As mentioned previously, we're also making changes to some of the workflows with which we categorise and process issues. Some of those changes were made two weeks ago. With this upgrade, we're moving towards another little tweak: renaming the Priority field to Severity and using it to describe the seriousness of effect that an issue has. This is for a couple of reasons: firstly, to reduce edit-war arguments by making the field topic a little more objective. (You can read the descriptions and criteria for the Severity field values on this wiki page.) Secondly, because Priority is meaningless as an attribute of a single issue; rather, an issue's Priority is its relative position amongst its peers, which is decided during project backlog review. The renaming of the field hasn't happened yet, since it requires tweaking of the underpinnings to be done after dust has settled on the upgrade, but in the meantime we've renamed the values that the field takes. Once again, we'd like to thank everyone who works with us through the bug-tracker to report and fix problems. With these and future JIRA improvements, we aim to give you a clearer view of how your contributions make Second Life better for everyone. Edited to add: Our screencast wizard, Torley, has created a couple of video tutorials which show off some new features that make JIRA use considerably quicker. Check out How to search the bug tracker and How to report a bug.

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.

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.)

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.

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.

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.