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

In this post Andrew Linden mentioned the Big List Of Things To Do (BLOTTD):

/108/da/95037/2.html#post948113

I say, let's lose the current voting system altogether! Instead, make the BIG LIST OF THINGS TO DO public. In addition to the title and description of each task on this BLOTTD, also include an approximate number of hours each task would take, and why it would take this amount of time (then residents could make arguments about why it might take shorter or longer).

Next, let each resident who wants to rate each task on an importance scale between ZERO and TEN.

Sort by the sum of total importance rating descending (the one with the most rates on top) and start taking your tasks off the top of the list.

Andrew, thanks for talking through the process in detail in the post; its always fascinating to get insight into how things work behind the curtain! I think allowing residents to vote for priorities on the list would be a huge improvement; I've noticed that residents spend a lot more time in world than Linden Lab (as it should be; we want you working!) and may be able to prioritize the needs of the community more effectively than LL could do internally!

Regards,

-Flip

Yep. Hmm, I found my other one around here, where's the one I need for this...


There we go.

So how much does a BLOTTD go for these days and is Pluto still on them?

If I had to guess, I'd say the BLOTTD is Jira, their internal bug tracker. They might have a separate list I guess but on most projects they're unified.

Opening those things up can be pretty tricky - we did it at my current employer but it took a while. In our case it was chock full of confidential client information though, whereas LL probably doesn't have so much of that.

Bug trackers are pretty central to any major software project - right now LL got burned when things they thought would be easy didn't pan out so they're pretty closed about what they're working on and their plans. Opening it up would be a total reversal of that policy - not that this would be a bad thing mind!

On voting, well, Firefox has this and it doesn't work at all. The total number of votes a bug accumulates usually has zero impact on actual developer priorities and it's generally susceptible to "flash mobbing", where people get loads of friends or strangers to all vote for a particular bug that may or may not be an issue for the majority of people.

Even with all those caveats, I'd still support Flips proposal! If LL are serious about SL one day being the de-facto metaverse system, they have to open up, and the BLOTTD would be a great place to start.

hehehehe, I'm sure there's a section of it that says:

Step 1: "Take care of" Flip (message left for Mr. Soprano)
Step 2: ???
Step 3: Profitability and world peace!

Regards,

-Flip

Wow, no offense but this is a horrible idea.

As much as I hate the fact that the voting dealie has never been of any use, and as much as I think the DEVs could all use a big kick in the bum, this wouldn't solve anything and would create absolute CHAOS as well.

Would you want to work somewhere where the customers argued with you about the organisation of your own "to do" list on a daily basis? All this would do is create a whole lot of extra work managing the "opinion input" on each task as it is done. Talk about slowing things down!

It's a fairly standard administrative practice to make lists of tasks and to rate them according to difficulty, but coming up with hard numbers on completion times is the kind of fantasy that only the worst micro-managers engage in IMO.

Nothing but the most rote of tasks can really be quantified to any realistic extent, and to open up what's already a questionable or subjective evaluation system like that to "public opinion" just seems silly, and really counterproductive.

Better that they spend less time "organising the organising" and actually just do the work. What's missing at LL is a good work ethic, and direction not more organisation tools.

Wow! YES! A thousand, million times, yes!

(Though it would still be a good idea to keep the place where residents can propose things.)

coco

Dianne, you raise some valid points and concerns.

However, I have worked in several environments where we've done exactly what I have proposed, and it has worked out very well. It kept us from working on something we might think was "shiny!" that no one would ever actually use.

For example...how many times has the "land pass" system ever actually been used? Have you ever actually paid for access to a land plot in SL? I've seen it used once in my 2.5 years here and that was on a live help call. I think we could have all lived without it pretty well. OTOH, how many server resources are wasted on AO scripts, which despite the best efforts of the programmers, don't work very well? An integrated solution is long overdue for overriding the default LL anims, and I'm convinced its somewhere on that BLOTTD; I'd rate that an eight or a nine on the to do list, as I believe it would have one of the shorter time periods to implement, compared to something like Havok 4 integration. The only thing I'd rate a 10 would be tasks to do with the continued scalability and reliability or the platform.

When I worked at the Internet's biggest online music store (at the time), we took a similar direction with customers who could take the valuable time they had to rate what projects we were working on and their importance after one large community portal project we developed had flopped. We spent months and months developing that product, and no one ever used it. Hundreds of thousands of dollars and lots of time was literally flushed away.

