Jump to content
Sign in to follow this  
Followers 5
Doc_musketeers

How to deal with negligent CO

Recommended Posts

5 hours ago, justintim1999 said:
9 hours ago, niraD said:

There are more choices than that. For example, Groundspeak could change the CHS system to better accommodate false positives.

That was one of the two options I gave,  tweak the system.     Unless you're talking about taking dnfs out of the equation all toghther  which I personally don't think they should do. 

I see them as separate changes. Tweaking the system is the ongoing updating of the formula that determines which caches get flagged and which don't. The change I linked to fixes the basic issue that the system does not accommodate false positives, and the team at Groundspeak that is tweaking the formula cannot learn from the false positives. If they fix that basic issue, then the tweaks (or the actual logs that violate some ideal of people are "supposed" to log) will cause fewer problems.

Share this post


Link to post

Here's another example of why even long strings of DNFs don't mean a cache needs maintenance. GCT2V1 a D3.5/T1.5 multi, 10 DNFs in a row including two from me but, admittedly with the aid of some help from a previous finder, I made another attempt this morning and found it, everything intact, right in the middle of where three Blind Freddies were searching much of yesterday afternoon. It's been right there all along, laughing at us, since its last find almost two years ago.

  • Upvote 2

Share this post


Link to post
46 minutes ago, barefootjeff said:

Here's another example of why even long strings of DNFs don't mean a cache needs maintenance. GCT2V1 a D3.5/T1.5 multi, 10 DNFs in a row including two from me but, admittedly with the aid of some help from a previous finder, I made another attempt this morning and found it, everything intact, right in the middle of where three Blind Freddies were searching much of yesterday afternoon. It's been right there all along, laughing at us, since its last find almost two years ago.

Did the owner get an automated low CHS email?

Share this post


Link to post
9 minutes ago, L0ne.R said:

Did the owner get an automated low CHS email?

I don't know but next time I see him at an event I'll ask him. In all likelihood he might have had several. But if he didn't, why did my D2.5/T5 get one after just one DNF?

Share this post


Link to post
On ‎12‎/‎14‎/‎2017 at 3:11 PM, dprovan said:

A third option is to give up on the CHS, but that's obviously not going to happen because GS is wedded to the idea that CHS is the Big Solution to a Big Problem. So a fourth option is to recognize that the CHS is only a tool, not a decision maker. The only reason false positives are a problem is because cacher's see them. If GS stops using the CHS to send automatic warnings and doesn't use it to create this "your cache is bad" list on the profile, then the problem of false positives is reduced to cases where a reviewer takes action against a cache based on the CHS alone without evaluating the cache directly.

Obviously GS developed a metric for identifying caches that may need attention.  There's no reason not to believe that the standards the CHS uses are the same ones reviewers have been using all along.    If that's true than the caches being flagged by the CHS would have been flagged by a reviewer doing a manual sweep.   So instead of a reviewer having to do a manual search the CHS preforms that search for them and generates a list of caches for the reviewer to look at.  What happens next seems to be the whole point of contention. 

I have no problem with the automated e-mail.  I've already explained why that makes sense.  

I have no idea what the CHS report looks like or what information is contained in it.   For all we know it could have all the relevant information needed right on it for a reviewer to make an informed decision without having to visit each and every cache page.

I have a hard time believing reviewers are disabling caches because the CHS said to.  

Share this post


Link to post
On ‎12‎/‎15‎/‎2017 at 8:52 PM, barefootjeff said:

Here's another example of why even long strings of DNFs don't mean a cache needs maintenance. GCT2V1 a D3.5/T1.5 multi, 10 DNFs in a row including two from me but, admittedly with the aid of some help from a previous finder, I made another attempt this morning and found it, everything intact, right in the middle of where three Blind Freddies were searching much of yesterday afternoon. It's been right there all along, laughing at us, since its last find almost two years ago.

I'm sure you could cite dozens of examples of caches that have been flagged that possibly shouldn't have been.    In my opinion the problem is, with 10 dnfs in a row,  the cache meets the general needs maintenance requirement. 

In these cases the cache owner needs to be proactive.   After three or four dnfs the cache owner should check up on it and post a OM that everything is good.   This may have to be done a few times before a reviewer sees and understands that either the D or T needs to be tweaked or it's simply a hard cache to find.  As a cache owner you just can't  ignore potential maintenance problems because your local caching community is having a hard time finding the cache.    

I'd bet that if you took all the caches out there with 10 dnfs in a row,  at least 8 out of 10 of them would be missing.       

  • Upvote 1

Share this post


Link to post
6 hours ago, justintim1999 said:

I'm sure you could cite dozens of examples of caches that have been flagged that possibly shouldn't have been.    In my opinion the problem is, with 10 dnfs in a row,  the cache meets the general needs maintenance requirement. 

