Heard That One Before, Part 2a&b

This is the second installment covering a series of statements that members of the Phoenix/Firestorm support team hear fairly often and that are more likely to pose barriers to troubleshooting than to help the process along because they point to misunderstandings about the way that viewers and/or issue-fixing works. For more of an intro, see the initial post on this topic.

We occasionally speak with users who need help with an issue and who, for one reason or another, decide to throw this in:

2) "A lot of my friends / people I've talked to / people in this group are having the same problem."

First, you don't have to use this to justify the importance of your issue. We'll help you if we can, even if you're the only person with a certain problem.

Second, if something is affecting a lot of people, you can trust our team to know that better than most. With thirty team members in English alone (more than twice that many when you include all nine language teams) each talking to dozens of people each week and to each other about them, we often find ourselves aware of grid problems even before the Lindens are. Certainly, we won't know the brand new ones right away. But if it's an issue prevalent enough for you to be able to say that "A lot of people are having the same problem" with accuracy, then yeah. We would know about it.

But the fact that we probably know it is not the reason this statement is in a list of things we don't need to hear. It's because of the oft-underlying implications, which may be any of the following:

 * "…so the problem's not at my end, it must be the viewer."

 * "…so why isn't it fixed already?"

 * "…so I must belong to a group that your developers don't care about."

 * "…and I need to tell you this because I'm more in touch with the wide world of Second Life than you must be."

Let's discuss these a little more. It's a lot to swallow, so this post will cover the first two, and I'll get to the other ones next time.

a) "…so the problem's not at my end." Maybe, maybe not. Just because it's common doesn't mean that it always has the same cause or that the cause is out of your control. And some people hate to hear this, but even if you didn't cause it, you're probably gonna need to do the work to fix it. Here's an everyday example:

Bake fail?* Server communications problem often aggravated by sim conditions, connection quality, and occasionally non-ideal viewer settings, among a bundle of other things. The most consistently common complaint, if not the most common, period. In the end, though, it doesn't matter where it came from; every known fix involves your active participation. And there's zip that can be done at the level of viewer development to prevent the issue.

So. Common issue? Hell yup. Viewer problem? No sirreebob. Something support can help you with? You bet your pretty little patootie, but only if you're gonna hold up your end of the process. Yeah, sorry, there's always a catch.

The conclusion of "so the problem's not at my end" doesn't start and finish with bake fail, of course. Denying that you can play a hand in the solution doesn't help the troubleshooting process. Sometimes we are accused of the reverse, trying to push "fault" onto users. Lemme tell ya something: I love it when I can identify a viewer bug. I want to be able to say, "Sorry, I can't do anything for you, it needs to be fixed in the viewer." Why? Because when it's true, it's a solid answer that saves me a buttload of support work. When I opt to take a closer look at causes and solutions that you, the user, can work on, it's not because I don't want to acknowledge that our precious viewers don't have problems (LOL); it's because factors that you have control over need to be ruled out before any progress can be made. It may turn out to be a viewer bug yet, but the work needs to be done to determine that. And "A lot of people are having the same problem" doesn't remotely qualify.

b) "…so why isn't it fixed already?" Dunno. Is there a bug report on it? This topic is a really good one for delving into the differences between the two main divisions of our overall organization: the support team and the development team.

If it's a problem that the "Why isn't it fixed already?" question even applies to, then it's not something support can control. If it is in fact a viewer bug, then we might be able to help you find workarounds, depending on the issue… but the only true "fix" would be the developers' domain. And for that you need to be filing and watching JIRAs. There's no alternative.

I know, I know, but you hate JIRAs. They're annoying to write, hard to read, prone to trolling by pseudo-know-it-alls, and you're not sure if anyone even looked at yours. Plus, some dev might come around and ask for more info, and then you have to do more work??? Pffbbt.

Or to put it as some do, you might be of the mind that "JIRAs don't work." Well, that all depends on what you expect them to do. They won't bring overnight change, but nor does complaining to the support team or trolling the group with "Why hasn't this been fixed yet?" All the JIRAs get looked at individually and eventually triaged. However, it probably won't go as quickly as you hope it to. Though it depends on the topic, support is usually fast; in comparison, development is sometimes really, really slow and is always affected by what else is on the docket. Something you report now might not be implemented for months. That's not the same as "not working." After all, it's still a lot faster than if you didn't file it at all.

I think one reason people are more likely to jostle support than file JIRAs is that they feel more comfortable when they have someone to talk to directly about their issue; if you can see the work happening, as you can in the kinds of issues that support can help you with, then it feels more real than if you have to wait ages for a release with your fix in it. That sense of comfort is understandable. I, for one, won't fault you for wanting that one-to-one contact, as long as you're aware that you can't speed up the bug-fixing process by talking to me. What I can do is help you get more comfortable with filing and commenting on bug reports. I'm happy to do that -- just ask!

If it's true that "a lot of people" have the same problem, then they'll appreciate you for it, too. As I said up top, there are other reasons we hear this statement. Tune in next time for a couple more.

* "Bake fail" is the term for a broad category of avatar rezzing problems. Some use the phrase just to refer to avatar texture rezzing; others include failure to load body parts as well. The broadest definition may include: ruthing, clouding, avatar partly or fully transparent, blurry textures, textures not changing, looking different to yourself from how you look to others, etc. Prim attachment problems are not included. Fixes can be found on our wiki pages, for Phoenix and for Firestorm.