[FEATURE] Cache maintenance "stars"

[+frinklabs]

Rather than select from a pick list of possible maintenance issues, this system could also be brought in line with the difficulty and terrain ratings?

 

User logs could select from a one to five rating of how badly the cache needs maintenance, with one "star" being something like a full log; maybe five "stars" indicating the cache is now a habitat for a range of organisms, feeding off the pulp that was a log?

[+thebruce0]

Like a 'Condition' rating... enh.

If it's going to be a cache-wide stat, it has to average - but how far back? How many? Which?

You could propose various rating periods, like show me condition over the past month (only average reported stars in the past 30 days), or year, or week, or life... but that's just adding more complexity I'd think to a system that's already pretty simple (relatively speaking).

 

Without making it a cache-wide stat, only a rating per NM, like a maintenance severity rating, that might be helpful to some, but it would be SO subjective and quite open to abuse. I'm not convinced it'd be a feasible feature idea...

 

ETA: Maybe more applicable (and I'm not advocating this as a suggestion) would be to separate just into major/minor maintenance attributes. You might not care about finding caches with just a wet log, so include them in your cache filter; but for cracked/lost containers you could keep them out (assuming the poster of the NM used an appropriate severity). The only difference to the current system is it's not for a cache-level rating as you suggest, but rather a class of maintenance that manifests as a different attribute. *shrug* It would of course have to be added to the API as well since otherwise the NM log is the only thing that flags the attribute; it would need to also know which with the log submission.

Edited May 10, 2017 by thebruce0

[+cerberus1]

I think the current means to mention maintenance issues is fine.

 

The issue is folks using it ...

 

"Stars" seems like yet another way to "rate" caches.

Even after seeing some of the carp out there today, I'm still not in favor of that, due to it likely being abused.

[+hzoi]

Rather than select from a pick list of possible maintenance issues, this system could also be brought in line with the difficulty and terrain ratings?

 

User logs could select from a one to five rating of how badly the cache needs maintenance, with one "star" being something like a full log; maybe five "stars" indicating the cache is now a habitat for a range of organisms, feeding off the pulp that was a log?

No, thank you.

 

This proposal needlessly adds a numerical component to something that is going to vary based on a cacher's experience and even on the conditions at the time of visit (a leaky cache in the desert can be fine 95% of the time but a hot mess during or after rain).

 

Why take a system that people are already reluctant to use and add a layer of complexity? It seems more likely that this would get used less, not more, than the current system.

[+niraD]

I think it would be more useful to have the new system prompt the user for a description of the maintenance issue, rather than allowing only a handful of options, and leaving the catch-all "other" option vague and undefined.

[+WearyTraveler]

I think it would be more useful to have the new system prompt the user for a description of the maintenance issue, rather than allowing only a handful of options, and leaving the catch-all "other" option vague and undefined.

 

No kidding, eh? Kinda like the previous NM log where we had to enter text...

 

Man, did they open a can of worms, eh?

[+barefootjeff]

Rather than select from a pick list of possible maintenance issues, this system could also be brought in line with the difficulty and terrain ratings?

 

User logs could select from a one to five rating of how badly the cache needs maintenance, with one "star" being something like a full log; maybe five "stars" indicating the cache is now a habitat for a range of organisms, feeding off the pulp that was a log?

While this might indicate the severity of the problem, it doesn't provide the CO with any information on what they need to do to fix it. Isn't that the main purpose of NMs, to get the CO to fix the problem?

[+The A-Team]

While this might indicate the severity of the problem, it doesn't provide the CO with any information on what they need to do to fix it.

Agreed. This system wouldn't seem to give any benefit over the new/current system. Instead of "someone reported this cache needs maintenance", we'd have "someone reported this cache is in need of 2-star maintenance". It still doesn't convey any useful information other than the vague concept that some kind of maintenance is required.

[+noncentric]

My 2-cents about this idea...no thanks!

[+edexter]

Well, it's clear that the current Needs Maintenance system isn't working well because finders are not using it and instead simply describe the problem in their "found it" log. There are typically three to five references to "wet log, torn baggie, cracked lid" etc. before anyone posts a NM log. The majority of NM logs are then ignored by the CO. So adding refinements to a system that is easy (one click and a cut and paste of the problem from your log) is going nowhere.

Instead, the "new logging system" eliminates the distinctive NM log and records it and Needs Archive as "a note". This seems to indicate the direction that Groundspeak is heading when it comes to encouraging maintenance.

 

I'd guess about 10 to 20% of all caches need maintenance at any given moment, that many COs never do any and that a significant portion of COs don't even know how to record what little maintenance they do (based on the number of many month old Red Wrenches on active caches).

 

I believe there are only two ways to increase the percentage of currently placed caches in good repair:

A, Improve COs maintenance performance so more stuff gets fixed by alerting them to the problem.

B, Archive the damaged caches so fewer damaged caches are in the data base.

 

As near as I can tell from experience, there is only one process that does both things. Here's the process:

 

1, When you find a wet log/damaged cache/non-waterproof container log a NM and see what happens. If the CO responds to the NM log and makes the repair A has happened and there is one less bad cache out there. If the CO archives the cache then B has happened, which also reduces the bad caches by one.

2, If the CO does not respond in a month, post an NA log. It takes a few seconds for a CO to respond to an NM log, so there aren't any good reasons not to respond. CO's can disable a cache and fix it sooner or later as they please and meanwhile the cache will not show up as active.

3, If the CO then fixes the cache then A has been accomplished. If the CO does nothing, then sooner or later The reviewer will disable the cache. If the CO then fixes the cache A has been accomplished. If the CO still does nothing, then eventually the Reviewer will archive the cache and B has been accomplished.

 

Typically this process takes anywhere from a few days to a few months to play out. In rough terms, following this process results in about 25% of caches being repaired and 75% getting archived, typically by the Reviewer because the cache has been abandoned by the CO. Develop a thick skin because a small number of COs will react negatively and make take it personally that their cache is failing and will decide to blame you for pointing it out. C'est la vie

edexter