Jump to content

Bring back "Needs Maintenance" for COs


the Seagnoid

Recommended Posts

When the ability to log a find on your own caches was removed (and quite rightly, too) the ability to log a Needs Maintenance on your own cache was also removed.

 

However many people who log a find and state that there is a problem that needs fixing, state that in their find log and do not log a Needs Maintenance. As a result Cache owners have to maintain a manual list in addition to the one that Groundspeak so nicely provides. The Groundspeak list can be accessed via a scheduled pocket query, or through Project GC's Needs Maintenance query. But the manual entries the cache owner needs to keep (or more likely, tries to remember) - is not so nicely stored, and certainly not in the same consolidated place.

 

Could we please have just one list of all caches we have that need maintenance to help us manage our maintenance trips? Could cache owners please be able to log a needs maintenance on their own caches. 

 

This would help make managing maintenance easier, and so make cache maintenance more likely to happen, increasing the enjoyment for cache finders.

  • Upvote 6
  • Helpful 1
  • Love 1
Link to comment
5 minutes ago, Max and 99 said:

Can you just disable it if it needs maintenance? It's hard to overlook that when you look at your caches. 

Not all maintenance is worth disabling the cache. I've had people report that the camouflage was falling apart on my cache. I wanted a reminder that I needed to build a new camouflaged container, but it wasn't worth disabling the cache for. (As long as the remaining camouflage was turned to face up, it was sufficient.)

  • Upvote 5
Link to comment
7 minutes ago, L0ne.R said:

 

As a premium member you can make a list. https://www.geocaching.com/help/index.php?pg=kb.chapter&id=7&pgid=283

 

You can also access those lists from an app. Or create a PQ from the "My Caches Need Fixing" list. 

 

@LOne.R  - perhaps you should read the original post. Your suggested methods to not pull the complete list of caches needed maintenance.

Link to comment
17 minutes ago, niraD said:

Not all maintenance is worth disabling the cache. I've had people report that the camouflage was falling apart on my cache. I wanted a reminder that I needed to build a new camouflaged container, but it wasn't worth disabling the cache for. (As long as the remaining camouflage was turned to face up, it was sufficient.)

That's true. 

 

Link to comment
6 hours ago, the Seagnoid said:

When the ability to log a find on your own caches was removed (and quite rightly, too) the ability to log a Needs Maintenance on your own cache was also removed.

I contest your claim that there was any good reason to remove the ability to log finds on your own caches. I think GS should have always left it to people to decide for themselves what logs they should use for whatever reason they might want to use them. Looked at that way, obviously it's silly to prevent a CO from logging an NM on their own cache. There's absolutely no logical reason to think a CO can't be the one to discover that his cache needs maintenance. The only reason GS stopped allowing these NMs was to prevent COs from mistakenly filing NMs on their own caches, and I think COs should be allowed to make whatever mistakes they want to. If there was a rampant problem with COs accidentally logging NMs, well, maybe at least I could see the logic even though I still wouldn't agree with the conclusion, but I never saw someone file an NM by mistake on their own cache, and if they ever did, it's a simple enough problem to fix, so there's really no good reason not to allow those NMs just as you suggest.

  • Upvote 1
Link to comment
10 hours ago, the Seagnoid said:

Could cache owners please be able to log a needs maintenance on their own caches.

I agree that this would be helpful.  Last year someone posted a DNF on one of my caches while I was out of town for a few weeks.  I tried to post a Needs Maintenance so I wouldn't forget to check on it when I got home.  Since I couldn't do that, I had to ask the DNFer to post one for me.

Link to comment

At one time, CO could add or remove the NM attribute from edit.  I'd like to see "add" from edit come back. 

 

I wouldn't mind seeing "remove" from edit as well, though I can argue against  that too; left as is seems okay.

 

If I were in charge and had unlimited time and money for change, my change would be to make the default owner log, "Write Note".

Link to comment
12 hours ago, the Seagnoid said:

When the ability to log a find on your own caches was removed (and quite rightly, too) the ability to log a Needs Maintenance on your own cache was also removed.

 

However many people who log a find and state that there is a problem that needs fixing, state that in their find log and do not log a Needs Maintenance. As a result Cache owners have to maintain a manual list in addition to the one that Groundspeak so nicely provides. The Groundspeak list can be accessed via a scheduled pocket query, or through Project GC's Needs Maintenance query. But the manual entries the cache owner needs to keep (or more likely, tries to remember) - is not so nicely stored, and certainly not in the same consolidated place.

 

Could we please have just one list of all caches we have that need maintenance to help us manage our maintenance trips? Could cache owners please be able to log a needs maintenance on their own caches. 

 

This would help make managing maintenance easier, and so make cache maintenance more likely to happen, increasing the enjoyment for cache finders.

 

So the problem is that finders aren't logging the appropriate NM logs, which means that you want to be able to log one in order to keep better track of it.  Seems to me that your suggestion isn't addressing the issue that started the whole thing, which is finders not logging NMs when they're needed.  If they log the NM, then you won't need to.  I realize that means you're putting the onus on someone else to "properly" do something you'd like to be able to do yourself and as many finders don't do what is needed, it leaves much to be desired.

 