In these cases the cache owner needs to be proactive.   After three or four dnfs the cache owner should check up on it and post a OM that everything is good.   This may have to be done a few times before a reviewer sees and understands that either the D or T needs to be tweaked or it's simply a hard cache to find.  As a cache owner you just can't  ignore potential maintenance problems because your local caching community is having a hard time finding the cache.    

I'd bet that if you took all the caches out there with 10 dnfs in a row,  at least 8 out of 10 of them would be missing.       

You still don't get it that some caches are meant to be difficult to find. DNFs are expected to be common. That cache is a D3.5 because it's hard to find. Why does it still need owner attention after every three or four DNFs? It already has a high D rating, why does it need further tweaking? And what about the D5 tower one? How can you increase the D rating of a D5? And why is it a maintenance problem if a high D/T cache that's expected to get lots of DNFs gets lots of DNFs?

  • Upvote 1

Share this post


Link to post
12 minutes ago, barefootjeff said:

You still don't get it that some caches are meant to be difficult to find. DNFs are expected to be common. That cache is a D3.5 because it's hard to find. Why does it still need owner attention after every three or four DNFs? It already has a high D rating, why does it need further tweaking? And what about the D5 tower one? How can you increase the D rating of a D5? And why is it a maintenance problem if a high D/T cache that's expected to get lots of DNFs gets lots of DNFs?

I get it,  I just don't think the whole CHS should be scrapped because of it.    Sorry if you've already posted it but do you have the GC code for the tower cache.   I'd like to take a look at it.    Thanks

 

Share this post


Link to post
15 minutes ago, justintim1999 said:

I get it,  I just don't think the whole CHS should be scrapped because of it.    Sorry if you've already posted it but do you have the GC code for the tower cache.   I'd like to take a look at it.    Thanks

 

The tower one is GC4ZAZH, a magnetic micro somewhere on a 40 metre high steel observation tower. It's a D5 and gets lots of DNFs because it's meant to get lots of DNFs. It's not missing and it doesn't need constant maintenance because of those DNFs. You keep saying any cache with three or four DNFs needs owner attention, and while that might be appropriate for a D1 or D1.5, it shouldn't be the case for higher difficulty caches like a D3.5 or D5 because they're supposed to get lots of DNFs.

Edited by barefootjeff
Grammar

Share this post


Link to post
22 minutes ago, justintim1999 said:

I get it,  I just don't think the whole CHS should be scrapped because of it.

Most of us are not calling for the CHS to be scrapped. We're just saying that false positives are a fact of life, and the system needs to be structured to better accommodate false positives.

Share this post


Link to post
20 minutes ago, justintim1999 said:

I get it,  I just don't think the whole CHS should be scrapped because of it.

I'm not saying the whole CHS should be scrapped because of it, I'm saying the CHS (or anyone else) shouldn't be using a DNF count or a DNF-to-find ratio to infer poor cache health on a high difficulty cache that's meant to get lots of DNFs.

Share this post


Link to post
10 minutes ago, barefootjeff said:

I'm not saying the whole CHS should be scrapped because of it, I'm saying the CHS (or anyone else) shouldn't be using a DNF count or a DNF-to-find ratio to infer poor cache health on a high difficulty cache that's meant to get lots of DNFs.

That too. But if the system was fixed to better accommodate false positives, then these particular false positives would cause less pain as well.

Share this post


Link to post
16 minutes ago, niraD said:

That too. But if the system was fixed to better accommodate false positives, then these particular false positives would cause less pain as well.

And that's the key.  Strings of DNFs on caches that are missing have always been a headache for finders when COs don't follow up. Scrapping DNFs from the CHS algorithm altogether undermines the whole point of it. The key is better fine tuning. And that can only happen if people continue to use their logs approrpriately and naturally as they always have, since the algorithm was based initially on that usage, with tweaks made to it once enacted - both to fine tune it to how logs are used and what can be inferred about potential cache states, and to nudge people into a more appropriate usage habits. It's a complex system.

  • Upvote 1

Share this post


Link to post
11 minutes ago, thebruce0 said:

And that's the key.  Strings of DNFs on caches that are missing have always been a headache for finders when COs don't follow up. Scrapping DNFs from the CHS algorithm altogether undermines the whole point of it. The key is better fine tuning. And that can only happen if people continue to use their logs approrpriately and naturally as they always have, since the algorithm was based initially on that usage, with tweaks made to it once enacted - both to fine tune it to how logs are used and what can be inferred about potential cache states, and to nudge people into a more appropriate usage habits. It's a complex system.

So how many DNFs is a D5 allowed to get before it's deemed to be in need of maintenance? Five? Ten? Twenty? Fifty? How can you put a number on it when D5 can mean anything from really-really-hard to nigh on impossible to find? DNFs are a poor measure of cache health at the best of times, but for higher D/T caches (and I'm throwing high T in there as well as that generally means they don't get enough attempts for any statistical analysis to be meaningful), DNF-counting is futile. It'd do just as well identifying problem caches by throwing darts at a dartboard and no amount of fine tuning is ever going to fix that.

