Geocache Health Score

[+Team Microdot]

The algorithm is assuming the worst about a DNF log (i.e. the cache is missing) but most of the time that's not true. Even if there's a string of DNFs that might hint more strongly at a missing cache, without reading the content that's still just speculation. A subsequent Found It! log, taken at face value, ought to override that speculation. If the Found It log is genuine, the cache cannot be missing. That string of DNFs might just have been a random clump or happened because it was school holidays and there were lots of muggles about - that's far more likely in my experience than a fake Found It log, and the algorithm shouldn't be speculating about this sort of thing if it's not reading log content.

 

I think we'll have to agree to disagree on this one - although in fairness I'm effectively just thinking out loud because it interests me. The proof of the pudding, as they say, would be in the eating.

 

The algorithm actually isn't assuming that a DNF log means the cache is missing. The algorithm is assigning a small detrimental score to the overall health score for the cache. If enough of these negative scores accumulate to bring the overall health score down below the pre-determined threshold the cache is brought to the attention of an intelligent human being.

 

I said earlier that I would pitch the beneficial score of a Found it higher than the detrimental score of a DNF so that Found Its would always outweigh DNF's and thus bring the health score back above the threshold quicker than DNF's would make it fall - it's just that I see no point to trust any log 100% - that's not how these things tend to work.

 

The algorithm doesn't 'trust' ANY log 100%. If it did it would be useless.

 

Having seen the sheer volume of examples in the Found It = Didn't Find it thread where people have posted Found It logs on caches that weren't even there I can't see any reason to trust a Found It log 100% - that log does not mean the cache is there. This isn't a reflection of people's characters - it's a cold, imperfect mathematical system that arrives at its 'conclusions' by guess-work.

 

Why shouldn't the algorithm be speculating? It has no power of its own, it can't archive a cache or even disable one. Not yet at least.

[+barefootjeff]

The algorithm is assuming the worst about a DNF log (i.e. the cache is missing) but most of the time that's not true. Even if there's a string of DNFs that might hint more strongly at a missing cache, without reading the content that's still just speculation. A subsequent Found It! log, taken at face value, ought to override that speculation. If the Found It log is genuine, the cache cannot be missing. That string of DNFs might just have been a random clump or happened because it was school holidays and there were lots of muggles about - that's far more likely in my experience than a fake Found It log, and the algorithm shouldn't be speculating about this sort of thing if it's not reading log content.

 

I think we'll have to agree to disagree on this one - although in fairness I'm effectively just thinking out loud because it interests me. The proof of the pudding, as they say, would be in the eating.

 

The algorithm actually isn't assuming that a DNF log means the cache is missing. The algorithm is assigning a small detrimental score to the overall health score for the cache. If enough of these negative scores accumulate to bring the overall health score down below the pre-determined threshold the cache is brought to the attention of an intelligent human being.

 

I said earlier that I would pitch the beneficial score of a Found it higher than the detrimental score of a DNF so that Found Its would always outweigh DNF's and thus bring the health score back above the threshold quicker than DNF's would make it fall - it's just that I see no point to trust any log 100% - that's not how these things tend to work.

 

The algorithm doesn't 'trust' ANY log 100%. If it did it would be useless.

 

Having seen the sheer volume of examples in the Found It = Didn't Find it thread where people have posted Found It logs on caches that weren't even there I can't see any reason to trust a Found It log 100% - that log does not mean the cache is there. This isn't a reflection of people's characters - it's a cold, imperfect mathematical system that arrives at its 'conclusions' by guess-work.

 

Why shouldn't the algorithm be speculating? It has no power of its own, it can't archive a cache or even disable one. Not yet at least.

I thought the purpose of the algorithm was to provide a gentle prod to COs who might have overlooked a maintenance issue, and to give reviewers a heads-up on potentially abandoned caches. I haven't seen anything about it being supposed to weed out dishonest cachers.

 

The problem with not accepting Found It logs in good faith is that it then causes the negative effect of DNFs to persist beyond the next find, even if the DNFs had nothing to do with cache health (which is most of the time). That in turn can only serve to dissuade people who realise it's happening from logging DNFs in situations when they know or are pretty sure the cache is fine. Is that the intention?

 

Yes, the Found It = Didn't Find It thread contains lots of examples, but compare that to the total number of finds logged globally over the same period and it has to be a vanishingly small percentage. Across my 26 hides spanning 4 years, I've never encountered a false Found It log other than newbie app duplicates. And, for the record, I've had 27 DNFs logged, none of which were due to a missing cache.

[+MartyBartfast]

 

The problem with not accepting Found It logs in good faith is that it then causes the negative effect of DNFs to persist beyond the next find, even if the DNFs had nothing to do with cache health (which is most of the time).

 

So your cache(s) get picked out by the alogorithm, you create a sock-puppet account & log a find against your own caches, all that bad karma is instantly erased and your missing cache is instantly returned to normality - sure that's the way to go.

 

Team Microdot's suggestion that "I would pitch the beneficial score of a Found it higher than the detrimental score of a DNF so that Found Its would always outweigh DNF's" sounds like an excellent solution to me.

[+dprovan]

We are talking about a universal system to identify which caches should be archived.

...er...

I thought it was an automated system that alerts cache owners about potential problems with their cache, and also helps reviewers by drawing attention to such caches first using an arbitrarily assigned 'score'.

Beyond that, it's all human interaction, as it is currently.

A big problem in this conversation is reflected in the fact that you think there's a significant difference between my description and yours. "Drawing attention to" is a synonym of "identify". Since the stated problem is bad caches, the reason we're drawing the reviewer's attention to a cache is for him to consider archiving it. And you automate a process by using a universal standard.

 

They're so similar, I really don't understand why you're objecting to my statement. It's as if you don't like it spelled out so clearly.

[+barefootjeff]

 

The problem with not accepting Found It logs in good faith is that it then causes the negative effect of DNFs to persist beyond the next find, even if the DNFs had nothing to do with cache health (which is most of the time).

 

So your cache(s) get picked out by the alogorithm, you create a sock-puppet account & log a find against your own caches, all that bad karma is instantly erased and your missing cache is instantly returned to normality - sure that's the way to go.

I give up. If the percentage of cachers who'd do that to avoid replacing or archiving a cache that really is missing is anything more than negligibly small, I'm in the wrong game.

[+fizzymagic]

The algorithm actually isn't assuming that a DNF log means the cache is missing. The algorithm is assigning a small detrimental score to the overall health score for the cache. If enough of these negative scores accumulate to bring the overall health score down below the pre-determined threshold the cache is brought to the attention of an intelligent human being.

 

You can make up any algorithm you like, but the one you describe here is quite certainly not the one being used by Groundspeak. If you want to talk about your hypothetical algorithm, that's fine, but please stop posting misinformation about the one actually in use.

 

We have good evidence that the Groundspeak algorithm will flag a cache for archival after as few as 2 logs.

 

Again, I reiterate: posting nonsense is not helpful.

[+barefootjeff]

The algorithm actually isn't assuming that a DNF log means the cache is missing. The algorithm is assigning a small detrimental score to the overall health score for the cache. If enough of these negative scores accumulate to bring the overall health score down below the pre-determined threshold the cache is brought to the attention of an intelligent human being.

 

You can make up any algorithm you like, but the one you describe here is quite certainly not the one being used by Groundspeak. If you want to talk about your hypothetical algorithm, that's fine, but please stop posting misinformation about the one actually in use.

 

We have good evidence that the Groundspeak algorithm will flag a cache for archival after as few as 2 logs.

 

