A proposal for automated cache health score letter

[+fizzymagic]

During our recent hiatus, I took the time to come up with an improved email notification that could go out for automated Cache Health Score notifications.  Here it is:
 

Quote

 

We're sending you this email because our automated Cache Health Score system has detected that there
might be a problem with your cache GCXXXXX.  Please review the last few logs for that cache to see if
they indicate a missing container or other maintenance issue.

If the logs do indeed indicate issues with the cache, you can resolve them by either visiting the cache
and fixing or replacing it, or (if the cache appears to be gone) by archiving the cache listing.

If you perform maintenance on the cache and leave it in place, please post an Owner Maintenance log so
that our system and other cachers can see that any problems have been fixed.

If the logs do not indicate a problem, or you have already addressed any issues with the cache, please
send us an email at chs@Groundspeak.com with the subject line GCXXXXX and a short description of the
current status of the cache. These notes will help us improve the Cache Health Score algorithm to reduce
erroneous notifications.

Thanks very much.

Groundspeak

 

It seems to me that this version eliminates all the offensive features of the current notification email while preserving all of the features desired by Groundspeak.

• It still notifies the cache owner of potential problems
• It still places the options of owner maintenance or archival first
• It treats the recipient with respect, including an option to deal with false positives
• All possible responses by a cache owner involve some action that HQ can see (either a log or an email)
• It addresses the main problem that the CHS was designed for -- absentee cache owners that will not respond at all

Do any of those who support the current notification email see any problems with this improved one?

[+J Grouchy]

I may be wrong, but isn't the biggest issue folks have the fact that these emails are triggered by DNF logs?  If that's not the case, ignore this...but if it's true, how does this address that?  It doesn't really appear to deal with DNFs and how they quite often have nothing to do with the cache's "health".

[+Team DEMP]

I like it. 

Consider alternative text for the first sentence from:
We're sending you this email because our automated Cache Health Score system has detected that there
might be a problem with your cache GCXXXXX. 

to:

Our automated Cache Health Score system has detected a possible situation with your cache GCXXXXX. 

[+Team DEMP]

2 minutes ago, J Grouchy said:

I may be wrong, but isn't the biggest issue folks have the fact that these emails are triggered by DNF logs?  If that's not the case, ignore this...but if it's true, how does this address that?  It doesn't really appear to deal with DNFs and how they quite often have nothing to do with the cache's "health".

It seems the issue is that the message apparently assumed an issue and didn't explicitly indicate an action to take if there's nothing to be done.  I guess these same people are "upset" when they receive a subscription renewal reminder months in advance because it doesn't say "or throw this out and we'll remind you next month" :-)

[+ChileHead]

I don't see what is "offensive" with the current message.

[+Team DEMP]

2 minutes ago, ChileHead said:

I don't see what is "offensive" with the current message.

The other threads landed on 2 points related to the automated message:

1. Assuming there is a problem that needs to be dealt with
2. No messaging that doing nothing is an option and what to do in if you feel you received this in error. 

The email in the original post improves on these 2 concerns multiple individuals have voiced.

[+thebruce0]

32 minutes ago, J Grouchy said:

I may be wrong, but isn't the biggest issue folks have the fact that these emails are triggered by DNF logs?  If that's not the case, ignore this...but if it's true, how does this address that?  It doesn't really appear to deal with DNFs and how they quite often have nothing to do with the cache's "health".

The problem is that "quite often have nothing to do with" is just like "quite often have something to do with", but it's impossible for the system to tell which is true; the line is arbitrary, and entirely up to the responsible CO to address. It's good that the email doesn't assume what specifically triggered the problem (if the algorithm takes numerous factors into consideration), but it can't ignore DNFs as a nudge factor since they very well could indicate a potential problem. So it really comes down to the wording within. Something triggered the notification, so if you haven't already been reviewing the logs on your cache (ie, you've been ignoring them, likely, unless you've been away), then this is a gentle reminder to check them out.  If you have, then feel free to ignore the email.  Better wording to that effect would be beneficial, many of us feel.

[+J Grouchy]

1 minute ago, thebruce0 said:

The problem is that "quite often have nothing to do with" is just like "quite often have something to do with", but it's impossible for the system to tell which is true; the line is arbitrary, and entirely up to the responsible CO to address. It's good that the email doesn't assume what specifically triggered the problem (if the algorithm takes numerous factors into consideration), but it can't ignore DNFs as a nudge factor since they very well could indicate a potential problem. So it really comes down to the wording within. Something triggered the notification, so if you haven't already been reviewing the logs on your cache (ie, you've been ignoring them, likely, unless you've been away), then this is a gentle reminder to check them out.  If you have, then feel free to ignore the email.  Better wording to that effect would be beneficial, many of us feel.

Sorry, but this is ridiculous. But I'm sure there's nothing I could say that hasn't already been said about it.  I just think it's setting the bar way too low.

[+thebruce0]

Okay.

[+barefootjeff]

Assuming the algorithm sending the email knows what circumstances triggered it, perhaps the text could be tailored accordingly. The Help Centre page says:

Quote

This algorithm is based on a combination of logs and circumstances, including

• Did Not Find (DNF)
• Needs Maintenance (NM)
• Needs Archived (NA)
• Caches that have not been found in a long time
• Difficulty and terrain rating

For caches that simply haven't been found in a long time, maybe just a reminder about the requirement for occasional cache visits or, if the intention is to weed out unpopular caches, a suggestion to move it or replace it with something easier to find.

For caches with an outstanding NM, assuming it's allowed at least a month for the CO to respond of their own accord, a reminder of the need to log an OM indicating that the problem's been addressed and to clear the red wrench.

I really don't know why caches with an outstanding NA need to generate a CHS email since it's now in the hands of the reviewer who'll either uphold or dismiss the NA. Either way, what purpose does the email serve in this circumstance?

For what seems to be the most common case of just one or more DNF logs with no outstanding NMs or NAs, maybe it should just say that an unexpected pattern of DNFs has been detected and the CO should check the logs to determine if the cache needs attention or if the D/T rating should be increased.

For feedback, a simple Was this helpful? Yes/No might be all that's needed, preferably with an option to add an explanation if the answer is No.

Edited July 17, 2017 by barefootjeff

[+humboldt flier]

Seems to me, the recipient of an earlier "nasty-gram", that the "power" was placed into the hands of new cachers with few finds and probably a phone app went from could not locate DIRECTLY to a "Needs Archived Note" ............

 

Who me bitter.   Let me ponder that.

 

Yepper bitter ... very much so.

[+Harry Dolphin]

23 minutes ago, barefootjeff said:

For caches that simply haven't been found in a long time, maybe just a reminder about the requirement for occasional cache visits or, if the intention is to weed out unpopular caches, a suggestion to move it or replace it with something easier to find.

Wow!  Many of my caches are not found very often because they require a hike along a trail in the woods.  (Yeah.  Used to be what geocaching was all about.)  That doesn't mean they're unpopular.  Those who find them love them!  Easier to find?  They're easy to find after a mile hike and a few hundred feet of climb.  

Then again, I've been working on the local blue caches.  Nice hikes in the woods that no one does anymore.  Two not found in four years.  Six not found in three years.  Fourteen not found in two years.  And twenty-six not found in one year..

[+Team Microdot]

12 hours ago, fizzymagic said:

Do any of those who support the current notification email see any problems with this improved one?

Looks pretty good to me.

[+Isonzo Karst]

14 hours ago, fizzymagic said:

If the logs do not indicate a problem, or you have already addressed any issues with the cache, please
send us an email at chs@Groundspeak.com with the subject line GCXXXXX and a short description of the
current status of the cache. These notes will help us improve the Cache Health Score algorithm to reduce
erroneous notifications.

Once in these forums, you attempted to make an explanation of probability to a forum user. This related to odds that a person would not be able to complete a multi-cache. I don't know if you recall this? it was about as funny as any thread I've ever seen here.  Guy was innumerate, and could not begin to get his head around anything you were saying.

I mention this because I suspect that 93.0917% of "emails to chs@Groundspeak.com" would include no info that would, "help us improve the Cache Health Score algorithm."  Those emails mostly be rants.

I can't tell if you're being deliberately disingenuous, or really think that individual cachers can think in terms of what an algorithm is, how it's generated.

 