Share this post


Link to post
14 minutes ago, barefootjeff said:

So how many DNFs is a D5 allowed to get before it's deemed to be in need of maintenance? Five? Ten? Twenty? Fifty? How can you put a number on it when D5 can mean anything from really-really-hard to nigh on impossible to find?

Don't know. Don't care to define. If it happens to me and I think it's incorrect, I'll report my concerns. If it happens to you, report your concerns.

  • Upvote 1

Share this post


Link to post
15 minutes ago, thebruce0 said:

Don't know. Don't care to define. If it happens to me and I think it's incorrect, I'll report my concerns. If it happens to you, report your concerns.

It did. I tried. I was told I needed to maintain my cache as I'd agreed to do. The system doesn't provide a false-positive reporting mechanism, but even if it did, it still shouldn't be trying to infer anything from DNF logs on high D/T caches where DNFs are the expected outcome. Yes, a string of DNFs can mean a cache is missing, but on a high D/T cache it can just as easily mean the cache's camo and terrain challenge is doing its job. If you think a string on DNFs on a particular cache means it might be missing, log an OM, then if the owner doesn't respond log an NA. Problem solved.

Share this post


Link to post
26 minutes ago, thebruce0 said:

Don't know. Don't care to define. If it happens to me and I think it's incorrect, I'll report my concerns. If it happens to you, report your concerns.

I forget...

What's the correct mechanism for reporting false positives in the CHS algorithm these days?

Share this post


Link to post
27 minutes ago, barefootjeff said:

It did. I tried. I was told I needed to maintain my cache as I'd agreed to do. The system doesn't provide a false-positive reporting mechanism

 

22 minutes ago, niraD said:

What's the correct mechanism for reporting false positives in the CHS algorithm these days?

Post OM with detail. Contact a reviewer. Share in forums. Email HQ. Afterwards, let it go.  Because nothing will happen to a cache if a human reviewer doesn't think something should happen.  And if a reviewer does something you think should not happen, you can appeal, as always.

 

29 minutes ago, barefootjeff said:

it still shouldn't be trying to infer anything from DNF logs on high D/T caches where DNFs are the expected outcome. Yes, a string of DNFs can mean a cache is missing, but on a high D/T cache it can just as easily mean the cache's camo and terrain challenge is doing its job.

A string of DNFs can't be ignored just because of a high D. A string of DNFs will always imply the possibility of a missing cache, just moreso on lower D's than high. So no, they can't be entirely ignored. Only their weight tweaked.

 

32 minutes ago, barefootjeff said:

If you think a string on DNFs on a particular cache means it might be missing, log an OM, then if the owner doesn't respond log an NA.

That can still be done. Clearly it wasn't enough and GS felt that implemented an automated system to remind and notify owners os possible issue was needed. Despite the occasional false positive. And as reviewers are consistently informing us here, the system has greatly helped them. And they still make case by case judgements.  Perfect judgements? Of course not, and I've not seen any reviewer say that. That's why they let COs know they can have decisions reversed, especially archivals due to inactivity.

The system allows for errors with easy fixes, knowing that the system cannot possibly be perfect around the globe.  So how does everyone make the system better? Report the problems.

Can GS make that step more visible and obvious? Most definitely! But if there's a problem, that's the problem. Not the mere existence of the CHS, or that it gives any weight whatsoever to DNFs.

Share this post


Link to post
41 minutes ago, thebruce0 said:

A string of DNFs can't be ignored just because of a high D. A string of DNFs will always imply the possibility of a missing cache, just moreso on lower D's than high. So no, they can't be entirely ignored. Only their weight tweaked.

Yes it can, because a D5 is supposed to generate long strings of DNFs. We have a perfectly good NM log for people searching for it to use if they want to differentiate between "it defeated me today" and "I think it might be missing". That NM is the thing that can't (well shouldn't) be ignored and that should be the threshold for requiring an owner visit, especially on high D/T caches where strings of DNFs just mean the cache's subterfuge is doing its job. These caches are meant to be a challenging find - some of my most memorable caches are ones that have taken multiple visits to crack and some I still haven't cracked but I'll keep trying until I do.

Share this post


Link to post

I should also add that all caches don't have the same likelihood of going missing. Caches in urban areas with high pedestrian traffic are much more likely to go missing than one tucked away under a nondescript rock ledge on the side of a mountain.

