Feature voting update - please come add some bugs

Awful lot of supposition there. You honestly think their intent with adding bugs to the voting is so they can avoid having to deal with ones that don't get enough votes? That's exactly what I mean about being insulting. With ghosting you assume the only reason they got around to fixing it was because it hit a critical mass of people screaming. Why do you assume that instead of the more logical assumption that it was tricky for them to fix and took a long time? Are you psychic or do you just like to assume the worst?



Of course it will exist in 1.7. I think to even suggest that is putting you way out in conspiracy theory territory. That's just silly.



That tells me that people are apathetic about submitting bug reports and they're trying to find out if there are bugs out there effecting a lot of people that they're not aware of so that they can move them up their to-do list if something serious is being overlooked. Why must you automatically assume the worst?

How so? Are people going to stop using the forums to voice their opinions? Is LL going to just stop listening to the forums entirely?

Um, I don't believe I said anything about ghosting at all.

I certainly don't read it that way.

I read it as: "Hmm, maybe we should bring this particular issue higher on our priority list, seeing as how our customers have voted it as THEIR top priority."

Same idea with the forums: "Hmm, maybe we should bring this particular issue higher on our priority list, seeing as how our customers are making a lot of noise about it on the forums."

Bug reports: "Hmm, maybe we should bring this particular issue higher on our priority list, seeing as how we're getting a lot of bug reports on it."

etc. etc.

Voting == Another tool for LL to help serve their customers. You and me. Hurrah to Phillip for actually wanting to do that!

Two lists is one of my proposals, and is something that several others have discussed here as well. It's not the preferred of my proposals, by me at least, but it is, I feel, a step in the right direction and seperately treats the priorities of features and bugs. There needs to be a solid commitment from Linden Lab to treat both lists as equals and accept with consistency, however.



How does having people vote, where they cannot submit any further data, help you to get data on these? I'm having a little trouble understanding that one, to be honest. I know proposals can be linked to threads but very few are being linked to threads and I don't suspect that many people would follow those threads up anyway. Especially if they've already previously submitted a bug report or 5 to you.



OK, this thread has not been about voting for features - I have seen almost nobody say that that's not a good idea, contrary to what you may believe. People may have made comments on the way the voting system is organised but I'd be hard pushed to come up with somebody who is dead-set against having a voting system for features. What the discussion on this thread is about is including bugs in that list. In a sense you're removing "ownership" of the bugs from the software writers and placing the ownership and worth on the customers - the reason you won't have seen many software companies do this is because it's just not the way you present yourselves to customers. You don't say "we're not going to fix any bugs, unless you can all get together and make us". That's showing great disrespect for your customers, and giving an impression that you're not committed to fixing them.

You know though, I'm going to do what you ask. I've just ordered myself a copy of Wisdom of The Crowds, as it appears you've been quite taken with this book and I'd like to understand why. The only real way I can do that is to read it, so I will. Plus, I've just finished "The Time Traveller's Wife" and need something a little more linear for my own sanity (very good book BTW)

Well, I think the decisions *should* continue to be made by a very few smart people.

However, those smart people whould be wise enough to research the forums, check out the polls and alter their perspective accordingly.

Yes there is supposition, as there has been in your replies as well from what I've read. You've supposed that they won't just use the voting list to decide their priorities, for one. They've hardly been pro-active on bugs, to say anything other than that would be a level of rose-coloured glasses that would weight your head down and break your neck I assumed that the only reason they solved object ghosting in 1.6 is because they had done nothing about it in 1.6 until people went balistic on the forums. I think that's a fair assumption all things considered, especially in view of how much it had been discussed over so long a period prior to this. It didn't actually take them long to resolve it once they had to though. Did you notice that? It's not about assuming the worst, it's about seeing how it played out.



I said dunno. I didn't suggest it would, so please stop with your rhetoric about "conspiracy theories" - you see you're falling back into the trap of de-valuing my opinion by making me out to be a crack-pot or something. You didn't on your previous post, why do you feel the need to do so again now? Linden Lab have often done things you didn't expect. I said I don't know as I couldn't say for certain that they wouldn't - anything is possible. but it's moot anyway, as they rarely lead to any action.



That's a big assumption from you again there Chip. Are you telling me that they weren't aware of object ghosting before they fixed it? Do they read their own forums? They must of been pretty blind to miss that over the course of months, musn't they! I know I submitted bug reports on it and I know many other people did as well. Wow, when their own mentors were telling me at show and tells when I first joined how we should remove our objects so they didn't ghost, you'd of thought they'd known about that. And that's just one example, but it's a good one, because it highlights the inaction on Linden Labs part.