I do understand what you're saying but it would be so much easier if finders took the time to post the NM log, even if it's something as minor as faulty camouflage like niraD mentions.  While that example certainly doesn't really affect the ability to find it (well, makes it a bit easier) or what state the contents are in, it is still an alert to the CO that something appears to be wrong with the cache. Perhaps they should add another type of log or rename the NM log, similar to the suggestion of the NA log being recast as a Needs Reviewer Attention, to Needs Owner Attention (NOA).  However, until such time as they might do that (yeah...right), NM seems to be the best way to let the CO know that there is an issue with the cache.  That also means that finders and COs need to be reminded that a NM log isn't a personal attack or critique of their cache but is instead a note telling the CO that the finder thinks something needs some attention.  Addressing the root problem could conceivably render your request as not needed, assuming everyone begins to use the NM log when it's needed.  That's certainly a big assumption but I'd rather see a concerted effort to remedy the stigma of a NM log over the ability of a CO to log a NM on their own caches as the validated used of a NM log would have a much larger affect on caching as a whole.

 

As to a list that shows ALL your caches, on the old dashboard (which I still use), you can see the entire list of your caches by selecting "(Yours)", which lists all of your caches and provides you with TB information, last found information, current status of your cache (archived, enabled, disabled) as well as any NM wrenches.  No need to run a PQ.  It obviously won't provide you with a manual list of issues that have been posted in Found it logs though.  However, even there, you can create a list (call it CO NM) and add any cache of yours you feel needs maintenance to the list so that you know.  Keep the list private so that others can't see it and delete it from the list when maintenance is done.  No PQ needed for this either.

Link to comment
2 hours ago, L0ne.R said:

My guess, COs were abusing NM so Groundspeak had to remove the option. 

I find it hard to see how/why this would be subject to abuse.  I think the logic was more that the NM was notification to the CO that the cache needed maintenance, and the CO wouldn't need to notify themselves. I also would like to see this logging option return.  My workaround is that I keep a list called "HOME" that I put all new local caches on until I have found them, and also put all of my own caches that need maintenance on it until I have taken care of them. Whenever one of my own caches is on this list I know that it needs at least to be checked on.

  • Upvote 2
  • Helpful 2
Link to comment
6 hours ago, Nylimb said:

I agree that this would be helpful.  Last year someone posted a DNF on one of my caches while I was out of town for a few weeks.  I tried to post a Needs Maintenance so I wouldn't forget to check on it when I got home.  Since I couldn't do that, I had to ask the DNFer to post one for me.

 

You were out of town so couldn't do maintenance.   Isn't that what Temp Disable is for ?

  • Upvote 2
Link to comment
6 minutes ago, cerberus1 said:

 

You were out of town so couldn't do maintenance.   Isn't that what Temp Disable is for ?

Just because someone couldn't find a cache doesn't mean that it needs to be disabled.  May not need maintenance either, but a maintenance check could be in order.

Link to comment
16 hours ago, the Seagnoid said:

Could we please have just one list of all caches we have that need maintenance to help us manage our maintenance trips? Could cache owners please be able to log a needs maintenance on their own caches. 

 

This would help make managing maintenance easier, and so make cache maintenance more likely to happen, increasing the enjoyment for cache finders.

 

Remembered you asked for this to be placed in your profile once too.  Guess I just don't understand how "keeping track" is an issue.

Rather than wait for a NM, we act on logs too.  We fix 'em when we can.  That wouldn't change with 3 or 300 caches...

  • Love 1
Link to comment
3 hours ago, coachstahly said:

So the problem is that finders aren't logging the appropriate NM logs, which means that you want to be able to log one in order to keep better track of it.  Seems to me that your suggestion isn't addressing the issue that started the whole thing, which is finders not logging NMs when they're needed.

Nope, that's not it at all. The observation is just that the CO can detect a problem just as well as anyone else can, so there's no logical reason for denying them the ability to react in the same way as anyone else by posting an NM. We think of NMs as alerting the CO, but they also alert anyone else looking at the log, both seekers and reviewers.

 

It's true people don't always post NMs when they should, but forbidding NMs by COs just exacerbates the problem. When I see a string of DNFs in a log and realize the last seeker really should have posted an NM, I sometimes post an NM myself without visiting the cache. It makes no difference whether I'm the owner or a third party: I need to file an NM, so I should be able to file one. Forbidding COs from filing NMs just, for no good reason, removes one individual from taking that corrective action.

 

In fact, if you're worried about people not filing NMs, then COs filing NMs on their own caches is a good thing because it might cause people to reconsider if they believe NMs are insults.

  • Upvote 1
  • Helpful 1
Link to comment
15 minutes ago, dprovan said:
4 hours ago, L0ne.R said:

My guess, COs were abusing NM so Groundspeak had to remove the option. 

I honestly can't imagine what you're thinking of. How could a CO abuse NMs?


I don’t get this either.


Ok, there are workarounds, but does anybody have a good reason why COs shouldn’t be able to post a NM log on their own cache?

Link to comment
17 hours ago, the Seagnoid said:

When the ability to log a find on your own caches was removed (and quite rightly, too) the ability to log a Needs Maintenance on your own cache was also removed.

 