For example, to reach one of my caches requires a 4km hike along a fire trail, then at a particular spot you head into the scrub along a very faint track to a ledge, then rock-hop another fifty metres north from there to a place where there's a nice water view. But the cache isn't there, it's down the bottom of the five metre cliff you're standing on, so you then need to go further north to find a way down and backtrack, where you'll find a pretty impressive wind-eroded cave in underneath the cliff. But the cache isn't in the cave, it's tucked deep under a rock ledge below it, in a place where it'll never get wet, flooded or chanced upon by muggles or even animals capable of moving it. Really, the only way that cache is ever going to go missing is if a cacher steals it, but why would they go through all of that to acquire a container that would only cost them a few dollars in the supermarket? I'm sure you're going to invent a whole lot of far-fetched scenarios where it might spontaneously disappear, but the reality is that cache just isn't going to go missing.

Share this post


Link to post
40 minutes ago, barefootjeff said:
1 hour ago, thebruce0 said:

A string of DNFs can't be ignored just because of a high D. A string of DNFs will always imply the possibility of a missing cache, just moreso on lower D's than high. So no, they can't be entirely ignored. Only their weight tweaked.

Yes it can, because a D5 is supposed to generate long strings of DNFs. We have a perfectly good NM log for people searching for it to use if they want to differentiate between "it defeated me today" and "I think it might be missing"

You completely missed the point. What I said doesn't contradict what you just said.

However I wouldn't say a D5 is supposed to generate long strings of DNFs unless you don't want your cache to be found (and I hate that cliche). The point you missed was that there's always a greater chance that a cache is missing after a string of DNFs than no DNFs, regardless of rating. Always. Guaranteed (the chance, not the missing). Obviously less so on a higher D than a lower D. "So no, they can't be entirely ignored. Only their weight tweaked." [which is where high D should weigh strings of DNFs lesser than low D].  But never should the "string of DNFs" be completely ignored, merely because of a high D.  The weight of the string should be tweaked, obviously, but never fully ignored.

Share this post


Link to post
24 minutes ago, thebruce0 said:

You completely missed the point. What I said doesn't contradict what you just said.

However I wouldn't say a D5 is supposed to generate long strings of DNFs unless you don't want your cache to be found (and I hate that cliche). The point you missed was that there's always a greater chance that a cache is missing after a string of DNFs than no DNFs, regardless of rating. Always. Guaranteed (the chance, not the missing). Obviously less so on a higher D than a lower D. "So no, they can't be entirely ignored. Only their weight tweaked." [which is where high D should weigh strings of DNFs lesser than low D].  But never should the "string of DNFs" be completely ignored, merely because of a high D.  The weight of the string should be tweaked, obviously, but never fully ignored.

That Queen's Tower cache is supposed to generate long strings of DNFs, it was deliberately created as a very difficult needle-in-a-haystack. The CO has said so. It's not meant to be unfindable, but it is meant to be a very challenging find, either requiring a lot of perseverence, very good luck or, as has turned out to be the case for some of the finds, hints from previous finders or perhaps the CO himself.

A CO is required to make occasional visits to a cache, and that's when the owner of this cache will likely determine whether it's missing or not. The number of DNFs is really immaterial because there's no way to tell whether any number of DNFs was due to a missing cache or the hide simply working as intended.

Edited by barefootjeff
Spelling

Share this post


Link to post
10 minutes ago, barefootjeff said:

The number of DNFs is really immaterial because there's no way to tell whether any number of DNFs was due to a missing cache or the hide simply working as intended.

Exactly. There's no way to know. Which is why they're weighed less on higher D caches. AN example of where this logic is an unfortunate side effect isn't sufficient reason to remove the effect of strings of DNFs on the CHS. Additionally, once again, having it flagged by the algorithm itself isn't a death note. If the reviewer knows that it gets an inordinate number of DNFs, then the CO has nothing worry about.

Share this post


Link to post
7 minutes ago, thebruce0 said:

Exactly. There's no way to know. Which is why they're weighed less on higher D caches. AN example of where this logic is an unfortunate side effect isn't sufficient reason to remove the effect of strings of DNFs on the CHS. Additionally, once again, having it flagged by the algorithm itself isn't a death note. If the reviewer knows that it gets an inordinate number of DNFs, then the CO has nothing worry about.

What's wrong with the CHS not acting on higher D/T caches until there's more evidence beyond just DNFs, such as an ignored NM? High D/Ts aren't cluttering up the landscape and are generally far less likely to go missing than, say, an LPC or a magnetic nano on the back of a seat in a busy mall. I'd wager that most DNF-only CHS hits on D/T 4+ caches are false positives. And if it's a long and/or dangerous trek for the CO to do an immediate check on a cache that's been incorrectly pinged, then I'd say the CO does have some concerns, particularly now that the CHS goes beyond just a nuisance email.

Share this post


Link to post
11 minutes ago, barefootjeff said:

What's wrong with the CHS not acting on higher D/T caches until there's more evidence beyond just DNFs, such as an ignored NM?

