SEATTLE ... "WE HAVE A PROBLEM"

[+humboldt flier]

Not sure about the rest of you, however, I see a large problem with "Cache Health Score Algorithm, Phone App, Newbies"

 

Countless time I have seen newbies caching with a phone app.

 

Can you say running in circles, not reading the cache page, not reading any hints, not locating the cache.

 

THEN ... dropping some NM / NA log ... with the cache being located where hidden as hidden.

 

Then adding insult to injury a "nasty-gram" from the "Cache Health Score Algorithm"

 

Rather chaps my tush.

[+Touchstone]

Can you define "large problem"?

[+redsox_mark]

I don't think it is a big problem, but yes it could happen. Well it is likely you will get DNFs from a newbie, I don't think so likely to get NM or NA.

 

A newbie has recently logged DNFs on 2 of my puzzle caches. He/she has only found traditional caches so far (8 of them). The first one I checked and the cache was there. I had a feeling they didn't solve the puzzle and just went to the posted coords. I sent email and a message asking if they solved the puzzle, offering help etc. No reply.

 

A week or so later, another DNF on another puzzle cache of mine. This one they said "if it is in the square, it is private". The "Square" is where the posted coordinates are, with clear statement on the cache page that there is nothing to find there. So this time I am sure they are looking at the posted coordinates only. I check the cache anyway, it is where it should be (puzzle coordinates). I sent another email and message, no reply.

 

Eventually I assume this newbie will figure out what a puzzle cache is. In the meantime, I have to be patient. If I was to get a "bad health" email because of this, yes it would annoy me. But I would just ignore it.

[+L0ne.R]

not locating the cache.

 

THEN ... dropping some NM / NA log ... with the cache being located where hidden as hidden.

 

I'm not seeing this where I cache, quite the opposite. Newbies usually log a find when the cache is missing, with a log that reads "TFTC"

 

Got any GC codes to support the problem with NM/NAs dropped inappropriately?

Edited March 29, 2017 by L0ne.R

[+ChileHead]

The geocache health score is just a tool. The automated notes are not nasty grams, they are just reminders that you might possibly need to check your cache, nothing more. Your cache will not be disabled or archived automatically, as a human reviewer (or dog in some cases) will look at the cache page and do the reasonable thing.

[+J Grouchy]

I don't think it is a big problem, but yes it could happen. Well it is likely you will get DNFs from a newbie, I don't think so likely to get NM or NA.

 

A newbie has recently logged DNFs on 2 of my puzzle caches. He/she has only found traditional caches so far (8 of them). The first one I checked and the cache was there. I had a feeling they didn't solve the puzzle and just went to the posted coords. I sent email and a message asking if they solved the puzzle, offering help etc. No reply.

 

A week or so later, another DNF on another puzzle cache of mine. This one they said "if it is in the square, it is private". The "Square" is where the posted coordinates are, with clear statement on the cache page that there is nothing to find there. So this time I am sure they are looking at the posted coordinates only. I check the cache anyway, it is where it should be (puzzle coordinates). I sent another email and message, no reply.

 

Eventually I assume this newbie will figure out what a puzzle cache is. In the meantime, I have to be patient. If I was to get a "bad health" email because of this, yes it would annoy me. But I would just ignore it.

 

I've seen that happen on puzzles and multis. Once, I saw a multi where folks had just logged a find on the first stage of a multi, which was virtual. I admit that annoys me...but what annoys me more is when the CO lets it stand. Same with challenges. There's a "Back to school" challenge here in Georgia that has quite a few 'found it' logs where the person clearly did not qualify...several of them didn't even have enough total finds to qualify (a minimum of 36 are needed since it's an A to Z and 0 through 9 challenge). When I posted a log stating this, the CO even told me to mind my own business.

 

Whatever.

[+thebruce0]

I've seen that happen on puzzles and multis. Once, I saw a multi where folks had just logged a find on the first stage of a multi, which was virtual. I admit that annoys me...but what annoys me more is when the CO lets it stand. Same with challenges. There's a "Back to school" challenge here in Georgia that has quite a few 'found it' logs where the person clearly did not qualify...several of them didn't even have enough total finds to qualify (a minimum of 36 are needed since it's an A to Z and 0 through 9 challenge). When I posted a log stating this, the CO even told me to mind my own business.