Again, I reiterate: posting nonsense is not helpful.

I have irrefutable evidence that the algorithm can ping a cache with only one DNF log, or at least it did back in late December. Whether it's been changed since is anyone's guess, but I hope it has.

 

From what I was told at the time, the reason my cache was pinged was that in its seven weeks since publication, it'd only had one find logged prior to the DNF. That suggests to me that it's looking at the ratio of DNFs to finds, which I think is logically wrong if the last log was a find, since a found cache can't be missing unless the finder is dishonest. Remember, DNFs can only reasonably infer missing caches, not broken or soggy ones.

 

The algorithm is a blunt instrument. It'll never flag every abandoned or missing cache and it'll always catch some caches that really don't need attention. That's because it's basing its judgement on DNF logs which at least half the time have nothing to do with cache health. So, to keep it simple, it doesn't make sense to have it trying to catch dishonest COs and finders - the false negatives (or positives) these introduce will be far less than those of its own making. So just assume all logs are honest, and if the last log is a find, the cache isn't missing. If you do that, the only subjective case it has to worry about is when the last log was a DNF. Then, and only then, should it start taking past history into account. Keep it simple.

 

So my flowchart would be:

Is there an outstanding NM/NA beyond the reasonable time limit?

-If yes, the cache needs attention.

-If no (and I'm ignoring WN logs since they're irrelevant to cache health), was the last log a find?

--If yes, the cache is good.

--If no, was it an OM/UC/TD?

---If yes, the cache is good for now as the owner's fixed or is fixing a problem (extended TDs are dealt with separately).

---If no, it was a DNF so now, and only now, it has to generate a score based on the cache's (and maybe the CO's) history.

 

This should be all that's necessary if the sole intent is to flag potentially abandoned or missing caches.

[+Team Microdot]

The algorithm actually isn't assuming that a DNF log means the cache is missing. The algorithm is assigning a small detrimental score to the overall health score for the cache. If enough of these negative scores accumulate to bring the overall health score down below the pre-determined threshold the cache is brought to the attention of an intelligent human being.

 

You can make up any algorithm you like, but the one you describe here is quite certainly not the one being used by Groundspeak. If you want to talk about your hypothetical algorithm, that's fine, but please stop posting misinformation about the one actually in use.

 

We have good evidence that the Groundspeak algorithm will flag a cache for archival after as few as 2 logs.

 

Again, I reiterate: posting nonsense is not helpful.

 

Thanks for pointing that out

 

The fact is that none of us know anything about the internal workings of the existing algorithm because Groundspeak haven't revealed any information about that other than telling us that it takes certain things into consideration

 

Thus any thoughts I have about inner workings can be taken as exclusively to do with my imaginings on how AN algorithm based system MIGHT work.

 

In my opening post I provided a link to the sum total, to the best of my knowledge, of the information Groundspeak has revealed about the Geocache Health Score alogorithm. For convenience I'll provide it here again:

 

Information from Groundspeak on their Geocache Health Score (and associated algorithm)

 

I thought everyone else in the thread, when discussing the features / workings of 'the algorithm' was also discussing a theoretical model. If not, hopefully this post will address any confusion that may have arisen from my posts.

 

Going forward I think I'll refer to the theoretical algorithm as algorithm-T in a bid to differentiate without using some long-winded description each time - that would just be a pain.

[+justintim1999]

Just wondering, if a cache gets a low health score because of one or more DNFs, does someone subsequently logging a find restore the score to pristine or are those DNFs an indelible mark against it for all time to come?

 

I would hope that an owner maintenance log would reset the score if several DNF logs lowered (is a low or high score an indicator of poor health).

 

OM followed by a Found It would be a better / more trustworthy measure that the cache had been maintained I think.

Huh? Do you mean the cache I DNFed the other day because of the nearby muggle on a lawnmower, and then found when I went back the next day, would still be considered unhealthy because the CO didn't visit the cache and log an OM saying he'd "fixed" the problem? What's the CO supposed to do, kill the lawnmower man?

 

I think we are at cross purposes, possibly a mix-up in the quoting - I don't know.

 

At the bare minimum your find cancels your DNF in terms of points scored so I'm not sure why you're bringing the CO or an OM up.

I initially pondered whether a found log would wipe away the negative score of preceding DNFs, NYPaddleCacher I think was saying it should take an OM log to erase the effect of DNFs, then I read your response as saying it'd need both an OM and a Found It! to do that. So yes, I think the quoting might have become muddled somewhere along the line.

 

In my opinion, if a cache has no outstanding NMs (or NAs) and the last log was a find, that should be sufficient prima facie evidence to say the cache is in good health, regardless of any prior history of DNFs. If the algorithm is only looking at log types and not their content, it shouldn't be trying to speculate on false finds or throwdowns.

 

Too lazy to read back through but I think I suggested an OM alone shouldn't necessarily cancel out an NM. A Found It after the OM would help to set the seal that the OM had actually taken place, rather than being an armchair OM - UNLESS that Found It was immediately followed by a NM.

 

I don't believe that a single find, by itself should cancel out multiple DNF's. I pointed to the Found It = Didn't Find It thread to show why I think that way.

 

Does that help at all? (I don't mean 'does that help you to agree' - just 'does that help to clear up any confusion / ambiguity).

 

I agree with the find after the OM but I think a find should cancel out multiple dnfs. I'm more interested in confirming the cache owner did indeed repair the cache.

 

We could try to tweak this thing endlessly but we'd only be doing it to try to stop miscreants from manipulating the system. For the majority of cachers out there a simple system would work just fine.

[+justintim1999]

The algorithm actually isn't assuming that a DNF log means the cache is missing. The algorithm is assigning a small detrimental score to the overall health score for the cache. If enough of these negative scores accumulate to bring the overall health score down below the pre-determined threshold the cache is brought to the attention of an intelligent human being.

 

You can make up any algorithm you like, but the one you describe here is quite certainly not the one being used by Groundspeak. If you want to talk about your hypothetical algorithm, that's fine, but please stop posting misinformation about the one actually in use.

 

We have good evidence that the Groundspeak algorithm will flag a cache for archival after as few as 2 logs.

 

Again, I reiterate: posting nonsense is not helpful.

 

Maybe I'm behind the times but when did everybody first know about this Health Score?

[+Mudfrog]

YOu wrote that the health score algorithm does not influence your way of hiding caches. May I ask whether it influences your way of logging in case you happen to log DNFs also when it is certainly not about the cache having a problem.

 

The algorithm does not affect the way i do any of my geocaching business. I log DNFs when i don't find a cache. My logs always give some information as to why i didn't find the cache. My log may include anything between, i punched "goto" on my gpsr but ran out of gas before ever reaching ground zero, to, i searched tirelessly for over an hour. If i feel there might be a problem with a cache, then i log my DNF along with a NM. As with a DNF, i make sure to add as much pertinent information as i can to my NM log.

[+Team Microdot]

Just wondering, if a cache gets a low health score because of one or more DNFs, does someone subsequently logging a find restore the score to pristine or are those DNFs an indelible mark against it for all time to come?

 

I would hope that an owner maintenance log would reset the score if several DNF logs lowered (is a low or high score an indicator of poor health).

 

OM followed by a Found It would be a better / more trustworthy measure that the cache had been maintained I think.

Huh? Do you mean the cache I DNFed the other day because of the nearby muggle on a lawnmower, and then found when I went back the next day, would still be considered unhealthy because the CO didn't visit the cache and log an OM saying he'd "fixed" the problem? What's the CO supposed to do, kill the lawnmower man?

 

