This post is part of a series on common barriers in communication when it comes to getting help for problems with Firestorm Viewer in Second Life. The series starts here.
9) Can't you just get the devs to do it?
Pffft. I wish.
"You there, dev. You got nothing better to do? Well, this random user wants me to get you to drop that project you're already in the middle of and work on the issue they think is more important."
Yeah…no.
There are two main reasons people ask, "Can't you just get the devs to do it?" One is that they don't want to file the bug report or feature request on it themselves for any of a variety of reasons (lacking in self-confidence, hate the JIRA, simply lazy, etc.). The other is that they think that a support person will be more effective at "getting a dev to do it" than they would be because we have "connections."
Both reasons are based on misconceptions of the process and our team's structure.
How It Works
The two biggest misconceptions that shape these problems have to do with 1) the process and 2) its pace, and these misunderstandings feed into animosity about or reluctance to engage in reporting bugs. Just a hunch, but I suspect that those who know more probably have more realistic expectations.
So we'll start with how bugs that you find or features that you want normally get implemented. I'll refer to bug reports here, but feature requests actually follow the same process.
In almost every case, it starts with a user submission at http://jira.phoenixviewer.com/. Now… a number of people who've delivered the "Can't you just…" line seem to argue, "But there was this one time when I mentioned this thing to a dev and it happened right away. I didn't need to file a JIRA then, so why should I have to now?" That's going to be an exception, not the rule, and most likely, the dev did it either because they were already planning to do it or because someone else filed a request for the same thing. If you look through old issues, there will most likely be one there that matches yours.
 |
