For those new to the game, JIRA is a product by Atlassian that helps software developers keep track of a monstrously huge pile of bug reports and feature requests. It helps organize issues in relation to each other so that the huge pile of information can be presented in an intelligible manner.

Linden Lab has used JIRA internally for a long time, and this year, with the advent of their open source client, they opened a new instance of JIRA to the SL public, called the “Public JIRA” or “PJIRA”. It’s for us in the community to track issues that affect SL, provide technical information, and help fellow residents by providing more information on the bugs they report. It’s a HUGE step forward in allowing the community to communicate with LL, and I really want to see it succeed. Before this, all we had was the Bug Report black box, and we had no idea if LL had even read what we reported.

Drama Ensues

There are two points to making the JIRA public: to allow communication between LL and residents about bugs to be public, and to allow residents to collaborate on bug reports, thereby enriching them. It’s that latter that causes the most drama.

Here’s what happened:

• Prokofy Neva reported VWR-3071.
• I commented on the report, giving my opinions on the matter.
• Separately from that, I also resolved the issue as per LL’s Issue Posting Guidelines, pointing out that the issue should be reclassified as a feature request.
• Prokofy went nuts because I “unilaterally closed” his issue. He reopened it.
• Prokofy opened MISC-799, a thinly veiled attack on my action in the guise of a request not to allow me or others to ever modify Prokofy’s issues.
• I pointed out the link to VWR-3071, and also moved the issue to its proper classification, WEB-382, since it was an issue about jira.secondlife.com.
• Drama ensued.
• I did my best to provide justification for my actions, and then I ducked out of the thread because I’ve learned in the past that it’s just not possible to out-talk Prokofy.
• The issue was addressed in the 2007/11/19 Bug triage. See transcript, starting around [12:15].
• That leads us up to now: The Lindens have decided to ask Prokofy for examples of abuses in JIRA that have caused problems; read this, this, and this if you’re interested in those examples.

Collaborative Editing and Accountability

My strongest feeling through all of this is frustration with Prokofy’s notion of “unilateral action”. He seems to feel that my “closing” of VWR-3071 constituted a unilateral decision to silence his speech, which it wasn’t. The Issue Posting Guidelines make it pretty clear that “resolving” an issue, especially for resolutions like “Needs More Information” is to be taken as a direct request that the author take more action and then reopen the issue if appropriate. In my comment at the time I resolved VWR-3071, I even gave an example of what Prokofy could do to fix the issue, which is considered good practice.

The thing is, even if I was wrong, the right thing to do would be to reverse my action. Simply reopen the issue and no harm’s done. I’m perfectly willing to hear that I’ve done something wrong, or that the rest of the community doesn’t agree with what I’ve done. If we had to run around getting votes from everyone in the community or approval of the reporter of an issue before the issue could be modified, then we’d never get anything done. On the other hand, if we leave things open, but keep track of everything everyone does, there’s a strong incentive to make sure that you’re NOT acting with impunity, because doing so will only result in your changes being reverted and your reputation suffering.

That’s the key here: this JIRA, like Wikipedia and many other collaborate projects, work on a theory that many people, working loosely and with little organization, can together shape something that’s bigger and better than anyone can do on their own. LL is simply too small a company to individually police the flood of JIRA issues (many of them inappropriate or filed in the wrong place) and shape it into a useful body of information. There’s just too much information for any one person to handle. We could try to elect a “president” of JIRA who we all were happy with and trusted to manage all issues, but the result would be unsatisfying. It’d be impossible to find such a “president” that everyone would be happy with, and even if we did, there’s just WAY too much information for one person to handle. The fact is that one vision can’t succeed.

Democracy can’t, either. We can’t make JIRA democratic, for the reason I stated above: we’d tie our own wrists. There’s just too much to be done, and voting takes too long. Nothing would ever get done. JIRA would topple in a mess of beauracracy.

The solution we’re trying now is collaboration. It’s just like how ants work: scientists are pretty clear on the fact that no one ant has any concept of the structure of the anthill as a whole, not even the queen. Instead, they have basic rules about how they’re supposed to act, and the result of getting a lot of ants together following those rules is that an anthill is created. Scientists would say the anthill “emerges”.

The idea is that we all do a little work here and there, making changes as we see fit, in order to move JIRA as a whole one small increment toward greatness. What about rogue elements? Well, just like in the body, where cancer cells are eliminated on a regular basis, rogue elements in JIRA are quickly subverted by the will of the community as a whole. I could run around closing issues I don’t like, and 20 other JIRA users will run around just behind me, reopening them and building a consensus that I’m being a jerk. Pretty soon I’ll find myself kicked out of the pool. It’s a pretty good system.

