Excessive owner maintenence logs!

[+kunarion]

30 minutes ago, Team Microdot said:

 

Oh G**! I'm still getting emails about it! ?

 

Unfollow causes emails?  That's like the opposite of what you want.

[+thebruce0]

3 hours ago, justintim1999 said:

21 hours ago, thebruce0 said:

accepting that that is never going to happen because this is all an argument about opinions and preference.

I can't accept that.   Those that are set in their ways may never change but those who are new to the activity may see some sense in what I'm saying and be willing to make that change or at least think about what logs they post before they post them.

 

I didn't say you can't stop influencing people by convincing them some way may be more informative for them as it is for you. It's your insistence that anyone who does something different than you is being unreasonable. THAT is what incites the unending arguments and debates, because it insults people's intelligence and/or common sense and no one's stance changes.  People have different preferences. Accept that without villifying them.  After 18 years there are some thing Groundspeak has still not attempted to define more than they have, and for good reason.

 

 

37 minutes ago, Team Microdot said:

39 minutes ago, justintim1999 said:

1 hour ago, Team Microdot said:

This is the first topic I have ever unfollowed.

I didn't realize you were following it in the first place.   Thanks for the update.  I'm sure your not the first.

Oh G**! I'm still getting emails about it! ?

Yup, I discovered long ago there's no way out. There's another thread I don't care about any more but it still shows with new replies in the list and sends emails if I view it. You have to resist looking at it. If you look at it, the flag will be set to remind on the next reply. It's quite frustrating.

 

 

4 hours ago, barefootjeff said:

For the record, I wouldn't log a DNF in a situation like that, although I've had some rainfall-induced DNFs on my hides. My rule of thumb is that it's a DNF if some aspect of the cache has defeated me. That might be the camo, the placement (it's somewhere I can't reach or in a spot teaming with muggles) or the terrain the CO has challenged me to overcome along the way. If I'm waylaid on the way to GZ because of something completely unrelated to the cache (a phone call from work, for example), or I've decided I've had enough for one day and will come back to complete the journey another time (particularly for a multi), then it's either a note or nothing. But if I've tried to do everything I can to find the cache (as in sign the logbook) and failed, it's a DNF. My DNFs just say that I tried but failed; they don't infer anything about the health of the cache and shouldn't be interpreted that way.

 

This is pretty much exactly my logging ethic too, point for point. But as per the bold - I think if our log says nothing (one way or another) about the health of the cache, then we don't know whether the DNF log (by type only, not by text) is due to the health/condition of the cache or not, so the algorithm is actually okay in weighing other factors in conjunction with our log to determine the likelihood of a health issue being the cause (interpreting our log as being relevant to the cache's health in that it could statistically be a result of a problem with the cache; at least until it can intelligently understand the log text itself) - so that doesn't drag our log down in the slightest.  We are posting our log type based solely on our personal finding experience; that's the context, and that's all it directly applies to. The algorithm makes judgements on a much wider scale where many little inputs are taken into consideration.

 

So, it shouldn't interpret the DNF log type as definitively indicating a problem with the cache, but it can certainly weigh it as one component towards the general health score based on its statistical analysis.

 

 

As for excessive OM logs, I'm on board with a comment I read previously somewhere. I wouldn't want to flood the latest logs with multiple almost identical 'checkup' OM logs. If I think there are too many, I would post a new one, indicate when the prior checkup log was, then delete the prior checkup log. (likely even list how many there were since the last non-OM log).  That at least means that if you get the most recent 5 or more logs, you'll see the most recent activity was the owner maintenance, and likely when the most recent find was and/or what caused the need for a maintenance run. To me those are the most relevant bits of info I'd look for in a small 'most recent logs' request.  And that latest log indicates to me that the owner is very active in ensuring the cache is good to go (text indicating they checked up 5 times in the past 4 months? Excellent chance of a findable cache in great condition)

Edited November 14, 2018 by thebruce0

[+kunarion]

27 minutes ago, thebruce0 said:

I think if our log says nothing (one way or another) about the health of the cache, then we don't know whether the DNF log (by type only, not by text) is due to the health/condition of the cache or not, so the algorithm is actually okay in weighing other factors in conjunction with our log to determine the likelihood of a health issue being the cause (interpreting our log as being relevant to the cache's health in that it could statistically be a result of a problem with the cache; at least until it can intelligently understand the log text itself) - so that doesn't drag our log down in the slightest.  We are posting our log type based solely on our personal finding experience; that's the context, and that's all it directly applies to. The algorithm makes judgements on a much wider scale where many little inputs are taken into consideration.

 

So, it shouldn't interpret the DNF log type as definitively indicating a problem with the cache, but it can certainly weigh it as one component towards the general health score based on its statistical analysis.

 

I try to be very clear in my log about what my DNF means, that I am terrible at Geocaching, the cache may in fact be perfectly fine, who knows. I gave it my best shot and Did Not Find it. But in the case of gates being locked and nowhere to park in an exclusive subdivision (no such info on the cache page), I may not find it even though everybody else has no trouble. I can't emphasize it enough that I can't find caches. I am the absolute Guinness Book Of World Records worst Geocacher ever, and can't find some of the easiest caches whether I search for 30 minutes or 30 days. And no matter where I illegally park, I attract LEO, he's right there in seconds, without exception, lights flashing and everything, and he calls for backup. Everybody else and his monkey can park there without issue, they all Found It. I did not.

 