I think we are at cross purposes, possibly a mix-up in the quoting - I don't know.

 

At the bare minimum your find cancels your DNF in terms of points scored so I'm not sure why you're bringing the CO or an OM up.

I initially pondered whether a found log would wipe away the negative score of preceding DNFs, NYPaddleCacher I think was saying it should take an OM log to erase the effect of DNFs, then I read your response as saying it'd need both an OM and a Found It! to do that. So yes, I think the quoting might have become muddled somewhere along the line.

 

In my opinion, if a cache has no outstanding NMs (or NAs) and the last log was a find, that should be sufficient prima facie evidence to say the cache is in good health, regardless of any prior history of DNFs. If the algorithm is only looking at log types and not their content, it shouldn't be trying to speculate on false finds or throwdowns.

 

Too lazy to read back through but I think I suggested an OM alone shouldn't necessarily cancel out an NM. A Found It after the OM would help to set the seal that the OM had actually taken place, rather than being an armchair OM - UNLESS that Found It was immediately followed by a NM.

 

I don't believe that a single find, by itself should cancel out multiple DNF's. I pointed to the Found It = Didn't Find It thread to show why I think that way.

 

Does that help at all? (I don't mean 'does that help you to agree' - just 'does that help to clear up any confusion / ambiguity).

 

I agree with the find after the OM but I think a find should cancel out multiple dnfs. I'm more interested in confirming the cache owner did indeed repair the cache.

 

We could try to tweak this thing endlessly but we'd only be doing it to try to stop miscreants from manipulating the system. For the majority of cachers out there a simple system would work just fine.

 

Come to think of it...

 

If a DNF gave a negative score of -1 and a find a positive score of +3, a find would effectively cancel out three DNF's.

 

The system I've described so far is pretty simple.

[+niraD]

I agree with the find after the OM but I think a find should cancel out multiple dnfs. I'm more interested in confirming the cache owner did indeed repair the cache.

So the owner of a good hiking cache goes to the trouble to schedule a day to hike to the cache site and repair a rarely visited good hiking cache, and then he posts an OM log to reflect what he did. But until someone logs a Find (perhaps weeks or even months later), his OM log is ignored by the algorithm, and he continues to get "visit it or archive it" emails from Groundspeak.

 

Is that really how you think this should work?

[+justintim1999]

I agree with the find after the OM but I think a find should cancel out multiple dnfs. I'm more interested in confirming the cache owner did indeed repair the cache.

So the owner of a good hiking cache goes to the trouble to schedule a day to hike to the cache site and repair a rarely visited good hiking cache, and then he posts an OM log to reflect what he did. But until someone logs a Find (perhaps weeks or even months later), his OM log is ignored by the algorithm, and he continues to get "visit it or archive it" emails from Groundspeak.

 

Is that really how you think this should work?

 

Maybe a special dispensation given to a cache like this. I'm looking more at the typical geocache.

[+niraD]

Maybe a special dispensation given to a cache like this. I'm looking more at the typical geocache.

In case you haven't noticed, a lot of the concern expressed about this system is the very negative effect it can have on atypical geocaches.

 

Yes, the system needs to work for typical geocaches. But atypical geocaches shouldn't be thrown under the bus.

[+thebruce0]

We are talking about a universal system to identify which caches should be archived.

...er...

I thought it was an automated system that alerts cache owners about potential problems with their cache, and also helps reviewers by drawing attention to such caches first using an arbitrarily assigned 'score'.

Beyond that, it's all human interaction, as it is currently.

A big problem in this conversation is reflected in the fact that you think there's a significant difference between my description and yours. "Drawing attention to" is a synonym of "identify". Since the stated problem is bad caches, the reason we're drawing the reviewer's attention to a cache is for him to consider archiving it. And you automate a process by using a universal standard.

 

They're so similar, I really don't understand why you're objecting to my statement. It's as if you don't like it spelled out so clearly.

The stated problem may be "bad caches", but the implementation identifies "potential maintenance issues", and the stated solution is "fix the problem". The result of not fixing (ignoring) is possible future reviewer attention. That is the extent of the algorithm's influence.

 

No, whatever a potentail outcome of the email may be, the algorithm is not there "to identify which caches should be archived." The algorithm is there to identify potential maintenance issues to their owners, while providing a metric a reviewer can also use to decide on the next step if/when the concern arises. That's it. That's all.

By your argument you could say the algorithm is there in order to do whatever the action one person may choose to take at any one point in time because of it. It loses all meaning and purpose. No, the purpose of the algorithm is to do precisely what the algorithm immediately does. Alert, and highlight. Real problem? Fix it. No problem? Ignore or reset it.

[+barefootjeff]

Maybe a special dispensation given to a cache like this. I'm looking more at the typical geocache.

In case you haven't noticed, a lot of the concern expressed about this system is the very negative effect it can have on atypical geocaches.

 

Yes, the system needs to work for typical geocaches. But atypical geocaches shouldn't be thrown under the bus.

Around here, anything much more than a roadside D/T 1.5 will get few finds once the handful of keen locals have been through. More than half my caches haven't had any finds at all so far this year and that period includes the bulk of our summer school holidays when there are plenty of visitors in the area. It'll be even quieter during the winter months.

 

