Feature voting update - please come add some bugs

I miss-type - "forum voting" as opposed to inWorld voting.

Having to go out on the web and vote ruins my immersion!

(Sorry, I really don't have anything really intellgent to add, but I do feel "Vote On Your Bug" deserves to be mocked.)

And yet a significant group of people not only submitted "Fix bugs before features" but voted on it. So even though we launched the voting system as a system designed for new features, our residents used it for their own purposes. Bravo! Our response is: great, we have heard you, but now we need to now what bugs are bothering you the most.

that dated your ass

You people really are beyond hope. If you think that for a company that is primarily involved in producing software it's a good idea to say to its users, "you're going to have to prove how important the bugs are before they'll get fixed" is a good, sensible policy, then you really deserve ridicule and derision.

You're doing this knowing full well that, even though people brought a single, global bug proposal to your attention (which you accepted, then promptly said ah but we need them individually), once it's split into hundreds of disparate proposals they won't really see the light of day apart from the odd one that affects more than 50% or so of the community. This leaves you free to push on adding new features and exonorating you from any responsibility when questions are asked why certain bugs still remain - you can just fall back on your new voting system and show how the community voted.

With all due respect, you can take your smart little voting "priority mixes" and shove them where the sun doesn't shine.

In all software development I've participated in -- I include Web site development, and have been a Web professional for some 6 years, but my experience is not limited to that -- bugs and features are tracked and considered separately.*

Yes, sometimes "bug reports" are actually feature requests in disguise (and often point to underlying usability problems). But it's the programmers who need to decide if something expected/unexpected is/isn't happening because of an inherent logic flaw, system spec gone awry, mismatch between spec and user expectation, or whatever. Those familiar with the system are generally the only ones qualified to make that distinction when it's in doubt.

What I can read of the "prop" is as follows:



Yes, it seems to cut off. Look at the language therein and consider the context. "whiz-bang features at the expense of stability and bugfixing." To me that does not sound like a plea to include bug fixes in a "feature request" ballot-stuffing contest, it sounds more like a call to put on the breaks with a newly introduced "feature" and focus instead on the bugs. That's what I hear echoed in this thread as well. It's why I suggest a second, separate ballot-stuffer if you're truly going to go that route -- it keeps the issues clear and separate for users, while letting you (Linden Labs) to determine if a feature has been misposted as a bug or vice versa.

Lastly, I have a couple questions. You reference "a significant group of people" in the above. The numbers don't appear readily available, so:

1. How many actual, distinct users (NOT accounts, as one person may hold several accounts) "voted" for this "prop?"

2. What percentage of actual, distinct SL users does that number represent?

Sorry if I missed the data while it was there. It appears the approval of a "prop" eradicates it, and the "prop's" acceptance was the impetus for this thread.

Thank you for replying, and thank you in advance for providing answers.

Edit: Just to clarify, no, I don't make claim to being either a software or a Web expert, or that this is the only way to track feature requests and/or bugs. But neither do I consider myself an ignoramus with regard to the fundamental processes of sortware development -- I've learned a lot in the last several years.

I agree with Moopf that this exercise is sending a whole lot of badly thought-out messages to the players. In the year I have been in SL, I have rarely heard people discuss whizz-bang new features that they want in world. I have heard endless discussion about lag and problems with sim crashes and bugs.

People who are trying to create good things in world, run good events, and make the inworld SL better, need the tools to be able to do this, and the conviction that their experience of SL is important to LL.

It is no good my team on Numbakulla creating the best possible game for people to play if the lag caused by prims/scripts/light/textures/who knows what makes the thing unplayable with more than four AVs in the sim.

I don't want to have to spend my time dreaming up another way to say that there is a linking bug ruining my building experience, or a rotation bug, convincing other people to vote on it...I want to know that LL, when they receive my bug reports, will be doing their best to fix any bug.

And stop to put the MBA speak into the forums. Generally...we hate this idea, but need negative votes to be able to prove it.
Cali

Hey, I'll have you know that none of my alts have bling or hoochie hair.

Honestly, when I see Philip blogging about this voting stuff in his own blog, and even dredging up some essay from 1937 (1937?!!! That was NOT a good year!)...I worry. I find it a little...scary. I'm going to read that essay "the Firm" thoroughly, but I can't know whether Philip is just name-dropping some weird-ass references or whether he actually sits up and reads a book like that about corporate theory and capitalist economic systems. I worry...when he talks about this new voting thing...and ideologies running around in 1937 (NOT a good year for ideologies like I said!)...and the fact that all Linden Lab employees get the same salary or something? And the same percentage of the company...did you see THAT? That's worthy of a whole thread on its own I guess.

Yeah I need to start one, but what I'm saying is that this fascination with voting/democracy/the people's voice springs full-blown out of some ideological *experiment* based on some theory...and that's when I began to feel like a guinea pig.

I endorse everything you're saying, it is so well said, it's some PR ploy really. And for someone to be posting about his visit to LL and making it seem like he fixed a bug right on the spot...well it's just over the top!

I honestly can't think of a single new feature they have in this patch, even the separate name/count prims which I use a lot now, that was worth all the negative of the patch (still crashing) and which would be worth having distracted the team from fixing bugs and old stuff that should have been done before. I think people really need and want more stability.

don't worry prok. you'll get wrinkles in your av. just play the game.

OK, I’ve been contemplating this change all evening yesterday and again this morning, trying to work out any possible way in which this is a good thing and I'm afraid that I can't.

Second Life is built by the community – its success or failure depends, to a very large extent, on the ingenuity and creativeness that the community can offer. We create the content, we create the attractions. In order to be able to do this, Linden Lab has to offer the following:

1. A stable network infrastructure
2. Stable server software
3. Stable client software

To do anything less that this is disregarding the main content creators – the people that make Second Life what it is. Those three points can only be achieved if there is an in-grained understanding from Linden Lab that software bugs and network issues are treated as a high priority with stability the core focus. They have to make it as easy as possible to develop free from as many issues as possible, to help empower the developers to create what makes this world so compelling and for the users to enjoy that.

By including bugs in the voting along with features Linden Lab have downgraded the import they give to creating a stable environment, a decision that it is difficult to agree with. Software companies don’t do this. This isn’t the way development is done. We pay an awful amount of money for this and to have the system developers basically absolve themselves of their mistakes, and make no firm undertaking to fix those mistakes, is a bizarre and dangerous move.

I cannot help but feel that in the long term this will lead to further decreases in stability and an even greater level of bugs in the system. My reasoning is simple. People will tend to vote upon new features, rather than bugs. Chris Linden earlier in this thread said Bravo! To how the community had taken the initiative and added a “fix bugs before new features” proposal and voted upon it, trying to discount the fears that bugs wouldn’t end up featuring highly. Unfortunately a single, all-encompassing proposal such as that, which has been accepted but shelved with the comment that they now want them individually, is bound to get a higher vote tally then 100+ separate bug report proposals. Those won’t get the same voting, not by any stretch of the imagination. That single proposal was also created to highlight how Linden Lab are so feature focused and not bug focused – an understanding we’ve now had confirmed by their actions. Look how they’ve listened to that proposal! Yes, by now making it even more difficult to have bugs addressed. Bravo indeed.

Interestingly this change also limits how many bugs will get proposed at any time. It takes 1 vote out of each account’s 10 votes to start a proposal. This is important as it will limit the number of bugs that actually can be “proposed”, thus limiting the number of bugs it appears Second Life has. Wrapping the users up in a system where it’s actually difficult to bring all the bugs to the voting “priority mix” is unprofessional, inconsiderate and wrong.

The demographic of the voters is also of great concern. Content creators are the minority in world so those bugs that affect the creation process, such as building bugs or scripting bugs, will generally not attract the votes other, more unilateral bugs such as crashing will as people won’t believe they affect them. However, for the people creating the content they are often very important but will have great difficulty getting them onto the high-vote radar because of the total number of people who would understand or appreciate the effect they have. This further penalizes the content creators who may not be able to get bugs important in the intensive creation of content solved. If you remove bug fixing support for the content creators, thus making the creation process more fraught for them, why on earth should they bother?

Philip wrapped up this change in his announcement and on his blog with a whole heap of marketing spin. I suggest that this change indicates that Linden Lab no longer has the resources, or a tight enough core system, to enable them to effectively eliminate bugs and need to limit how much of that they do whilst still forging ahead with new features, building upon a house made of cards to a certain extent. They can now work from a single community sanctioned task list, limiting the amount of bug repair work they have to do. This doesn’t strike me as positive. I cannot find any way to rationalize this and end up in the belief that the system will become further bug-ridden in the process.

I’ve been saying for months that Philip increasingly talks the talk of marketing and in the process is separating himself further from the community he apparently was once so close to. To wrap this up as anything other than an admission that they simply cannot cope, and need to shift responsibility to make that easier on themselves, is to insult the intelligence of the community.

I’m not willing to play this voting game as long as bugs are included. Linden Lab need to accept the responsibility that goes with creating software, not exonerate themselves by leaving the decision making on bugs to the community.

Voting for features is a welcome change in policy and something I support. Voting for bug fixes as part of the same list, as a combined features / bug fix list, is ridiculous. Plain and simple.

Well, its nice that they approved my proposal, but if feels like a bit of a cop out to me, saying we have to list and vote on every bug we'd like fixing before we get new features.

It feels more like they're burying the proposition than approving it. And yes, it's kinda ridiculous to now throw feature suggestions and bugs into the same voting pile. That wasn't my idea, honest!

I figured they'd kinda *know* which bugs were a priority and affected most people, or had most severe consequences. Like I listed in the proposal, some of these have been around for ever, and seemingly ignored.

If you *really* want us to prioritize bugs for you, LL, could you implement a parallel voting system so we don't just irretrievably break the feature suggestion one before it gets started?

The way I figured it, bugfixing was at priority #5. Meaning that you shouldn't really add any new features at lower priority than #5 before people are satisfied enough with SL's stability to withdraw votes from it.

I searched for "bug" but it didn't find anything.

Philip,

Since we've started pre-filling bug reports with the headers for the standard format, and since Dan, Vektor, and Kona & crew love when bugs are in standard format, can we have the bugs on the voting have the appropriate fields?
- Summary
- Steps to Reproduce
- Observed Results
- Expected Results
- Notes

Also, while we're at it, can we use the flag for bugs to easily sort them so that we can just view the bugs?

i too have slept on this and have a little bit different attitude than moopf. his and prok's posting's are true but those things have all been stated by many people many times over the past months. i suppose there is a difference in saying them and ll outright proving them.

this model works for large software companies though. microsoft e.g. has published hopelessly unstable operating systems for years, marketed crippling bugs as "features," and charged loyal customers money for the priviledge of beta testing software in production environments.

granted ll is not so large, but they do have a monopolistic mentality, a dangerously radical ceo, and a very loyal base of wor^h^h^h customers. it seems clear to me that they're just following a proven model and we can expect the same type of results.

is that so bad?

YES! Let's vote to add some more bugs to SL!

The object of SL is to see who can stay logged in the longest. Daring players gather in groups, cross sim boundaries wearing attachments, or rez prims and move them around. (It's easy to stay logged in if you are alone standing still in a barren area. That's not the challenge.)

There are far too few bugs in SL. We need more. I solved the current set of puzzles in just a couple of weeks, so now I hardly ever lose because I've figured out the answers to all the riddles.

"Don't use the new features" is too easy a strategy. "See if the old borked features are still borked" is too predictable. "Find the borked features that used to work" is MUCH more fun! So more riddles like that, please.

Buster

Personally, I'd like to see a second voting system - structured identically to the current one - set up for bugs.

This would make it easier to reach the goal I think LL is really after: Overall prioritizing.

The features system would let the dev team know which features are most important to the community for each major release. The bug system would let the dev team know which bugs the community finds most harmful in each minor release/patch.

They could even use it to time major releases. For example: when activity in the bug system has reached a certain very low level, it's time to work out the next major release.

Don't get me wrong, I don't expect Linden Lab to prove or disprove them - I don't believe they would bother to either way to be honest. They present things as experiments, and have done many times before, when in actual fact what they mean is "This is what we're going to do and although we might say we'll see how it goes it's set it stone although we really want feedback on it to make you feel like we're involving the community."

The way they jump upon ideas is almost sarcastic and mocking towards the community. People complained about how many places stuck in popular places for long lengths of time, so they stuck two fingers up to the community and said "OK, we're going to charge and call it sponsored listings now. Bet you wish you'd never said anything, eh!". Somebody posts a proposal on the voting to highlight how bugs get left and they stick two fingers up again and say "haha, great idea but don't think that's going to work, you've now got to submit each bug individually, so fat chance we'll actually have to fix anything. Nice try though, but we can beat you at that game by playing by our new rules".

I agree with you that the business model of letting the bugs mount and still charging customers works, but you know I'd always been led to believe (especially by certain brain-washed sections of the community) that Linden Lab was different. They do have a monopolistic mentality, they do shove it to their customers, they do charge for shite QA on their software and expect the paying customers to test it (then bizarely get pissy if something crops up late - as we saw Philip Linden do on Lordfly's post, if I remeber rightly), then they have the cheek to tell us that we've got to vote to get bugs high in priority in amongst new feature proposals before they'll do anything to fix them. This company is no different from the ones we love to hate, yet there's no need for them to be this way, unless they are totally out of their depth which I'm starting to wonder might not have a ring of truth about it.