And yes, I've been told many times that if I'm that bad at Geocaching, that I must quit.  I take it under advisement.

 

 

Edited November 14, 2018 by kunarion

[+thebruce0]

11 minutes ago, kunarion said:

I try to be very clear in my log about what my DNF means, that I am terrible at Geocaching, the cache may in fact be perfectly fine, who knows. I gave it my best shot and Did Not Find it.

 

Exactly, and that's all stuff that can't be gleaned from the DNF type. But statistically, the number of DNFs caused by what has been determined to be a problem with the cache (analysis of chances DNFs are followed by NM/OM logs, for instance) means that the algorithm has to decide how to weigh your DNF given other possibly relative factors about the listing.  Hopefully surrounding factors (say, for example, loads of finds before you, or find count of previous finders, or a find after yours, or zero maintenance issues on the cache, a low D rating, etc - who knows, all just guesses at this point) will indicate to the algorithm that your DNF log type isn't as likely to indicate a problem and weigh it less than if your DNF followed another 10 DNFs (a higher likelihood of a problem, but still not for certain, especially if the D rating is high, for example - who knows, just a guess at this point).

All the algorithm can do is decide how to weigh your DNF, knowing that it doesn't directly mean anything good or bad about the cache, only how much of a chance statistically that it could indicate a problem based on its context.

 

11 minutes ago, kunarion said:

And yes, I've been told many times that if I'm that bad at Geocaching, that I must quit.  I take it under advisement.

 

Those people should quit geocaching. People who tell people to quit should quit-- Wait... that means... no, I take that back. I take it back!!

[+Mudfrog]

Just popped in to say,,, you guys must really be bored! 

 

It's just amazing to see this kind of debate argument on something so insignificant. How bout this, you guys and gals log your DNFs your way and I'll log mine my way. I'll log a DNF when I don't find a cache. My definition of not finding a cache may differ from yours but in the grand scheme of things, it doesn't matter.

 

[+kunarion]

 

16 minutes ago, thebruce0 said:

All the algorithm can do is decide how to weigh your DNF, knowing that it doesn't directly mean anything good or bad about the cache, only how much of a chance statistically that it could indicate a problem based on its context.

 

I've seen CHS go wrong. Well, maybe not "wrong", but I caused it to happen with my DNF!  Sort of.  It's a cache placed by a once-and-done cache hider.  Zero Maintenance (not what you call "excessive").  So the issue is real.  The impending archival... justified.  I mean, it's what CHS was made for.  But it was a surprise to me.  It's the... efficiency... that's kinda unexpected.  Or something.

 

 

16 minutes ago, thebruce0 said:

  People who tell people to quit should quit-- Wait... that means... no, I take that back. I take it back!!

 

You'd better take that back or I quit! 

 

 

 

 

 

Edited November 14, 2018 by kunarion

[+niraD]

5 hours ago, justintim1999 said:

On 11/13/2018 at 10:22 AM, thebruce0 said:

accepting that that is never going to happen because this is all an argument about opinions and preference.

 I can't accept that.   Those that are set in their ways may never change but those who are new to the activity may see some sense in what I'm saying and be willing to make that change or at least think about what logs they post before they post them.      

You do realize that the vast majority of "those who are new to the activity" will never visit the forums, and will never read this thread, don't you?

[+dprovan]

8 hours ago, barefootjeff said:

On the other hand, OM logs just saying that the waypoint was cleaned don't really offer any help to someone in the field; the waypoint would be just as usable even if I never cleaned it.

I think what you're overlooking is that the comments you put in your OM logs ("cleaned off algae") can be just as valuable any similar offhand comments in a found log. There's no particular reason to think that the older Found logs will be more valuable to a seeker than your OM logs...unless you don't write decent OM logs. (And, by the way, if you don't write decent OM logs, you can't really complain about seekers writing decent found logs. I often wonder how many CO that complain about "TFTC" logs say "Still there" or "Replaced missing cache" in their OM logs without recognizing the standard they're setting.)

 

Or, more to the point, even if you had no OM logs, juicy tidbits in old found logs are going to get pushed out of the PQ logs by DNFs and Founds just as easily as by OMs. Yes, we all recognize that going back in the logs can be useful, but we also all know that that important clue is not going to be there every time. I don't think it much matters which kind of log pushes it out.

 

If you're really worried about it still, then just read those last five found logs looking for tidbits that you can imagine being helpful, and then drop something similar into your OM log. Even something as simple as "It really cracked me up when RecentFinder mentioned climbing the slope even though it's not up there. Don't do that!" Yeah, you might not recognize every useful clue, but won't you spot most of them?

[+dprovan]

6 hours ago, justintim1999 said:

I can't accept that.   Those that are set in their ways may never change but those who are new to the activity may see some sense in what I'm saying and be willing to make that change or at least think about what logs they post before they post them.      

It's so typical of today's society that we can discuss this, in detail, over and over for weeks on end, and you still have learned nothing about the other side of the argument and think everyone that disagrees with you is just "set in their ways".

 

It's also quite normal for someone like you to give up trying to convince grownups through logical discussion and, instead, decide to capture the next generation before they hear the other side of the argument and can make up their own minds.

[+TeamRabbitRun]

Here's the silliness of one of the positions expressed in this thread.

 

A person wants to declare a new unilateral change to the meaning of the "DNF" log type because GS is (may be) using it in a manner that's substantially different than it's original intended and stated purpose.

 

