Feature voting update - please come add some bugs

that's entirely possible.

Well, since this thread is starting to get into personal flame wars - which is a pity - I'll try to "turn the tide" for a bit and go back to the original topic...

While I still think that there should be separate "wish lists" and "bug fix lists", you must agree that Philip - no matter how much you disagree with him and no matter how much professional experience you have in developing software - has a point: there is no way to know whenever a piece of software is bug-free before releasing it. If that were so easy, people wouldn't still be finding bugs on TCP/IP code - the core of which is almost 32 years old, has been "public" for decades, and still has a few bugs.

I, for one, don't want to wait 32 years until a new release with new features of SL comes out, because, as Philip pointed out, there are almost infinite possibilities of "something going wrong". Really. I don't believe that anybody, either in SL, or at LL, really wants that.

So, there must always be a trade-off: how many bugs can a software survive in order to be usable, and how many new features it does need to keep up with user's interests/demands and stay "afloat" among the competition...

Some of you tend to prefer stagnation with a perfect software (we could argue if that can ever exist for anything that has over N lines of code...) instead of evolution with a less-than-perfect software. Being used to buggy software all my life - and yes, I'm mostly an Unix user of the Mac persuasion - I know that bug-free software is "mission impossible". So I'll side with the realists out there, who prefer something that works 99% of the time for 99% of the people (guess what? only 350 of us are out...) and have evolution, instead of waiting an infinite amount of time to get all bugs fixed.

However, this is besides the point. I still think that the feature list and the bug list should be separate and voted independently. Figuring out the "10 least wanted bugs" will be an exercise in self-control, but I still prefer that to having a single list. It's tidier.

And I also think that people are demanding too much of Linden Lab - next, you'll be demanding to press buttons on Andrew's electric chair if he doesn't work too hard...

"another bug you missed, Andrew! Naughty Andrew! BZZZZZT!"

Well, I appreciate Philip's concerns in discussing LL's policy with us (thanks for that!) but I guess it's a bit too condescending trying to tell him what *he* should do with *his* company. After all, we still have 35.000 happy residents

"Polishing" the current relationship between LL and the residents is one thing. "Demanding" a different policy from LL just to please a handful of users is pushing the line a bit too far. A company is never a 100% democratic operation - *someone* has to draw the line somewhere.

And sincerely - we're users of a US $9,95 software solution, with free lifetime tech support and upgrades, and we still get to vote on features and bug fixes. Can we really "demand" much more?

Can I say that I like voting on features, and I like the idea of being able to indicate which bugs annoy me most too (that would be 1, crashing after a tp, mercifully much rarer than it used to be and 2, falling off the map crossing sim boundaries and having to relog).

As several other people have suggested I feel they should be on separate lists - tp crashes are not reproducible in a strict sense, they happen sometimes even if I don't change clothes, attachments etc. which makes it hard to bug fix, same for crossing sim boundaries and falling off the map.

So, I vote for them and the LL team say (quite reasonably) we can't work out how to fix it, we're still trying though as we accumulate more data.

But there are things I'd like to see introduced too, and I've voted for them. Yes LL has a small team and they have to choose their priorities. Yes if there is a clear bug it should be fixed, and if it can't be fixed data should still be collected to see if a fix emerges. But if they can't fix anything on the list (for whatever reason) free their time to look at something new - I'm sure that is actually what is done anyway.

I'm not going to pretend to tell you how to run the company - you deliver an excellent product under very trying circumstances, so you despite other people's comments I'm inclined to trust you to carry it on. I do moan and bitch occasionally, but I'm still here 9 months and more in...

But please separate lists for the two. Apart from anything else being able to see the bugs and hopefully see comments, including "We know this happens, but it appears to be random, we're still looking and if we find something we will fix it" and the chance to see which bugs really bug others as well as indicating which ones bug me without ploughing through tons of feature suggestions (which will often get more votes and so be higher up the list as currently shown) would be wonderful. Please?

I've been trying to think of scenarios that might explain Philip's rather unique comment on bug fixing, and I think I have one. Sheer speculation of course, but based on analoguous events at some places I've been at.