It seems unreasonable to have to wait for a find after logging an OM for it to be recognised by the system as valid (or presumably by the reviewer who looks at it if they're instructed to be as sceptical of CO honesty as the theoretical algorithm).

 

Edit to add "theoretical".

Edited March 4, 2017 by barefootjeff

[+barefootjeff]

I agree with the find after the OM but I think a find should cancel out multiple dnfs. I'm more interested in confirming the cache owner did indeed repair the cache.

So the owner of a good hiking cache goes to the trouble to schedule a day to hike to the cache site and repair a rarely visited good hiking cache, and then he posts an OM log to reflect what he did. But until someone logs a Find (perhaps weeks or even months later), his OM log is ignored by the algorithm, and he continues to get "visit it or archive it" emails from Groundspeak.

 

Is that really how you think this should work?

Are fake OM logs such a rampant problem that allowance needs to be made for that possibility?

 

Our theoretical algorithm isn't a court of law, it's a blunt tool meant to give inattentive COs a prod about caches that might need maintenance and to give reviewers a heads-up on caches that might be abandoned or missing.

 

Edit to fix wrong quotes.

Edited March 4, 2017 by barefootjeff

[+barefootjeff]

We are talking about a universal system to identify which caches should be archived.

...er...

I thought it was an automated system that alerts cache owners about potential problems with their cache, and also helps reviewers by drawing attention to such caches first using an arbitrarily assigned 'score'.

Beyond that, it's all human interaction, as it is currently.

A big problem in this conversation is reflected in the fact that you think there's a significant difference between my description and yours. "Drawing attention to" is a synonym of "identify". Since the stated problem is bad caches, the reason we're drawing the reviewer's attention to a cache is for him to consider archiving it. And you automate a process by using a universal standard.

 

They're so similar, I really don't understand why you're objecting to my statement. It's as if you don't like it spelled out so clearly.

The stated problem may be "bad caches", but the implementation identifies "potential maintenance issues", and the stated solution is "fix the problem". The result of not fixing (ignoring) is possible future reviewer attention. That is the extent of the algorithm's influence.

 

No, whatever a potentail outcome of the email may be, the algorithm is not there "to identify which caches should be archived." The algorithm is there to identify potential maintenance issues to their owners, while providing a metric a reviewer can also use to decide on the next step if/when the concern arises. That's it. That's all.

By your argument you could say the algorithm is there in order to do whatever the action one person may choose to take at any one point in time because of it. It loses all meaning and purpose. No, the purpose of the algorithm is to do precisely what the algorithm immediately does. Alert, and highlight. Real problem? Fix it. No problem? Ignore or reset it.

Yes!

 

Now if we just had a clear mechanism to reset it in the case of false positives, without having to resort to fake OM logs, make unnecessary visits or pester reviewers, it'd be sweet.

[+Team Microdot]

Now if we just had a clear mechanism to reset it in the case of false positives, without having to resort to fake OM logs, make unnecessary visits or pester reviewers, it'd be sweet.

 

Well - if this thread has achieved anything it's to utterly castrate any potential algorithm

 

Looks like we'll just have to let Groundspeak get on with it in whatever way they think best without our input.

 

Community Volunteer Reviewers greatly benefit from the Cache Health tool. It's made our jobs much easier when it comes to maintenance issues. And, while we don't receive copies of the individual emails sent to cache owners, we have multiple tools in our toolbox to know about them.

 

the Cache Health tool also benefits cache owners and local communities, because an increased focus is placed on maintenance. It's a response to the complaints over the years about so many caches that are in poor condition. Now, if a community loved missing and broken caches, and hated clean, dry caches, then they'd be bummed about the Cache Health notification system.

 

Even when we've been told that Groundspeak's Cache Health Tool is for our benefit and in response to complaints that we've made about so many caches in poor condition, we'd still rather have something useless that achieves nothing.

 

Welcome to geocaching.

[+barefootjeff]

Now if we just had a clear mechanism to reset it in the case of false positives, without having to resort to fake OM logs, make unnecessary visits or pester reviewers, it'd be sweet.

 

Well - if this thread has achieved anything it's to utterly castrate any potential algorithm

 

Looks like we'll just have to let Groundspeak get on with it in whatever way they think best without our input.

 

Community Volunteer Reviewers greatly benefit from the Cache Health tool. It's made our jobs much easier when it comes to maintenance issues. And, while we don't receive copies of the individual emails sent to cache owners, we have multiple tools in our toolbox to know about them.

 

the Cache Health tool also benefits cache owners and local communities, because an increased focus is placed on maintenance. It's a response to the complaints over the years about so many caches that are in poor condition. Now, if a community loved missing and broken caches, and hated clean, dry caches, then they'd be bummed about the Cache Health notification system.

 

Even when we've been told that Groundspeak's Cache Health Tool is for our benefit and in response to complaints that we've made about so many caches in poor condition, we'd still rather have something useless that achieves nothing.

 

Welcome to geocaching.

Forgive me if I'm reading this wrongly, but we seem to be coming at this from opposite directions.

 

It seems you see the main issue is preventing false negatives, where an unscrupulous CO will try to subvert the algorithm when maintenance really is required, or false Found It logs that'll prevent it from detecting caches that really are missing. You appear to see the algorithm's main purpose is to catch wilful maintenance-shirkers, and despair at those who escape the net.

 

I see the main issue as false positives and trying to minimise the impact these have on conscientious COs when there really is no maintenance required. I see the algorithm's main purpose being to prod inattentive or forgetful COs and to give reviewers a heads-up on abandoned caches that have fallen into disrepair, and despair at innocent COs caught in the net.

 

We must live in very different caching worlds, and I'm not sure there's a single algorithm that, looking only at log types and not their content, can successfully satisfy both.

[+Team Microdot]

Now if we just had a clear mechanism to reset it in the case of false positives, without having to resort to fake OM logs, make unnecessary visits or pester reviewers, it'd be sweet.

 

Well - if this thread has achieved anything it's to utterly castrate any potential algorithm

 

Looks like we'll just have to let Groundspeak get on with it in whatever way they think best without our input.

 

Community Volunteer Reviewers greatly benefit from the Cache Health tool. It's made our jobs much easier when it comes to maintenance issues. And, while we don't receive copies of the individual emails sent to cache owners, we have multiple tools in our toolbox to know about them.

 

the Cache Health tool also benefits cache owners and local communities, because an increased focus is placed on maintenance. It's a response to the complaints over the years about so many caches that are in poor condition. Now, if a community loved missing and broken caches, and hated clean, dry caches, then they'd be bummed about the Cache Health notification system.

 

Even when we've been told that Groundspeak's Cache Health Tool is for our benefit and in response to complaints that we've made about so many caches in poor condition, we'd still rather have something useless that achieves nothing.

 

Welcome to geocaching.

Forgive me if I'm reading this wrongly, but we seem to be coming at this from opposite directions.

 

No - I think you're right - I think we are coming at this from opposite directions.

 

It seems you see the main issue is preventing false negatives, where an unscrupulous CO will try to subvert the algorithm when maintenance really is required, or false Found It logs that'll prevent it from detecting caches that really are missing. You appear to see the algorithm's main purpose is to catch wilful maintenance-shirkers, and despair at those who escape the net.

 

Your summary is half fair - apart from the bit about despair and the characterisation that goes along with it. If I'm able to apply tight focus to a problem for the purposes of an interesting and hopefully productive discussion that's no indicator that I'm experiencing anything as colourful as despair in relation to it. I'm always fully aware that there are much, much bigger problems in real life, so no need to worry on that score

 

Having thought about how the alogorithm might work I can see that it has very little to work with in order to arrive at useful conclusions. Several posters here - including yourself - seek to reduce what the algorithm has to work with even further. You yourself have suggested that there needs to be an automated mechanism to allow the CO to outright reject the algorithm's conclusion as a false positive with the click of a mouse button

 

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

2) That CO, given the opportunity to tell the algorithm that it's wrong every time he gets an email by simply ticking a box, isn't going to tick that box?

 

I see the main issue as false positives and trying to minimise the impact these have on conscientious COs when there really is no maintenance required.

 

See above - consicentious CO's are not the target. And because you see the main issue as false positives you're prepared to build in an override switch in the form of a tick box which instantly castrates the algorithm, rendering it useless as a tool

 

I see the algorithm's main purpose being to prod inattentive or forgetful COs

 

Really? I mean come on - how many prods do they need?

 

and to give reviewers a heads-up on abandoned caches that have fallen into disrepair, and despair at innocent COs caught in the net.

 

So you think the algorithm should score highly for CO's who:

 

1) Don't respond to NM

2) Don't respond to NA

3) Don't respond to automated email

4) Don't respond to reviewer notes

5) Don't respond to reviewer temp disablement

 

I have to agree.

 

The issue is that 1 and 2 aren't happening in those cases which have led to the complaints to Groundspeak which have in turn led them to conclude that they need to do something about the problem.

 

We must live in very different caching worlds, and I'm not sure there's a single algorithm that, looking only at log types and not their content, can successfully satisfy both.

 

We don't live in very different caching worlds at all. The only difference here is the way we are looking at the problem which has given rise to the Geocache Health Score.

 

It is entirely possible that Groundspeak could get their Geocache Health Tool to look at the content of the logs too and use something like bayesian probability to further enhance the scoring mechanisms of their algorithms. I suppose it's up to them if they wish to invest time, effort and money in doing so. They might just be hoping that some of us grow up a bit and actually deliver on the promises we made when we signed up.

[+justintim1999]

Maybe a special dispensation given to a cache like this. I'm looking more at the typical geocache.

In case you haven't noticed, a lot of the concern expressed about this system is the very negative effect it can have on atypical geocaches.

 

