SUBMITTED (24994) - [FEATURE] option to ignore all caches hidden by x user

[+HHD]

Can we please have this feature to help weed out caches by habitually poor maintainers & hiders. It should be a simple thing to implement. I realize we can ignore individual listings but not all of one cos hides at once. There are some cos in my area with over 500 hides.

 

Ps I know this option is available with gsak but I don't use it and would like not to have to to have my problem resolved. So please leave gsak out of the debate.

[Moun10Bike]

We currently have this request in our database.

[+HHD]

Ok any I could get a link to the thread?

[Moun10Bike]

There is no thread to which to link you; it is an entry in our internal database referenced by the number I added to your edited topic title.

[+HHD]

Anyone have an opinion? I really don't want to have to start using gsak.

[+TheLoneGrangers]

I agree with you, great idea.

[+niraD]

Also, with this feature available, those who create numbers run trails like the ET Highway trail or the Route 66 trail could stop abusing the scuba attribute. Seekers could filter based on the account that owns the numbers run trail caches, instead of filtering based on low-terrain scuba caches in the desert.

[+Ambient_Skater]

Anyone have an opinion? I really don't want to have to start using gsak.

It is in the database. Any more opinions won't make a difference. You will have to use GSAK or manually ignore the caches individually.

[+northernpenguin]

Also, with this feature available, those who create numbers run trails like the ET Highway trail or the Route 66 trail could stop abusing the scuba attribute. Seekers could filter based on the account that owns the numbers run trail caches, instead of filtering based on low-terrain scuba caches in the desert.

Or, alternatively the reviewers could start challenging bogus attributes like that (or we could just remove attributes as a failure)

[+HHD]

Anyone have an opinion? I really don't want to have to start using gsak.

It is in the database. Any more opinions won't make a difference. You will have to use GSAK or manually ignore the caches individually.

 

Not if gs gives us the option to ignore all caches by user.

[+Ambient_Skater]

It is in the database. Any more opinions won't make a difference. You will have to use GSAK or manually ignore the caches individually.

Not if gs gives us the option to ignore all caches by user.

Don't hold your breath. Just because a request in the database doesn't mean it's planned to be implemented. Think of it as asking someone to do something and having them reply "We'll see." You might get it soon, you're more likely to get it later, but it's also possible you won't get it at all.

[+cerberus1]

I posted this in geocaching General topics, but apparently, this area, the Big Guys read...

 

Many forum regulars are saying that GSAK handles this and that's what we should probably do too. Some claim an ignore feature's a lazy way around filtering.

My reply:

 

First off, I'm not a lazy cacher. Anyone who looked at our profile pics can tell.

If anything, I apparently work harder at finding caches I'll do, rather than "throw everything in and go."

This GSAK business may be fine for those who want a couple of thousand caches in their GPSr or phone. Those who'll look for anything anywhere may find GSAK helpful.

 

I still search by "from your home location" or "newest in my state" and sometimes look to see what's new in Jersey.

Many must still use this "old" style of searching, or they'd have been long gone in an update, if GSAK was the norm.

Don't forget, these forums are comprised of less than a percent of the total caching population. Many of us may not be as tech friendly as forum regulars.

 

I'm now around page 34 if I want a decent hike and "ignore all caches by X" would clear up the guard rail, pmo, lamp post skirt, etc. caches I'll never do.

They're all done by the same COs, so "ignore all caches by X" would work great.

BTW, most of those cOs know why I haven't done them (many within biking distance of home) and you know what? Doesn't bother them in the least.

They realize that not all are in for the numbers and we get along fine.

 

So I believe a "ignore all caches by X" would be a needed, welcome feature for less tech-savvy folks and those who don't care to use (yet) another added app.

 

Thank you for your time.

[+HHD]

Thanks for the support

[+HHD]

Bump

[Moun10Bike]

There's no need to bump threads that have already been responded to by Groundspeak.

[+edscott]

Since we can no longer vote for the features that are most important to us what other recourse do we have beyond bumping the thread?

[Moun10Bike]

There's no need for voting of any sort. We make decisions on what to implement based on user feedback received from multiple channels along with established long-term goals and plans.

[+edscott]

Since we can no longer vote for the features that are most important to us what other recourse do we have beyond bumping the thread?

 

There's no need for voting of any sort. We make decisions on what to implement based on user feedback received from multiple channels along with established long-term goals and plans.

 

Translation: NONE

[Moun10Bike]