Is it so bad? Yeah I think it is. I think for a small company to try and behave in the same way towards their customers as a big mutli-national like Microsoft who have billions in reserves and a monopoly that is massive in terms of captive market is poor, misguided management. Microsoft can get away with it because the market is such that they basically own it anyway. Second Life has what, 25,000 subscribers? They may have a monopoly but it's a mighty small customer base in comparison. Piss those customers off in the same way a multi-national would and you can kiss your company goodbye.

I can't believe that Linden Lab are acting with such arrogance with regards to bug fixing by doing this. Small companies live or die by their customer service. Here we have a company that does not respond as they should to support requests, consistently shift the blame on any issue that arises for their customers and now has the gaul to say that they're not going to fix bugs unless the community manages to get them to the top of a voting mechanism that's also filled with new feature proposals.

You know, the more I write about this, the more I realise that the only reason I'm still spending money with this company is to honour my commitment to the project team on Numbakulla. As soon as that's over I can't possibly see that I would want to put any further money into this company until they get their act together on service, stability and QA.

Yes, it's the same idea as a previous post I made further up this thread. If it was a second voting system then it would make much more sense and be more palatable I feel. At least then it wouldn't look like they're trying to avoid bug fixing, which is what it feels like currently. But it would require them to be consistent in acceptance between the two voting systems, and I'm hazy on whether I think that would happen or not, or whether we'd have the current status quo regardless.