However many people who log a find and state that there is a problem that needs fixing, state that in their find log and do not log a Needs Maintenance. As a result Cache owners have to maintain a manual list in addition to the one that Groundspeak so nicely provides. The Groundspeak list can be accessed via a scheduled pocket query, or through Project GC's Needs Maintenance query. But the manual entries the cache owner needs to keep (or more likely, tries to remember) - is not so nicely stored, and certainly not in the same consolidated place.

 

Could we please have just one list of all caches we have that need maintenance to help us manage our maintenance trips? Could cache owners please be able to log a needs maintenance on their own caches. 

 

This would help make managing maintenance easier, and so make cache maintenance more likely to happen, increasing the enjoyment for cache finders.

 

OK - I understand what you're saying, and how it would help.  Yet, logging "needs maintenance" on one's own cache is still a manual step a CO would have to take, even if the system is changed to allow it.

 

Unless/until Groundspeak decides this is worth dedicating a programmer to execute, consider making a basic member sock puppet account to flag your own caches.  Or make a bookmark list, which can also be mapped and/or turned into a pocket query.

  • Upvote 1
  • Helpful 1
Link to comment
1 hour ago, IceColdUK said:


I don’t get this either.


Ok, there are workarounds, but does anybody have a good reason why COs shouldn’t be able to post a NM log on their own cache?

 

We would be changing the function of the tool. It's a tool for finder's to alert owners of a significant problem that needs owner attention.

 

It would make a reviewers job harder when the tool is misused. 

 

Perhaps we need more cache owner tools, but separate from finder tools so it doesn't confuse. 

Edited by L0ne.R
  • Upvote 1
Link to comment
26 minutes ago, L0ne.R said:

We would be changing the function of the tool. It's a tool for finder's to alert owners of a significant problem that needs owner attention.

It would make a reviewers job harder when the tool is misused. 

Perhaps we need more cache owner tools, but separate from finder tools so it doesn't confuse. 

 

I don't see how a log would "confuse" Reviewers.  They figure out issues better than most of us.    :)

I remember a thread on having NM listed on one's profile (and started by the OP as well).   

If caches are in such shape that keeping track of which hides need maintenance is an issue, maybe it's better to start from A, and work to Z.

  • Upvote 1
Link to comment
2 hours ago, dprovan said:

Nope, that's not it at all.

 

Pretty sure the OP stated that finders not logging NMs was one of the stated reasons they wanted this to be implemented. 

 

18 hours ago, the Seagnoid said:

However many people who log a find and state that there is a problem that needs fixing, state that in their find log and do not log a Needs Maintenance. As a result...

 

(paraphrasing here) Because of finders logging their finds and stating that there's a problem, instead of filing the appropriate NM log.......I'd like to suggest that COs to be able to file a NM on their own caches in order to track maintenance on their own caches on one list instead of maintaining two separate ones - one from cachers who file appropriate NM logs and one from cachers who don't.

 

2 hours ago, dprovan said:

The observation is just that the CO can detect a problem just as well as anyone else can, so there's no logical reason for denying them the ability to react in the same way as anyone else by posting an NM.

 

Then you go and post this example.

 

2 hours ago, dprovan said:

When I see a string of DNFs in a log and realize the last seeker really should have posted an NM, I sometimes post an NM myself without visiting the cache. It makes no difference whether I'm the owner or a third party: I need to file an NM, so I should be able to file one.

 

Apparently the CO of this cache hasn't actually detected the problem (despite your stated belief that a CO can detect a problem just like anyone else can), nor have you if you need to file a NM against your own cache if it were this example you provided.  I would hope that repeated DNFs on a 1.5/1.5 (or some similarly rated cache) would entice the CO to go out and check on the cache to make sure it's in play and then fix it if it's not, not file a NM on their own cache and wait to fix it.  The implication in this example is that it might be missing. The CO knows what type of container and hide it is. The CO brings a replacement container with them in case it is missing (which seems the most likely scenario) and fixes the issue by putting out the new one or verifying the old one was in place (or had migrated some).  The CO filing a NM seems to add an extra and unnecessary step to the process.  If they can't get to it in a timely manner (out of town, a more remote location, too busy due to work or family obligations, etc...), then disabling it is the way to go, not filing a NM log.  If the CO thinks it's missing, then why would a CO purposely keep a cache active that they think is missing?

 

Since the ability for a CO to file a NM log on one of their own caches isn't available, and the suggested feature is to provide an easy way to track needed maintenance of your own caches, the only thing we have that satisfies this suggestion is a temporary disable log.  The line through the cache should be sufficient notice to the CO that their cache needs to be tended to and it's visible to all, COs, seekers, and reviewers.  IIRC, I think that if you begin a new cache submission, disabled caches pop up and the site tells you that you appear to have some caches in need of attention, before you get too far along in the submission process.  You can bypass it but it at least tracks your caches with issues.  No PQ needed as you can view a list of all of your caches on the old version of the dashboard (not sure about the "new" dashboard) and see any cache that has a line through it.  Or, as hzoi has posted, create a sock puppet account and file your own NM logs that way.

 

  • Upvote 1
Link to comment
7 hours ago, L0ne.R said:

My guess, COs were abusing NM so Groundspeak had to remove the option. 

 

I'm trying to figure out what form that abuse might take and am coming up empty.

 

2 hours ago, L0ne.R said:

It would make a reviewers job harder when the tool is misused.

 