As many people have seen, and has come up recently as well. There are 'correct and accepted' ways to let Linden Labs know about problems, and there are other methods that they provide that they don't treat as correct. Pathfinder Linden recently said that the technical issues forum was not to be used with the expectation of a Linden response. There's one example for you off the top of my head. Oh and here's another. I submitted a bug report as I crashed constantly in 1.6 - no response for days. i was then told by a Linden that the best way was to email [email]support@lindenlab.com[/email] - no response for days. In the meantime somebody on the technical issues forum happened upon shadows being turned on causing the crash - it was all over the technical forum. Got a response from Linden Lab some days later basically saying to turn off anti-virus, check drivers etc. - the usual. You see, the avenues they give us are often the wrong ones to use according to them, so I see this as being no different.



No I used it as an example of how you said a voting system would allow them to distinguish between a real hot topic and forum drama. The only reason object ghosting was fixed was because so many people were angry that it wasn't fixed in 1.6, thus forcing their hand through your so-called 'drama'.



Really? I read it exactly the way it's said.

OK, I need to switch off for tonight as I need some sleep. Don't think I'm ignoring, I just won't be able to respond any further until the morning to continue this almost pointless conversation

No, it's all about you assuming the worst. The fact that ghosting was such a well known and complained about issue is exactly what makes your supposition illogical and unfair. Your whole theory is based on the assumption that LL is apathetic about fixing bugs, which (pardon the frankness) is irrational. Ghosting was annoying but that's all it was. It didn't prevent people from being able to log in. It didn't cause crashing. It wasn't a show stopper for anyone. It stands to reason that it simply wasn't a high priority because it was only an annoyance bug and they devoted their limited resources to more serious problems and to adding new features (so they can attract more users, make more money, hire more developers, and fix more bugs). LL has also said on numerous occasions that ghosting was difficult to fix. And guess what, it got fixed!



Yes, actually you did suggest that voting would be the only means of submitting bugs, hence my reply to the suggestion. I didn't just pull that out of thin air. Whether it was just sarcastic or serious only you know.



ummm, guilty as charged... because I think you're being a bit of a crackpot.



I feel the need because overwhelming negativity annoys me. People who assume that because things aren't being done exactly the way they feel they should be done that it must be the result of negligence, lazinness, or ineptitude... that annoys me. It's rude and unhelpful.



Of coure they were aware of it! Perhaps it just took a long time to fix because it took a long time to fix?! No? Too logical? It must be because they don't care about their own product or the experience of their users. Yeah, that must be it. I tend to give LL the benefit of the doubt because they've demonstrated to my satisfaction that they care a great deal about those things, and they're proving it to me again right now by experimenting with new ways to better prioritize bug fixing...



That must just be PR



[sarcasm]I'm sure it was a super simple fix and it just took so long because LL doesn't care.[/sarcasm]

I think LL deserves a lot more credit than that.

Yes, I'm reading further into it than what it really says. And so are you, because nowhere in that sentence does it says that those bugs will be the ONLY ones to be fixed.

Taking the literal meaning, we get.. nowhere. Bugs voted highly will be added to the priority mix.. ok, so?

So beyond the literal meaning there are 2 proposals:

1. Bugs/features voted highly are the ONLY ones to be taken care of.
2. Bugs/features voted highly will tell LL what we want to see taken care of first.

Which makes more sense? Honestly.

Actually, ghosting was fixed because a resident found a reliable way to reproduce it every single time, and bug reported the exact step-by-step procedure to do so.

If everyone would do that, we would have a lot fewer bugs, becuase most of the time spent fixing them is spent trying to find a way to reliably recreate them so that their source can be found.

Bugs need identifying, much more than voting, and once identified they must be fixed as a matter of elementary dev-team professionalism. This has absolutely nothing to do with feature prioritization. We should expect dozens of bugs to be fixed every week and applied during a regular weekly maintenance slot, without waiting for major patch times.

If a *SEPARATE* bugs forum has a voting facility attached to it then that's fine, but there certainly must not be any limit on the number of bug-votes available to people. Let them register an interest in all bugs that concern them, without limit, and only one vote per bug is ample for that. All bugs must be fixed.

The key thing about bug forums is the discussion area where bugs are examined and detailed and become better understood. Voting is just an auxiliary item of less interest --- ALL bugs must be fixed.

My alt promptly dropped all her votes on this feature proposal With a few more volunteers, we'll have that proposal reaching the first page in no time. And as you all know, the higher on the first voting page a proposal is, the higher the probability of more people voting on it.