Yup, and if you raise it as a concern, you get "everyone plays their own way", or criticized for deleting finds when ultimately it "doesn't matter" because they're "only hurting/cheating themselves".

 

You get a smiley, you get a smiley, everyone gets a smiley!

 

...whatever happened to the proper experience of finding a cache (by its intended listing type requirements)?

(you don't sign the log, you don't get a smiley; you don't quality, you don't get a smiley; you don't answer the necessary questions, you don't get a smiley, etc)

Edited March 29, 2017 by thebruce0

[+narcissa]

Not sure about the rest of you, however, I see a large problem with "Cache Health Score Algorithm, Phone App, Newbies"

 

Countless time I have seen newbies caching with a phone app.

 

Can you say running in circles, not reading the cache page, not reading any hints, not locating the cache.

 

THEN ... dropping some NM / NA log ... with the cache being located where hidden as hidden.

 

Then adding insult to injury a "nasty-gram" from the "Cache Health Score Algorithm"

 

Rather chaps my tush.

 

This goes back to one of the issues I tend to harp on about, which is that the shift to an app-based game means that new people are not getting any kind of detailed introduction to the game. They don't know anything about cache types, or what different logs mean, and they don't have any knowledge of the general parameters and norms that keep the game from being a total mess.

 

I like that the app makes the game more accessible to people, but I really wish there was more of an effort to "onboard" new cachers regardless of their entry point. The bar is set so low now. Aside from the fact that it's driving older cachers crazy, I don't think new cachers get as much enjoyment out of the game as they could, because they don't understand how it works.

 

With this "Cache Health Score," I can see what they're aiming at, but we really need people to be learning about best practices for cache ownership starting when they join the game, not when the garbage they tossed into a park because they didn't know any better has become a string of DNFs.

[+Mudfrog]

You would think people would understand that the GHS is a tool and that it isn't the end of the world if they happen to get a notification. But, as i've read in some of the forum posts around here, it'll probably just cause more disgruntlement than anything. Some will see it as being helpful and take action to make sure their cache is up to par but i'd bet that most just get upset. I'm sure there would be some geocides as well.

 

It would be better if the GHS hadn't come about in the first place. Again, imo, Groundspeak's changes in philosophy from quality to quantity is why the GHS is here now. I just don't think we would be seeing this if the emphasis hadn't been placed on making geocaching a game to bring in as many new players as possible. I understand that Groundspeak is a business, and that more players is where the money is, but the hobby shouldn't have evolved into a microcache, placed in the lamest places imaginable, every 525 feet, phone app game.

Edited March 29, 2017 by Mudfrog

[+thebruce0]

Again, imo, Groundspeak's changes in philosophy from quality to quantity is why the GHS is here now.

Ironically, taken at face value, this sentence seems precisely the opposite of what the GHS system is intended for. Its function is to encourage quality more than quantity. A secondary effect may be that caches (remaining unmaintained and in bad condition) are more likely to be archived in a timely manner, which means less quantity. Not sure how GHS promotes more quantity over better quality though. Unless to the extent that bad condition archived caches makes room for more new caches. But... isn't that a better thing?

Edited March 29, 2017 by thebruce0

[+Touchstone]

You would think people would understand that the GHS is a tool and that it isn't the end of the world if they happen to get a notification. But, as i've read in some of the forum posts around here, it'll probably just cause more disgruntlement than anything. Some will see it as being helpful and take action to make sure their cache is up to par but i'd bet that most just get upset. I'm sure there would be some geocides as well.

 

It would be better if the GHS hadn't come about in the first place. Again, imo, Groundspeak's changes in philosophy from quality to quantity is why the GHS is here now. I just don't think we would be seeing this if the emphasis hadn't been placed on making geocaching a game to bring in as many new players as possible. I understand that Groundspeak is a business, and that more players is where the money is, but the hobby shouldn't have evolved into a microcache, placed in the lamest places imaginable, every 525 feet, phone app game.

You must be new around here....

 

Unmaintained cach thread from 2004

[+Mudfrog]

Again, imo, Groundspeak's changes in philosophy from quality to quantity is why the GHS is here now.