I'm not sure how a CO could "misuse" a NM log on their own cache and how a NM log would make a reviewer's job harder since they're not notified when a NM log is filed.  

 

2 hours ago, L0ne.R said:

Perhaps we need more cache owner tools, but separate from finder tools so it doesn't confuse. 

 

We already have a tool that can do, to some extent, what the OP has suggested.  The temporary disable log notifies the CO, a reviewer (if they're viewing it for any reason), and all seekers that this cache is down for some noted reason.  It also visually allows the CO the ability to see that their cache has some sort of issue if disabled and also allows the CO to see, in one place (at least on the old dashboard), any of their caches that they disable to track maintenance.

Link to comment
17 hours ago, coachstahly said:

 

So the problem is that finders aren't logging the appropriate NM logs, which means that you want to be able to log one in order to keep better track of it.  Seems to me that your suggestion isn't addressing the issue that started the whole thing, which is finders not logging NMs when they're needed.  

It is far easier to sort the problem myself, than to try to retrain the entire geocaching community! (or at least, all the ones that need training)

Link to comment
5 hours ago, the Seagnoid said:

It is far easier to sort the problem myself, than to try to retrain the entire geocaching community! (or at least, all the ones that need training)

 

Sure it is but I don't think you're going to get what you desire.  We can't even get an attribute or new icon for a power trail (which so many of us have said would be really nice to have).  The only thing that currently would come even close to what you want would be the temporary disable log.  I don't know that it would be a "new" use, as it's always been used when more time is needed to address maintenance issues that take a bit longer to get done.  However, for something minor like a log replacement, it seems a bit "heavy" if all you need is a manner of tracking your caches that need minor maintenance.

Link to comment
19 hours ago, cerberus1 said:

 

You were out of town so couldn't do maintenance.   Isn't that what Temp Disable is for ?

No.  At that point I didn't know if there was a problem with the cache, or if the DNFer just couldn't find it.  Soon afterward, someone else, who had more time to search, posted a DNF, so I decided it was probably missing, and Temporarily Disabled it.  When I got back home I prepared a replacement container and took it to the cache site.  It turned out that the original was still there, but had gotten buried under debris from a decomposing driftwood log.

  • Upvote 1
  • Funny 1
Link to comment
17 hours ago, coachstahly said:

Pretty sure the OP stated that finders not logging NMs was one of the stated reasons they wanted this to be implemented. 

It's true that the OP wants to post NM because they should have been posted but weren't, but the more important observation is that it's just plain illogical not to allow it.

 

17 hours ago, coachstahly said:

I would hope that repeated DNFs on a 1.5/1.5 (or some similarly rated cache) would entice the CO to go out and check on the cache to make sure it's in play and then fix it if it's not, not file a NM on their own cache and wait to fix it.

But until they can get there, they should post an NM.

 

17 hours ago, coachstahly said:

The CO filing a NM seems to add an extra and unnecessary step to the process.

It's not a required step, it's just a tool they can use when they need to, like when they realize the NM needs maintenance but, regretfully, they -- say for example -- have a life, so they can't run out right away to confirm it's missing.

 

As you point out, the OP is suggesting this because he has to maintain his own list of caches that need maintenance. Save the argument that COs should always run out and fix caches the very instant there's a hint of a problem for another thread. For whatever reason, the OP has decided against that.

 

18 hours ago, coachstahly said:

Since the ability for a CO to file a NM log on one of their own caches isn't available, and the suggested feature is to provide an easy way to track needed maintenance of your own caches, the only thing we have that satisfies this suggestion is a temporary disable log.

As others have mentioned, not all problems make the cache unseekable. Simple suspicion of being missing is a prime example. In those cases, disabling is just a poor substitute for the more accurate and obvious NM which was taken away from COs for no good reason.

  • Upvote 2
  • Helpful 1
Link to comment
2 hours ago, coachstahly said:

Sure it is but I don't think you're going to get what you desire.  We can't even get an attribute or new icon for a power trail (which so many of us have said would be really nice to have).  The only thing that currently would come even close to what you want would be the temporary disable log.

You seem to have forgotten that this isn't a request for a new feature, it's a request to remove the change that took away a previously existing feature.

 

2 hours ago, coachstahly said:

However, for something minor like a log replacement, it seems a bit "heavy" if all you need is a manner of tracking your caches that need minor maintenance.

Leaving aside the discussion about whether an NM is appropriate for a full log -- I don't think it is, but GS encourages it -- one of the reasons for a CO posting an NM even though the problem is minor is that no one else, detecting the same problem, needs to post the NM. In fact, they can see the COs NM and skip looking for the cache altogether if that's their preference.

Link to comment
8 minutes ago, dprovan said:

It's true that the OP wants to post NM because they should have been posted but weren't, but the more important observation is that it's just plain illogical not to allow it.

 

But that wasn't what you replied to regarding my initial post.  You stated that that wasn't it at all, despite the OP actually saying that's why they wanted to be able to file the NM on their own - seekers/finders weren't posting the needed NM, instead opting to post their issues in their found log.  

 

15 minutes ago, dprovan said:

But until they can get there, they should post an NM.

 

Why?  If there's a delay to get to the cache to fix the issue, file the TD.  That should, presumably, prevent anyone from seeking out the cache while at the same time let potential seekers know that the CO is aware of the problem but just can't get to the cache quickly enough to take care of the problem.  The NM acknowledge's there's a problem (however minor or major it might be) but keeps a cache active, potentially drawing seekers to a cache that's potentially not there or has a container issue that has rendered the cache a mess.  Why would a CO, who believes it is probably missing or has a container issue that is making the experience a bad one, willingly keep a cache active and provide a potentially negative experience?  

 

Let's look at it from the other side - the side of a finder posting a NM (as probably should have been done).  A CO is most likely going to temporarily disable a cache from a seeker filed NM log that states that it might be missing (with information that strongly supports that assumption) or one that states the lid is missing and the cache is full of water.  Wouldn't you TD the cache if you received a NM from a seeker for either of those situations?  So why would you file a NM instead if you were the one to file it, without also filing the TD?  The TD skips an extra and unnecessary step, in this type of situation.

 

26 minutes ago, dprovan said:

It's not a required step, it's just a tool they can use when they need to, like when they realize the NM needs maintenance but, regretfully, they -- say for example -- have a life, so they can't run out right away to confirm it's missing.

 

Which is why the TD is there, to let seekers know that the cache has an issue that the CO can't get to right away.  It's just a tool they can use when they need to as well.  If you can't get out there right away (and I'm not advocating for that at all), then a TD provides a MUCH easier manner of tracking maintenance issues on your own caches (right now), rather than having to rely on you maintaining some list manually.

 