Yes, the system needs to work for typical geocaches. But atypical geocaches shouldn't be thrown under the bus.

 

I don't know about you but I had no idea that this Health Score even existed until this thread. From what I understand reviewers have been using it for quite a while.

 

How many Maintenance reminder e-mails have you received? Me, zero.

 

What is the issue. The idea of the Health Score, the way it's determined or the fact that you know about it now.

[cezanne]

 

I don't know about you but I had no idea that this Health Score even existed until this thread. From what I understand reviewers have been using it for quite a while.

 

 

I have learnt about the score before this thread. My concern is about using the score for automatic messages. If reviewers use the tool to help them and have a look at the logs, human intelligence is involved.

 

Mails like the one sent to barefootjeff are what causes a lot of the concern voiced here.

 

I do not know what you call a typical cache. I do not think that I own a typical cache and probably most of the caches I like are untypical in your eyes.

[+niraD]

What is the issue. The idea of the Health Score, the way it's determined or the fact that you know about it now.

None of the above.

 

To me, the issue is that the system does not handle false positives well, especially for caches that are difficult to visit at the drop of a hat. The only options offered to the CO are to visit the cache site or to archive the cache listing. There is no option to tell Groundspeak that there is nothing in the logs to indicate a problem, and that their system is being overly aggressive.

[+barefootjeff]

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

2) That CO, given the opportunity to tell the algorithm that it's wrong every time he gets an email by simply ticking a box, isn't going to tick that box?

I thought it was mainly about cleaning up after COs who have left the game, and giving active COs a prod if they've slipped up clearing an NM or missed seeing a pattern in DNF logs that might suggest a problem. It happens; people have distractions like jobs and families, and I'm sure most of the time it's that rather than wilful intent to shirk maintenance. We already have a mechanism in place for dealing with an NM that hasn't been resolved - someone in the community just has to post an NA, then it's out of the COs hands and into the lap of a reviewer. Around here, that works pretty well.

 

I see the main issue as false positives and trying to minimise the impact these have on conscientious COs when there really is no maintenance required.

 

See above - consicentious CO's are not the target. And because you see the main issue as false positives you're prepared to build in an override switch in the form of a tick box which instantly castrates the algorithm, rendering it useless as a tool

It'd be far from useless at detecting COs who have left the game (they won't respond at all) and honest COs can still get benefit from a reminder if they've inadvertently overlooked an issue.

 

I see the algorithm's main purpose being to prod inattentive or forgetful COs

 

Really? I mean come on - how many prods do they need?

On caches that get few finds, a cluster of DNFs spread over many months or years can be easily overlooked, particularly if the CO has many hides. Or the common scenario here: someone posts an NM because of a full log, the next finder replaces the log, the CO thinks everything's fine and no OM gets posted to clear the NM.

 

and to give reviewers a heads-up on abandoned caches that have fallen into disrepair, and despair at innocent COs caught in the net.

 

So you think the algorithm should score highly for CO's who:

 

1) Don't respond to NM

2) Don't respond to NA

3) Don't respond to automated email

4) Don't respond to reviewer notes

5) Don't respond to reviewer temp disablement

 

I have to agree.

 

The issue is that 1 and 2 aren't happening in those cases which have led to the complaints to Groundspeak which have in turn led them to conclude that they need to do something about the problem.

COs that don't respond to an NA are already in the hands of a reviewer so I don't see why this is a problem that needs to be fixed. 4 and 5 are also in the hands of a reviewer and don't need an algorithm. As for 3, the CO can't respond to the email if they're sure there's no maintenance needed (the DNF that triggered it had nothing to do with cache health or they've confirmed with the DNFer that they were looking in the wrong place). If the algorithm is supposed to be flushing out inactive COs who've left the game, there really needs to be some way for a false positive CO to say "I'm not one of those."

 

We must live in very different caching worlds, and I'm not sure there's a single algorithm that, looking only at log types and not their content, can successfully satisfy both.

 

We don't live in very different caching worlds at all. The only difference here is the way we are looking at the problem which has given rise to the Geocache Health Score.

Somehow I think we do. Around here, wilfully negligent COs are very rare, but there are forgetful ones who could benefit from a nudge and many who leave the game after a year or two and then don't respond to anything, leaving behind a trail of discarded caches. In those latter two cases, an algorithm that treats all logs as truthful and allows responsible COs to report a false positive would still be quite a useful tool, whereas one that treats everyone with suspicion, and doesn't offer the conscientious CO a way to deal with false positives, discourages those who are innocently caught, leading to a reluctance to post DNFs for fear of the repercussions and a reluctance to hide caches that might get a few DNFs.

[Blue Square Thing]

To me, the issue is that the system does not handle false positives well, especially for caches that are difficult to visit at the drop of a hat. The only options offered to the CO are to visit the cache site or to archive the cache listing. There is no option to tell Groundspeak that there is nothing in the logs to indicate a problem, and that their system is being overly aggressive.

Yes there is - you can write a note and place it on the cache page. Given that caches are not automatically archived but are looked at by human beings this should essentially tell the people who matter what the situation is. Doesn't that work to solve the problem that is being suggested?

[+barefootjeff]

An afterthought...

 

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

**SNIP**

If flagging wilful maintenance shirkers is the principal purpose of the algorithm, why bother with the email at all? Why not just send the list of unhealthy caches straight to the reviewer? That'd eliminate the angst caused to the rare conscientious CO who gets a false positive, and for the rest the reviewer could just immediately slap a TD and 30-day ultimatum on the cache.

 

I think the reason we're seeing this differently is that wilful maintenance shirkers aren't a problem here, so all we're seeing are the adverse effects of the algorithm without any of the benefits.

[+barefootjeff]

Another afterthought....

 

2) That CO, given the opportunity to tell the algorithm that it's wrong every time he gets an email by simply ticking a box, isn't going to tick that box?

 

Just so there's no confusion, I'm only concerned about the case where the cache's only misdemeanour is to have had one or more DNFs logged on it. If there's an outstanding NM, the list of options provided in the email (repair and log OM, disable until you can or archive) is quite appropriate. If someone else has already replaced the full logbook, logging an OM saying that is still the appropriate response just to clear the red wrench.

 