Ironically, taken at face value, this sentence seems precisely the opposite of what the GHS system is intended for. Its function is to encourage quality more than quantity. A secondary effect may be that caches (remaining unmaintained and in bad condition) are more likely to be archived in a timely manner, which means less quantity. Not sure how GHS promotes more quantity over better quality though. Unless to the extent that bad condition archived caches makes room for more new caches. But... isn't that a better thing?

That didn't come out right. What i was trying to say is that Groundspeak has made mistakes with some of the changes they've made in the past. Now they see this and in response, have introduced the GHS algorithm in an effort to help get things back on track. I just don't think we would need any kind of GHS if Groundspeak had just kept their focus more towards quality in the first place.

[+Mudfrog]

You would think people would understand that the GHS is a tool and that it isn't the end of the world if they happen to get a notification. But, as i've read in some of the forum posts around here, it'll probably just cause more disgruntlement than anything. Some will see it as being helpful and take action to make sure their cache is up to par but i'd bet that most just get upset. I'm sure there would be some geocides as well.

 

It would be better if the GHS hadn't come about in the first place. Again, imo, Groundspeak's changes in philosophy from quality to quantity is why the GHS is here now. I just don't think we would be seeing this if the emphasis hadn't been placed on making geocaching a game to bring in as many new players as possible. I understand that Groundspeak is a business, and that more players is where the money is, but the hobby shouldn't have evolved into a microcache, placed in the lamest places imaginable, every 525 feet, phone app game.

You must be new around here....

 

Unmaintained cach thread from 2004

Yep, i'm a newbie.

 

Of course i realize there have always been lame caches and lazy cache owners out there. But, the prevalence of these bad characteristics was a lot less than it is these days. Responsible, creative, and more social cachers were more of the norm back in 2004. We just don't see these traits near as much with the phone app crowd.

[+L0ne.R]

...we really need people to be learning about best practices for cache ownership starting when they join the game, not when the garbage they tossed into a park because they didn't know any better has become a string of DNFs.

 

+1

[+Manville Possum]

Well it is likely you will get DNFs from a newbie, I don't think so likely to get NM or NA.

 

It was the newbie NVM's posting NM and NA on my listings when the intro app was introduced is why I made all my listings PMO.

 

So yes, it is very likely to happen.

[+dprovan]

You must be new around here....

 

Unmaintained cach thread from 2004

Thanks for the link. Good to know that since forever, people have been complaining about bad caches. Yet it seems it isn't really that much of a problem, since geocaching kept getting more and more popular after that, even before smartphones became common.

 

What I found particularly amusing is that the first response was also exactly the same as the typical objection to such complaints made today:

 

How is this different from someone visiting a cache, noticing there's a problem, and clicking the "should be archived" option....which kicks off the process you describe below.

[+NYPaddleCacher]

The geocache health score is just a tool. The automated notes are not nasty grams, they are just reminders that you might possibly need to check your cache, nothing more. Your cache will not be disabled or archived automatically, as a human reviewer (or dog in some cases) will look at the cache page and do the reasonable thing.

 

I understand that it's just a tool, primarily for reviewers.

 

If I'm understanding the way it works, an automated note is sent to a CO if a cache falls below (or above?) some threshold which indicates that cache might not be healthy. I also assumed that reviewer could run a tool which identifies caches with a poor health score, and take action on the cache if necessary. Whether or not a reviewer takes any action by looking at the cache page seems to be independent of the automated note.

 

Looking over a handful for caches with a D4 rating or higher it seems that it's pretty common to have about half as many DNFs as there are finds. I know of several caches with *more* DNFs than finds, and for a cache with a D4 rating or higher, that's how it should be (if not, the cache is likely overrated). Those automated notes may not by nasty grams, but how many could a CO of a well maintained, high difficulty cache expect to get simply because it gets a lot of DNFs. A Difficulty 4 cache, by definition, is going to have a lot of DNF logs. According to the ratings for difficulty or terrain page in the Help Center, a D4 rating means "Very difficult and may take special knowledge, advanced preparation, or multiple trips." Multiple trips implies that a DNF would be posted for every unsuccessful search (assuming that seekers are logging correctly).

 