The problem is that Prokofy doesn’t agree with the community that runs JIRA, as a whole. He has said over and over that JIRA is frequented by a “cabal” of users that think we speak for the community as a whole, when in fact we’re just speaking for our own bloc. While I feel that JIRA is egalitarian because any SL user can wander over and make changes as they see fit, Prokofy feels that we regular users (“lifers”) occupy a privileged place in the SL community because of the time we devote to JIRA. His feeling is that, by spending hours a day on JIRA, we see our opinions gain an unfair weight because we’re exercising them so often. And he also seems to feel that only a certain kind of person (ie the “techie crowd”) will spend this much time in JIRA, so only a certain kind of opinion will shape JIRA. It’s like a voting bloc. [Note: Prokofy, if I’ve unfairly stated your opinion here, let me know.]

It’s a fair criticism, and I admit that it’s a possibility in a system like this. However, I don’t think it applies in this case. Generally, I try to act in as unbiased a manner as possible, and give reasons and suggested actions when I change or resolve an issue. When I’m not sure I should make a given action, I propose it in a comment rather than doing it immediatley. I haven’t done these things enough in the past, and I’m going to do them more in the future in hopes that I can avoid the kind of drama we’re seeing now. I also don’t think the users of JIRA are exercising any kind of groupthink. There are widely disparate elements that are frequently seen in JIRA, and these people regularly face me head-on and disagree with me. I appreciate it. It helps me do a better job in the future. Thanks, Mercia McMahon!

While I agree that Prokofy’s theory is a possibility, I don’t think that merely stating the fact makes it true. It’s fairly clear to me that Prokofy likes to build up theories of secret cabals of people that are out to influence Second Life to their own selfish ends while ignoring the good of the community as a whole. I don’t think such cabals really exist; rather, Prokofy has a hard time understanding that what is obviously correct to him may not be how everyone else feels. He builds theories of secret cabals to explain why people act the way they do, rather than understand that maybe what he takes to be a fact is just his opinion.

There’s just one way that the JIRA system does filter who uses it, and that’s the interface. This is a tough problem. The fact is that there are many issue trackers out there, and that the vast majority of them just aren’t up to the task of organizing such a vast body of knowledge as that seen in LL’s PJIRA. The JIRA tool helps us perform critically important tasks such as linking issues together as related or as duplicate issues, searching for and categorizing issues based on myriad criteria, and facilitating voting and discussion. I’ve used a lot of issue trackers in the past, and JIRA is hands down the best tool for the job. Without it, we’d spend way more time trying to organize information, and way less time actually doing useful work on concrete issues. In short, without JIRA, we’d waste a ton of time.

On the other hand, JIRA is, by its nature, geared toward technical users. It works GREAT for us. It’s designed by technical people, for technical people. It does exactly what we want in a way that makes sense to us. The problem is that this runs straight up into the first principle of User Interface design that I learned in college: “You are not normal”. In short, when designing a user interface, what the programmer likes is very likely not to make a bit of sense for non-programmers. This explains why a vast majority of computer interfaces are still horrible for most users, and why computers are hard to use for many people.

So the problem is that the JIRA interface itself acts as a filter on who can use it. This sucks, because it’s such a useful tool otherwise. Where Prokofy and I disagree is in what should be done about this. He thinks that everyone should be limited from using PJIRA so that the playing field is levelled. I think that LL should do a ton more work to simplify the interface presented to PJIRA users so that they are better able to participate. Prokofy’s method means that we lose all of the progress we’ve gained so far. Mine means that we keep all of our current progress and gain much more from all of the new users with different backgrounds.

Until then, it’s up to us who easily understand JIRA to reach out to those in the community. Provide links to important issues in forums outside of JIRA. Explain to people that logging in and voting is important, and commenting is useful as well. INCLUDE people. Remember that you are not normal.

That said, I hope that the rest of the community realizes that I’m not some kind of tech-minded automaton. I’m highly technical, but I’m also very concerned about social and economic issues in SL. I make my entire living in SL. It’s in my interests not to bury economic issues in JIRA. And I don’t spend my life in JIRA. I spend about 20-40 minutes on average per day, and I do it because I like to keep track of new issues in JIRA that might affect my business and my job. I clean things up while I’m there because it’s a little bit that I can do to help out. I definitely don’t have hours a day to spend on this stuff.

Open Letter

Well, I just said way more than I thought I was going to say. The problem with Prokofy and me is that we both have very forceful personalities, and we both type a heck of a lot. I’m the kind of person that wants to call people on their bullshit, and won’t back down just because someone else says really hard that they’re right. Going head to head would be a scary thing, because Prokofy and I would probably never stop talking. We both care a heck of a lot about SL. I’m doing my best to avoid getting in an outright flamewar with him, because I know no one will win. I feel a deep need to counter and address many of the thing he’s said, so I’m using my blog as an outlet.