The only-DNFs case is the problem one, since "But nothing's wrong!" is a likely response that the CO ought be able to communicate back. DNFs are a blunt instrument and most of the time don't mean the cache is missing. It doesn't have to be just a checkbox - the ability to reply to the email with a reason why the CO thinks it got it wrong would be fine. Right now, the only options for a conscientious CO to take are to unnecessarily do one of the things listed, ignore it and hope it goes away (something as an engineer I've been trained never to do), or somehow figure out that you have to pester a reviewer about it.

Edited March 6, 2017 by barefootjeff

[+niraD]

To me, the issue is that the system does not handle false positives well, especially for caches that are difficult to visit at the drop of a hat. The only options offered to the CO are to visit the cache site or to archive the cache listing. There is no option to tell Groundspeak that there is nothing in the logs to indicate a problem, and that their system is being overly aggressive.

Yes there is - you can write a note and place it on the cache page. Given that caches are not automatically archived but are looked at by human beings this should essentially tell the people who matter what the situation is. Doesn't that work to solve the problem that is being suggested?

So, can we get that added to the email that the system automatically sends? Something simple, like: "If you have received this email in error, then post an explanation as a Note to your cache listing."

[+fizzymagic]

So, can we get that added to the email that the system automatically sends? Something simple, like: "If you have received this email in error, then post an explanation as a Note to your cache listing."

 

That was requested months ago during the first brouhaha. You'd have thought it was a request to throw puppies into a blender. Apparently even hinting that no action could be taken is tantamount to giving "maintenance shirkers" carte blanche to clutter the landscape with trash.

 

It seemed to me to be a reasonable request at the time, and still does.

[+barefootjeff]

So, can we get that added to the email that the system automatically sends? Something simple, like: "If you have received this email in error, then post an explanation as a Note to your cache listing."

 

That was requested months ago during the first brouhaha. You'd have thought it was a request to throw puppies into a blender. Apparently even hinting that no action could be taken is tantamount to giving "maintenance shirkers" carte blanche to clutter the landscape with trash.

 

It seemed to me to be a reasonable request at the time, and still does.

Looks like I was wrong about the principal purpose of the algorithm. My apologies to Team Microdot. What a sad state of affairs we've ended up in.

[+Team Microdot]

I thought it was mainly about cleaning up after COs who have left the game, and giving active COs a prod if they've slipped up clearing an NM or missed seeing a pattern in DNF logs that might suggest a problem. It happens; people have distractions like jobs and families, and I'm sure most of the time it's that rather than wilful intent to shirk maintenance. We already have a mechanism in place for dealing with an NM that hasn't been resolved - someone in the community just has to post an NA, then it's out of the COs hands and into the lap of a reviewer. Around here, that works pretty well.

 

I too have a job and a family and I still manage to keep on top of all our caches without difficulty. I tend to find that a pro-active approach works best. When someone logs one of our caches I'll read the email (logs tend to be short so this doesn't take long) and if it looks like there might be a problem I'll take a quick look at the cache page and decide what action, if any, needs to be taken.

 

Anyone struggling to fit cache maintenance around their busy lifestyle or finding that they 'inadvertently' overlook cache issues on a regular basis might own too many caches.

 

If more people were posting NA when it needs to be posted we wouldn't be having this discussion in the first place.

 

On caches that get few finds, a cluster of DNFs spread over many months or years can be easily overlooked, particularly if the CO has many hides. Or the common scenario here: someone posts an NM because of a full log, the next finder replaces the log, the CO thinks everything's fine and no OM gets posted to clear the NM.

 

CO's who suffer from these issues might own too many caches, although they might do better if they adopt a strategy similar to the one I describe above i.e. a pro-active one which involves taking the small amount of time required to check over information coming in at the time it comes in and responding accordingly. It's not difficult.

[cezanne]

To me, the issue is that the system does not handle false positives well, especially for caches that are difficult to visit at the drop of a hat. The only options offered to the CO are to visit the cache site or to archive the cache listing. There is no option to tell Groundspeak that there is nothing in the logs to indicate a problem, and that their system is being overly aggressive.

Yes there is - you can write a note and place it on the cache page. Given that caches are not automatically archived but are looked at by human beings this should essentially tell the people who matter what the situation is. Doesn't that work to solve the problem that is being suggested?

So, can we get that added to the email that the system automatically sends? Something simple, like: "If you have received this email in error, then post an explanation as a Note to your cache listing."

 

That would be very helpful indeed and if they allowed a note (instead of OM) it would also also cases like easily can arise for old caches which are in good shape but do not have an active owner. Post #4 in this thread

http://forums.Groundspeak.com/GC/index.php?showtopic=343284 describes a situation which I have encountered in many areas. It would be very painful to lose such caches as a result of something which claims to have cache quality in mind.

[+Team Microdot]

An afterthought...

 

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

**SNIP**

If flagging wilful maintenance shirkers is the principal purpose of the algorithm, why bother with the email at all? Why not just send the list of unhealthy caches straight to the reviewer? That'd eliminate the angst caused to the rare conscientious CO who gets a false positive, and for the rest the reviewer could just immediately slap a TD and 30-day ultimatum on the cache.

 

I think the reason we're seeing this differently is that wilful maintenance shirkers aren't a problem here, so all we're seeing are the adverse effects of the algorithm without any of the benefits.

 

I think the principal purpose of the algorithm is probably to reduce the number of complaints received by Groundspeak about unmaintained caches - however they come to be that way.

 

I can't even imagine why a conscientious CO would feel angst at getting a false positive. Personally I'd be happy to see the evidence that more was being done to clear junk from the map

 

And if the emails don't go out, all those cachers you believe would benefit from a nudge won't get it

[+redsox_mark]

Regardless of what the algorithm does, around here my observation is the reviewers seem to focus more on the "might be missing" cases. An example: I found the remains of a cache this weekend. It was just a torn ziplock bag with a wet log. The logs report their used to be a container, but it was reported missing in October. NM raised in Nov, NA in Jan. Eventually there may be some action, but none yet. It is getting found logs, as there is a container (of sorts) and a log (of sorts). CO doesn't seem to be active. I'm not criticizing the reviewers here, they are busy. But to compare to another recent case. I was FTF on a new cache. Joint FTF actually, I met up with another cacher and we found it after a long search. Tricky hide. Over the next month, there were 3 or 4 DNFs. Then the reviewer intervened to disable the cache and start the timer. It is now archived as the CO didn't react.

 

I think it is highly likely that the second cache is still there, and still OK.

 

These are just examples, but I've noticed a trend. DNFs seem to trigger disabling quickly. NM and NA do not, as long as what remains of the cache is still being found.

 

Back to the algorithm; if a priority is on "likely missing", then DNFs need to be considered, as much as I don't like the false positives.

[cezanne]

 

I can't even imagine why a conscientious CO would feel angst at getting a false positive.

 

I rather feel angst that caches get archived that mean a lot to me and which are not junk.

I'm also concerned about the system as I use DNFs in a way completely unrelated to the issues of junk and caches that might be missing.

 

When I post a NA for a cache for which this is appropriate, I'm not concerned about how the CO might feel. However when I post a DNF reporting on for example my issues with climbing trees or going down steep slopes, then I'm very much concerned if a new system changes what never has been a problem since I have started with geocaching. For those cache owners out there who have almost or completely stopped to hunt for geocaches themselves but still maintain their caches requests like of the type sent out by the mail come across as particularly weird and it easily can be the last drop that makes the cup run over and lead to archival of caches in good shape. In my opinion it is important to keep in mind that the mail is not only sent out to those who still cache regularly and who keep an active eye on how things develop at this site, they are also sent out to people who are not any longer closely attached to geocaching and kept their caches to please the community. Mails of the sent type will reinforce the feeling of those cache owners that the current community does not have much in common with what geocaching used to be.

[+barefootjeff]

An afterthought...

 

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

**SNIP**

If flagging wilful maintenance shirkers is the principal purpose of the algorithm, why bother with the email at all? Why not just send the list of unhealthy caches straight to the reviewer? That'd eliminate the angst caused to the rare conscientious CO who gets a false positive, and for the rest the reviewer could just immediately slap a TD and 30-day ultimatum on the cache.

 

I think the reason we're seeing this differently is that wilful maintenance shirkers aren't a problem here, so all we're seeing are the adverse effects of the algorithm without any of the benefits.

 

I think the principal purpose of the algorithm is probably to reduce the number of complaints received by Groundspeak about unmaintained caches - however they come to be that way.

 

I can't even imagine why a conscientious CO would feel angst at getting a false positive. Personally I'd be happy to see the evidence that more was being done to clear junk from the map

 

And if the emails don't go out, all those cachers you believe would benefit from a nudge won't get it