I'd like to see both the email and the article include a "do nothing" option, an acknowledgement that logs cannot read for content, and that there will be false positives.

[+NYPaddleCacher]

In general I think the new version is an improvement but this section could be improved:

 

"If the logs do indeed indicate issues with the cache, you can resolve them by either visiting the cache
and fixing or replacing it, or (if the cache appears to be gone) by archiving the cache listing."

 

I would be useful to suggest that "If you can't visit the cache right away, disable the cache listing until you can confirm that there are issues".

 

That, at least, acknowledges that there might be issues until it can be confirm what additional action may be necessary (performing maintenance on the physical container or archiving the listing".  Obviously, disabling the cache shouldn't be used to postpone maintaining the cache, but it's unrealistic to expect a CO to immediately go out and fix or replace the container as soon as someone reports an issue.

[+Team Microdot]

52 minutes ago, Isonzo Karst said:

I'd like to see both the email and the article include a "do nothing" option

That would be a fundamental flaw in the entire process.

[+fizzymagic]

8 hours ago, Isonzo Karst said:

 

I mention this because I suspect that 93.0917% of "emails to chs@Groundspeak.com" would include no info that would, "help us improve the Cache Health Score algorithm."  Those emails mostly be rants.

I can't tell if you're being deliberately disingenuous, or really think that individual cachers can think in terms of what an algorithm is, how it's generated.

 

I'd like to see both the email and the article include a "do nothing" option, an acknowledgement that logs cannot read for content, and that there will be false positives.

 

I understand that at least some of the emails would be rants.  I agree completely that there will be false positives, but I don't agree that "do nothing" should be an option.

 

I was trying to think in terms of what Groundspeak wants to get out of the interaction.  For them, even an angry response indicates an active cache owner. If no action at all is an option, then the interaction is not able to distinguish between absentee cache owners and active cache owners that don't see a problem.

 

And I don't think it is disingenuous to say that the emails can be used to refine the algorithm. Groundspeak can use the non-rant ones to identify real false positives in the system, which can indeed be used to improve the algorithm.

 

But the main point here is that a "do nothing" option provides zero information and loses the ability to identify inactive cache owners.

[+WarNinjas]

I think  the new wording is good.  I don't know what the old one was but no need to be mean in the email.  I like the idea for sure.  As a CO of many caches sometimes you can miss out on noticing some need some love.  If I got one of these emails I would definitely go check it out.

[+Isonzo Karst]

My apologies, clearly my intent with, "do nothing", was badly stated and misunderstood. Below the text of the current email, with a new text in red that's close to my meaning. It could doubtless use some wordsmithing, but it speaks to the case where there are 4 DNFS, all of the, "never got out of the car" type. Or DNF stutter logs,  3 identical DNFs from a 2 finds logger. Or other logs that a human being with reading comprehension can discount ~  rather than a computer counting log types.

 

Hello _______________,

 Your geocache, GCXXXXX looks like it might need some attention. The recent logs may contain more details about what sort of maintenance needs to be performed. This could be anything from a new logbook to replacing a missing container. Here are a few options for what to do now:

•  Physical Maintenance: Visit your geocache, make any needed repairs, and post an "Owner Maintenance" log so the community knows it's available to find.
• Listing Maintenance: Check the logs carefully. It may be that  no action is needed.
•  Disable: If you cannot check on your geocache within a reasonable amount of time, please disable your geocache listing. Once you perform maintenance, you can enable it and post an "Owner Maintenance" log.
•  Archive: If you decide it is time for your geocache to be permanently retired, please archive the listing and retrieve all physical stages.

For tips about how to perform maintenance and to learn why Geocaching HQ sends occasional geocache maintenance reminders, please see this Help Center article.

Thanks,

Geocaching HQ

 

I'd be tempted to add to Listing maintenance that cache may need a different rating, but that's in the Help Center article. 

Edited July 19, 2017 by Isonzo Karst
link/ speeling

[+justintim1999]

On ‎7‎/‎18‎/‎2017 at 6:56 AM, NYPaddleCacher said:

In general I think the new version is an improvement but this section could be improved:

 

"If the logs do indeed indicate issues with the cache, you can resolve them by either visiting the cache
and fixing or replacing it, or (if the cache appears to be gone) by archiving the cache listing."

 

I would be useful to suggest that "If you can't visit the cache right away, disable the cache listing until you can confirm that there are issues".

 

That, at least, acknowledges that there might be issues until it can be confirm what additional action may be necessary (performing maintenance on the physical container or archiving the listing".  Obviously, disabling the cache shouldn't be used to postpone maintaining the cache, but it's unrealistic to expect a CO to immediately go out and fix or replace the container as soon as someone reports an issue.

The option to disable is a great point. 

 

When reading fizzymagic's proposed message I get the sense new cache owners may think that archival is the only option if the cache is "gone".  I also think that those who are exiting the game, will read that part and simply archive the cache without collecting up the container first.

 

For me this is all playful banter as I think the original GS e-mail is just fine.

[+niraD]

On 7/17/2017 at 1:09 PM, fizzymagic said:

• It treats the recipient with respect, including an option to deal with false positives

While treating the recipient with respect is always a good thing, the system really does need to deal with false positives better.

[+Rebore]

I think the old system which required fellow cachers to log NM/NA worked quite well, at least in my area. Now you just have to click a checkbox to send a canned NM Message to the owner without explaining why. So Groundspeak invented the CHS and now an algorithm is deciding if a cache is in need of attention and is sending out another canned message to the owner. Great.

Your version of the text is more friendly than the actual one, though.

 

[+dprovan]

54 minutes ago, Rebore said:

I think the old system which required fellow cachers to log NM/NA worked quite well, at least in my area. Now you just have to click a checkbox to send a canned NM Message to the owner without explaining why. So Groundspeak invented the CHS and now an algorithm is deciding if a cache is in need of attention and is sending out another canned message to the owner. Great.

I don't think that's the way it worked. There's now a general "understanding" that monitoring by geocachers (i.e., NM/NA, etc.) was not working. These other approaches -- CHS for a seemingly objective measure of "bad" that reviewers can use, using CHS to mechanically detect problem caches, and turning NMs into an impersonal checkbox, among others -- were all invented to "fix" that problem. You make it sound like one mistake led to another, but I think they were all motivated by the same sincere attempt to make things better.

Me, I never thought there was a problem to begin with, but I lost that war a couple years ago, although I still sometimes engage in a guerrilla comment or two about the question.

[+Rebore]

58 minutes ago, dprovan said:

You make it sound like one mistake led to another, but I think they were all motivated by the same sincere attempt to make things better.

Yes, it seems like TPTB are always fixing things that are not boken and one "fix" leads to another. But of course I don't have the insight that they hopefully have. Well-intentioned is often the opposite of well done.

Edited December 12, 2017 by Rebore

[+Gill & Tony]

I like Fizzymagic's new form letter.  I think it is an improvement on the current one.

It might be better if the action suggested for a false positive was "Please reply to this e-mail", rather than "send an e-mail to ..."

I suspect that TPTB run the CHS score program and that program generates the e-mail.  If this is the case, the e-mail could contain information regarding which factors in the CHS algorithm caused the e-mail to be sent.  This might be in the wording, advising the CO exactly why the e-mail was triggered, or, it TPTB want to keep the reason hidden, it might be in a different reply-to address - chs1@ means one thing, chs2@ means something else.   Now, replying to the e-mail would give TPTB more information about why the e-mail was triggered and that makes the analysis of the false positive easier.

[+barefootjeff]

55 minutes ago, Gill & Tony said:

I like Fizzymagic's new form letter.  I think it is an improvement on the current one.

It might be better if the action suggested for a false positive was "Please reply to this e-mail", rather than "send an e-mail to ..."

I suspect that TPTB run the CHS score program and that program generates the e-mail.  If this is the case, the e-mail could contain information regarding which factors in the CHS algorithm caused the e-mail to be sent.  This might be in the wording, advising the CO exactly why the e-mail was triggered, or, it TPTB want to keep the reason hidden, it might be in a different reply-to address - chs1@ means one thing, chs2@ means something else.   Now, replying to the e-mail would give TPTB more information about why the e-mail was triggered and that makes the analysis of the false positive easier.

Yep, or just include an incident ID number in the subject line so the recipient of the reply can go straight to the relevant system log, assuming of course that the CHS algorithm keeps logs of what it's doing.