| http://jira.phoenixviewer.com/ |
And so, it starts with a bug report on the JIRA. The issue will get its first look pretty quickly. A few people on the team look at new issues daily. They'll ask for additional info if necessary. They'll link and close issues that are out of scope or duplicates of previous reports. They'll move issues to the support section (not publicly visible, but you'll be able to view your own issues there) if they aren't true bugs. After that, though, it's time to wait.
Depending on the issue, it may sit for a while. Some sit for only days, others for months and months and months. This doesn't mean the issue has been lost, that it will never get implemented, or that it isn't getting looked at on occasion. All it usually means is that there is no developer available at the moment who has the time to work on that specific issue and knows what needs to be done to implement it. That's actually pretty straightforward when you think about it, right?
After an hour, a week, a month, or a year, it may get assigned to a developer. That developer will work on fixing the bug for however long it takes, given the complexity of the code, their real life and SL schedules, and their other development workload. After another hour, week, month, or year, they'll finish the code, mark the issue as fixed or completed, and add it to the viewer repository (the big code collection that comprises the viewer).
Once the code is in the repo, it waits to get tested. Since Firestorm's releases are usually about two to three months apart, it might take even more time before that bug fix actually shows up in a publicly available version of the viewer, but the status can be tracked in the issue you filed. If it passes QA (quality assurance), then it will be included in the next release.
And voila, that's the route from issue to fix.
How long can you expect it to take? Well, over Firestorm's history, the average time from issue creation to issue resolution has been about 73 days, though specific issues have taken anywhere from one to 535 days. As far as I'm aware, that's not an unusual pace for software development, especially when the developers are doing the work in their free time. I include these numbers to provide some perspective. Some people "hate the JIRA" because they think it "doesn't work," and they base this assumption on the fact that the bug they reported last month hasn't been fixed yet. It's like refusing to use a car because it doesn't fly. Or teleport. Patience, grasshopper.
And there's always the duh factor. Although 73 days might sound like a long time to wait for something you think you need, guess how long it will take if you don't file at all? Go ahead and hold your breath. I'll let you know when your face turns blue.
"Connections"
The more laughable reason we hear "Can't you just get the devs to do it?" is when folks think that if the request comes from someone on the team, it will hold more weight than if they do it. In some cases, they think that we have so much weight that we wouldn't even have to file a JIRA for it -- that all we need to do is ask. I even got into an argument once with someone who wanted Jessica Lyon to file a JIRA for him because her voice would have the most pull. And she should do this favor for you… why, exactly?
To address the idea that we don't have to file JIRAs: We do. Everything gets filed. If we have a feature request, we file it. If we spot a bug, we file it. Developers file JIRAs for other developers to work on. Developers file JIRAs for themselves to work on. And if a developer has already done work on something, they'll file a JIRA retroactively so that it's documented for the testers.
The JIRA is a to do list and a record of what has already been worked on. Literally no one is spared from JIRAing.
As for the "connections" perception, well… it's an odd one because it's more skewed than it is completely wrong. But it's a weird interpretation of our actual team dynamic, and the weirdness feeds into why saying, "Can't you just have a dev do it? You're the one with connections," won't get you very far.
So… yeah, I know the devs. I'm in contact with them all day in our various inworld and out-of-world chat rooms. We have a whole virtual office going on. With that frame of reference, would you say the shoe department has "connections" with the furniture department? That patents has "connections" with accounting? That obstetrics has "connections" with oncology? We're just different departments on the same team. When we work together, it's not about pulling strings, it's about collaboration, as teams do.
We don't schmooze with devs, we work with them. And when we have issues we want looked at, we file JIRAs. Indeed, if we asked the devs for "special favors" for everything we wanted, let alone all those we are asked about, our working relationship would sour very, very quickly.
Making it Work for You
Admittedly, filing a JIRA is easier said than done. I can repeat the mantra til kingdom come and some people will still avoid it like syphilis. Let's talk about the legitimate concerns and how we can help you with them.
"It's designed for people who aren't me." Would it make you feel better if I said that's how I feel about Facebook?
"I can never find anything on it." The search functions actually became easier to use lately with a platform update, but I agree it can still be confusing.
"I'm afraid of putting something in wrong and ruining my chance of getting my issue looked at." Been there myself, so I'll try to quell the fears.
Yeah. A large chunk of it feeling foreign and uncomfortable is just that it's foreign and uncomfortable. The fact that it appears jargony and techie and scary can intimidate some into thinking it's hard to get used to, but it's really no worse than any other platform when it's new to you. The biggest difference is that when it comes to the JIRA, you have a team of support people standing by to answer your questions.
There are three ways you can learn about how to use the JIRA:
- Reading and following the wiki page on how to file a JIRA;
- Attending the Reporting Bugs, Requesting Features class we hold inworld (class schedule updated progressively);
- Asking a member of the support team -- not to do it for you but to explain anything you don't fully understand.
 |
| http://wiki.phoenixviewer.com/file_a_jira/ |
If you're just trying to find your way around, either the wiki page or the class will work well for you. If you're specifically having trouble with the search mechanisms, come to the class -- we give some tips on that, with visual aids. If you're worried about embarrassing yourself by filling the report out wrong, either attending the class or seeking out one-on-one help is probably best.
We're used to seeing errors in the JIRA, and we can edit your ticket if the errors create ambiguity. We'd rather have a shabby JIRA from you than no JIRA at all.
I should note that on some occasions, support people will do a JIRA themselves based on your complaints or comments, but this is most often the case if it's a bug they can reproduce on their systems and that they think they can describe best. It's not as common for feature requests, and if the team member can't reproduce the bug, they're not going to be the best ones to file the report -- you are. Furthermore, it's a case-by-case matter even when we choose to do the filing. If you have a bug that takes place only in Mouselook, for instance, I'm not going to file it for you even if I can reproduce it: I don't use ML regularly, and my familiarity with its quirks is probably limited to what you've just told me in our conversation. I wouldn't be able to describe the problem as well, and if a dev asked for more info, I'd be totally useless.
Fact is, you are the expert on your own experience, and in most cases we need to hear it from you when things are not right for you. Finding and reporting bugs is a collaborative responsibility. You are entrusted to take part in this process, and we'll do our best to show you how.