The angst I felt was getting an email telling me my seven-week-old T5 cache might need attention, "anything from a new logbook to replacing a missing container", three days after just one person logged a DNF because she was put off by muggles and was looking in the wrong place. According to the email, my options were to visit the cache and repair it, disable it until I could, or archive it. It's a 3km kayak paddle to do a maintenance visit, it was right in the middle of the summer school holidays so the normally quiet waterway was busy with water skiers and jet skis, and it was either hot, around 40C, or very windy, so I wasn't inclined to go and "fix" a problem that didn't exist, particularly after the DNFer went back and found it a few days later. There was no way to report what was a blatant false positive and no indication of what would happen if I ignored it - now it seems I've probably been marked in the system as a maintenance-shirker.

[+Team Microdot]

An afterthought...

 

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

**SNIP**

If flagging wilful maintenance shirkers is the principal purpose of the algorithm, why bother with the email at all? Why not just send the list of unhealthy caches straight to the reviewer? That'd eliminate the angst caused to the rare conscientious CO who gets a false positive, and for the rest the reviewer could just immediately slap a TD and 30-day ultimatum on the cache.

 

I think the reason we're seeing this differently is that wilful maintenance shirkers aren't a problem here, so all we're seeing are the adverse effects of the algorithm without any of the benefits.

 

I think the principal purpose of the algorithm is probably to reduce the number of complaints received by Groundspeak about unmaintained caches - however they come to be that way.

 

I can't even imagine why a conscientious CO would feel angst at getting a false positive. Personally I'd be happy to see the evidence that more was being done to clear junk from the map

 

And if the emails don't go out, all those cachers you believe would benefit from a nudge won't get it

The angst I felt was getting an email telling me my seven-week-old T5 cache might need attention, "anything from a new logbook to replacing a missing container", three days after just one person logged a DNF because she was put off by muggles and was looking in the wrong place. According to the email, my options were to visit the cache and repair it, disable it until I could, or archive it. It's a 3km kayak paddle to do a maintenance visit, it was right in the middle of the summer school holidays so the normally quiet waterway was busy with water skiers and jet skis, and it was either hot, around 40C, or very windy, so I wasn't inclined to go and "fix" a problem that didn't exist, particularly after the DNFer went back and found it a few days later. There was no way to report what was a blatant false positive and no indication of what would happen if I ignored it - now it seems I've probably been marked in the system as a maintenance-shirker.

 

I guess the T5 rating might have had something to do with that.

 

My view is that the algorithm shouldn't fire after a single DNF on any cache. I can only imagine it's already been tweaked to prevent that from happening.

[+barefootjeff]

An afterthought...

 

If we remember that we are looking mainly at caches where the CO isn't taking proper care of them in the first place, despite having access to ALL of the information about the cache already in the logs, what makes you think that:

 

1) One extra email from an algorithm is going to make a difference to that CO's approach to maintenance?

**SNIP**

If flagging wilful maintenance shirkers is the principal purpose of the algorithm, why bother with the email at all? Why not just send the list of unhealthy caches straight to the reviewer? That'd eliminate the angst caused to the rare conscientious CO who gets a false positive, and for the rest the reviewer could just immediately slap a TD and 30-day ultimatum on the cache.

 

I think the reason we're seeing this differently is that wilful maintenance shirkers aren't a problem here, so all we're seeing are the adverse effects of the algorithm without any of the benefits.

 

I think the principal purpose of the algorithm is probably to reduce the number of complaints received by Groundspeak about unmaintained caches - however they come to be that way.

 

I can't even imagine why a conscientious CO would feel angst at getting a false positive. Personally I'd be happy to see the evidence that more was being done to clear junk from the map

 

And if the emails don't go out, all those cachers you believe would benefit from a nudge won't get it

The angst I felt was getting an email telling me my seven-week-old T5 cache might need attention, "anything from a new logbook to replacing a missing container", three days after just one person logged a DNF because she was put off by muggles and was looking in the wrong place. According to the email, my options were to visit the cache and repair it, disable it until I could, or archive it. It's a 3km kayak paddle to do a maintenance visit, it was right in the middle of the summer school holidays so the normally quiet waterway was busy with water skiers and jet skis, and it was either hot, around 40C, or very windy, so I wasn't inclined to go and "fix" a problem that didn't exist, particularly after the DNFer went back and found it a few days later. There was no way to report what was a blatant false positive and no indication of what would happen if I ignored it - now it seems I've probably been marked in the system as a maintenance-shirker.

 

I guess the T5 rating might have had something to do with that.

 

My view is that the algorithm shouldn't fire after a single DNF on any cache. I can only imagine it's already been tweaked to prevent that from happening.

Who knows? There's no documented way to officially report a false positive, because apparently that'd let maintenance-shirkers off the hook. The only confirmation I got back from the Support Centre was that the subsequent find following the DNF had cleared the cache's health score - just as well the DNFer tried again as no-one else has been out there since.

[+Team Microdot]

There's no documented way to officially report a false positive, because apparently that'd let maintenance-shirkers off the hook.

 

Probably by design.

[+justintim1999]

 

I don't know about you but I had no idea that this Health Score even existed until this thread. From what I understand reviewers have been using it for quite a while.

 

 

I have learnt about the score before this thread. My concern is about using the score for automatic messages. If reviewers use the tool to help them and have a look at the logs, human intelligence is involved.

 

Mails like the one sent to barefootjeff are what causes a lot of the concern voiced here.

 

I do not know what you call a typical cache. I do not think that I own a typical cache and probably most of the caches I like are untypical in your eyes.

 

Point was that I think the use of the health score has been going on for a while and it's only now that we know about it it's somehow become a problem. If it was as big an issue as some are making it out to be I'd think we would have noticed it before now.

 

Typical as in a simple traditional hidden less than lets say a 1/2 mile from a parking area which is probably the majority of the caches out there.

 

I see reviewers using the health score in two ways. First to flag potential problems, helping identify caches they need to be watching. Second, The e-mail reminder is as a way to get some of these cleaned up without reviewer involvement.

 

This was born out of necessity. GS realized that with the growth of caching and the sheer number of hides out there, they needed to develop something that would complement the current reporting process.

 

If the opposition to this is about active cache owners receiving a couple more e-mails, well to me that's silly. Every other argument against the use of this tool has either been paranoids who are ready to stock up the shelters, long time cachers who can't or won't realize that the caching world has changed or bad cache owners who see the writing on the wall.

[cezanne]

Point was that I think the use of the health score has been going on for a while and it's only now that we know about it it's somehow become a problem. If it was as big an issue as some are making it out to be I'd think we would have noticed it before now.

 

There have been threads about the topic before.

Moreover, 2017 has been announced as the year with special focus on cache health which lets me think that more is to come.

 

Typical as in a simple traditional hidden less than lets say a 1/2 mile from a parking area which is probably the majority of the caches out there.

 

But also the type of caches I do not care about. I'm worried about the rest.

 

Every other argument against the use of this tool has either been paranoids who are ready to stock up the shelters, long time cachers who can't or won't realize that the caching world has changed or bad cache owners who see the writing on the wall.

 

Apparently you misunderstood my point regarding the changes in the caching world which is very far from paranoia. I know many cache owners who do not cache actively longer and their willingness to comply with things they will regard as unnecessary formalities will be limited and at some point there is the point where they decide to give up their caches which they still maintain despite having stopped to hunt for caches. That's certainly a different perspective you have from that point of view than as someone who regularly hunts for caches and stays in contact with cachers (through cache hunts, events, forums, social media, meetings cachers at other caches etc). Have you contact to such former cachers and have talked about them how they perceive certain changes and how this influences their reactions and actions?