Translation: NONE

 

This sort of sniping is completely unnecessary and counterproductive in this forum. This request is already in our database and in our list of "hot topics". But if it makes you feel better, go ahead and bump it all you want.

[iryshe]

This is so low on the priority list I sincerely doubt it will ever be implemented. The major reason is that it has a high difficulty to implement with a very low number of users that would take advantage of the feature. We're more likely to work on projects that have a higher result with a high difficulty project.

[+Ambient_Skater]

This is so low on the priority list I sincerely doubt it will ever be implemented.

You've really done it this time, haven't you edscott?

[jholly]

This is so low on the priority list I sincerely doubt it will ever be implemented. The major reason is that it has a high difficulty to implement with a very low number of users that would take advantage of the feature. We're more likely to work on projects that have a higher result with a high difficulty project.

I agree 100%. For users of a certain 3rd party software this is a fairly simply and painless task to accomplish.

[+edscott]

This is so low on the priority list I sincerely doubt it will ever be implemented. The major reason is that it has a high difficulty to implement with a very low number of users that would take advantage of the feature. We're more likely to work on projects that have a higher result with a high difficulty project.

 

Good... A real answer. That's my point. I could care less about the feature itself, but we should get concise truthful answers, not an its on the list so don't ask again approach.

[+DanPan]

We're more likely to work on projects that have a higher result with a high difficulty project.

I agree 100%.

Wherigo Beta, Geocaching Maps Beta, Geocaching Live Beta, Wherigo Builder Alpha (last update 2008), ...

Edited December 31, 2011 by DanPan

[Moun10Bike]

Good... A real answer. That's my point. I could care less about the feature itself, but we should get concise truthful answers, not an its on the list so don't ask again approach.

 

I'm sorry that my response came across like that. My only intent was to say that once we have an idea in our database, simply bumping a thread with no additional commentary or explanation for why the feature is needed has no effect on our decision making process.

[+Chokecherry]

Seeing as submitted may not actually mean anything (as noted up thread) maybe there could be some note about the probability that a submitted idea will actually come to fruition.

[knowschad]

Seeing as submitted may not actually mean anything (as noted up thread) maybe there could be some note about the probability that a submitted idea will actually come to fruition.

 

+1

 

Too many games of this sort are being played regarding requests. I found Jeremy's reply to be extremely refreshing, regardless of how I feel about the request!

[Moun10Bike]

knowschad, your comment is absurd and insulting. We are not "playing games" with requests. We have made a point to clarify just how much of a backlog we have and that we cannot accommodate every request posted in the forums, or even answer them. This sort of comment does not further discussion along in any way.

[jholly]

knowschad, your comment is absurd and insulting. We are not "playing games" with requests. We have made a point to clarify just how much of a backlog we have and that we cannot accommodate every request posted in the forums, or even answer them. This sort of comment does not further discussion along in any way.

 

This is not a criticism, but a suggestion to improve the already valuable communication.

 

I never thought you were playing games, but a Declined/Submitted divide is pretty broad. Submitted would imply the idea was accepted and that there is some reasonable chance in some period of time for the suggestion to be acted on. But the one commented on by Jeremy certainly sounds like it will never see the light of day. Maybe you need some graduation of of submitted. Perhaps something along the lines of Submitted - it is in the active queue, Considered - it is in the standby queue and if we can grab it and do it we will, and then Snowball - about the same chance as frozen water in a hot place. It would seem to me that the one commented on by Jeremy should be rated as Snowball. Or maybe it should have been labeled declined right off the bat with the explanation that only a limited few would use the feature at a high development cost. There is nothing wrong with that as an answer.

 

The other thing that might help perceptions is to blow your horn a bit. Nate just mentions the fixes by ticket number. But until this thread there was no way to tie that back to a specific suggestion. I'm sure come the update later this month there will be quite a section on the revised cache submissions, as there should be. But if you also implemented some forum suggestions put those in their own section so we can tie the updated feature to a forum suggestion. Then the bug fixes, and especially if they were [bUG] submissions from the forum.

 

I do like the forum as a better medium. The voting thing just lead to false hopes and frustrations.

[Moun10Bike]

Thank you, jholly. I'll investigate ways to make the "process" that our bugs and feature requests go through more transparent to forum readers without setting up unrealistic hopes. I'm sure everyone would like immediate and definitive answers on everything posted here as Jeremy did above, but as you might imagine no one but Jeremy has the authority to make that sort of call.