At my current RL job, we poll our customer base, showing them the list of features we're planning on implementing at some time in the next 24 months that affect them, and ask them to vote. By tallying and weighting by the amount of business they give us, we prioritize. It works out very well, and makes our customers feel as though we're really in it to serve them.

Regards,

-Flip

I think this is a brilliant idea, but I don't like making devs estimate the number of hours it will take to complete every task, and I dread the idea of constant public arguments about how long things should take to get done. I've used a slightly different approach that has worked well. Why not have Linden developers simply rank features by cost to implement? High cost is 10, low cost is 1. It's just a relative ranking and is fairly easy to do accurately and doesn't take much time away from development. Then we get to provide the other side of the analysis, the benefits, using voting as Flip proposed.

A simple ranking algorithm makes low cost/high benefit features jump to the top of the to do list. It's important not to do low cost/low benefit features next - there are so many of them that developers can use up all their time and not get to the most important things on the list. By weighting the ranking algorithm slightly in favor of benefits, high cost/high benefit features move up the list. And of course high cost/low benefit features are never implemented because there are always more important things to do.

Great suggestions; a relative number of time / resource cost to implement is much better than hours. In fact, I'm going to start using that at my RL job.

Regards,

-Flip

Yes, we use Jira as our BLOTTD.

I believe it is technically possible to open sections of Jira to be publically browsable, maybe even votable, not sure. We had some plans on doing that; I'm sure it is an entry on the BLOTTD.

I like the idea of Residents being able to vote on Jira tasks, however I don't like the idea of having to spend more of my day providing time estimates, updating them when they change, or arguing over technical merits, time estimates, or priorities. That just sounds like a time sink that would be better off spent working on code.

Jira is good for some things, and not for others. Internally LL employees use jira in different ways. It is an idea bucket: got an idea? --> write it up in jira and throw it into the pool. It is a record of who did what: got a list of things you need to get done this week? --> write them up in jira and document that you did them (Some items are entered into jira only to record that they were done, even if adding them to jira takes nearly as long as it takes to get the thing done.). It is an offline design forum -- don't want to cloud up everyone's email with a design thread? --> post design discussions into the item as comments.

Sorting Jira items by votes, or priority, doesn't necessarily provide the correct order in which things should be done. Other things affect order too such as how long something will take, or how fun or tedious it will be. For instance, on Friday afternoon I might prefer to pick up a lower priority easy project rather than a new tedious 3-day task. Some "low priority" jobs might help ease the pain of implementing "high priority" things on the schedule for next week, so maybe they should be done first. LL employees are expected to choose jira projects when they can, or when they want to, but they are also sometimes assigned projects, especially big projects (or sub tasks of big projects) that are on the short schedule. Some lower priority/vote things may be done early because they fit well inside small gaps between the bigger projects on the schedule.

In short, _absolutely_optimal_ scheduling is complicated and probably impossible, but votes help the schedule approach optimal.

Now are you suggestiong that we do project management on LL's behalf?

Although the suggestion is completely inappropriate for a private company like this, even if they allowed us, would you even want to do that? Do you have any idea the kind of work you're asking for?

The time estimates would be also quite volatile changing based on what features/fixes were rolled in as a part of the last update.

I think the line between customer and service is really starting to blur here. While I support increased involvement of users in LL decisions, I don't think this is the right direction for anyone involved. This suggestion at best will result in misguided micromanagement if not total absolute grid-lock chaos.

Troy

Thanks for the reply, Andrew. I guess I'm just really curious to see how the process works and trying to figure out a way for interested residents to help identify, more clearly, what problems affect a large portion of us. Your criticisms are quite valid; discussions would lead to a slow-down.

Troy, how would you suggest we communicate our utmost needs to LL? I don't see how I'm saying in any way we take over project management, I'm just trying to come up with a mechanism to allow the residents to express needs; I see that as a void right now, since the residents don't have the necessary data to have an honest opinion.

Right now the system is clearly not working as well as it could (and as Andrew said, I doubt we'll ever be 100% optimal - that's pretty much impossible). Got any input on a better way? Or are you throwing your vote to maintaining the status quo?

Regards,

-Flip

PS- Andrew, thank you for your candor and the time you take to provide well-thought out replies. I know you're busy, but your forum posts are always some of the most honest and detailed, and I think they really help people (or at least me) understand how complex a lot of the processes can be. While insightful, I enjoy the touch of humor and your ability to talk tech without talking down.

Regards,

-Flip

Yah, just an 'off the cuff' idea of how hard something is... and if another developer thinks they can do it easier, or thinks it's harder, let 'em adjust it. 1-10 may even be too fine a division, but it's a place to start.