(No comment expected on internal issues of course -- goes without saying.)

We know that LL is in a certain amount of bug-fixing trauma at the moment --- the problems with 1.6 must have taken them aback. Fire-fighting is a painful process, very tough on people, and a good manager is one that tries to reduce the burden on the shoulders of those at the sharp end of doing the technical work.

Well there are two common tactics in that area, one is to heavily prioritize workload, and the other is to shoo away any annoying pests, like higher managers or customers. (A manager who has absorbed the Cluetrain Manifesto does not consider customers as pests, but they can be short-term distractions, yes.)

While there is undoubtedly also team-level work prioritization at the LL pit face, the new voting system seemed to offer a wonderful bonus in that area, because it results in the customers themselves actually de-prioritizing items from the workload! Wow, a gift from heaven!

The voting system is extremely crafty in the amazing imbalance it creates between its very positive public perception (prioritization of up to 10 issues) and its actual negative effect (de-prioritization of many hundreds of issues). Just the ticket for protecting an embattled workforce working their guts out on the problems of 1.6.

It got even better or much worse (the same view but from different sides of the fence) when BUGS were added to the list of things being de-prioritized by popular demand ... although any glee there didn't last long, because the customers wised up to it immediately, so apparently bugs are now going to be handled separately.

With bugs no longer on the voting list, the terribly long buglist was still concerning ...

"Didn't some comp sci guru say that all software has latent bugs, and that they simply cannot be eradicated 100% in any non-trivial system? Maybe this means we don't need to fix ours!" It won't have been anything like that simplistic in reality of course, but one can see roughly where such ideas come from, and the desire for any idea that could shorten the bugfix workload.

Well unfortunately Philip forgot about that key word "latent", and extrapolated from this into thinking that *known* bugs were perfectly normal and only needed to be fixed if they result in major complaints. Obviously this view couldn't have lasted long, since it's plain that a system where the speed of development outpaces the rate of bugfixing is destined to be entirely unusable very soon through the compounding of bug issues.

No problem, just a mistake. But the question that remains is, where does one go from here, given the admitted large number of bugs that were introduced by a relatively small extension to the 1.5 functionality?

I have only one easy answer at the moment (open-sourcing the client, to free up dev resource to focus on the server end), but I am sure that there are many others.

Any suggestions?

Morgaine, I think you've just phrased more eloquently than I have the points I've been trying to get across in most of this thread. Thanks for your clarity.

The problem is many residents don't read the forums. They aren't aware of behind-the-scenes bug fixes.

Many judge LL's patching efforts based on the few bugs they've noticed and care about.

Resident voting will greatly increase visibility. This will help residents tolerate bugs even if their least favorite bugs aren't fixed right away.

We've heard your concerns about including bugs in the Feature Voting tool and have decided you're right. The votes will be yours to use exclusively on Features. Separately we will be looking at our mechanisms for bug collection and, be assured, we will be working to get rid of all of them as soon as possible!

Also, thanks for all the great ideas about the feature voting system. Over the next couple of weeks we'll be refining the tool further, to include adding better searching ability, consolidating duplicate posts, and setting up a process for letting you know which features are moved into development and for the return of those votes to you.

As changes are made we'll continue to discuss them with you and aim to build this sytem so that it's a genuinely useful way to work together to set feature priorities for SL.

Robin thank you for your post and for the update on what's the happen with bugs, I'm obviously pleased that Linden Lab have accepted that the voting mechanism is not the place for bugs and I look forward to seeing how you present the bug situation to the community in the future.

I notice that you say you will be working towards getting rid of all bugs - can I take it that this is a change in Philip's thinking as well, as he was advocating that Linden Lab didn't have a responsibility to fix all bugs in his posts later in this thread.

Also, could you get the voting admin to accept Proposal 220 (which was a proposal covering the decision you have made) and Proposal 219 (which is now no longer needed) so that people can get their votes back.

Thanks a lot, Robin It seems that this long thread was worth the trouble, and despite many residents' opinions, LL has shown once more that they are always paying close attention to what some residents actually say...