Suppose an automated note was sent for caches with a poor GHS only if the cache has a D3 or T3 rating or below. A reviewer could still use the tool to identifier any caches with a poor DHS, but COs with hides with a high or D/T ratings, but don't have unaddressed NM or NA logs, wouldn't get false positive notes suggesting their cache needs maintenance simply because they chose to rather than throw out yet another cookie-cutter D1.5/T1.5 hide they wanted to create something more challenging.

 

 

[+thebruce0]

Looking over a handful for caches with a D4 rating or higher it seems that it's pretty common to have about half as many DNFs as there are finds. I know of several caches with *more* DNFs than finds, and for a cache with a D4 rating or higher, that's how it should be (if not, the cache is likely overrated). Those automated notes may not by nasty grams, but how many could a CO of a well maintained, high difficulty cache expect to get simply because it gets a lot of DNFs. A Difficulty 4 cache, by definition, is going to have a lot of DNF logs. According to the ratings for difficulty or terrain page in the Help Center, a D4 rating means "Very difficult and may take special knowledge, advanced preparation, or multiple trips." Multiple trips implies that a DNF would be posted for every unsuccessful search (assuming that seekers are logging correctly).

 

What would be very useful is if reviewers can manually adjust the weighting of various contributing factors to the score. If a D4 cache (which may or may not get loads of DNFs) hits the threshold and the CO reports back that this is normal, and a reviewer understands this, they could go to that cache and adjust the actual algorithm for that specific cache to weigh DNFs less. So human judgement still plays a role, and the algorithm still gets to do its thing while being adjustable on a case by case basis.

[+The A-Team]

Well it is likely you will get DNFs from a newbie, I don't think so likely to get NM or NA.

It was the newbie NVM's posting NM and NA on my listings when the intro app was introduced is why I made all my listings PMO.

 

So yes, it is very likely to happen.

I think you're misremembering. You couldn't submit an NM or NA from the Intro app (that ability was only introduced a month and a half ago), and an NVM wouldn't be able to log into the website to submit an NM/NA. If you were getting lots of NM/NA logs on your caches, it wasn't related to either NVMs or the Intro app.

[+The A-Team]

If a D4 cache (which may or may not get loads of DNFs) hits the threshold and the CO reports back that this is normal, and a reviewer understands this, they could go to that cache and adjust the actual algorithm for that specific cache to weigh DNFs less.

That information should be relayed back to HQ so they can adjust the algorithm accordingly. Dealing with the symptoms at the cache level won't fix the underlying problem, which will lead to more false-positives.

[+Team Microdot]

Looking over a handful for caches with a D4 rating or higher it seems that it's pretty common to have about half as many DNFs as there are finds. I know of several caches with *more* DNFs than finds, and for a cache with a D4 rating or higher, that's how it should be (if not, the cache is likely overrated). Those automated notes may not by nasty grams, but how many could a CO of a well maintained, high difficulty cache expect to get simply because it gets a lot of DNFs. A Difficulty 4 cache, by definition, is going to have a lot of DNF logs. According to the ratings for difficulty or terrain page in the Help Center, a D4 rating means "Very difficult and may take special knowledge, advanced preparation, or multiple trips." Multiple trips implies that a DNF would be posted for every unsuccessful search (assuming that seekers are logging correctly).

 

What would be very useful is if reviewers can manually adjust the weighting of various contributing factors to the score. If a D4 cache (which may or may not get loads of DNFs) hits the threshold and the CO reports back that this is normal, and a reviewer understands this, they could go to that cache and adjust the actual algorithm for that specific cache to weigh DNFs less. So human judgement still plays a role, and the algorithm still gets to do its thing while being adjustable on a case by case basis.

 

Can open - worms everywhere...

 

Angry CO A, realising that their reviewer CAN tweak the algorithm for their specific cache harasses the life out of the reviewer, demanding special treatment and so on and so forth.

 

Then Angry CO's B, C and D cry that they are being unfairly penalized if they don't get the same treatment as Angry CO A.

 

Chaos ensues.

 

Riots on the streets.

 

Civilization as we know is ceases to exist.

 

The world ends.

[+Manville Possum]

Well it is likely you will get DNFs from a newbie, I don't think so likely to get NM or NA.

It was the newbie NVM's posting NM and NA on my listings when the intro app was introduced is why I made all my listings PMO.

 

So yes, it is very likely to happen.