There may be. We don't know. That's where the tweaking happens.  And if it doesn't look like there's any other factor, well then that's a potential for a tweak isn't it? But we can't know if one is being made, or will ever be made, if GS doesn't deem it prudent to tell us, because of the algorithm gaming factor. Just like spam algorithms and google search ranking algorithms will never be disclosed. None of them are perfect. All of them get tweaked with new information.

Share this post


Link to post
13 hours ago, thebruce0 said:
14 hours ago, niraD said:

What's the correct mechanism for reporting false positives in the CHS algorithm these days?

Post OM with detail. Contact a reviewer. Share in forums. Email HQ. Afterwards, let it go.  Because nothing will happen to a cache if a human reviewer doesn't think something should happen.  And if a reviewer does something you think should not happen, you can appeal, as always.

 

For a high difficulty cache three DNFs in a row would not be uncommon.  So the CO posts an OM with detail, contacts their reviewer and HQ, then a week later 3 more DNFs triggers another CHS  message.  Repeat and recycle until the CO gets tired of responding to false positives, archives the cache and decides to place T1.5 caches that never get a DNF.

13 hours ago, thebruce0 said:
14 hours ago, barefootjeff said:

it still shouldn't be trying to infer anything from DNF logs on high D/T caches where DNFs are the expected outcome. Yes, a string of DNFs can mean a cache is missing, but on a high D/T cache it can just as easily mean the cache's camo and terrain challenge is doing its job.

A string of DNFs can't be ignored just because of a high D. A string of DNFs will always imply the possibility of a missing cache, just moreso on lower D's than high. So no, they can't be entirely ignored. Only their weight tweaked.

Although we don't know how or if DNF logs are weighted this seems to most obvious tweak to the algorithm.  Suppose the CHS is set such that a rating of 20 or higher triggers the CHS warning.  If DNF logs are weighted inversely proportional to the D rating, from a 10 (for a D1) to a 1 (for a D5) it would take 20 DNFs on a D5 cache to trigger the CHS message but only 2 for a D1 cache. When DNFs are weighted based on the D rating, now it starts to make a little more sense.  

The CHS is an algorithm;  a mathematical formula that can weight various factors to come up with a number which is either above or below a threshold.  It somehow should work for all caches, in all locations.  Keep in mind that in some areas the number of visits on a cache is significantly higher than in other areas. (e.g. caches in some cities in Europe may average a dozen or more logs in a day, while caches in other places may never get a dozen logs in a year).  All of those factors can be weighted.

Share this post


Link to post
15 hours ago, barefootjeff said:

The tower one is GC4ZAZH, a magnetic micro somewhere on a 40 metre high steel observation tower. It's a D5 and gets lots of DNFs because it's meant to get lots of DNFs. It's not missing and it doesn't need constant maintenance because of those DNFs. You keep saying any cache with three or four DNFs needs owner attention, and while that might be appropriate for a D1 or D1.5, it shouldn't be the case for higher difficulty caches like a D3.5 or D5 because they're supposed to get lots of DNFs.

A couple of observations on the Tower cache.   First I don't see where a reviewer has taken any action regarding this cache.   I have no doubt that this one was flagged by the CHS.  I scanned through the logs and checked the owners last log in date.   It took me about 3 minutes to come to the conclusion that no action was necessary at this time.   I have to believe the local reviewer came to the same conclusion.

Is the uproar regarding this particular cache because of the automated e-mail the cache owner could be receiving?   

 

Share this post


Link to post
11 minutes ago, justintim1999 said:

A couple of observations on the Tower cache.   First I don't see where a reviewer has taken any action regarding this cache.   I have no doubt that this one was flagged by the CHS.  I scanned through the logs and checked the owners last log in date.   It took me about 3 minutes to come to the conclusion that no action was necessary at this time.   I have to believe the local reviewer came to the same conclusion.

Is the uproar regarding this particular cache because of the automated e-mail the cache owner could be receiving?   

 

You've been repeatedly saying that after 3 DNFs in a row the CO needs to go check on the cache...

Quote

After three or four dnfs the cache owner should check up on it and post a OM that everything is good.

I gave this as an example to show how ridiculous that is. On a D5 cache like this, it's meant to get lots of DNFs, that's the whole point of it. I don't know how many CHS emails it's generated, I'm just trying to make the point that a one-size-fits-all check-the-cache-after-3-DNFs takes no account of difficult-to-find caches. There are other D5 caches I've seen mentioned in the forums that have hundreds of DNFs with no or very few finds, yet they're not missing - you can't infer anything at all about the cache by counting DNFs on a D5.

Share this post


Link to post
15 hours ago, barefootjeff said:

I'm not saying the whole CHS should be scrapped because of it, I'm saying the CHS (or anyone else) shouldn't be using a DNF count or a DNF-to-find ratio to infer poor cache health on a high difficulty cache that's meant to get lots of DNFs.