Are people just totally apathetic towards Linden decisions these days? Or do people actually think this is a good idea but don't want to say anything? Or think it's a bad idea, but don't want to vocalize that?

I'm suprised Philip's thread hasn't caused more discussion than this seeing as the implications are pretty important. Very suprised.

I should state from the beginning that I am part of the Numbakulla team Moopf refers to above, but that has no influence over my views on this subject .

I have posted in half a dozen place about this subject, because the more I have thought about it the crosser I have felt. As Kris says above, the proposal that bug fixing should come above features HAS NOT been accepted by LL it has been buried. If bug fixing were going to be above features, then the list of bugs would be easily accessible and would be at the top of the voting thing. It makes TOTAL nonsense of the whole scheme. If the first vote to be accepted really means something, then where bugs come in the great pop pickers chart of features is irrelevant... but hold on a moment, if the position in the chart is irrelevant...then what's the point...(head explodes)?

If LL accept that the proposal put forward is valid and means something, then I have to have a list of bugs I can access and vote on, and the fixing of the bugs HAS to come before features. As it is, hundreds have voted for a try before you buy feature, and 2 - yes count em, two - people had voted for fixing the damn ******* linking bug that has been the bane of my life this week.

Does LL REALLY think this indicates the relative urgency of the two things? If I continue to be as frustrated with building as I have been this week, I shall go back to making jewellery and painting in the real world. If you lose investors like Moopf and builders like me over the introduction of this system, then SL will no longer be what it can be...and that will be a great shame. I will get back 70 hours of my week I could be doing other things with.