I think you're misremembering. You couldn't submit an NM or NA from the Intro app (that ability was only introduced a month and a half ago), and an NVM wouldn't be able to log into the website to submit an NM/NA. If you were getting lots of NM/NA logs on your caches, it wasn't related to either NVMs or the Intro app.

 

I can tell you what I do remember being the reason my caches went PMO. A UVM trashed GZ on one of my caches and posted a NM.

[+dprovan]

I think you're misremembering. You couldn't submit an NM or NA from the Intro app (that ability was only introduced a month and a half ago), and an NVM wouldn't be able to log into the website to submit an NM/NA. If you were getting lots of NM/NA logs on your caches, it wasn't related to either NVMs or the Intro app.

Good point. But newbies do sometimes post mistaken NMs and NAs through the website, so even though Manville Possum might not be remembering exactly how the newbies were armed back then, as of a month and a half ago, newbies with the app can now make that mistake, too.

 

Can open - worms everywhere...

I claim the worms are already out even before you start considering cache by cache modifications to the algorithm.

 

The world ends.

And the world's end will be caused by poorly maintained caches, apparently.

[+thebruce0]

If a D4 cache (which may or may not get loads of DNFs) hits the threshold and the CO reports back that this is normal, and a reviewer understands this, they could go to that cache and adjust the actual algorithm for that specific cache to weigh DNFs less.

That information should be relayed back to HQ so they can adjust the algorithm accordingly. Dealing with the symptoms at the cache level won't fix the underlying problem, which will lead to more false-positives.

Well that's the point - if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged (that's why the DNF component was there in the first place). But if DNFs are flagged then caches in good condition that fool people who then post DNFs are flagged as potential maintenance required. One D4 cache may get DNFs because it is in bad condition, one may DNFs because it's legitimately hard to find. The cache-level adjustment for (certain) factors, again presuming reasonable reviewers/HQ, could take that all into consideration, fairly. Adjusting the unviersal algorithm always leaves one of those two circumstances out of place.

 

However...

 

Angry CO A, realising that their reviewer CAN tweak the algorithm for their specific cache harasses the life out of the reviewer, demanding special treatment and so on and so forth.

Good point. More subjective reviewer judgement that isn't based on explicit guidelines means more drama for reviewers.

So... scratch the idea

[+barefootjeff]

If a D4 cache (which may or may not get loads of DNFs) hits the threshold and the CO reports back that this is normal, and a reviewer understands this, they could go to that cache and adjust the actual algorithm for that specific cache to weigh DNFs less.

That information should be relayed back to HQ so they can adjust the algorithm accordingly. Dealing with the symptoms at the cache level won't fix the underlying problem, which will lead to more false-positives.

Well that's the point - if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged (that's why the DNF component was there in the first place). But if DNFs are flagged then caches in good condition that fool people who then post DNFs are flagged as potential maintenance required. One D4 cache may get DNFs because it is in bad condition, one may DNFs because it's legitimately hard to find. The cache-level adjustment for (certain) factors, again presuming reasonable reviewers/HQ, could take that all into consideration, fairly. Adjusting the unviersal algorithm always leaves one of those two circumstances out of place.

ratch the idea

Caches in bad condition (mushy logbook, broken container, etc.) don't get strings of DNFs, the only health issue such a string might suggest is a missing cache. To my mind, a simple change to the GHS that would eliminate a lot of false positives would be to require at least one outstanding NM. If no-one in the community is prepared to take that step, perhaps they deserve to have a map full of missing caches.

[+dprovan]

Caches in bad condition (mushy logbook, broken container, etc.) don't get strings of DNFs, the only health issue such a string might suggest is a missing cache. To my mind, a simple change to the GHS that would eliminate a lot of false positives would be to require at least one outstanding NM. If no-one in the community is prepared to take that step, perhaps they deserve to have a map full of missing caches.

Watch out or you might come to the too logical conclusion that nothing should be done until someone in the community is prepared to take the step of filing an NA and -- hey presto! -- the scoring makes no sense to begin with.

[+NYPaddleCacher]