I agree but in most cases a long list of dnf do indicate a possible issue with the cache.  So the argument isn't whether or not dnf should be included in the CHS because they should.   I'm looking for a particular example of where a cache was wrongly disabled because of a long string of dnfs.   The Tower Cache  has enough history to show that multiple dnfs are the norm and the logs don't indicate any other issues.    The fact that this cache has not been disabled a some point tells me that a reviewer has looked at the cache and understands the dynamics at work there.     

Share this post


Link to post
6 minutes ago, justintim1999 said:

I agree but in most cases a long list of dnf do indicate a possible issue with the cache.  So the argument isn't whether or not dnf should be included in the CHS because they should.   I'm looking for a particular example of where a cache was wrongly disabled because of a long string of dnfs.   The Tower Cache  has enough history to show that multiple dnfs are the norm and the logs don't indicate any other issues.    The fact that this cache has not been disabled a some point tells me that a reviewer has looked at the cache and understands the dynamics at work there.     

How many times do I have to say it? It's a D5 traditional, that in itself should be enough to say "lots and lots of DNFs", regardless of any history. If a D5 traditional was getting lots of finds and only an occasional DNF, you ought to be complaining about its D rating. The reviewers shouldn't be looking at it at all, if the CHS is pinging this cache then the CHS writers don't understand what D5 means.

Share this post


Link to post
9 minutes ago, barefootjeff said:

You've been repeatedly saying that after 3 DNFs in a row the CO needs to go check on the cache...

I gave this as an example to show how ridiculous that is. On a D5 cache like this, it's meant to get lots of DNFs, that's the whole point of it. I don't know how many CHS emails it's generated, I'm just trying to make the point that a one-size-fits-all check-the-cache-after-3-DNFs takes no account of difficult-to-find caches. There are other D5 caches I've seen mentioned in the forums that have hundreds of DNFs with no or very few finds, yet they're not missing - you can't infer anything at all about the cache by counting DNFs on a D5.

Take anything that's 3.5 or less, which constitutes the bulk of the caches hidden in the world.   These caches should be checked up on after 3 or 4 dnfs.   If any one of my caches generated as many dnfs as the tower cache I'm sure I would have been contacted by my local reviewer by now.    You have to set the standard based on the majority of caches your monitoring and allow for more leeway when dealing with the rest.   To me it looks like that's exactly what's happening with the Tower Cache.

Share this post


Link to post
11 minutes ago, barefootjeff said:

How many times do I have to say it? It's a D5 traditional, that in itself should be enough to say "lots and lots of DNFs", regardless of any history. If a D5 traditional was getting lots of finds and only an occasional DNF, you ought to be complaining about its D rating. The reviewers shouldn't be looking at it at all, if the CHS is pinging this cache then the CHS writers don't understand what D5 means.

Please tell me what negative action has been taken against the Tower Cache.   Your citing a cache that has had no reviewer involvement since it's been published.  

Share this post


Link to post

Posting to confirm that the Tower Cache does not now have, and has never had, a Cache Health Score low enough to trigger an automated maintenance reminder email, or to be put on a list for reviewer attention.

  • Upvote 2

Share this post


Link to post
55 minutes ago, justintim1999 said:

Take anything that's 3.5 or less, which constitutes the bulk of the caches hidden in the world. 

And as soon as cache owners discover that they can use a D rating higher than a 3.5 to avoid CHS messages they'll increase the difficulty to 4.0.   Yes, there is a lower percentage of caches with a D4 or higher.  Your solution would just create an incentive to incorrectly rate a cache higher than is accurate and likely reduce the percentage of caches that were legitmately rated D4 or higher.   Instead of a threshold of 3.5 it would make more sense to weight DNFs based upon the actual difficulty.  

Share this post


Link to post
1 hour ago, NYPaddleCacher said:

For a high difficulty cache three DNFs in a row would not be uncommon.  So the CO posts an OM with detail, contacts their reviewer and HQ, then a week later 3 more DNFs triggers another CHS  message.  Repeat and recycle until the CO gets tired of responding to false positives, archives the cache and decides to place T1.5 caches that never get a DNF.

That's unfortunate for everyone who likes the cache that the CO can't put up with the emails. It's also unfortunate in this very hypothetical situation that GS does absolutely nothing about it. It's also unfortunate in this hypothetical situation that the CO resorts to a tantrum by sticking it to the man and not caring about providing a fun and relevant game for the community after the fact.

 

1 hour ago, NYPaddleCacher said:

When DNFs are weighted based on the D rating, now it starts to make a little more sense. 

This is why they suggest raising the D if a CO gets notifications because of strings of DNFs. This is already a known aspect of the algorithm.

  • Upvote 2

Share this post


Link to post
12 minutes ago, NYPaddleCacher said:

And as soon as cache owners discover that they can use a D rating higher than a 3.5 to avoid CHS messages they'll increase the difficulty to 4.0.   Yes, there is a lower percentage of caches with a D4 or higher.  Your solution would just create an incentive to incorrectly rate a cache higher than is accurate and likely reduce the percentage of caches that were legitmately rated D4 or higher.   Instead of a threshold of 3.5 it would make more sense to weight DNFs based upon the actual difficulty.  

Why is it that everyone is out to beat the system?   If you spending all the time and brain power thinking of ways not to get out of maintaining your caches than you shouldn't be a cache owner in the first place.   I'm sure some will try but I have a feeling most won't succeed.

  • Upvote 2

Share this post


Link to post
7 minutes ago, thebruce0 said:

That's unfortunate for everyone who likes the cache that the CO can't put up with the emails. It's also unfortunate in this very hypothetical situation that GS does absolutely nothing about it. It's also unfortunate in this hypothetical situation that the CO resorts to a tantrum by sticking it to the man and not caring about providing a fun and relevant game for the community after the fact.

 

This is why they suggest raising the D if a CO gets notifications because of strings of DNFs. This is already a known aspect of the algorithm.

To be honest I don't even know if the e-mails are even an issue.  I haven't seen any examples of repeated e-mail requests issued to anyone.  I'm not saying it hasn't happened,  I'd just like to see exactly what they're receiving and how often they're receiving it.   I'd also like to know how the cache owner responded to them and what was done about it.   It's like trying to convince me Bigfoot exists with plaster casts and grainy photos.   

  • Upvote 1

Share this post


Link to post
4 hours ago, justintim1999 said:

Take anything that's 3.5 or less, which constitutes the bulk of the caches hidden in the world.  

3 hours ago, NYPaddleCacher said:

And as soon as cache owners discover that they can use a D rating higher than a 3.5 to avoid CHS messages they'll increase the difficulty to 4.0.   Yes, there is a lower percentage of caches with a D4 or higher.  Your solution would just create an incentive to incorrectly rate a cache higher than is accurate and likely reduce the percentage of caches that were legitmately rated D4 or higher.   Instead of a threshold of 3.5 it would make more sense to weight DNFs based upon the actual difficulty.  

We saw similar a lot when that pesky "Intro" app came out, COs "upping" their D/T simply to keep it away from the weekend-n-done kids. 

 - So, yeah, I can see the possibility that a few COs would game the system to beat that chs thing too.    :)

 

Share this post


Link to post
17 minutes ago, cerberus1 said:

We saw similar a lot when that pesky "Intro" app came out, COs "upping" their D/T simply to keep it away from the weekend-n-done kids. 

 

And now it's common to see the D/T rating lowered to include basic member app users. B) 

  • Upvote 1

Share this post


Link to post
1 hour ago, cerberus1 said:

e saw similar a lot when that pesky "Intro" app came out, COs "upping" their D/T simply to keep it away from the weekend-n-done kids. 

 - So, yeah, I can see the possibility that a few COs would game the system to beat that chs thing too.    :)

I

I'm quite sure your right.   I can see that happening here and there but overall I don't see it as a problem.  In fact I'd bet most of the cache owners I know would want to have the D/T set correctly and trying to game the system wouldn't even cross their mind.   When people hide caches it's usually for the enjoyment of other people.  When it becomes a choice between owning a cache and maintaining it or figuring out ways to game the system it's time to ask yourself what your doing here.

Since I started caching It's never crossed my mind to question a D/T rating.  I've had a few finders mention that one of my caches was a little low on the T.  I may have to start paying attention to such things and mention them in my log when appropriate.   Any information that can help another cacher or reviewer is a good thing right.:)  

  • Upvote 1

Share this post


Link to post
7 hours ago, justintim1999 said:

Please tell me what negative action has been taken against the Tower Cache.   Your citing a cache that has had no reviewer involvement since it's been published.  

I never said any action had been taken against this cache, and Keystone has confirmed that to be the case. You keep saying that any cache that gets 3 or more DNFs in a row needs a visit from the CO and an OM log to say it's okay, so I cited this as an example where that's clearly not true. Likewise the D3.5 multi I mentioned earlier (GCT2V1) that had 10 DNFs in a row until I found it on Saturday. The OM log posted back in October says it all: "The cache is not missing, just hard to locate. Hence the higher difficulty rating."

Difficult caches will generate lots of DNFs, they're supposed to be challenging to find, and frankly I'd rather spend my caching time trying to crack caches like this than in finding yet another magnetic nano on the back of a road sign.

Edited by barefootjeff
Spelling

Share this post


Link to post
12 minutes ago, barefootjeff said:

I never said any action had been taken against this cache, and Keystone has confirmed that to be the case. You keep saying that any cache that gets 3 or more DNFs in a row needs a visit from the CO and an OM log to say it's okay, so I cited this as an example where that's clearly not true. Likewise the D3.5 multi I mentioned earlier (GCT2V1) that had 10 DNFs in a row until I found it on Saturday. The OM log posted back in October says it all: "The cache is not missing, just hard to locate. Hence the higher difficulty rating."