29 minutes ago, dprovan said:

As others have mentioned, not all problems make the cache unseekable. Simple suspicion of being missing is a prime example. In those cases, disabling is just a poor substitute for the more accurate and obvious NM which was taken away from COs for no good reason.

 

I know that.  However, you're commenting on what used to be while I'm commenting on what can be done right now.  Unless you have some other solution that can use current tools at our disposal (like hzoi's example of using a sock puppet account to file NM logs), then you're hoping for something to be reinstated at some point in the future, which doesn't help the OP right now.  Saying that it's a poor substitute doesn't change the fact that it's one way that this issue can be addressed, using the tools we currently have at our disposal.  I'm also not saying that what I'm suggesting is the only solution.  I'm just saying that, despite it's flaws, it's currently the easiest way to track your caches that need maintenance without having to revert to PQs or sock puppet accounts.  All you need to do is go to your list of your caches and see which caches are lined out due to the TD log.  You could also create a list and then edit the comments so you know which caches have what problems and then remove them from the list once maintenance is completed but that seems to entail just as much work, if not more.

 

26 minutes ago, dprovan said:

You seem to have forgotten that this isn't a request for a new feature, it's a request to remove the change that took away a previously existing feature.

 

That doesn't really matter though, does it.  We had it, then we didn't.  We want something added that we don't have the capability to do right now, regardless of whether or not we previously had the ability to do so.

 

31 minutes ago, dprovan said:

Leaving aside the discussion about whether an NM is appropriate for a full log -- I don't think it is, but GS encourages it...

 

I don't either.

 

31 minutes ago, dprovan said:

...one of the reasons for a CO posting an NM even though the problem is minor is that no one else, detecting the same problem, needs to post the NM. In fact, they can see the COs NM and skip looking for the cache altogether if that's their preference.

 

This is the only reason I can see that carries any weight (for me) for why a CO NM should be allowed but it places more of the onus on the CO to detect the problems (which they should be doing already, to some extent) rather than on the community to help detect the problems.  Unless I visit the cache daily or weekly, I'm not going to know if the lid is cracked or if construction has rendered the area inaccessible, if the log is full, if the log is wet, if there's an issue with one of the stages, or if it might be missing.  I hope that the finders (and DNFs) provide me with that feedback because I don't want to have to go check on all of my caches on a daily or weekly schedule, nor should I be expected to.  I placed my caches in a manner that hopefully allows me to do as little maintenance as possible, due to the selection of good containers, good logs, and good locations that prevent the placed cache from being inadvertently discovered by someone other than a geocacher.  The onus is on me (as it should be) to fix any issues that might arise but I don't think the onus should be on the CO to be the one to file the NM to let others know that something is off on the cache.  Now you're not only placing the emphasis on maintaining the cache on the CO, you're also placing the emphasis on the CO to detect the issue that would lead to maintenance being performed.  Don't think that could happen?  Aren't you the one lamenting the fact that the community now appears to take less responsibility for holding COs accountable for maintenance because GS has enabled reviewers to be more proactive when it comes to potential maintenance issues?  "I don't have to do that now because the reviewers are doing it on their own."  This is just one more little step that takes some of that community responsibility for detecting potential maintenance issues (and alerting the CO) and puts it in the hands of someone else who is already responsible for performing maintenance.

 

I realize that this is probably taking things a bit to the extreme, especially considering the OP just wants a method to track their own caches that need maintenance more easily. I don't mind a CO being able to file a NM on their own cache but I don't know that there's some sort of necessity that this be something we can do as COs.  I know I never used it (and never thought to use it) but realize that others may have used it as such.  Is the only "need" for this - to be able to track your own caches that need maintenance without also maintaining a manual list?  

  • Upvote 1
Link to comment
On 5/21/2020 at 4:23 AM, coachstahly said:

Is the only "need" for this - to be able to track your own caches that need maintenance without also maintaining a manual list?  

Yes. What is the point of a Needs Maintenance log except to alert the CO that they need to plan a maintenance trip? Going out on the day is not always feasible, especially where the caches require significant effort to reach.

Given that, why can I not have a single list of ALL my caches that need maintenance?

Link to comment
7 minutes ago, the Seagnoid said:

Yes. What is the point of a Needs Maintenance log except to alert the CO that they need to plan a maintenance trip? Going out on the day is not always feasible, especially where the caches require significant effort to reach.

Given that, why can I not have a single list of ALL my caches that need maintenance?

 

So why not disable it so you know you need to plan a maintenance trip? You don't have the ability to file a NM log (even though you used to) so wouldn't this, at the very basic level, serve the same purpose?  It would allow you to see all your caches that are disabled due to needing maintenance.  I realize it's not perfect but unless you're willing to adopt hzoi's suggestion (sock puppet account and file a NM on your caches needing maintenance) or create a list and title it "Maintenance needed" and add your caches to that list, I don't see any other "easy" way of doing it.

 

I fully understand why you want it and I'm not really sure why GS took that ability away when they took the ability to log a find on your own cache away, but it's gone and I don't suspect it's coming back.  

  • Upvote 1
Link to comment
33 minutes ago, coachstahly said:

So why not disable it so you know you need to plan a maintenance trip?

 

Well, how about...

On 5/18/2020 at 5:44 PM, niraD said:

Not all maintenance is worth disabling the cache.

On 5/19/2020 at 9:45 AM, NanCycle said:

Just because someone couldn't find a cache doesn't mean that it needs to be disabled.

On 5/20/2020 at 7:44 AM, dprovan said:

As others have mentioned, not all problems make the cache unseekable.

 

Just sayin'...

Link to comment
1 hour ago, coachstahly said:

I fully understand why you want it and I'm not really sure why GS took that ability away when they took the ability to log a find on your own cache away, but it's gone and I don't suspect it's coming back.


Website

Discussions about features, bugs, and ways to improve Geocaching.com.


Sure, there are workarounds to the OP’s issue, but as I see it, this is an idea to “improve Geocaching.com”.  You’re right, this feature might never come back, but no harm in bringing it to HQ’s attention.

 

Nobody’s persuaded me (for what that’s worth!) that it’s a bad idea, and who knows it might be a simple change. ?

Link to comment
1 hour ago, L0ne.R said:

Perhaps I'm not understanding, but you can do that. 


Yes, you can manage your own Lists (with a capital ‘L’), but so much easier to just use the same mechanism for NMs raised by others and those you identify yourself:

 

- NM adds to list (with a little ‘l’). 

- OM removes from list.

 

Simples!

  • Helpful 1
Link to comment
1 hour ago, IceColdUK said:

Yes, you can manage your own Lists (with a capital ‘L’), but so much easier to just use the same mechanism for NMs raised by others and those you identify yourself:

 

- NM adds to list (with a little ‘l’). 

- OM removes from list.

 

Hzoi's suggestion seems like an easy workaround for those COs who really want to leave an NM on their own cache, instead of making a personal list, or logging a disable.

 

On 5/19/2020 at 1:43 PM, hzoi said:

consider making a basic member sock puppet account to flag your own caches. 

 

-----------------------------------

 

On 5/18/2020 at 8:44 PM, niraD said:

I wanted a reminder that I needed to build a new camouflaged container, but it wasn't worth disabling the cache for. (As long as the remaining camouflage was turned to face up, it was sufficient.)

 

The disable is the owner-tool that does the job of the NM finder-tool. If a disable is too much, then I'm not understanding why an NM is not also too much to apply to a cache that has minor issues like camo tape coming off? For those minor issues, a personal list seems to me to be a very good option. 

Link to comment
1 hour ago, L0ne.R said:

For those minor issues, a personal list seems to me to be a very good option. 

So then I have the NM status to track reports where others logged NM, and a personal list to track reports where others didn't log NM.

 

It would be easier if I could just log NM when someone else mentions something in a Find or Note log, and not have two places to check.

  • Upvote 2
Link to comment
On 5/20/2020 at 9:23 AM, coachstahly said:

But that wasn't what you replied to regarding my initial post.  You stated that that wasn't it at all, despite the OP actually saying that's why they wanted to be able to file the NM on their own - seekers/finders weren't posting the needed NM, instead opting to post their issues in their found log.

I was posting my own opinion, not the OP's.

 

On 5/20/2020 at 9:23 AM, coachstahly said:

Why?  If there's a delay to get to the cache to fix the issue, file the TD.

We've been over this over and over: not all NMs make the cache unfindable, so not all NMs mean the cache needs to be disabled.

 

On 5/20/2020 at 9:23 AM, coachstahly said:

Let's look at it from the other side - the side of a finder posting a NM (as probably should have been done).  A CO is most likely going to temporarily disable a cache from a seeker filed NM log that states that it might be missing (with information that strongly supports that assumption) or one that states the lid is missing and the cache is full of water.  Wouldn't you TD the cache if you received a NM from a seeker for either of those situations?

No, I would not disable a cache simply because an NM was posted. I'm perfectly comfortable with people finding my less than pristine cache until I can go replace it. I guess this explains our disagreement.

 

On 5/20/2020 at 9:23 AM, coachstahly said:

Which is why the TD is there, to let seekers know that the cache has an issue that the CO can't get to right away.

No, a TD is there to flag a cache that no one should go look for. There's a huge gulf between having a problem and being a waste of time.

 

Anyway, you're trying to convince me why I shouldn't file an NM. I'm saying there's no good reason for us to prevent a CO from filing an NM no matter how strongly you feel about whether you'd file a TD instead.

12 hours ago, the Seagnoid said:

Yes. What is the point of a Needs Maintenance log except to alert the CO that they need to plan a maintenance trip?

An NM log tells everyone, the CO, seekers, reviewers, and anyone else, present or future, about the situation.

  • Upvote 1
Link to comment
4 hours ago, dprovan said:

No, I would not disable a cache simply because an NM was posted. I'm perfectly comfortable with people finding my less than pristine cache until I can go replace it. I guess this explains our disagreement.

 

Last year, a friend mentioned in his log on one of my caches that a rat had been chewing on the plastic container's handles. He didn't post an NM but I wouldn't have minded if he'd done so. Enough of an issue for me to replace it a week later with a steel container (get your teeth into that, ratty!) but certainly not enough to warrant disabling the cache in the meantime.

  • Helpful 1
Link to comment
15 hours ago, IceColdUK said:

Nobody’s persuaded me (for what that’s worth!) that it’s a bad idea, and who knows it might be a simple change.

 

I've never said it was a bad idea.  I am saying that I'm not sure I truly understand the need for it, other than to alert yourself that you have a cache that needs attending to.  From personal experience, if you stay on top of maintenance issues, then the list should be relatively small and manageable to the point that some list, either manually maintained or otherwise, needn't be created.  I'm also agreeing with those that say that not all caches that need maintenance also need to be disabled.  However, there's no easy way, currently in place, that allows a CO to quickly look at their cache to see if it needs some attention and this is the easiest, despite not being applicable to all maintenance issues.  It doesn't require a sock puppet account and it doesn't require the CO to create a list to which they'd manually need to add and delete their caches once the need for maintenance is noted or completed.  It's a workaround that does what the OP would like, even with all of its flaws.

 

I realize it's not an optimal solution but everyone is providing reasons for why it shouldn't be used and the CO-filed NM log is a better option.   I agree that it's a better and more equitable way to apply to all of your caches as a cracked lid/broken container is different than a wet or full log.  However, a CO-filed NM log is not an option we have right available to us right now (or might ever have again).  

 

Abilities/tools that we don't have access to (or used to but don't anymore) but what we want don't seem to be high on the list of developers while some things that we didn't need seem to get prioritized and implemented, despite no one bringing them up.  Did we really need two types of maps?  A new dashboard? A new manner of logging caches that combines finds with NMs?  An additional format added to the cache creation tools?  Souvenirs?  Old "challenges"?  Adventure Labs? Message Center? CHS? Statistics about finds and FPs on your profile?

 