Moopf, I've re-read Philip's posts again, and I wouldn't say "he was advocating that Linden Lab didn't have a responsibility to fix all bugs". The way I read it, he was explaining the trade-offs between "fixing bugs" and "releasing new features", meaning, for me at least, that it's always a difficult choice to make... and explaining a bit how LL decides which one is more important at each point in time.

Philip Linden in this thread:



He rejects that all bugs should be fixed as a matter of principle and has always accepted personally that the system would create more bugs than they could fix. Either way you look at it he's distancing Linden Lab from a responsibility to fix all bugs. He treats this here without mention of new features, simply that LL, in his view, would not make a commitment to fix all bugs as they arise.

Now Robin has said all bugs. There is a disparity between the two statements which is why I think clarification would be good.

That's pretty clear, to be honest.

We all make mistakes, and we correct them when they're brought to light. It's no biggie when they are corrected.

The excellent thing is that we ARE given the opportunity to redline mistakes here. That doesn't happen in a lot of companies, it's pretty enlightened, ranks at the very top.

Would there be howls and tears from anyone if the next update of new features was delayed, to enable as many bugs as possible to be found and dealt with?

Alexa

Well that was supposed to have been happening anyway - with short term development focusing on bugs rather than new features according to what Philip said a while ago. It never seemed to play out that way though.

I'm quite glad that LL not only heard but listened, and will be looking at more robust ways to track and prioritise bugs in the near future.

I'm also glad it wasn't an instant decision -- obviously some thought is going into the process and it wasn't a kneejerk reaction. Hopefully LL will foster this same thoughtfulness throughout its organisation.

This one deserves a shiny new kudo!

I agree, Meilian.

It's interesting that occasional mistakes and corrections like this are a good thing, because they highlight that the "embrace the community" meme is truly alive and well at LL, and not purely a matter of lip service like at so many other places.

I'm quite impressed. <hat off>

If you stand still, you regress though, so "the fight" continues. All in good spirit.

It is sometimes joked about that "Is it a bug or a feature?" much like "Is the glass half-full or half-empty?" or "Is that a bunny rabbit or a rabbit bunny?" in my case.

Well, I had an epiphany the other day, related to Star Wars. It has to do with the Light and the Dark side of the Force. But strangely, Count Dooku, who is also known as Darth Tyrannus, was representing the Light side because of his elegant Form II technique. I will not say who his opponent was. It went on for awhile, but I'll boil it down to this: it's kind of ironic that when we vote for certain features, we're gonna be grudgingly (perhaps) voting for the bugs that come along with them, and that fixing those bugs and adding even more features will lead to more termites out of the woodwork and soforth. Giving birth to a baby, raising a child, all of that encapsulates so much pain and hardship at times, but is it worth it? Well . . .

It's just nice at the end of the day -- or maybe weeks, if not months or years from now -- if we can all have a good laugh about some of this stuff.

Time does tell, and perspective does show that Happy Foot Disease... I mean, isn't that funny?

That is true, but whether it matters or not is a simple function of the growth rate in bug manifestation.

If this "bug rate" is greater than the bug fix rate measured over all reasonable time intervals taken as units, then the trend is terminal --- you might as well stop work now and go on to other things. Your system will eventually collapse under compounded bug infestation, and any effort now will be wasted.

If in contrast the bug rate is lower than the fix rate over some reasonable time units like say a few days or a week or even two, then the introduction of bugs is under control and manageable. Development with managed bug rates just deals with squishing a monotonically decreasing list of bugs after each change.

In other words, there is no problem.

No problem? Morgaine, that sounds REALLY yummy to me. Not that I'm gonna eat said bugs.

OK, fair enough, I should have added a proviso.

It's no problem if the pace of new feature development is adjusted such that the height of the bug rate curve at each feature release point is kept within tolerable bounds. This implies either increasing the interval between releases, or else decreasing the bug rate and/or increasing the bug fix rate.

It's not uncommon to refactor the system to reduce coupling so that bugs are fewer and more localized, and this often makes the bug fix rate increase too. Nothing really new here.

So yeah, there was a proviso. But I think it's an easy one to meet.