Yes, although I love the voting system, I also agree that "bugs" and "features" are two different things and should be kept on different queues.

And there are lots of tiny little things that have to be implemented on this feature voting list as well. However, it's best to start from a "working base" and discuss what needs to be fixed, than to "imagine" what a voting system should be and talk about it for ages and never reach a conclusion...

Kudos for Azelda Garcia for having put up a workable feature voting system which captured LL's attention. Now we just need to polish it to make it workable

I 100% disagree that we must fix all the bugs as a matter of principle. We launched SL knowing that the complexity of the content would create more bugs than we could fix. For example, there are hundreds of commands in the LSL scripting language, almost all of which can be used in some interdependent way. Fully testing the language would therefore be impossible for even pairwise interaction tests (100x100 for example is 10,000 test cases, and we have MANY more testable cases than that).

I think that the fun and learning and freedom that SL has given people so far is well worth the bugs. It would be a loss to everyone if we had decided that SL had to be bug free before launch, or that version 1.1 had to fix every identified bug. I stand behind that decision.


Therefore, what we need is help with priority, not a mandate to fix every open bug. We currently fix about 20 or so bugs per DAY on average. That isn't going to close all of them any time soon, but with help we can close the right ones to make SL better fast.

Philip, that is entirely incorrect, and this is an area in which I have spent my whole professional career.

It is only latent bugs in software that are inevitable, but once a bug is identified and hence no longer hidden, it is pure and simple professionalism to eliminate them as promptly as possible, as a matter of simple developer integrity. To run a pace of development in which new features outpace bugfixing effectively means supporting a poor quality end product, and it's on a hiding to technical disaster.

As you point out, bugs are geometrically compounded, but what this means is that unless you eradicate them, your system will pretty soon be 100% unusable. It is only latent bugs, and hence undiscovered and thus not yet harmful ones, that can safely be left to appear in their own time.

Bugs have nothing to do with untested states in a computer language.

If it were so, all languages on the planet would be riddled to their back teeth with bugs and completely unusable, since none of the states defined in a user's application have ever been tested by a language designer.

For a system that is tweaked and poked through a computer language, in the way that LSL allows for some control of SL, the only entities that need testing are individual LSL functions applied to the arguments for which they are defined, and testing that is a normal task for the developer who creates the functions or the objects to which they are applied. No doubt you have a test harness for automated regression testing of all that anyway.

What any individual script does with functions is totally out of bounds for testing, indeed it is theoretically untestable for any Turing Machine which LSL implements by equivalence. This is no research area at all, nor does it require an "All Hope Is Lost" approach.

Bugs are all fixable once identified, and only intermittent bugs resulting from race conditions and asynchronous exceptions are in any way "hard". Any developer suggesting the contrary is simply avoiding the unsexy work of tidying up after his or her poor hacks.

Wow, I really am going to give this conversation a wide berth in future if this is your attitude Philip. We're not actually asking you to fully test, we're asking you to fix bugs when they come up. And yes, make a commitment to fixing those bugs. You seem to be saying that you've always been aware that you won't be able to address all bugs, so presumably you have always been aware that bugs will end up compounding long term?