I think the key detail is letting us see what the BLOTTD has in terms of contents, and the priorities that Lindens have assigned.

Being able to vote on it isn't particularly necessary for me, but it would be nice to know what's coming down the pipe so I can architect my content and business models appropiately.

I can agree with the idea of making the BLOTTD public, including perhaps some sort status indicator showing where it is in the lifecycle. Revive the Voting System and put a link on each BLOTTD item that corresponds to a Proposal in the Voting System. Not all items on the BLOTTD would correspond to a user proposal, obviously some (most?) would be internally driven. Add a status indicator to show whether the BLOTTD item is [ In-Queue | Assigned | In Progress | Deployed ]. That, I think, would provide the most benefit. If LL is going to pay heed or interest to user priorities, the proposal / voting system can/will work. If they aren't, then no new system you devise will change that.


Posting approximate hours to complete & Justfication of duration? No way, this is just one way to ensure people who SHOULD be spending their time actually working to implement a feature or change are spending it arguing with people in the fourm over how they should write code, and how some person thinks code something better/more quickly than Linden Coder X. You've seen the arguments in the forum, do you REALLY want THAT to be injected into the middle of the LL development process? Gods help us...NOTHING would get done.

Absolutely agree. I learn more about what's going on with the future of the service through a single Andrew Linden post than in 20 posts made by other Lindens. Fellow's definitely got a knack for communicating, in addition to the obviously necessary and abundant talents for code jockeying. Thanks for all the time you give us, sir.

Ladies & Gents, the Action Priority Matrix:

Here is an experpt from our internal "Vision and Mission", which is considered required reading for LL employees. This is actually just an internal wiki page so it should be considered a work in progress and no, I did not write it. This justifies why we do things the way we do and why I can talk about this stuff on the forums:

...

Choose your Own Work.
Given how dynamic the challenges are we face, and the opportunity for increased job satisfaction and productivity, Linden Lab places a high premium on choosing your own work, rather than being told by anyone what to do. By choosing your own work, you are more likely to have more fun at work and add more value to Second Life. By setting your own goals, you are more likely to meet them. When you commit to a team project, be prepared to be directed by the team lead, but when deciding what project you will take on next, rely first on your own best intuition and the counsel of peers.

Be Transparent and Open
There are many ways to emphasize responsibility, accountability, communication and trust. We believe that the one key principle that best supports all of these values is transparency. As much as possible, tell everyone what you are doing. This transparency makes us responsible to our peers, makes us accountable to our own statements, and replaces the need for management with individual responsibility. Over time, it creates and reinforces trust. Be willing to share ideas before you feel they are ‘baked’. Report on your own progress frequently and to everyone.

...

I should mention now, before somone points out inconsitencies between those principles and LL's public actions in the past, that the "transparent and open" item above is talking about internal behavior rather than public behavior. That is, there are some things that LL can't discuss publicly (some business, financial, or legal issues) as well as some things that may be unproductive to talk about (such as some strategy decisions or tentative plans). So while LL is not totally transparent to the public these internal principles affect our external policies which is why LL is as open at it is.

I think the main item people have taken issue with is not the idea of communication on what's being worked, and a means to receive feedback from user on what important to us. I think the problem is with this part of your suggestion: "...include an approximate number of hours each task would take, and why it would take this amount of time (then residents could make arguments about why it might take shorter or longer".

That is trying to have a committee (the residents) micromanage the specific work done. That is where the bit about taking over PM duties from LL comes from.

-Alexin

Caring about employee job satisfaction is a wonderful thing. But there is a problem with these statements - they don't mention us, your users. Choose your own work from the things your users want most.

That was a misstep, and I've said as much above in my reply to Sky above - just brainstorming here, there's plenty of room for improvement from my original brain-dump.

Andrew, thanks for posting that portion of the Vision/Mission statement, I'd never seen it before. Pretty cool. Do you think a system like this would help LL employees know what people want most? Would it help with any of the decisions of what LL employees work on? I guess I'm trying to bridge the gap that is JohnDoe Linden has two projects he's equally interesting in working on, this would allow him to choose project A if its clear that's what the citizens are clamoring for. I hear a lot of Lindens repeat the refrain, "Wow, I really wish I could spend more time in world, I'm so busy!" A system like this should help keep LL employees in touch when they're too busy to be hanging out wasting time with the rest of us.

Do programmers actually choose to fix bugs? Isn't the "Choose your Own Work" approach the reason why there are long term bugs in Second Life?


Shouldn't Philip be threatening the programmers with horrible names if they don't fix the bugs?

This makes sense.