Seems to me, if you have hundreds of items for sale, at lots of stores throughout SL, it would take you a long time to go through and mark them all for search.

I disagree that "show in search" must be opt-in, rather than opt-out. You already opted into search when you set your parcel to show in search. You had plenty of warning that the system is changing (and continue to do so; the new search isn't live yet). Uncheck those boxes.

Once again, a tiny minority of coders are trying to speak on behalf of the community.

One blog post by Jeska Linden and an ideological support by Joshua on a third-party site do not constitute community opinion.

The community must be warned – and repeatedly – that anything set to sale will be showing up in search.

And that means defaulting the system to NOT show up objects set to sale until people have had plenty of time to make the adjustment.

The reason that there is a known bug mentioned in VWR 3072 is reason enough not to have the default be having "objects for sale" show in search – until that bug is fixed and that problem eliminated, people's privacy should be protected. There is no justification for inflicting this on the community.

There are numerous reasons people set objects to sale that they do not want to be showing up in search, and have no idea they will be showing up in search!

Temporary actions that may still show up in search and cause problems:

o undeeding of TVs – unfortunately, there is no system devised yet to undeed a TV when a tenant wishes to leave a group rental, they have to set it to $0 and buy it back

o group objects are often required to be sold to distribute reimbursements or payments in groups – no other system has been devised for this action

o transfer of any deeded objects to an individual – can only be accomplished by $0 sale

Permanent actions that may show up in search without the knowledge of the 98 percent of the population that doesn't read the blog:

o sale of object for $0 left for a friend, or low cost left for a friend
o accidental set of low price
o experimental set of price while still in testing and only wishing a small circle of people to buy
o sale between members of a household or group

The period of a release candidate review is NOT repeat NOT sufficient period for adaption of a community to deal with this unwanted infliction of global for-sale status.

My choice to resolve the issue was justified on the grounds that this functionality works as LL designed it. BY DEFINITION that makes this issue not a bug; it's a feature request. I asked you to convert it to one. Now I've done it for you. Please don't convert it back. It's not useful to have a bogus bug report. It'll be much more useful if you leave this as a feature request, and get a large horde of your friends to come vote it up as such. That way, LL will know you want this policy changed, and soon. Once you get it over 100 votes or so, which should be easy since everyone agrees with you, then give it a gentle nudge by emailing Torley if she hasn't already noticed it. That's the way to get the change you want.

Prokofy, you have to remember that not everyone shares your opinion. You have an incredibly forceful personality, and you tend to steamroll others' opinions. I know it may seem inconceivable to you, but there may be people who disagree with you, and they may NOT be "just coders who don't know what real users need". You speak for YOU, not for anyone else. Let them speak with their votes and their comments.

The functionality does not work as Linden designed it. Linden designed avatars, objects, etc with checkboxes that you can check or not. From the very beginning, when they designed their SEARCH unlike the Sheep, they made it opt-IN not opt-OUT.

They've defeated their own design by arbitrarily and strangely suddenly deciding to default all for-sale objects to search.

The objects contain no notification that WHEN you put them on "for sale" they are going to default into search. Therefore it is a bug in the design – a flaw in the overall design. They need to become aware of their mistake and undo it. An opt-in search, with check-boxes on each object or avatar or land parcel, is a design decision for opt-in. That means that a deviation from that global design decision, that takes everything that someone marked "for sale," that they DID NOT repeat DID NOT opt-in consciously to search, is a defeat of the design. Indeed, it undermines collaboration with their SEARCH in the worst possible way.

You've already got a coterie of your friends voting here, and I hardly see how calls for people to come and examine what's going on in their name in the JIRA constitutes calling "hordes" of friends. I don't believe in "stampeding" and "flash-mobbing" voters as you obviously do. The idea that you get "friends" to vote "just because their friends" seems awfully pernicious to me.

The idea that a deep flaw in a global design has to get a popular vote and then clear through Torley before a huge barking disaster happens is of grave concern to me.

The main problem here of course is perceived privacy. Wether that perceived privacy in the skybox is true or not is not the thing to debate, though. It's about the impact of ch anges like the mentioned one on a community with that perceived privacy. People wil be irritated by their stuff showing up in search.

The good and sane solution is opt-in. Yes, for some ppl it will be a bit of a pain to list all objects they have for sale again for search - but then, that's a one-time action. And really, LL could just make it easier to flag multiple objects. For example they could offer a "mark all for-sale objects on th is parcel as for-search, too".

Or even better, they tie it to the parcel setting. The time you toggle your parcel from "not in search" to "included in search", the system asks wether all included for-sale objects should be listed in search, too.

Give people a way to efficiently work with their objects and their object listing, but don't throw the vast majority into something they are not prepared to handle right just because some people are lazy and prefer the default-listing out of egoistic reasons.

The argument "had ample time" is void, too. There are still loads of people who don't look at the blog at all - because they just happen to use SL and don't care for the stuff around it. Go out and see who knows about it and who doesn't and you will be astonished how many don't know. And even if they did, many will just look for the "grid borked" posts to see wether something is up or not and skip the tech posts like "hey, new search, read way down into this posting, beyond the fold on the main page, to see how to be prepared and wether you should be prepared at all" ...

The common denominator for residents is the unprepared and unknowing resident. Not the tech geek who hooks his brain to the Blog RSS feed. So make SL understandable to the unknowing resident. The tech geeks can help themselves.

1. The bug is not fixed; it is still live in 1.8.5. The Lindens have so far refused to recognize that it is still live and still a huge problem.

2. The duplication you claim is not true. That bug describes the problem of teleportation to an object.

In 1.8.5, in fact, you cannot teleport to the object. It has no means of teleporting to the object. Indeed, that becomes a problem from the perspective of a large parcel owner who wants people teleporting to an object.

But on a small parcel, it opens up immediate problems because you don't need to teleport to the object to be able to find it anyway.

http://jira.secondlife.com/browse/VWR-2908

Essentially, when Lindens mark something as "internally resolved" it is not REALLY resolved as Ordinal Malaprop has eloquently explained in her proposal here which is to STOP this practice of "resolving" items that are "internally resolved".

When I see that two Lindens have a fundamental disagreement about this issue, I realize that it may never make it out of "internally resolved" status to REALLY get in the client.

Steve is making the same argumentation that some here were making to close this issue – that it is a small subset, that it doesn't matter, everything should be in search regardless of privacy, that it's only on parcels in search (it's not, any object set to show in search shows in search; perhaps this is a database update issue but I'm constantly seeing parcels that I have definitely unchecked and made sure are not in search continuing to show their objects in search). He's also claiming that residents have 4 weeks to fix this (not enough time) AND implying that it IS fixable – it isn't, because you can't physically edit many of these items set to no-mod/no-transfer obviously. You cannot uncheck it when you cannot edit it.

2811 describes teleporting to the object.

3071 describes showing up in search despite being not for sale WITHOUT teleporting – it's just not part of this issue – that doesn't go on with this particular version.

You're implying that the only thing only wrong with this problem is the teleportation. But it's the appearing at all in search that is a violation of privacy and an open invitation to disruption and griefing. You don't need a read beacon to find an object on a smaller lot or even a larger parcel.

When you're ready to remove or modify the description "teleportation to object," then I can consider conflating 3071 with 2811.

All avatars, parcels, and objects have a check box, that makes the inclusion in search OPTIONAL, as in "opt-in" and not "opt-out".

The only place where this isn't happening with a blanket default of objects for sale to show – an "opt-out" that in fact doesn't even work on these buggy non-transferrable objects you can't even edit.

For that reason alone, it should be stopped. Even if that bug of 3072 or 2811 is fixed, there is the separate issue of the global inclusion of content against the community's will. The community has neither had proper notification nor proper participation in this issue.

But this is not a bug. Linden made a decision, to do things this way. And it is being done that way, as they intended.

This means it is not a bug.

From the other issue:
"A flaw in a Linden design principle manifested in all the parts of the design, for which some special policy has to be devised – curiously, and as an aberration – is a bug. It is a mistake. It's a mistake that results from lack of sufficient attention to feedback (people with a stake) in the system. Once the full information and input are available I have no doubt it will be persuasive. After all, the bug was "fixed internally," was it not? And the issue of putting everything for sale in search isn't over yet. I discussed this in the Concierge group today – not a soul had even heard of the issue yet."

A bad decision is not a bug. Regardless of how much you agree or disagree. This design works as linden intended it. This is the definition of a working feature. You cannot change the definition of a word to suit your argument. I have already quoted wikipedia on the definition of bug. Do you want me to start digging through dictionaries too ?

Farthermore, There are people who likely would prefer the way things are being done now. For example, June Dion. Owner of Bare Rose. One of the largest clothing stores in SL. She uses sell contents prims, as opposed to scripted vendors. And has an unimagineably vast product range. I'm sure she wouldn't be too happy about having to manually set the thousands of products in her store, to show in search.

This doesn't mean I agree with the decision. But you must realise that there are other considerations. Other opinions and experiences to take into account, and hence, reasons why lindens made this decision.

Feature request is not perfect, but bug classification is completely incorrect for this.

There are far more content consumers than there are content creators.

It's a bug, because it has unintended consequences and is a design flaw that generated those consequences about which the makers seemed unaware, or even unconcerned.

Is the causing of deformities by Thalidomide a feature or a bug, WarKirby? It's a bug. This is the same, by analogy.

Again, items are showing up in search as the whole parcel under region search even when the parcel is unchecked.

The population has not been alerted to these problems and that compounds the effects of the bug.

We don't need the Lindens to force-populate our world with objects; the world is drowning with objects that will eagerly be put in search by creators who consciously toggle the "show in search".

Items showing up when parcel is not set for search. If you're certain about that, then open a seperate issue. As the title clearly states, this issue is about arguing against the linden policy, not about bugs within it.

Gordon, you're caving to the narrow way of thinking that implies that coders can do no wrong, that only some technical problem can be characterized as a bug. You're satisfying some notion of symmetry, reallocating something that seems like a "feature request" to you not a bug, thereby making a political move – you even think it should be "major," but in fact the way to make it be "major" is to admit it is a bug not some mere "feature request".

I'm simply not going to on on trying to make the point here, moving this back to bug – but I will keep reopening it.

This is a design flaw – it confounds the entire design, which is in every other element has opt-in, not opt-out. It has unintended consequences. Therefore, it is a BUG. It's wrong, and technically malfunctioning, as it has the unintended consequence of putting many, many things into search that people have no intention of having wind up in search, whether the false-flag non-transferrables, which are ostensibly being fixed, or many other things that people do not realize will end up in search.

It costs nothing but their pride for the Lindens who are overriding their own design system to inject an anomaly in the design. They can effortlessly unflag the search to stop it from searching for sold objects, and enable the public to put objects they wish to go for sale themselves.

Again, the invocation of "inconvenience" is a red herring, because people will face just as much inconvenience unchecking things that are not transferrable from search as they would checking things needing to go in to search.

IT'S A HUGE INVASION OF PRIVACY AND CAUSE FOR THEFT.

all objects in your inventory that have "for sale" checked off on them automatically rez out as "show in search" when you rez them out of inventory, necessitating your having to turn off "show in search".

While the fastidious may find this constitutes another bug, I think it's an element of the existing problem that still needs to be turned off.

And your answer is why I asked, nowhere in this issue was inventory for sale defaulting to show in search ever mentioned.

Um, the problem with objects automatically defaulting into "show in search" out of inventory wasn't discovered, der, that's how bugs work, you don't always see them or some element of them until the overall bug or flawed feature is declared as "fixed," then you find out that something is making it "not fixed".

It wouldn't be possible to predict all flawed aspects of bugged/flawed features at the outset of an open-minded rational scientific bug chase.

Therefore any demands that it should somehow be included from the get-go is prescriptive, not descriptive, as bug-hunting should be. Trying to circle around and club a proposer over the head with something not seen or anticipated as an outcome of a bug fix is pretty oppressive and illustrative of bad faith.

And I am sorry if you take my questions and answers as being "pretty oppressive and illustrative of bad faith", they were in no way intended to be that way, you are reading far, far too much into them, what you obviously think is my intention never crossed my mind.

"And your answer is why I asked, nowhere in this issue was inventory for sale defaulting to show in search ever mentioned."

By saying "nowhere in this issue" in that sort of imperative tone, you imply that it should have been included, or its failure to be included is proof of somehow failure of oversight. You imply that this issue can't stay open if it didn't think to include every possible bug outcome created by bug fixes.

Again, I can only urge you to stop trying to browbeat people who have proposals open and attend to your own. I don't "forget to close" issues, Harleen, so cut it out.

As for adding to the description, or posting in a comment, I've just noticed this problem in the last 2 days. And again, you are brow-beating by implying that unless a person keeps trying to update their proposal in real time 24/7 like you lifers on the JIRA, they can't get to keep their proposal open, and that's illegitimate.

I was waiting to see if I could experiment and get this to repeat on the latest version of Windlight. But I don't have to explain myself at all here. Bug off.

So how should I have asked if this bug was fixed and could be closed and not incur your wrath?

Your "testing" here reveals that you just aren't thinking practically and trying to run a business, but merely trying to prove abstract coders' points.

In a practical business experience, you don't want things you put out defaulting to sale without you deciding that it should go on sale.

Things you put out that are marked for sale (a TV to deed, something to give to one person and not the entire world, and so on) shouldn't be automatically going into search.

Everything in SL is predicated on the idea of free will: YOU decide the permissions on your land, on your objects, on your avatar. There are few, if any, forceable actions imposed on you. That's why this design flaw is a serious one.

It doesn't matter if brand-new objects you create since James did this don't show in search. What of it?Unable to render embedded object: File (Things created at that time DO show in search) not found. Who cares if new things don't do that? I have 19,000 old things in my inventory, duh. I don't want this inflicted on them. So do many others.

I happen to go through a lot of inventory lately pulling out very old things and I found ANNOYINGLY that they were automatically rezzing with SHOW IN SEARCH because that's evidently how this worked – everything with sold marked on it was pushed into "show in search". It might have been even marked for sale not by me, but by the seller, that happens frequently, where you buy something or get something inside a prim and it is showing "for sale" still.

If it remained passive in inventory, that didn't matter; rezzing is not the trigger for it, it's mere for-sale checkoff is the trigger, and that's wrong.

I DO NOT WANT OBJECTS THAT I DID NOT DECIDE TO MARK TO SHOW IN SEARCH FORCIBLY BEING PUT IN SEARCH, END OF STORY DO YOU READ ME.

New objects are irrelevant, as long ago, James said he turned this off. But old objects abou in SL; therefore this remains as a problem. I'd like to hear how hard it would be to fix.