Looking over a handful for caches with a D4 rating or higher it seems that it's pretty common to have about half as many DNFs as there are finds. I know of several caches with *more* DNFs than finds, and for a cache with a D4 rating or higher, that's how it should be (if not, the cache is likely overrated). Those automated notes may not by nasty grams, but how many could a CO of a well maintained, high difficulty cache expect to get simply because it gets a lot of DNFs. A Difficulty 4 cache, by definition, is going to have a lot of DNF logs. According to the ratings for difficulty or terrain page in the Help Center, a D4 rating means "Very difficult and may take special knowledge, advanced preparation, or multiple trips." Multiple trips implies that a DNF would be posted for every unsuccessful search (assuming that seekers are logging correctly).

 

What would be very useful is if reviewers can manually adjust the weighting of various contributing factors to the score. If a D4 cache (which may or may not get loads of DNFs) hits the threshold and the CO reports back that this is normal, and a reviewer understands this, they could go to that cache and adjust the actual algorithm for that specific cache to weigh DNFs less. So human judgement still plays a role, and the algorithm still gets to do its thing while being adjustable on a case by case basis.

 

Can open - worms everywhere...

 

Angry CO A, realising that their reviewer CAN tweak the algorithm for their specific cache harasses the life out of the reviewer, demanding special treatment and so on and so forth.

 

Then Angry CO's B, C and D cry that they are being unfairly penalized if they don't get the same treatment as Angry CO A.

 

Chaos ensues.

 

Riots on the streets.

 

Civilization as we know is ceases to exist.

 

The world ends.

 

But the thread continues

[+thebruce0]

But the thread continues

...On and on... ironically, by the very comments mentioning the length of the thread. A self-perpetuating dilemma, methinks...

[+thebruce0]

Well that's the point - if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged (that's why the DNF component was there in the first place). But if DNFs are flagged then caches in good condition that fool people who then post DNFs are flagged as potential maintenance required. One D4 cache may get DNFs because it is in bad condition, one may DNFs because it's legitimately hard to find. The cache-level adjustment for (certain) factors, again presuming reasonable reviewers/HQ, could take that all into consideration, fairly. Adjusting the unviersal algorithm always leaves one of those two circumstances out of place.

ratch the idea

Caches in bad condition (mushy logbook, broken container, etc.) don't get strings of DNFs, the only health issue such a string might suggest is a missing cache.

Yes. "Bad condition" means maintenance required. The reference was to a 'string of DNFs' correctly implying maintenance is required (for whatever reason), vs a 'string of DNFs' demonstrating a difficult to find cache in good condition. The algorithm can't tell the two situations apart if the factors are weighted the same. If it can be adjusted on the cache level then that's no longer a concern. But I go back to the problem of introducing undesireable geodrama for reviewers, which is why this wouldn't be a good idea in general. =P

[+Team Microdot]

Well that's the point - if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged (that's why the DNF component was there in the first place). But if DNFs are flagged then caches in good condition that fool people who then post DNFs are flagged as potential maintenance required. One D4 cache may get DNFs because it is in bad condition, one may DNFs because it's legitimately hard to find. The cache-level adjustment for (certain) factors, again presuming reasonable reviewers/HQ, could take that all into consideration, fairly. Adjusting the unviersal algorithm always leaves one of those two circumstances out of place.

ratch the idea

Caches in bad condition (mushy logbook, broken container, etc.) don't get strings of DNFs, the only health issue such a string might suggest is a missing cache.

Yes. "Bad condition" means maintenance required. The reference was to a 'string of DNFs' correctly implying maintenance is required (for whatever reason), vs a 'string of DNFs' demonstrating a difficult to find cache in good condition. The algorithm can't tell the two situations apart if the factors are weighted the same. If it can be adjusted on the cache level then that's no longer a concern. But I go back to the problem of introducing undesireable geodrama for reviewers, which is why this wouldn't be a good idea in general. =P

 

I've had a very long and difficult week and am not at my best in terms of mental acuity I will admit - but I struggled to follow what you are intending to convey here.

 

The part that I'm finding confusing is

 

if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged

 

For my understanding - could you please clarify / expand? Thanks

[+thebruce0]

if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged

 

For my understanding - could you please clarify / expand? Thanks

 

Context: D4 cache A and B. A is pretty easily findable but needs maintenance, B is in good condition but very difficult to find. The question is whether it's better to keep a universal algorithm, or allow for adjusting factors on a cache by cache basis.

 