You have to fix this AND FAST.
Cali

i don't know about that cali. ll has, to date, matched the exodus of building and investing residents with hordes of treadmill refugees. philip didn't make a fortune to invest in linden lab without some keen sense of dealing with masses of people. it really just boils down to the fact that the dancing sex alts pay the bills. the voting system grants the masses a sense of ownership because they believe that the system will function to make second life more entertaining. i imagine that several of the employees believe it too.

as long as they believe, they'll stay. as long as they stay, money will be made. the fact that a few developers and content creators get wise, and equally frustrated, and abandon the experiment, is not important in the grand scheme. it doesn't even register on the radar.

the best part is that anyone who argues against the voting board, the residential prioritizing of bugs, or any newly proposed entertainment feature, is tagged as "the bad guy." we are the aliens for trying to edge the masses out of their rightful place as world developers. we are the cancer for saying that the average resident doesn't know a bug from a hole in the virtual ground. see, this is a very effective tool, for what it actually is.

I think this "vote" system is not an appropriate tool for expressing which bugs should be fixed. For a start, 10 votes isn't enough. Off the top of my head, I can name over 10 bugs which I'd like to see fixed.

- llRezAtRoot
- Sim crossing with avatars + vehicles
- Client crashing for no apparent reason
- Server crashing for no apparent reason
- Stalled texture loads
- Rotating an avatar from an attachment
- Prims resizing themselves for no reason while editing
- llGetAgentSize() and their visible height not corresponding
- script bounds-check crashing if receiving an email while crossing sim borders
- if/else if chains in LSL limited to 30(?) nested conditionals
- avatars being invisible for no reason
- Email server stability
- client unable to recover after a burst of dropped packets
- client laggy while typing in a notecard
- items you buy sometimes don't show up in your inventory (can show up later sometimes)
- Everything on the "bugs" page on the scripting wiki