[Sandy]

Hi all,

 

What we hope you realize is that we aim to reply to these reports or feature discussions in a timely and informative manner. There is no playing of games. Not only do we not want to do that, we simply do not have the time to dedicate to messing you about.

 

The team that works to troubleshoot issues, discuss and consider feature requests and report these matters to the engineering team, has a variable workload. At times we are able to step into the forums more actively, because the many other aspects of our work are taxing our time less. But there will be times when the response our users get is succinct, because we are working on more of the back-end stuff. At no time are we sitting around plotting ways to mess our users around.

 

And when those sorts of comments are posted in our forums, our time is then spent addressing behavior that violates forum guidelines. This is frustrating, as we would rather spend our time working on bettering the site for you.

 

And as always we greatly appreciate the time and effortsof those who take the time to post requests and report bugs. Thank you.

[+Der Wald-Pirat]

This is so low on the priority list

 

Please take this idea down from the priority list. The proposal is a very bad one. It can only help to discriminate some users by other users who don't like them.

[iryshe]

We're more likely to work on projects that have a higher result with a high difficulty project.

I agree 100%.

Wherigo Beta, Geocaching Maps Beta, Geocaching Live Beta, Wherigo Builder Alpha (last update 2008), ...

 

Yep. All of these are low priority with the exception of the Maps, which we're actively working on now.

[+baloo&bd]

It can only help to discriminate some users by other users who don't like them.

 

Ummmm...I think that is the whole idea.

Edited January 6, 2012 by baloo&bd

[jholly]

We're more likely to work on projects that have a higher result with a high difficulty project.

I agree 100%.

Wherigo Beta, Geocaching Maps Beta, Geocaching Live Beta, Wherigo Builder Alpha (last update 2008), ...

 

Yep. All of these are low priority with the exception of the Maps, which we're actively working on now.

Glad to hear that, thanks!

[jholly]

We're more likely to work on projects that have a higher result with a high difficulty project.

I agree 100%.

Wherigo Beta, Geocaching Maps Beta, Geocaching Live Beta, Wherigo Builder Alpha (last update 2008), ...

 

Yep. All of these are low priority with the exception of the Maps, which we're actively working on now.

Dang, does this mean the api is going to slowly die? That would be most unfortunate.

[Moun10Bike]

He's referring to http://live.geocaching.com, not http://www.geocaching.com/live.

[jholly]

He's referring to http://live.geocaching.com, not http://www.geocaching.com/live.

Whew, thanks for straighten me out. I'll go and stand in the corner now.

[GOF and Bacall]

Ok. You aren't playing games. But to be honest it sure feels like we are being strung along on this stuff. It's in our data base. It's on our list. We've created a ticket for it. It always sounds like we are gonna see something happen. And now we get "This is so low on the priority list I sincerely doubt it will ever be implemented." and "Yep. All of these are low priority...". I'm not trying to be nasty, but you can see how it appears from our side. It feels like Groundspeak has just been telling us what we want to hear with no intention of actually doing these things.

[Keystone]

I think it would be a really good idea for this thread to steer back to relevant posts about the option to ignore all caches hidden by x user.

 

jholly did offer a constructive suggestion. Consideration could be given to splitting that off into its own thread.

 

Thank you everyone in advance for staying on-topic, which helps in the orderly administration of the features and bugs forums.

[+HHD]

Wow...interesting read. I'm so proud of my little post. I'm saddened that it probably won't become a feature and I'm being forced to use gsak but I get it. You have other priorities that are higher on the list and have limited resources with which to accomplish your goals. I'm happy that all this bickering at least got me an answer. I guess I just need to figure out how to use gsak.

 

On a side note...what about you guys buying gsak an incorporate all the "great" things it does into the site everyone uses?

[+baloo&bd]

On a side note...what about you guys buying gsak an incorporate all the "great" things it does into the site everyone uses?

 

Because, and this is not a slam on GS, they can not support it to the degree that Clyde does/can. This is one of the main things that made it so wildly popular.

[+Frank Broughton]

This is so low on the priority list I sincerely doubt it will ever be implemented. The major reason is that it has a high difficulty to implement with a very low number of users that would take advantage of the feature. We're more likely to work on projects that have a higher result with a high difficulty project.

 

Good... A real answer. That's my point. I could care less about the feature itself, but we should get concise truthful answers, not an its on the list so don't ask again approach.

response redacted..

Edited January 8, 2012 by Frank Broughton