This change in usage was made without alerting the two million users currently applying the function.

 

Continued use of the original method and intent may result in what many people with 'skin' in the 'cache-ownership' game might consider undue pressure to take unneccesary trips into the field, many of which could be difficult, for no good reason.

 

There's no way to communicate the new intent because GS doesn't want to publicize the new methods lest they be 'gamed', and should that change, there's absolutely no way in the world to change the behavior patterns of millions of players.

 

Just ain't gonna happen.

 

So, the rational thing to do in my opinion is for GS to change the CHS 'DNF' trigger, IF in fact there actually is one.

 

It appears as though they're taking concrete action on how they 'wish' people would use the DNF Log Type, and that's just foolish. No insult intended.

[+justintim1999]

13 minutes ago, dprovan said:

It's so typical of today's society that we can discuss this, in detail, over and over for weeks on end, and you still have learned nothing about the other side of the argument and think everyone that disagrees with you is just "set in their ways".

 

It's also quite normal for someone like you to give up trying to convince grownups through logical discussion and, instead, decide to capture the next generation before they hear the other side of the argument and can make up their own minds.

Easy buddy.   No need to be nasty. 

 

I just don't think like you do.

Edited November 14, 2018 by justintim1999

[+justintim1999]

11 minutes ago, TeamRabbitRun said:

Here's the silliness of one of the positions expressed in this thread.

 

A person wants to declare a new unilateral change to the meaning of the "DNF" log type because GS is (may be) using it in a manner that's substantially different than it's original intended and stated purpose.

 

This change in usage was made without alerting the two million users currently applying the function.

 

Continued use of the original method and intent may result in what many people with 'skin' in the 'cache-ownership' game might consider undue pressure to take unneccesary trips into the field, many of which could be difficult, for no good reason.

 

There's no way to communicate the new intent because GS doesn't want to publicize the new methods lest they be 'gamed', and should that change, there's absolutely no way in the world to change the behavior patterns of millions of players.

 

Just ain't gonna happen.

 

So, the rational thing to do in my opinion is for GS to change the CHS 'DNF' trigger, IF in fact there actually is one.

 

It appears as though they're taking concrete action on how they 'wish' people would use the DNF Log Type, and that's just foolish. No insult intended.

None taken.

[+TeamRabbitRun]

Just now, justintim1999 said:

None taken.

 

Justin, does this make sense? I think it's what many of us have been trying to say.

[+The Jester]

28 minutes ago, dprovan said:

It's so typical of today's society that we can discuss this, in detail, over and over for weeks on end, and you still have learned nothing about the other side of the argument and think everyone that disagrees with you is just "set in their ways".

 

It's also quite normal for someone like you to give up trying to convince grownups through logical discussion and, instead, decide to capture the next generation before they hear the other side of the argument and can make up their own minds.