Difficult caches will generate lots of DNFs, they're supposed to be challenging to find, and frankly I'd rather spend my caching time trying to crack caches like this than in finding yet another magnetic nano on the back of a road sign.

If the relationship between dnfs and the CHS is having no effects on this cache what-so-ever,  then what are we talking about here?  I understand that high D/T caches are going to have more dnfs.    I thought this was all about the CHS and it's use of dnfs to negatively effect these types of caches?   Looking at the example given,  that's not the case at all.

Please tell me this isn't just about receiving the automated e-mail reminder?

  • Upvote 1

Share this post


Link to post
6 minutes ago, justintim1999 said:

If the relationship between dnfs and the CHS is having no effects on this cache what-so-ever,  then what are we talking about here?  I understand that high D/T caches are going to have more dnfs.    I thought this was all about the CHS and it's use of dnfs to negatively effect these types of caches?   Looking at the example given,  that's not the case at all.

Please tell me this isn't just about receiving the automated e-mail reminder?

As I just said, I quoted those as examples to refute your insistence that 3 DNFs in a row always means a CO visit and OM are needed. That's all. There are some caches that are expected to get lots of DNFs in a row - that's what a higher difficulty rating means. I don't know how better I can explain that.

Share this post


Link to post
8 minutes ago, barefootjeff said:

As I just said, I quoted those as examples to refute your insistence that 3 DNFs in a row always means a CO visit and OM are needed. That's all. There are some caches that are expected to get lots of DNFs in a row - that's what a higher difficulty rating means. I don't know how better I can explain that.

I think 3 dnfs should be the norm for most cache owners.   Obviously there are exceptions.   

The tower cache example was very enlightening.   I was curious to see how a reviewer would handle a cache like that with the assistance of the CHS.    I'm happy to see that no caches or cache owners were harmed in the process.     

Share this post


Link to post
6 minutes ago, justintim1999 said:

I think 3 dnfs should be the norm for most cache owners.   Obviously there are exceptions. 

Perhaps it should be the norm for most low D/T caches, but for me high D/T caches are the lifeblood of caching so I don't see them as rare exceptions that can just be ignored or wiped away in the grand scheme of things. For me, anything that discourages people from hiding high D/T caches, intentionally or otherwise, is killing off the aspect of the game I most love, hence my passion on this subject.

  • Upvote 1

Share this post


Link to post
22 minutes ago, barefootjeff said:

Perhaps it should be the norm for most low D/T caches, but for me high D/T caches are the lifeblood of caching so I don't see them as rare exceptions that can just be ignored or wiped away in the grand scheme of things. For me, anything that discourages people from hiding high D/T caches, intentionally or otherwise, is killing off the aspect of the game I most love, hence my passion on this subject.

the vast majority of caches out there are a 4 D/T or less so I think the standard should be geared toward those.   6, 7 and even 8 dnfs in a row doesn't' seem to effect high D/T caches when it comes to the CHS so why not set the bar high and expect most cache owners to take notice at 3?   

Share this post


Link to post
26 minutes ago, justintim1999 said:

I think 3 dnfs should be the norm for most cache owners.

When the system is designed for the norm, what you'll get is the norm.

The problem with the CHS is that it's unreliable. When people point out problems, supporters say, "Well obviously that's an exception." That would be a perfectly reasonable argument if the CHS results were always filtered by a human who removes those obvious exceptions. But both the e-mail alerts and now this list of caches needing attention present the CHS directly to the cache owner with no hint that any given result might be an obvious exception. Furthermore, as niraD keeps pointing out, even when the CO does understand that the CHS result is an obvious exception, there's no way for him to report it or change the status other than by gaming the system with a random OM or some such.

  • Upvote 1

Share this post


Link to post
17 minutes ago, justintim1999 said:

the vast majority of caches out there are a 4 D/T or less so I think the standard should be geared toward those.   6, 7 and even 8 dnfs in a row doesn't' seem to effect high D/T caches when it comes to the CHS so why not set the bar high and expect most cache owners to take notice at 3?   

A quick search shows there are about 260,000 caches worldwide with either D or T set to 4 or greater, which is about 6.5 percent of the total caches. Not a big proportion but still a significant one that shouldn't be just swept away with generalisations like 3 DNFs with no owner response equals maintenance-shirker.

Share this post


Link to post
2 hours ago, dprovan said:

The problem with the CHS is that it's unreliable. When people point out problems, supporters say, "Well obviously that's an exception."

Considering what we've heard from reviewers about the effectiveness of the CHS helping them deal with caches, yes, the false positives are indeed the exception to the norm.

Edited by thebruce0
  • Upvote 2

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 5

×
×
  • Create New...