Option 1: Weigh strings of DNFs as a negative. Cache A with a string of DNFs is flagged (as intended) and the CO is informed of a potential maintenance concern. Cache B with a string of DNFs because they just can't find it will also (and incorrectly) cause the 'nag' alert for the CO. Favour: Cache A.

 

Option 2: Don't consider DNFs in the score. Then, Cache A with a string of DNFs because of needing maintenance won't be flagged; the CO won't receive the 'nag' email. (but this is why DNFs were being weighed in the first place). But in this case, the CO of a difficult cache that often produces strings of DNFs rightly won't be nagged. Favour: Cache B.

 

Cache-level adjustment to weighing: CO of Cache B can request that a reviewer adjust the weighing of DNFs in their cache so they don't keep receiving nag emails about having a low GHS based on DNFs. Cache A still gets flagged rightly, and Cache B no longer receives nags merely for being a difficult to find cache.

 

(but as noted, reviewers subjectively judging 'reasonable' adjustment to algorithm factors opens another door for geodrama; not very enticing)

Edited March 30, 2017 by thebruce0

[+SwineFlew]

Dear cache, please shine a light so I can find you.

[+Team Microdot]

if we don't weigh DNFs, then caches with a string of DNFs that are in bad condition won't be flagged

 

For my understanding - could you please clarify / expand? Thanks

 

Context: D4 cache A and B. A is pretty easily findable but needs maintenance, B is in good condition but very difficult to find. The question is whether it's better to keep a universal algorithm, or allow for adjusting factors on a cache by cache basis.

 

Option 1: Weigh strings of DNFs as a negative. Cache A with a string of DNFs is flagged (as intended) and the CO is informed of a potential maintenance concern. Cache B with a string of DNFs because they just can't find it will also (and incorrectly) cause the 'nag' alert for the CO. Favour: Cache A.

 

Option 2: Don't consider DNFs in the score. Then, Cache A with a string of DNFs because of needing maintenance won't be flagged; the CO won't receive the 'nag' email. (but this is why DNFs were being weighed in the first place). But in this case, the CO of a difficult cache that often produces strings of DNFs rightly won't be nagged. Favour: Cache B.

 

Cache-level adjustment to weighing: CO of Cache B can request that a reviewer adjust the weighing of DNFs in their cache so they don't keep receiving nag emails about having a low GHS based on DNFs. Cache A still gets flagged rightly, and Cache B no longer receives nags merely for being a difficult to find cache.

 

(but as noted, reviewers subjectively judging 'reasonable' adjustment to algorithm factors opens another door for geodrama; not very enticing)

 

Thanks - I must have woken up from earlier because now I can read the original statement as I think you meant it. Although the adrenaline boost from watching Life at the cinema this evening might have something to do with my increased alertness

 

Earlier I was wondering how the DNF's could be in bad condition, rather than the caches being in bad condition

 

At the risk of a fizzy eruption (tin hat firmly in place) I IMAGINE that the existing algorithm based system COULD, if done well, automatically self-regulate to a degree to cope with this sort of thing as a less labour / angst intensive alternative to individual reviewer tweaks.

[+fizzymagic]

At the risk of a fizzy eruption (tin hat firmly in place) I IMAGINE that the existing algorithm based system COULD, if done well, automatically self-regulate to a degree to cope with this sort of thing as a less labour / angst intensive alternative to individual reviewer tweaks.

 

Since there is no proposal to automatically punish anyone, no eruption is forthcoming.

 

I can imagine a workable statistics-based system to alert to problem caches and reduce reviewer workload. However, it would need to have several important features:

1. It would need to explicitly acknowledge the possibility of false positives. The existing system does not, and assumes every positive is a true positive until proven otherwise. That is very, very bad design.
   
2. It should use modern machine-learning algorithms to do classification (that is, detect problem caches). As much information should be used as possible. Simply basing a score on log types is likely to give poor results. As an example, a NA log should be treated differently if it comes from a cacher with 10 finds than one coming from a cacher with 1000 finds. Also, logs coming from cachers with a history of being troublemakers should be discounted accordingly.
   
3. It would need to be able to accept feedback to improve the detection algorithm. The feedback should be for both false positives and false negatives. Good feedback usually requires ground truth, which is a little problematic in this instance.
   