It's his subtle way of putting down anyone who doesn't agree with him.  Of course, he should (but doesn't seem to) recognize that he is as "set in their ways" as those he is putting down.  He explained that early on as a CO every DNF meant the cache had a problem and he had to go check - it seems without reading the content of the log.  So he is set in his ways that a DNF equals Problem and isn't willing to change his way of thinking/doing things, but expects everyone else to change to match him. 

[+barefootjeff]

5 hours ago, L0ne.R said:

 

I don't think so. I believe Keystone said a find after a DNF cancels out previous DNFs. 

 

Actually he inferred the opposite in that "How to see a cache health score" thread, where a cache that had a DNF followed by a WN from the owner and a subsequent find still had a "less than awesome" CHS, and the WN should have been an OM to properly clear the impact of the DNF:

 

Quote

On 10/22/2018 at 8:29 AM, Keystone said:

All of your caches have awesome health scores, except for this one, which is still way above the point where a cache health score email notice would be sent to you.  Tip:  If you had written an "Owner Maintenance" log instead of a "Write Note" log when you checked on your cache, its health score would be even higher.

 

This is something I really don't understand. The log pattern on that cache goes Publish - Found - Found - DNF - WN - Found. Why doesn't the most recent find cancel out the preceding DNF? Surely the only maintenance issue a DNF can suggest is a missing cache (people don't log DNF if the logbook is wet or full, or the container is damaged), and the subsequent find shows that it wasn't. Why does it still need an OM to fully wipe away the effect of that DNF?

 

There have also been several recent examples in other threads where a CHS email has been sent when the most recent log prior to that was a find and there were no other negative logs (like NM or NA) other than a couple of DNFs.

 

A find probably gives the CHS a small positive boost, but I suspect from the examples I've seen that it would probably take quite a few of them to completely erase the negative impact of a DNF. It may well be that the relative impact of a find and DNF on the score depends on the D rating of the cache, so that DNFs have a greater impact than finds on low-D caches and vice-versa on high-D ones, but of course that's only guesswork based on observation.

[+barefootjeff]

1 hour ago, dprovan said:

10 hours ago, barefootjeff said:

On the other hand, OM logs just saying that the waypoint was cleaned don't really offer any help to someone in the field; the waypoint would be just as usable even if I never cleaned it.

I think what you're overlooking is that the comments you put in your OM logs ("cleaned off algae") can be just as valuable any similar offhand comments in a found log. There's no particular reason to think that the older Found logs will be more valuable to a seeker than your OM logs...unless you don't write decent OM logs. (And, by the way, if you don't write decent OM logs, you can't really complain about seekers writing decent found logs. I often wonder how many CO that complain about "TFTC" logs say "Still there" or "Replaced missing cache" in their OM logs without recognizing the standard they're setting.)

 

In case you missed it, the cache in question is GC6PE5B so you can see for yourself whether my OMs are decent or not. My most recent one said "A routine visit today to check on Plodfoot's steed. The recent rains have replenished the waterhole, giving him plenty to drink (or drown in). After a wipedown he's looking good and awaiting his next finder." But the purpose of my OMs isn't to provide extra hints to searchers, it's to state what maintenance I've performed and whether anything in the surroundings has changed that might impact on the cache (in a previous one I mentioned that the undergrowth was a bit thicker than when I'd hidden the cache, in this one it's the recent rains replenishing the waterhole). If I think future searchers might need extra guidance, I'll edit the description or hint, not do it in an OM.

 

1 hour ago, dprovan said:

If you're really worried about it still, then just read those last five found logs looking for tidbits that you can imagine being helpful, and then drop something similar into your OM log. Even something as simple as "It really cracked me up when RecentFinder mentioned climbing the slope even though it's not up there. Don't do that!" Yeah, you might not recognize every useful clue, but won't you spot most of them?

 

I don't think it's my role as CO to go searching for things in earlier logs that might possibly be helpful to a future finder and summarise those in an OM. I don't even know what things in those earlier logs another searcher might find helpful - as I said, the location of the cache makes each search something of a choose-your-own-adventure which might or mightn't match some aspects of a previous searcher's adventure. In any case, as a searcher, part of the fun, for me anyway, is trying to tease useful titbits from earlier logs when I'm out in the field and I really wouldn't want that spoon-fed to me in a CO's OM.

 

[+dprovan]

2 hours ago, justintim1999 said:

Easy buddy.   No need to be nasty. 

I didn't mean to be nasty. Teaching the next generation is a time honored approach to social progress.

 

2 hours ago, justintim1999 said:

I just don't think like you do.

Well, OK, now I will be nasty: I don't think you have any idea how I think, so you wouldn't have any idea whether it's like you or not.

[+dprovan]

41 minutes ago, barefootjeff said:

In case you missed it, the cache in question is GC6PE5B so you can see for yourself whether my OMs are decent or not.

I was just making a general point. I was assuming your OMs would be high quality. That's why I'm encouraging you to value them more than you seem to be.

 

42 minutes ago, barefootjeff said:

I don't think it's my role as CO to go searching for things in earlier logs that might possibly be helpful to a future finder and summarise those in an OM.

That's fine with me. I'd never do it, either. But if that's your opinion, I suggest that logic dictates that also isn't your role to worry about whether helpful clues are available in PQs despite your newer OM logs.

 

Did I completely miss your point? I thought you were worried about your own logs kicking out previous logs along with the interesting information that might contain. I've been trying to give you reasons to stop worrying about it as well as ways to mitigate it if you can't stop worrying about it, but now you're coming back by arguing that it's not your role to worry about such things. My whole point was that you shouldn't worry about it, but you seem to reject the option of not worrying about the old logs while simultaneously arguing that you'd never worry about the old information.

 

Anyway, since it strikes at the heart of the OP, and it continues to be my answer to your "Any thoughts?" question, at this point I'll just repeat what I always said. If the OM is important, always post it. If the OM is obsolete, delete it if you want. The effect of those actions on other logs in the PQ isn't an interesting consideration compared to the value of the OM.

[+thebruce0]

3 hours ago, TeamRabbitRun said:

A person wants to declare a new unilateral change to the meaning of the "DNF" log type because GS is (may be) using it in a manner that's substantially different than it's original intended and stated purpose.

 

Howso? It's my understanding that GS has created the algorithm to make choices based on statistical analyses of various log types in relation to known cache problems, taking into consideration the chance the various log types have of being caused by a problem, then adjusting a cache's health score accordingly.  I don't infer any prescriptive practices that are intended to change the use of a log type from it's "original intended and stated purpose".  A DNF has always meant you "can't find the cache or the cache might be missing", and to my knowledge that's how the algorithm weighs a DNF in relation to a cache's health.

 

 

3 hours ago, TeamRabbitRun said:

So, the rational thing to do in my opinion is for GS to change the CHS 'DNF' trigger, IF in fact there actually is one.

 

It appears as though they're taking concrete action on how they 'wish' people would use the DNF Log Type

 

Howso?

Already stated numerous times, but if Groundspeak was assuming that a DNF meant that a cache was actually missing, then every cache with an outstanding DNF would be flagged and "nudged". Obviously that's untrue.  So the issue is actually how significantly the algorithm weighs the chance that a DNF might be caused by a problem needing attention - not merely that it is weighing the DNF.  Outside of direct reports of problems (NM/NA), the DNF log is about the best indicator of potential problems, especially when combined with numerous other contextual factors (which is what the algorithm analyzes).

 

 

31 minutes ago, dprovan said:

If the OM is important, always post it. If the OM is obsolete, delete it if you want. The effect of those actions on other logs in the PQ isn't an interesting consideration compared to the value of the OM.

 

Agreed with this

[+dprovan]

18 minutes ago, thebruce0 said:

Already stated numerous times, but if Groundspeak was assuming that a DNF meant that a cache was actually missing, then every cache with an outstanding DNF would be flagged and "nudged". Obviously that's untrue. 

The CHS assumes that every DNF has the same statistical value for determining that a cache is missing, so it counts every one the same even though a human would read "Saw the cache but could not retrieve it" and recognize the difference. The automated CHS system is replacing the original human based NM/NA system, so it makes sense to recognize it's inherent flaws. People keep claiming the reviewer retains the human factor in the CHS process, but I'm not seeing that happen in practice.

[+barefootjeff]

19 minutes ago, thebruce0 said:

A DNF has always meant you "can't find the cache or the cache might be missing"

 

And that's the whole crux of the problem - the algorithm has no way of telling the difference. The best it can do is take some weighted average across all the caches and logs out there, but that average is unlikely to be right for any individual cache, especially one that gets few attempts so its DNF to find ratio (or whatever other parameter it's looking at) won't be statistically valid anyway. Because the percentage of DNFs that are actually caused by a missing cache is quite low (for my DNFs it's about 20%), there can be no sweet spot in its tuning that'll catch most of the missing caches but not ping the ones that aren't. The DNF log is too broad a brush to be using as a meaure of cache health.