Edited March 6, 2017 by cezanne

[+thebruce0]

Let's assume we're targeting maintenance shirkers with this algorithm.

 

- Jack CO gets an email, known to be a false positive due to being a DNF on a hard cache. Despite wording, CO ignores it and doesn't post any note.

- Joe CO gets an email for a broken container issue, a finder posted a NM. CO is lazy and doesn't address it, feeling that another cacher will replace the container.

 

- Jack, over time, receives another DNF, maybe another email, eventually a Find. Another DNF, another email, cache is highlighted to the attention of a reviewer, as it wasn't reported but bumped in priority on their maintenance sweep.

- Joe receives another three finds and a DNF, plus another NM, and another email. Eventually the cache is raised to the attention of a reviewer due to the outstanding NM, and DNF also dropping its score to have it bumped in priority.

 

Which one will the reviewer actually do something about? (presuming of course a rational reviewer)

Edited March 6, 2017 by thebruce0

[+Team Microdot]

Let's assume we're targeting maintenance shirkers with this algorithm.

 

- Jack CO gets an email, known to be a false positive due to being a DNF on a hard cache. Despite wording, CO ignores it and doesn't post any note.

- Joe CO gets an email for a broken container issue, a finder posted a NM. CO is lazy and doesn't address it, feeling that another cacher will replace the container.

 

- Jack, over time, receives another DNF, maybe another email, eventually a Find. Another DNF, another email, cache is highlighted to the attention of a reviewer, as it wasn't reported but bumped in priority on their maintenance sweep.

- Joe receives another three finds and a DNF, plus another NM, and another email. Eventually the cache is raised to the attention of a reviewer due to the outstanding NM, and DNF also dropping its score to have it bumped in priority.

 

Which one will the reviewer actually do something about? (presuming of course a rational reviewer)

 

Which algorithm and who are you asking?

 

Given that your question doesn't appear to be directly related to any algorithm but rather to the reviewer's response I'll hazard a guess that the reviewer will try do something about Joe's cache.

[+justintim1999]

Point was that I think the use of the health score has been going on for a while and it's only now that we know about it it's somehow become a problem. If it was as big an issue as some are making it out to be I'd think we would have noticed it before now.

 

There have been threads about the topic before.

Moreover, 2017 has been announced as the year with special focus on cache health which lets me think that more is to come.

 

Typical as in a simple traditional hidden less than lets say a 1/2 mile from a parking area which is probably the majority of the caches out there.

 

But also the type of caches I do not care about. I'm worried about the rest.

 

Every other argument against the use of this tool has either been paranoids who are ready to stock up the shelters, long time cachers who can't or won't realize that the caching world has changed or bad cache owners who see the writing on the wall.

 

Apparently you misunderstood my point regarding the changes in the caching world which is very far from paranoia. I know many cache owners who do not cache actively longer and their willingness to comply with things they will regard as unnecessary formalities will be limited and at some point there is the point where they decide to give up their caches which they still maintain despite having stopped to hunt for caches. That's certainly a different perspective you have from that point of view than as someone who regularly hunts for caches and stays in contact with cachers (through cache hunts, events, forums, social media, meetings cachers at other caches etc). Have you contact to such former cachers and have talked about them how they perceive certain changes and how this influences their reactions and actions?

 

I wouldn't say your overly paranoid but some of the comments in this thread smell of just that.

 

I'd say that any cache I'd deem as not typical more often than not has an owner that is active. Any one who spends any significant time properly going through the process of hiding a good cache will probably maintain it, collect up the container and archive it when their done. This isn't about them.

 

They may be unnecessary formalities to some but are they unnecessary to geocaching as a whole?

 

Some people only ask "what's in it for me". Others look at the big picture. I'm sorry but a few false positives, even on my own caches, or a couple of e-mail reminders isn't going to cause me to pack up and leave the game. If this type of tool helps reviewers be more efficient in their work than I'm for it even though it may inconvenience me a little.

[+Team Microdot]

I'm sorry but a few false positives, even on my own caches, or a couple of e-mail reminders isn't going to cause me to pack up and leave the game. If this type of tool helps reviewers be more efficient in their work than I'm for it even though it may inconvenience me a little.

 

You've clearly misunderstood and are going about things in completely the wrong way

 

You have to get all angry and stuff

[+thebruce0]

Let's assume we're targeting maintenance shirkers with this algorithm.

 

- Jack CO gets an email, known to be a false positive due to being a DNF on a hard cache. Despite wording, CO ignores it and doesn't post any note.

- Joe CO gets an email for a broken container issue, a finder posted a NM. CO is lazy and doesn't address it, feeling that another cacher will replace the container.

 

- Jack, over time, receives another DNF, maybe another email, eventually a Find. Another DNF, another email, cache is highlighted to the attention of a reviewer, as it wasn't reported but bumped in priority on their maintenance sweep.

- Joe receives another three finds and a DNF, plus another NM, and another email. Eventually the cache is raised to the attention of a reviewer due to the outstanding NM, and DNF also dropping its score to have it bumped in priority.

 

Which one will the reviewer actually do something about? (presuming of course a rational reviewer)

 

Which algorithm and who are you asking?

 

Given that your question doesn't appear to be directly related to any algorithm but rather to the reviewer's response I'll hazard a guess that the reviewer will try do something about Joe's cache.

 

Exactly.

The algorithm targets nothing but potential maintenance issues.

The ultimate result of this score system is that the only ones tangibly affected by it are the problem caches or cache owners, and after human intervention.

[+hzoi]

...

 

I can't believe this topic required 500 posts to discuss it. Yet we're nearly there.

[cezanne]

I'd say that any cache I'd deem as not typical more often than not has an owner that is active.

 

I would not dare to say that and even if it were true it does not help. I rather have 20 junk caches not filtered out among 1000 typical caches than say 1 out of 20 atypical ones affected.

 

Any one who spends any significant time properly going through the process of hiding a good cache will probably maintain it, collect up the container and archive it when their done. This isn't about them.

 

First, I was referring to the point in time when someone decides to archive a cache they maintained until then. Things like the emails discussed here can make alleviate the decision towards archival by someone not any longer attached to geocaching.

Second, there can be many reasons for someone leaving geocaching without following the procedure above.

 

They may be unnecessary formalities to some but are they unnecessary to geocaching as a whole?

 

It depends on one's view point. I also regard NM logs as unnecessary (not messages about maintenance issues). I never ever search for or hide more caches than I can read logs for from the start to the end.

 

Some people only ask "what's in it for me". Others look at the big picture. I'm sorry but a few false positives, even on my own caches, or a couple of e-mail reminders isn't going to cause me to pack up and leave the game. If this type of tool helps reviewers be more efficient in their work than I'm for it even though it may inconvenience me a little.

 

The difference is that you still actively participate in geocaching too. Someone who only left some caches out there because there are some local cachers out there whom they want to please will not care at all about the big picture. They are willing to keep their caches up to the point where it is getting (too) inconvenient/cumbersome.

 

Moreover, what about geocaches in good condition hidden by cachers who passed away or left geocaching without having been able or willing to remove the container? Why shouldn't we enjoy those cachers if there are issues with them?

Archiving such caches for formal reasons does not solve a single issue and does not make anyone win anything in the cases I have in mind (not urban spots where 1000 people want to hide their new short lifed micro/nanos).

 

Cezanne

Edited March 6, 2017 by cezanne