4. It must not be used to automate punishment or accusations. As a tool for reviewers to flag caches that may need attention, it is fine. As the source of automated emails from Groundspeak accusing COs of poor maintenance, it is not acceptable.
   

 

In my prior rant on another thread, I stated that the cache health score as implemented by Groundspeak shows that they do not understand statistics. I stand behind that statement for a number of reasons. The first red flag came with the wording of the automated email; further evidence came from the crude use of a single "score" to represent a multidimensional characteristic, and the paucity of parameters used to generate the score.

 

I am willing to be convinced in the future that a scoring system could be developed into an effective tool for reviewers; I am pretty certain that the existing algorithm is not it.

[+Team Microdot]

At the risk of a fizzy eruption (tin hat firmly in place) I IMAGINE that the existing algorithm based system COULD, if done well, automatically self-regulate to a degree to cope with this sort of thing as a less labour / angst intensive alternative to individual reviewer tweaks.

 

Since there is no proposal to automatically punish anyone, no eruption is forthcoming.

 

I can imagine a workable statistics-based system to alert to problem caches and reduce reviewer workload. However, it would need to have several important features:

1. It would need to explicitly acknowledge the possibility of false positives. The existing system does not, and assumes every positive is a true positive until proven otherwise. That is very, very bad design.
   
2. It should use modern machine-learning algorithms to do classification (that is, detect problem caches). As much information should be used as possible. Simply basing a score on log types is likely to give poor results. As an example, a NA log should be treated differently if it comes from a cacher with 10 finds than one coming from a cacher with 1000 finds. Also, logs coming from cachers with a history of being troublemakers should be discounted accordingly.
   
3. It would need to be able to accept feedback to improve the detection algorithm. The feedback should be for both false positives and false negatives. Good feedback usually requires ground truth, which is a little problematic in this instance.
   
4. It must not be used to automate punishment or accusations. As a tool for reviewers to flag caches that may need attention, it is fine. As the source of automated emails from Groundspeak accusing COs of poor maintenance, it is not acceptable.
   

 

In my prior rant on another thread, I stated that the cache health score as implemented by Groundspeak shows that they do not understand statistics. I stand behind that statement for a number of reasons. The first red flag came with the wording of the automated email; further evidence came from the crude use of a single "score" to represent a multidimensional characteristic, and the paucity of parameters used to generate the score.

 

I am willing to be convinced in the future that a scoring system could be developed into an effective tool for reviewers; I am pretty certain that the existing algorithm is not it.

 

All sounds fair to me and good common sense.

 

I do like the fact that I often have to look up the meaning of some of the words you use in your posts.

[+thebruce0]

Thanks - I must have woken up from earlier because now I can read the original statement as I think you meant it. Although the adrenaline boost from watching Life at the cinema this evening might have something to do with my increased alertness

 

Earlier I was wondering how the DNF's could be in bad condition, rather than the caches being in bad condition

I often think too fast for my expression so I may have missed a word in a place or two =P

Recommend Life?

 

At the risk of a fizzy eruption (tin hat firmly in place) I IMAGINE that the existing algorithm based system COULD, if done well, automatically self-regulate to a degree to cope with this sort of thing as a less labour / angst intensive alternative to individual reviewer tweaks.

I stopped reading the other thread after my last comment, for my own sanity, so I missed anything that followed. A self-regulating algorithm though would still need some form of feedback to inform it of its result accuracy. With no feedback, it has no way of knowing when it errs. In theory it could analyze its own statistics to weigh what happens after its own reportings, such as low GHS followed by more and more finds without issue. But then the algorithm could be played if COs choose not to post OM logs, tricking the algorithm into thinking it was a false positive having noticed numerous DNFs followed directly by numerous Finds. ... I don't think self-regulation would be feasible either. Unless maybe GS hired Skynet.

[+Team Microdot]

Recommend Life?

 

Not sure - although my critique wouldn't be reliable anyway as we suffered an interruption in the form of a telephone call from France just as things were getting going and an ongoing dialogue which led to me not really settling into it.

 

It's scored 66% on Rotten Tomatoes and that's probably about right.

 

It has some good, very tense scenes but it was all over more quickly than I expected with very little plot development. I got the impression that there wasn't much of a budget to play with. Can't really say much more without spoiling the plot.