Get rid of voting; give us the Big List Of Things To Do (BLOTTD)!

Philip Linden: "Based on your Annual Performance Review, you will henceforth be known to the world as NutSack Linden."

You're not understanding the spirit of the forums. The idea is to waste time at work instead of actually doing any. You should try it.

Well said. When developing things I like to focus on what my customers want.

While there is definitely value to be had for taking your own path, being accountable to your customers is key.

In fact, looking above, I didn't see the word "customer" or "user" once.

Kinda scary, no?

Yes Flipper, I think that Resident votes would be useful for prioritizing things on the list. Most LL developers have gone through the experience of completing the bug they're working on and asking themselves, "OK, now what is next." If they don't have something they have already singled out they will often go to Jira and sort by internal votes and go down the list until they find something that fits within their interests, skill set, or time constraints. If they could sort by Resident votes then I'm sure they would try it.

To set that up would take work, and therefore competes with bugs and other features for resources. I actually went to the BLOTTD and tried to find that item so I could vote for it. Although I didn't find it I'm not going to add it at this time because I want to talk to Karen and Chris to see what they know about its feasability -- there is no point in entering an item that cannot be done. For one thing, I know the feature has been discussed -- I think I remember Karen talking about it. On the other hand, Jira is written in Java, and while we have the source code, we don't have a lot of Java expertise in house, at least none that is easily from other more important tasks. Doug Linden, for example, knows Java well and is an absolute star programmer, but he is always busy working on a lot of other tools or core code.

You can consider the idea something that is being kicked around the lab, but I don't know what the timeline would be (now that sounds like something I would say .

So making the BLOTTD public is on the BLOTTD...

teehee am I the only one that got a giggle outta that?

Everyone thought I was an asshole when I posted a thread last year because I explicitly stated that the Linden mission doesn't seem to have much in the way of customer focus. I asked what that mission might actually happen to be, and no one from Linden Lab responded. The peanut gallery chimed in with nonsense mission statements and I don't think many people took me seriously when I suggested a solid, cogent, end-user focused mission would be helpful for LL to have.

Well, now you see what happens when your stated mission is based on the production team enjoying themselves, rather than focused on delivering a specific and consistent end-user outcome.

Now, to be fair, this is certainly a small excerpt from a larger document. Still, it reads like an excerpt from a declaration of independence penned by software engineers rebelling against the top-down, objective-driven corporate structures beneath which they had toiled for years and years. It reads like a cry of joy from someone who is delighted to abandon structure and follow whimsy.

But there just doesn't feel like there's an objective driving development beyond personal satisfaction for the folks involved. That objective could be anything, for all I care, be it platform stability or feature innovation or simple customer satisfaction.

But satisfaction of the research and development staff? I don't know if that's the priority I'd be spending my time emphasizing. And given the inconsistencies we see time and again with promised features that later disappear, I feel like everything makes a whole lot more sense now.

It's all very utopian and everything, but I think it completely explains most of the failures and inadequacies that really piss off long-term customers of this service.

I have to admit... I actually admired the document and I thought it fit very nicely with LL.

Especially the bit about transparency and accountability, stressing that in a flat environment is very important.

Unfortunately, it reads like a document that hates customers, in fact, seeks isolation from its customers.

No company can exist doing that. It's impossible. A company survives by serving its customers. Building products people do not want is the fastest way to the corporate graveyard.

It is surreal that this message is having such a hard time making it through.

I hope Andrew Linden is not a lone voice here, but the fact that he can't find this item on the BLOTTD does make me wonder that he might be.

I'd like to think Andrew meant "feature" or "project", and that things aren't planned as bugs from the outset...

s/completing/fixing/

Making Jira read only would probably not be too much of a strain - implementing voting and such would IMHO be a waste of time, just look at the feature voting page ...... there's more features asked for there than could be done in a million man years. And then you'd get people complaining when the bug they voted on is resolved as a dupe of another, etc.

If nothing else, it would make the system more transparent.

A lot of software projects use the term "bug" internally to mean "any task that needs to be done". For instance if you search the Firefox/WineHQ bug trackers you'll find everything from "crash when I do XYZ" to "Wouldn't it be neat if ..." to meta-bugs like "Tracker for 1.9" which exists only to depend on other bugs.

Quite how sophisticated LLs use of Jira is, I do not know. But to assume the term "bug" in this discussion means a fault in the software wouldn't be right. Anything and everything is a bug, including features that don't exist yet

hm that's the way i would wish to work give to your customers enough to get em to pay you and invest this money by experimenting what you really want to do

At my work place, we use a custom-built task list I coded for I.T. (we wanted a custom-built system suiting our industry instead of off the shelf).

All tasks are broken into three categories:

Maintenance (bug fixes, quick tweaks, customer data requests)
Enhancement (changes to existing features & tools)
Development (new feature / tool requests)

Up until now, we've tried to approximate the time in hours each task would take (I think an easy...hard system would be better after reading suggestions on this thread). Based upon these factors, we poll our I.T. customers (whether they be within our company or external to our company) and prioritize based upon those responses.

In the above discussion, its seems like the terms "bugs" and "features" could all be included under the umbrella of "tasks". This system works out well for us (we're a small team) - and sounds like a much smaller version of Jira. It also sounds like LL has been spending a lot of time in Maintenance (to keep today's world rolling) and Enhancement (scalability for the future); this would logically leave little time for Development. I'd be curious to see how resident voting would pan out. If we saw the "big picture", I think Havok integration might take a back seat when we see everything on LL's dev plate, whereas with the resident voting tool that would never happen.

I don't see the point in having two lists; it follows logically that LL would pay little attention to the voting system is its not their working task list!

Regards,

-Flip

I don't know what to think about this proposal - having customer feedback on priorities is desirable, but an internal bugtacker will almost inevitably contain information you don't want to be public. Based on 3+ years of our whining LL should have pretty good idea what users want and just get on with it. In fact, I would prefer if LL communicated much less than now and didn't tease us with features they don't deliver. Imagine last year without the object-object com, html on prim, havok2 (I care about them in that order) announcements - SL today would be the same as it is, just with less bitter aftertaste

Well said Enabran!

I really dig people who talk ex(1) .

Thank you very much for the candor. To echo some sentiments above, opening JIRA to the customers would likely be a disaster as being micro-managed by one person can be disheartening, having 300 or more could well be maddening - not to mention productivity killing.

Having a very high level view onto what is planned, under development, rejected, etc. would be incredibly useful to the customers, even if they (we, I) were to whine endlessly about it doesn't mean you need to alter anything. Merely knowing broad intentions would be vastly better than the current state of unknowing.

I've not looked into JIRA in depth but would be surprised if it couldn't generate reports of useful but sufficiently discreet overview. Thanks for any visibility you can get the customers into the development choices.

You mean they become Pox Linden or Syphilis Linden or Phlegm Linden? I like it! We'd soon know which ones to kick....
Cali

Yea, it WOULD be nice to know the direction SL is heading towards. What is its purpose? What is it good for? What is LL's vision for SL? Enquiring minds want to know! I hated this about Active Worlds but at least it TRIED to define itself (e-commerce, education, 3D homepages, etc). Unfortunately, most flopped and were short-sighted and/or ineptly implemented (as was the case with most of its features) but at least AW tried.

That could be, though fixing long term bugs is something some programmers love to do. I do... it's a really great way to be a hero to the other programmers.
Heh.

I'll have to start doing that then.

I've avoided using that metaphor in SL and the forums because I was afraid it'd confuse people.