Nobody sensible would try to say that there will never be bugs that crop of in Second Life, due to the complex nature of what you can do in the system, but I think it's reasonable to expect a software company to make a commitment to solving those bugs as they arise - it's in your own interests as much as anything. And it is a matter of principle. Sure not everything can happen straight away, but there has to be a commitment towards resolving all bugs that are highlighted. I think the problem, to a certain extent, is that your own quality control has been extremely poor and bugs have been left to mount over many, many months (and it appears from what you've said that you've always been aware that this would be the case and accepted that premise without thinking that it's going to cause a major long term problem.) That's Linden Lab's fault, not the users. You're now having to justify why it's not feasible to clean up the mess you created by suggesting that we would of all lost out if you had to fix bugs. That justification is flimsy at best and to continue in this fashion would be to further compound your issues in the future.

If you are fixing 20 bugs a day on average, I'd suggest it may be in your interests to document this to the users. Are these bugs in the live system or bugs in code for features yet to be released? There is an important difference. 1.6 didn't have anywhere near this number of bugs listed as fixed. If you are honestly fixing so many then it may be better to make the users aware of this. Your bug queue (http://secondlife.com/support/bugtracker.php) would be a perfect place for this but there does not appear to have been much action on this since 1.6 was released. I can't see 20 a day on there, which I'd expect to, but then it's difficult to interogate this system to get at that sort of information. And if the excuse is that the bug queue system isn't being used for the majority of bugs then I suspect you need to re-think this with relation to quality assurance - we've all been aware of "undocumented" changes that have crept into SL releases and have often been something the community has expressed dismay at.

Open source the client. If the company can't keep up with its own bug rate, we can, at least for this part of the system which is just a millstone around developer necks anyway.

20 bugs/day refers to the internal rate of closure (we use bugzilla) near release and during patching of the new release (like the 1.6.x releases). So, for example, when we are patching about once a week, we are probably fixing around 100 bugs per patch. Many are below the threshold of what goes into the release notes, and as discussed, some are not really bugs but refinements to features.

It feels to me like we need to get better visibility for everyone into the buglist - probably the only way to get to some sort of agreement on what we are doing right or wrong.

Try this, Philip --- purely internal, with no external visibility.

1. Attach owners to source modules --- if multiple contributors, still name only one owner, and it has to be a hands-on programmer.

1. Increment module bug counts for each bug reported --- if many modules are affected, limit the increments to no more than 3 or 4 modules, to avoid the "Haha, we've all got bug counts, let's do nothing" syndrome.

1. Post up the module / owner / bugcount lists each week for all to see (purely internal). Two fixrate columns will help, this week's and historical.

1. If there is a majorly excessive bugcount against one particular owner, pull in a firefighting team to handle it as a matter of urgency.

1. Don't let designers get away with lack of accountability: mark up some complaints as design bugs, and let designers "suffer" the same need for good work.

Variations on this theme have worked in several companies I've been in. There is nothing quite like personal responsibility and reputation to get quick action on bugs. And there is nothing quite like lack of accountability to encourage growth in bug lists.

You know I'm kind of interested in the fix rate for existing issues, excluding bugs as part of the development of new features (although bugs and obviously need to be resolved, they are for things still in development) or issues newly created by a major release (possibly poor QA or a testing regime, including preview here, that isn't working well for you - for whatever reason) for the moment. Do you have any stats on fix rates for existing issues at all? And any idea of the current outstanding volume of existing issues? And what's the average time an existing issue is in your bug system before it is resolved?

Also, what decision making currently goes on to decide if a bug is worth fixing or not at present? Maybe some of this information may help the community understand what's going on and help towards visibility which I agree would help a lot.

Design bugs for raising the designer's bugcount are typically somewhat elusive to tie down, so here's a simple example. And it's just an example --- the substance of it is irrelevant here.

Currently if you position your camera far from your avatar and go into Appearances mode with both your camera-movement controls unselected (ie. no movement thanks), then on entry to Appearances the camera moves a bit, and on exit from Appearances the camera is given a wholesale reset and you're right up close to the avatar again, despite explicitly not wanting movement.

Now, this cannot be viewed as a coding bug because everything works as intended --- it's just that the intention is clearly wrong, ie. it's a design bug. No code bug squisher will touch it, because the code isn't broken per se, ie. the code doesn't fail in its purpose. So, without the designer modifying hiis or her part of the product, this would never be fixed --- hence the need for lists of design bugs too.

In general, to spot a design bug you need to look for either an inconsistency (as above), or an inflexible feature after someone points out a much more flexible approach, or an absence of control points or hooks for commonly-requested actions, or simply an obvious lag behind the competition in some key (but still reasonable) area. It's hard to generalize, but once you identify a design bug, it becomes very visible and glowing in evil red.

Frankly, appeasing the masses with the current voting tool seems to be working quite well. I see no reason for you to refine that process at all. However the people posting in this thread are not the masses. We are concerned professionals that want to help LL develop Second Life. If you're going to talk to us constructively, shift out of mass marketing hype mode and treat us like brainiac technichians pounding out code in a windowless closet. We're not the crowd; we're people that want to eventually use your software for a vast array of projects that don't even remotely resemble a video game. As a bonus, we don't mind paying inital purchasing costs and annual licensing fees.

What I can't figure out is whether you're afraid of mass revolution promtped by perceived favourtism or you just really don't want our help. If the latter is true, please say so. If you do, listen to us when we tell you what we can and cannot do to contribute to the product's development.


Be the host.

SourceForge.

LL would need to set up the SF project in the way most suitable for them, since they will want to update the client regularly to match the server end. And if you recall the Town Halls before Xmas, LL acquired venture capital and part of it was expressly intended for manpower to oversee open-source projects.

Of course we'll be helping massively! I'd be delighted to work on bug fixes off a Bugzilla list, not only on my own improvements as per my sig links. In fact, fixing bugs is an excellent stepping stone for getting to know the source, and no doubt many FOSS developers will take that road.

Maybe he's just unimpressed by self important arrogant know it all blowhards.