Already, we have a list of over 20 bugs.

A while back, someone mentioned that LL was going to impliment a "visible bug queue" so we could actually see what LL's up to. What happened to that? It seemed like a great idea. Maybe it would be possible to instrument that with a priority vote?

I think what the community is trying to say with this "feature request" is that LL should reconsider the relative importance of new features with bug fixing/stability. Maybe there could be a simple poll, everyone could vote 10 points towards bugfixes vs new features. It would be a better guage of how the community values stability vs features, and would help LL design the developmental roadmap to reflect that

Honestly... You people are being pretty narrow-minded.

By giving us a voting system, the developers now have a way to align, more or less, what they're working on with what their customers want.

When did anyone ever say that something not voted high enough won't be worked on? I have more trust in the common sense of the Lindens than that! If you don't, you need to step back and think if you truly believe this, or if you are just caught up in 'forum drama'.

Some of these technically aren't "bugs."

Par example: one can deduce from the linden ops blog that sim-crossing with vehicles isn't a bug, but a rather large technical challenge. Same with attachments and some inventory/rezzing issues.

I think it's quite a feat that we're able to do what we can do in SL. An entirely in-RAM database that tracks all objects and a virtual-grid system to transfer objects from sim to sim in real time... over a year ago, this wasn't technically possible. Heck, an entirely in-RAM realtime database was almost ludicrous. Each sim has to transfer parts of it's database info + a lot of 3D vector information to the next sim each time you cross in real-time... while this is all streaming to your computer.

Now to weigh in on this thread (a whole 2grams worth woo!) ---

So what?

It's becoming obvious to me that even older players of SL are starting to take the technology of SL for granted.

While I've noticed myself that some bugs still exist and others have been quashed... and while at times I have been a little confused by bug fixing priorities.. none of it has really destroyed my experience in-world.

Where I have a problem with this voting system is that it opens up the community on far too much of LL's priorities. Where non-techies can vote on technical things, where a known bug could be fixed this week, but will wait for the community to vote on it, etc.

In all, democracy is annoying in many ways.

Personally (and this could be taken with a grain of salt), I think LL should do away with this public voting system. Despite cries of favortism, LL should grab up as many volunteers as possible from the community that come from technical training/careers to work on a closed bug-priority list.

Feature requests... whatever. I think the features introduced in 1.6 will be enough for a long while. But having a feature-request voting system isn't necessarily a bad thing... except again, it may provide inaccurate statistical data.

And boy do I love statistics. Interesting but completely useless if you don't get proper sample data.