Do any of these "improve geocaching.com"?  The only thing I can see that has any real potential benefit to the actual activity of geocaching (and that's been debated on here) is the CHS. The rest seem to be things added just to be added.  Perhaps the dashboard is geared toward app users so that it loads and interacts much easier on a phone.  Some of them are nice to have but I wouldn't be upset if they were retracted (although I'm sure some would be). Things that we want that would help improve geocaching.com that are user generated don't tend to find much traction amongst those who have the ability to do something about it.

 

Knowing this, we have to figure out workarounds that closely proximate what we would like to be able to do or find a third party and use their programs to accomplish what can't be accomplished on the site.  Until such time as GS reinstitute the ability for a CO to file a NM on their own cache, however likely or unlikely that might be, the easiest way right now (even with its flaws) is to TD your cache because you'll have a quick visual confirmation for any cache of yours that needs maintenance.  The second easiest way that's been mentioned so far is to create a sock puppet account and file the NM log using that, which would do exactly what the OP wants but would require a new account. The third way is to create a list and keep it private, title it "NM", manually add the cache, edit the comments so you know what maintenance might be needed, delete the cache when done with maintenance, and repeat.  

 

They don't fully replicate what the OP wants in the way that the CO-filed NM did, but they come as close as can possibly be done now with some minimal effort involved.

 

5 hours ago, dprovan said:

Anyway, you're trying to convince me why I shouldn't file an NM.

 

You apparently seem to think that I don't want the ability for a CO to be able to file a NM on their own cache and that somehow my TD suggestion is a better way to deal with this.  That's not it at all.  Telling me that a CO-filed NM log is a better solution that TDing a cache certainly makes sense to me as so many of you have pointed out.  I don't know why it was removed as an option and I'd have no problem with it coming back (although I doubt I'd use it and I doubt it will come back).  I completely agree with all of you on that.  Not every maintenance issue is the same and requires a TD.  I'm not saying that my solution/workaround is better than a CO-filed NM log; I'm saying that it's one way we can come close to what the OP desires, under the current tools we have access to and I'm defending my point as a potential valid substitute for something we can no longer do, despite the main flaw inherent in it (not every maintenance issue needs to be TDed to be addressed), which I've readily acknowledged.  For whatever reason, many of you continue to point out that a CO-filed NM is the better tool for what I've suggested, despite the fact that it's actually NOT a tool we can use.  We cannot file a NM on our own caches.  If you can't do something, but you tell me that what I can't do is a better solution than what I can do, then that just doesn't make any sense to me as it pushes the problem further into an unknowable future rather than attempting to find some solution/workaround for the present.  

 

  • Upvote 1
Link to comment
2 hours ago, barefootjeff said:

Last year, a friend mentioned in his log on one of my caches that a rat had been chewing on the plastic container's handles.

He didn't post an NM but I wouldn't have minded if he'd done so.

 

Exactly.   :)     You read the log , and acted on it when you were able.   Whether he placed a NM or not, you got what was said.   Cool.

Did you feel you needed to be "reminded" to stop sometime to fix it ?   

 

The OP wants to be able to place a NM on his own cache.

The OP needs to be reminded enough that they say,  "This would help make managing maintenance easier, and so make cache maintenance more likely to happen, increasing the enjoyment for cache finders. "

If someone acted on cache logs ( and the OP has said they have...), how many caches have to have issues before they're fixed ?

I don't think there's anyone we know who'd forget that one cache they own has issues.  Two either...   

Link to comment
5 hours ago, coachstahly said:

I'm saying that it's one way we can come close to what the OP desires, under the current tools we have access to and I'm defending my point as a potential valid substitute for something we can no longer do, despite the main flaw inherent in it (not every maintenance issue needs to be TDed to be addressed), which I've readily acknowledged.

OK, thanks for explaining. I took your arguments as being why a TD is the desired action. Everyone already knows the TD is available as a hack solution, so I found it impossible to interpret you vehemence as being just a friendly reminder about it. What made you think anyone was arguing against that?

 

5 hours ago, cerberus1 said:

I don't think there's anyone we know who'd forget that one cache they own has issues.

Wow, you have a special set of friends. If everyone were like the people you know, we wouldn't need the NM flag at all. But, in reality, people forget. We know this. An NM log sets an NM flag for very important reasons, all of which are as important when a CO recognizes the need as it is when anyone else recognizes the need.

  • Upvote 1
  • Funny 1
Link to comment
6 hours ago, cerberus1 said:
9 hours ago, barefootjeff said:

Last year, a friend mentioned in his log on one of my caches that a rat had been chewing on the plastic container's handles.

He didn't post an NM but I wouldn't have minded if he'd done so.

 

Exactly.   :)     You read the log , and acted on it when you were able.   Whether he placed a NM or not, you got what was said.   Cool.

Did you feel you needed to be "reminded" to stop sometime to fix it ?   

 

 

Across all my 38 active caches I rarely get more than a handful of logs a month and I could count on one hand the number of times over my seven years of caching that someone has mentioned a maintenance issue in their logs, so no, I didn't neeed to be reminded, I just gave it as an example of a maintenance issue where a TD would be inappropriate.

 

For someone with lots of hides that get lots of visitors and frequent minor maintenance issues (full logs, o-rings needing replacement, etc.), a reminder mechanism could be useful, particularly in the present situation where CO visits might have to be delayed for some time.

  • Upvote 1
Link to comment

I like the idea if a sock puppet account - A Needs Maintenance Autobot  that uses advanced AI (ie, me) to intelligently read Found logs to detect for maintence needed on my caches that are difficult to get to . The easy ones, of course get maintenance immediately, but as numerous others above state, needing maintenance does not necessarily mean the logbook is affected in such a way that the cache needs to be disabled.

  • Upvote 2
Link to comment

The sock puppet is about the easiest way to accomplish this if one really really must do it. If it's obvious what the account is created for and who owns it, then there'd be even less concern of questionable practices. 

 

If I were to see such an account post a NM after I post my log where I didn't include a NM, I don't feel I'd take issue with that. If you want to NM your own cache, well that's entirely up to you. (just don't shame the prior logger for not including a NM log - that's a whole other level of petty, imo)

  • Upvote 1
Link to comment
20 hours ago, thebruce0 said:

The sock puppet is about the easiest way to accomplish this if one really really must do it. If it's obvious what the account is created for and who owns it, then there'd be even less concern of questionable practices. 

 

 

I don't believe having a separate sock puppet account by itself runs afoul of the Terms of Service.  Nor do I think that using one just to log NM on one's own caches would be an issue, either.  To my knowledge, where one gets in trouble with a sock puppet is when one employs it to deliberately conceal one's identity

 

But my knowledge here runs a little thin.  Maybe @Captain Clorox can help us out.

 

edit: herp, apparently I could have read through some of my old posts before sending up the Sock Signal.

Edited by hzoi
Link to comment

We haven't heard from Captain Clorox in a long time.  I am guessing that he is busy sanitizing surfaces to help in the fight against COVID-19.

 

So, I will answer instead.  There is a difference between a "Sock Puppet" and an "Alternate Account."  The statements above by @thebruce0 and @hzoi are accurate.  To avoid doubt, an Alternate Account can state its purpose on the profile page, and can disclose its true owner.  If an Alternate Account is used to hide caches (like a group of three friends setting out a power trail), the identities of the true owners should be disclosed to the Reviewer privately during the cache review process.  If an Alternate Account is used to target or communicate with other geocachers in a negative way, or is used to support the views of the true owner, then it crosses the line and becomes a Sock Puppet.

  • Upvote 2
  • Helpful 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...