Second Life

Show Up: Your Guide to Helping to Improve Second Life

As you may know, Linden Lab has made a significant shift in viewer development through Project Snowstorm. Rather than the viewer being developed in a separate code repository from the open source initiatives, it will be the main repository for all future Lab efforts.

OK, but what does this mean for you, the Resident of Second Life? With a more open process for improving the Second Life experience, you can play a role too! It makes sense to solicit feedback from Residents, after all….they know the Viewer and can probably suggest a hundred improvements.

Well not to worry. Oz Linden needs your help, as he said at the recent Second Life Community Convention (emphasis added, and on video near the end of the session):

“I want everyone in this room to consider themselves to be a stakeholder. I want everyone in Second Life to consider themselves a stakeholder. And I want you to (voice rising) SHOW UP. I’m also going to assist that you’re civil about it frankly. I want productive, useful input, and if I GET productive, useful input we promise we will use it. We have office hours multiple times a week. SHOW UP.

Show up with something intelligent to say. Show up with something that you’ve actually thought about. Don’t show up and tell me we want Viewer 1.0 back. We’re not going back, we’re going forward to the future. We’re going to find new and better solutions to all the problems we’ve got together.

No flaming. Just come and do the job!

If we don’t do what you need done and you haven’t told us what it is in a way we can understand and use, then you’re at fault too.

Please help.”

So there you go – an invitation to DO YOUR JOB (on a platform many of you pay to be on, but you didn’t think you needed to simply pay MONEY did you?)

And an invitation to BE INTELLIGENT! And CIVIL! No idiots, whiners, mopers, or complainers, please. Have you been tearing your hair out for the last 3 years because of some bug fix that’s been sitting in the queue? Don’t bother – you clearly didn’t understand the process.

The Process
It’s really not that difficult to contribute an idea but it’s helpful to have some insight into the very quick, easy steps you can take if you’re one of the 80% of Residents who can’t make it to office hours (and if you can’t SHOW UP then maybe you shouldn’t be in Second Life – every Resident, after all, has an obligation to attach themselves to a Scrum team).

So first, use the handy wizard to make sure that the idea you have isn’t already listed:


Make sure you cross-collate the feature set request to the version number of the viewer. You may find it handy to quickly toggle the priority issues. Once you’ve figured out the proper filter to use, scan the listings to see if your idea for, say, a slight change to the “Snapshot” feature is already there.

Listings are easy-to-follow. It’s not much more complex than reading the table of contents of People magazine or something!

So, you’re ready to check whether your idea is already listed. If it’s an interface change, for example, simply read through the 1,605 matching issues. Don’t be discouraged by the fact that, um, 1,602 of them seem to be unresolved or unassigned – persevere! SHOW UP!

Check with the Product Teams

Now, please understand that Second Life is a highly complex process. It’s quite possible that your request for a change isn’t actually a change to the viewer, it’s a product request. Don’t confuse things you see in the Viewer with things that are done by the Viewer team!

Here’s a simple chart that explains how this works:

Good – so now you understand how the central development stream coordinates with the feature streams. Those feature streams are embedded within products, which are assigned to Scrums. While you may have, organizationally, one person who’s in charge of product development that’s monetized, you’ll have another group within the Lab who is in charge of, say, community segments.

Please don’t confuse the areas of responsibility related to product with the Scrum teams related to projects or sub-sets of the feature development. Also, please note that experimental features are often prototyped AHEAD of being fully developed as products and assigned to Scrums, so what may seem like a feature is often actually a use case.

If your feature is best described as something being covered by the product development efforts of one of the Scrum teams, you may want to first touch base with the Linden in charge of the product before liaising with the Scrum team. This will avoid the Scrum team needing to circle back to the Chickens, because the management of the product team is more closely aligned to the community team, and both report in not to the technology road map but rather the business road map. Also, please don’t bother the developers, because while they may be quite clearly engaged in a Scrum, they’re probably too busy on a sprint to take your suggestion in context.

But that’s fairly simple – and once you’ve assured yourself that your issue is both not in the tracker and does not more appropriately reside under a product team, you can now log your issue.

Getting Your Issue Out There

OK, so now’s the part where you SHOW UP.

Don’t be shy. But please don’t bring up issues that:

a) Have been reported

b) Can not be further reported without additional replication capabilities

c) Have been overly reported, because the presence of issues and ideas in volume is not an indication that the volume is indicative of any sense that it should be taken seriously

d) You have a solution for. (“Do not add comments about how to build a solution.”)

e) Are bugs

f) Are not expressed in a way that Oz understands

g) Are not productive

h) You haven’t thought about

i) Goes backwards.

Improvements Wanted!

But most of all, please do NOT suggest things that are not improvements. Oz was very clear about that – because it’s only IMPROVEMENTS that Linden Lab is after. And thankfully you don’t need to do any thinking or analysis because Linden LAB will decide whether your suggestion is an improvement or not.

But can you judge in advance whether the Lab will consider your idea to be an improvement?

This is the easy part!

Just ask yourself a simple question: you’ve seen Viewer 2.0, you know what the Lab’s idea of an improvement was – so would your idea have made it into Viewer 2.0??? If not, then don’t suggest it!

Only suggest things (locked windows, itty bitty chat chiclets, black interface elements) that likely would have made it into Viewer 2.0 and you’re probably sitting on a winner.

Actually, I’ve just confused things a little. Because interface ideas don’t really fit the format of submission. Your ideas MUST be phrased as a story and it should be no more than a sentence or two (no fantastic design suggestions please! There are waaaay too many people with Photoshop out there!) The story should follow this format:

As a resident, I would like to be able to make changes to what items of clothing I am wearing now by displaying the current list of items and selecting items to remove.

PLEASE, do NOT submit thoughtful assessments of what it takes to be a landlord, a merchant, a club owner, an event planner, a shopper or a creator. If you can’t break your thoughtful assessment of the overall experience of being in Second Life into a 2 sentence chunk, if you can’t show up at office hours, if you can’t figure out the difference between the Viewer and product teams well….then just remember:

“If we don’t do what you need done and you haven’t told us what it is in a way we can understand and use, then you’re at fault too. Please help.”


Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.