I also wrote to Rob Lanphier (head of open source stuff at LL and, I believe, a fairly major authority on PJIRA) in response to the discussion during the bug triage. I ended up saying a lot of things that were on my mind, and I think this stuff might be interesting to the rest of the community outside of LL, so in parting, I’ll leave you with what I wrote:

Rob,

I just had a chance to check the transcript of the latest bug triage for the discussion about WEB-382 (Prokofy’s crusade). I can’t help but feel a little responsible for Prokofy’s tirade because it was my action in VWR-3071 that set him off, but I suppose it would have happened eventually the moment anyone touched one of his issues.

I’m sorry that I wasn’t able to make it to that triage, and that I generally am not able to devote the time to triages and email lists. I spend 20-40 minutes a day checking JIRA, just to keep up on the latest bugs affecting the grid, and I clean up while I’m at it. I think that even that contribution is pretty helpful, because between us “JIRA cleaners”, we sweep out a lot of cruft. BUT, if I’m doing anything wrong, making any unilateral actions I shouldn’t, I want to know, and I’ll be glad to change or stop what I’m doing. I’m just trying to contribute to making JIRA actually useful.

In regards to the triage, one of the suggestions was to limit closing/resolving issues to people deputized by LL (probably “good-citizens”). It looks like this proposal was tabled, but just in case, I want to put in my two cents. I really don’t think you should do that. As someone pointed out, ANYONE deputized by LL will not satisfy Prokofy, and he will see it as a list of people to villify and as evidence of his “secret cabal” of people ruining SL. It won’t help at all.

As to the actual issue at hand (whether open issue modification rights cause abuse), I haven’t seen any abuse or improper actions in JIRA that were not quickly reversed. Sometimes an action is reversed by the original reporter, but often enough someone else in the community does it. Actual abuses that need to be reverted are very rare, and I’ve NEVER seen an unchecked “revert war” where two people argued by repeatedly undoing and redoing each other’s actions. It just hasn’t happened.

Prokofy seems not to understand what JIRA is for. I see it as a tool to help the community speak with a voice that’s actually useful to LL with regard to what bugs exist in the world. There’re so many that it’s just not as obvious as someone like Prokofy thinks it is to list them all, much less fix them all.

Prokofy seems to want to use JIRA as a weapon to force LL to change to suit his whims, or at least to use as ammunition in his never-ending battle against LL. He seems to want to be able to report an issue and keep it open even if LL doesn’t agree with it, so that he can say “Look, the Lindens aren’t listening to Us!” This is not to say that I think LL always listens perfectly to what the community says, or that I’m an unswaying “LL fangirl”; I’m just of the opinion that JIRA is not a good forum for this kind of thing. It’s not a soap-box. It’s not a wall outside at LL HQ where we can paste our grievances so that the world can see how horrible LL is. It’s for providing LL useful information, not for ranting.

The Triage decision was to ask Prokofy to provide examples of issues in which “unilateral” action caused damage. My action in VWR-3071, of course, is one of those examples, and while I think what I did was defensible, I’m certainly willing to listen to the fact that I may have acted incorrectly.

However, most of Prokofy’s other current examples were either resolved by a Linden or by the issue reporter. It seems that he doesn’t want to allow even Lindens to close issues. He doesn’t trust any Lindens at all. With that in mind, I don’t think JIRA’s going to be particularly useful to him at all.

With all of this said, I think there’s one useful change that should come out of this. It should be made much more clear what LL’s policy on JIRA is. I’ve had plenty of situations where I acted according to the JIRA usage guidelines and people were upset because “some random person not approved by Linden Lab is changing my issue”. I think it needs to be made much more clear what LL wants people to do, what their recourse should be when they feel someone acted inappropriately on JIRA (and reverting the change doesn’t settle the conflict).

More specific to VWR-3071, I think there should be a much more clear definition of whether an issue should be a bug report or a feature request. My feeling is that the definition should be something like, “a bug is when the system does not function as designed”, whereas “a feature request is when the system works as designed, but you want the design changed”. Also, it should be made clear where policy change requests go, if they belong in JIRA at all. Furthermore, Prokofy’s main problem with my action was that I “closed” his issue and am therefore an tyrant. The JIRA policy guidelines already say that a resolution is NOT the same as closing an issue, but this needs to be made much more clear.

Finally, I think the priorities should be more clearly spelled out, with distinct examples of types of issues that belong in each category, and perhaps with concrete examples of properly-prioritized issues. That, or we should completely do away with the priority system. So many people become personally upset when their issue, which drastically impacts their ability to play SL (but no one else’s) is reduced from “Showstopper” to “Normal”. If I’m the one that makes that change, they feel like I’m telling them their issue isn’t important. I’d love it if I could direct them to a more comprehensive explanation of issue priorities than already exists. And while I’m on the subject, I think that the explanation of priorities needs to also include descriptions of priorities for Feature Request proposals, because the current priority descriptions don’t apply very well to feature requests.