[+thebruce0]

3 minutes ago, dprovan said:

29 minutes ago, thebruce0 said:

Already stated numerous times, but if Groundspeak was assuming that a DNF meant that a cache was actually missing, then every cache with an outstanding DNF would be flagged and "nudged". Obviously that's untrue. 

The CHS assumes that every DNF has the same statistical value for determining that a cache is missing, so it counts every one the same even though a human would read "Saw the cache but could not retrieve it" and recognize the difference. The automated CHS system is replacing the original human based NM/NA system, so it makes sense to recognize it's inherent flaws. People keep claiming the reviewer retains the human factor in the CHS process, but I'm not seeing that happen in practice.

 

We've gone over this so..many..times.  Nothing happens to a cache outside of a reviewer action or owner action. Nothing. Absolutely nothing. An email might get sent out, but that's not something that happens to a cache listing. A reviewer always has to interpret what the tool tells them. Always.

I'll give you this though - you and I have as much evidence as each other (ie none) about whether every single DNF caused the exact same adjustment to a cache's health score or whether a DNF's adjustment is weighted based on other relative factors we don't know about.

(Actually, except that we do know a DNF's value IS indeed affected by the difficult rating of the cache).

That doesn't change the fact that the system does not assume that every single DNF must be interpreted that a cache is missing. Absolutely not.  How a DNF alters the listing's score is based on a statistical analysis of the chance that problem caches have previously led to DNF logs. No one in their right mind would assume that's 100% of the time. I'm absolutely confident Groundpseak has not programmed the algorithm that way, and the fact that not every cache with a DNF gets a nudge email is the front-facing proof.

 

 

6 minutes ago, barefootjeff said:

36 minutes ago, thebruce0 said:

A DNF has always meant you "can't find the cache or the cache might be missing"

 

And that's the whole crux of the problem - the algorithm has no way of telling the difference. The best it can do is take some weighted average across all the caches and logs out there, but that average is unlikely to be right for any individual cache, especially one that gets few attempts so its DNF to find ratio (or whatever other parameter it's looking at) won't be statistically valid anyway. Because the percentage of DNFs that are actually caused by a missing cache is quite low (for my DNFs it's about 20%), there can be no sweet spot in its tuning that'll catch most of the missing caches but not ping the ones that aren't. The DNF log is too broad a brush to be using as a meaure of cache health.

 

Exactly. Which is why thankfully it's not the only measure of a cache's health.

[+CachedIronSkillet]

I have placed a difficult gadget cache.  Everyone who visits the location can find it... most cannot open it.  Then again, a seven year old solved it a few days ago.  DNFs help me understand that the cache is difficult and deserves the 4.5 rating.  Many experienced cachers have required multiple visits to figure it out.  Should I care if the DNFs hurt the cache health score?   If so, why?  I can think the algorithm sucks, but the lack of a gadget cache attribute means they don't really have a choice.   I add the word Gadget to the names of my gadget caches in hopes that they will take that into consideration someday, and to make them easier to search for, but really... I lied... I have no hope that they're going to change anything.

[Keystone]

1 hour ago, CachedIronSkillet said:

I have placed a difficult gadget cache.  Everyone who visits the location can find it... most cannot open it.  Then again, a seven year old solved it a few days ago.  DNFs help me understand that the cache is difficult and deserves the 4.5 rating.  Many experienced cachers have required multiple visits to figure it out.  Should I care if the DNFs hurt the cache health score?   If so, why?  I can think the algorithm sucks, but the lack of a gadget cache attribute means they don't really have a choice.   I add the word Gadget to the names of my gadget caches in hopes that they will take that into consideration someday, and to make them easier to search for, but really... I lied... I have no hope that they're going to change anything.

All of your gadget caches have stellar health scores.  I mean, over the top awesome, like I'm not used to seeing.

Assuming that one of them ever got DNF'd enough to trigger a CHS notification email, you've also got a reviewer who is well aware of the care you take with hiding and maintaining your gadget caches.

I suggest that you stop reading this thread and HIDE MORE GADGET CACHES.

[+colleda]

A few minutes ago one of my PQs threw up a couple of Reviewer Disabled caches. I'm guessing that it was due to the CHS but neither had DNFs. But, as this thread is about multiple OMs I will refrain from going into detail here. Can someone point me to an appropriate thread please?

[+Mudfrog]

7 hours ago, colleda said:

A few minutes ago one of my PQs threw up a couple of Reviewer Disabled caches. I'm guessing that it was due to the CHS but neither had DNFs. But, as this thread is about multiple OMs I will refrain from going into detail here. Can someone point me to an appropriate thread please?

 

I doubt it was CHS related if there were no DNFs and no NMs on the cache. Someone either reported to the reviewer that something was amiss or, I think this has happened in the past, the reviewer noted no activity on the cache for a long period of time and decided for himself to disable the cache until its owner chimed in. 

[+L0ne.R]

I would love to see an example of excessive use of OMs. Perhaps even an example of monthly OMs. 

[+dprovan]

18 hours ago, thebruce0 said:

We've gone over this so..many..times.

I know. And you still don't get it.

[+thebruce0]

? I get it just absolutely fine thank you very much.

[+coachstahly]

18 hours ago, thebruce0 said:

I'll give you this though - you and I have as much evidence as each other (ie none) about whether every single DNF caused the exact same adjustment to a cache's health score or whether a DNF's adjustment is weighted based on other relative factors we don't know about.

 

You're right, but the fact is that a single DNF, regardless of how it's weighted, subtracts from the CHS, even if the seeker never got to GZ or if the seeker saw the cache but couldn't sign the log (I'd file a DNF on the latter but not the former).  The only way guaranteed to recoup those lost points is to log an OM.  That seems to be an excessive use of the log which was never intended.

[+thebruce0]

2 minutes ago, coachstahly said:

the fact is that a single DNF, regardless of how it's weighted, subtracts from the CHS, even if the seeker never got to GZ or if the seeker saw the cache but couldn't sign the log (I'd file a DNF on the latter but not the former).  The only way guaranteed to recoup those lost points is to log an OM.  That seems to be an excessive use of the log which was never intended.

 

Yes, there's a small adjustment to a scored health on a cache, based on statistical likelihood related with other factors that the DNF was caused by a potential problem, because the actual cause of the DNF can't be gleaned by the algorithm. I see absolutely no way around that, and no issue with that.  A perfect health cache might become 95% health after a DNF. So what?  It only becomes an issue when the algorithm has enough statistical weight to make an educated guess that there may be a problem with the cache. Not from a single DNF. From a collected set of factors that brings a score below a threshold that Groundspeak thinks is sufficiently balanced between true positives and false positives.  That threshold can only be adjusted over time.  And not by removing DNF logs entirely from the equation.

[+coachstahly]

2 minutes ago, thebruce0 said:

Yes, there's a small adjustment to a scored health on a cache, based on statistical likelihood related with other factors that the DNF was caused by a potential problem, because the actual cause of the DNF can't be gleaned by the algorithm.

 

That's not my point, bolded above.  One single DNF subtracts from the health score, all by itself.  How much that DNF reduces the score is related to the other factors. Those other factors shouldn't actually subtract from the CHS, with the possible exception of length between finds.  The NM log is a given that it's negative, but I'm leaving that out because it shows, without needing analysis, that something is truly wrong with the cache. Each subsequent DNF subtracts from the score on its own merit, again, the value related to the other factors.  My point is that it's the one of two things we can absolutely determine has a negative score all by itself, the other being the NM log.

 

You and I both understand that DNFs don't always mean the cache is missing but for the program to work as it's written, that's the ONLY assumption that can be made based on multiple DNFs and their related factors, assuming there are no NM logs.  There's no way a cache pinged by the CHS with only DNFs recorded can possibly be flagged as a cache that just needs some TLC.  That makes no sense.  Therefore, the only logical conclusion that the CHS can arrive at is that the cache is missing, based on the fact that the DNFs are the only statistical negatives that can be ascertained.  Those other factors only influence the value of the DNF, which means the DNF is the only inherent negative value in this whole thing.

 

The D/T rating, the length of time between finds, number of finds - consecutive or even non-consecutive, OM logs, etc...  All of these other factors you continue to refer to, on their own, shouldn't subtract from the CHS on their own merit, with the sole possible exception of the length between finds, but that would mean remote caches, high D/T caches, and caches in cache poor areas without many cachers would be essentially "targeted" due to the infrequency of the visits they receive.  I would hope that's not the case, that the length of time between finds automatically deducts points from the CHS.  The longer the time gap, the more points that get deducted from the CHS.  Else, those caches, if not found when visited, would accrue a disproportionately higher negative score and fall under the threshold at a much faster rate than a 1.5/1.5 in an urban setting.

 

Can you give me an example of some other factor, other than the NM log, that would negatively affect the CHS, on its own merit?  I can only think of the length of time between finds as a possibility, but that certainly has its drawbacks as it pertains to certain types of caches.

[+thebruce0]

8 minutes ago, coachstahly said:

1 hour ago, thebruce0 said:

Yes, there's a small adjustment to a scored health on a cache, based on statistical likelihood related with other factors that the DNF was caused by a potential problem, because the actual cause of the DNF can't be gleaned by the algorithm.

 

That's not my point, bolded above.  One single DNF subtracts from the health score, all by itself.

 

I'm saying that IS the point. The weight of the DNF IS related to other factors. It is NOT the DNF on its own merit.  Another way to look at it is there are actions, and there are properties. A DNF posted would be an action; its significance to the score would be determined in combination with other passive factors like who knows, D, T, owner activity, time passed since last log, number of prior NM logs, etc.  All in determining statistical likelihood of a problem, and how much to adjust the score.

 

9 minutes ago, coachstahly said:

How much that DNF reduces the score is related to the other factors. Those other factors shouldn't actually subtract from the CHS, with the possible exception of length between finds.

 

Just because something detracts from a health score does NOT mean there is a problem with the cache. Just because statistically some action on a listing can occasionally be caused by a problem with the cache does not mean that reducing a score based on that statistical likelihood means anyone is assuming there IS a problem.

 

10 minutes ago, coachstahly said:

You and I both understand that DNFs don't always mean the cache is missing but for the program to work as it's written, that's the ONLY assumption that can be made based on multiple DNFs and their related factors, assuming there are no NM logs.

 

You see how you just combined the log with a number of other factors again? That's the whole point. The DNF on its own does not mean there IS a problem with the cache, and that's NOT how the algorithm interprets it. I'll say it again - Just because something detracts from a health score does NOT mean it's implying there is a problem with the cache.  EVEN IF a score drops below the threshold, that STILL doesn't mean it thinks there is a problem with the cache, and the nudge email in no way implies that it thinks there IS a problem with the cache. That is precisely why no action is taken against the listing merely for crossing that score threshold, and at worst it's made more visible to reviewers who can better judge the situation.

 

13 minutes ago, coachstahly said:

There's no way a cache pinged by the CHS with only DNFs recorded can possibly be flagged as a cache that just needs some TLC.  That makes no sense.

 

Sure it does!  The statistical likelihood that a cache with multiple DNFs has a problem is greater than that of a cache with one DNF, or none.  And, if whatever other factors influenced that cache's health score (like D or T) drop it below the threshold, then all of those factors combined (NOT just the dnf(s)) influenced that flag.

 

15 minutes ago, coachstahly said:

Those other factors only influence the value of the DNF, which means the DNF is the only inherent negative value in this whole thing.

 

Of course. The reason for a DNF is either unrelated to cache condition, or directly related to cache condition. The net likelihood is a negative. HOW negative is based on whatever the algorithm analyzes about that listing!  I would wager (educated guess, based on the number of geocaches that exist out there with outstanding DNFs) that in MOST cases the DNF action has so little effect on the listing's health that it's of absolutely no concern to anyone and I can't fathom why a handful of people are still so hung up on this.

 

18 minutes ago, coachstahly said:

The D/T rating, the length of time between finds, number of finds - consecutive or even non-consecutive, OM logs, etc...  All of these other factors you continue to refer to, on their own, shouldn't subtract from the CHS on their own merit

 

I don't know how Groundspeak has decided to code the algorithm. All we know is that a number of factors alter the health score to various degrees up or down. Some would be active (a new DNF), some would be passive (rating, length of time between logs).  That's all.  If you don't like how much you think some attribute a listing is affecting its health score (which of course no one can know until a CO gets that dreaded nudge email), then you need to take it up with Groundspeak. But I'm pretty confident that exclaiming that DNFs should not in any way ever be considered as a factor to affect a cache's health won't get much attention. As I said above, I think they're about the best public facing action on a listing apart from direct reports of problems (NM/NA) that is available. Despite not being a definitive indicator.

 

21 minutes ago, coachstahly said:

that would mean remote caches, high D/T caches, and caches in cache poor areas without many cachers would be essentially "targeted" due to the infrequency of the visits they receive.

 

Why do you assume that? I can just as easily say that it's possible the algorithm takes all that into consideration. We can theorize all we want with what ifs. Cite examples if you want to keep banging your head asking why something happens knowing that you'll never get an explanation because of the covert nature of the scoring algorithm and the fact that it does indeed throw the occasional false positive.

 

24 minutes ago, coachstahly said:

I would hope that's not the case, that the length of time between finds automatically deducts points from the CHS.

 

Okay. Although if it does, I would guess that it would be considering 'cache health' in the aspect of condition of the container over long periods of inactivity. It of course wouldn't know what container was physically used, or its actual condition, so it might weigh the statistical likelihood of long periods between logs being followed up by a NM. The longer that gap, the more likely (even if extremely rare) the container might actually need maintenance from natural degradation. So practically speaking, I wouldn't be surprised if long periods between logs is a passive factor that could slightly lower a score increasingly over time.  All things being equal, a cache not found in 5 years stands a statistically increased chance of needing some TLC than if it was found yesterday, so maybe amongst whatever other factors, one day its score sneaks below the threshold and the owner gets a nudge email to check on it because it might need a checkup.  Reviewers used to do that.  Now the system can. And then, if the CO does nothing, the reviewer could see the unresponsice status and think "hey this owner might not be active" and followup with reasonable action; or maybe the CO will check on it; or maybe the CO will couch-log an OM.  etc etc.  The system progresses.

 

30 minutes ago, coachstahly said:

Can you give me an example of some other factor, other than the NM log, that would negatively affect the CHS, on its own merit?  I can only think of the length of time between finds as a possibility, but that certainly has its drawbacks as it pertains to certain types of caches.

 

Nope, I can only theorize because I have no idea what Groundspeak has specifically coded in regards to listing data to determine an ongoing health score. We know a few things and can sort of glean how the algorithm may work, but that's about it. Different people will have different opinions about whether certain aspects of a listing should have a negative or positive net effect on the score.

 

I see two classes of effects: direct and indirect. Direct effects are actions that explicitly push a listing beyond the CHS bubble into reviewer territory. NM, NA.  Indirect are effects that are based on statistical analysis of various actions and passive properties of a listing to determine the chance of there being a problem with the cache that needs attention - before it's put into reviewer action territory.  That's all part of the pre-emptive effort to improve general geocache quality and ensure cache owners are active and attentive.

 

Based on how I understand the system - does a NM negatively affect the score? Sure, it puts the listing below the threshold as a certain problem. I don't believe a NM causes a nudge email - the NM notification is sufficient, and it's now in direct sights of a reviewer. It literally means there is a problem with the cache and/or listing. (the listing because there's a NM flag that must be cleared). No indirect factor has the same effect on its own merit. No indirect factor itself says "there is a problem with the cache", because by definition those indirect factors may or may not be caused by a problem with the cache.

 

So does an OM positively affect the score? Well of course. It puts the listing above the threshold as a certain fix. (inferring of course a legitimate action from the CO on the cache and/or listing being checked and verified).  Excessive OM logs (consecutively) won't do much more to a listing than one, it seems, and understandably so.  So it'd be pointless to do that just for the CHS.

(although I haven't seen evidence that an OM log actually returns a score to 100% or not - I'm thinking not, since I've seen references to "stellar" scores, but I recall ever reading about a "perfect" health rating)

[+barefootjeff]

2 hours ago, thebruce0 said:

EVEN IF a score drops below the threshold, that STILL doesn't mean it thinks there is a problem with the cache, and the nudge email in no way implies that it thinks there IS a problem with the cache.

 

The email sure sounds like it thinks there's a problem with the cache.

 

"Your geocache, XXXXX, looks like it might need some attention." If someone said to me, "Your car looks like it might need a wash," I think I could be pretty sure they thought it was dirty.

 

"The recent logs may contain more details about what sort of maintenance needs to be performed." This implies that some sort of maintenance needs to be performed, it's just that the recent logs might or might not provide a hint as to what that is.

 

"This could be anything from a new logbook to replacing a missing container." This gives a range for that maintenance, anything from a new logbook (the most minor) to replacing a missing container (about as major a maintenance requirement is likely to be). No maintenance needed falls outside that range.

 

"Here are a few options for what to do now." While the list that follows might not be exhaustive (here are a few options certainly suggests there could be other options it hasn't listed), it does imply that the CO is expected to at least do something.

[+thebruce0]

Oh my gosh... mountains, molehills. Come on. Back to the literal email wording again?

 

3 minutes ago, barefootjeff said:

If someone said to me, "Your car looks like it might need a wash," I think I could be pretty sure they thought it was dirty.

 

It might not be. That person's opinion of "clean" might be different than yours. Plus that person is likely being sarcastic. You'd make the judgement as to whether it needs to be cleaned. Completely different context. Groundspeak's wording - though imprecise (ymmv) - does not state that your cache HAS a problem and that you MUST physically go and fix it. But we've gone over how one can easily infer that from the wording without knowing any better, and thus it should be fixed.

 

"Your geocache, XXXXX, 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."

 

Again, one can easily infer that there are no other options, but it's not a literal statement, there are no definitive comments regarding the state of the cache, and I've always advocated that the wording be clarified for that confusion. How is this still going?

I'm out, of this dnf/chs thing. Done. (wish we could ignore keywords) Topic should be in that other thread anyway.

 

So how about those excessive OM logs?

[+barefootjeff]

1 hour ago, thebruce0 said:

But we've gone over how one can easily infer that from the wording without knowing any better, and thus it should be fixed.

 

And yet you insist that "the nudge email in no way implies that it thinks there IS a problem with the cache". Fine, have it your way.

 

So, getting back to those excessive OM logs, I'm not sure if this has been mentioned earlier in the thread (it's getting a bit long to do a definitive search), but perhaps part of the reason there's an upsurge is because OM is the default log type for a cache owner logging on the website. If they want to, say, just log a note for a TB drop or respond to something a previous logger said, they have to consciously change that log type to a WN. I've had a few finds logged on my hides where it was clear the logger intended it to be a DNF, but didn't change the log type from the default; some have spotted the error straight away and changed their log, others have needed a query from me for them to make the change. I'm sure there are probably others where it's not clear from the context of the log whether it was actually a find or a mislogged DNF, and the same is no doubt true for some OMs.

[+thebruce0]

I could see how someone might get confused between 'imply' and 'infer'.

 

 

8 minutes ago, barefootjeff said:

perhaps part of the reason there's an upsurge is because OM is the default log type for a cache owner logging on the website.

 

Possibly. I was never a fan of there being a default log type selection for anyone when posting a log - no the website or in the app.  A person should have to choose the log type explicitly. If confusion about the logging process is the concern, then if they submit without choosing a type, just say "Please select a log type".  I really don't see why the devs would have specifically chosen to auto-populate that field. That was the weirdest design discovery with the log posting form when it rolled out, imo.

Would OM logs decrease without the default? Dunno... but I think that should change anyway =P

[+barefootjeff]

3 minutes ago, thebruce0 said:

then if they submit without choosing a type, just say "Please select a log type"

 

From a programming point of view, I think it'd be better to grey out the Submit button until a log type is selected, rather than let an incomplete log be submitted then tell them to go back and fix it, but yes, I've long opposed default options in many things, especially log types.

[+thebruce0]

True true. Denying form submission until the form is complete could be accomplished in a variety of ways. :) As long as it log type is not defaulted and required, I'm with them dealing with aesthetic. ..wait that's a dangerous stance... =/