New feature for Owner Maintenance

[+Team OPJim]

Say a cache owner has a cache that is reported missing/needs maintenance. They disable the cache until they can visit it.

 

After visiting the cache and doing the needed maintenance, it will be necessary to post two logs: one for maintenance to get rid of the red monkey wrench, and another to enable the cache.

 

I suggest that the Owner maintenance log have a checkbox that will also enable the cache. This way it can be done with a single log, but the option exists to leave it disabled should the need arise.

[AZcachemeister]

This goes hand-in-hand with the thread to be able to ADD the 'Needs Maintenance' icon when posing a 'Found It'.

 

What is the big deal about posting a second log for a different purpose?

 

If it 'clutters up the page', delete it.

 

Or, go in and edit the attributes to remove the NM attribute after posting the 'Enabled' log.

 

If the clean-up chores are becoming a drag, perhaps there is another problem.

[+T.D.M.22]

unless the cache is missing/destroyed I won't disable it if it need maintenance. If I do, I just disable it. Fix it. Enable it, and owner maintenance. I then delete the disable and enable cache logs.

[+BlueDeuce]

They shouldn't have to necessarily check both options. If you got an owner who does maintenance why not provide it? Lords knows there's enough enabled caches that the NM was never removed.

[+The_Incredibles_]

Good idea. The process is kind of cumbersome the way it is now.

[team tisri]

Say a cache owner has a cache that is reported missing/needs maintenance. They disable the cache until they can visit it.

 

After visiting the cache and doing the needed maintenance, it will be necessary to post two logs: one for maintenance to get rid of the red monkey wrench, and another to enable the cache.

 

I suggest that the Owner maintenance log have a checkbox that will also enable the cache. This way it can be done with a single log, but the option exists to leave it disabled should the need arise.

 

Seems like this is expecting Groundspeak to schedule a development task when the only benefit is reducing a CO's workload from two logs to one. When the log need say nothing more than "It's back, go find it" or some such it's hard to see why this should be a priority.

[+dprovan]

There's certainly a logic to this idea, although it might be more useful in reverse: a check on enable that says maintenance has been done since there's a common problem with COs enabling a disabled cache and thinking that automatically implies they've done maintenance.

 

In a perfect world, I'd rather people recognize and utilize the difference between the two logs even though in practice the enable log doesn't carry additional information very often. This case isn't as clear as the case of the found/need maintenance logs where the two logs can and should carry entirely different information.

[+Team OPJim]

If it 'clutters up the page', delete it.

 

If the clean-up chores are becoming a drag, perhaps there is another problem.

The rationale is simple: the current system wastes time and resources.

Why have two logs when one will do?

Why require 6-8 clicks when 3-4 will do?

Why take up room on the server with two logs (even if one is deleted it is still archived) when one will do?

If the CO is actually willing to check on and do maintenance on their caches rather than ignoring them, why not help them out, rather than requiring a completely useless and unnecessary step?

 

Honestly, I already contacted Groundspeak directly, and the lackey who replied asked me to post it on the forums. I'm not sure why, since the forums seem to generate acrimony disproportionate to the actual importance of the topic. Anyways, I suppose they will let everyone weigh in on their straw poll and then decide based on whatever criteria they use.

[AZcachemeister]

 

Honestly, I already contacted Groundspeak directly, and the lackey who replied asked me to post it on the forums. I'm not sure why, since the forums seem to generate acrimony disproportionate to the actual importance of the topic. Anyways, I suppose they will let everyone weigh in on their straw poll and then decide based on whatever criteria they use.

 

If such a feature is developed, I would use it.

 

However, I don't find myself 'wasting' much time each month posting that extra log. If I did, I would probably consider that there MUST be a problem with my caches, not the process required to enable them and remove the NM attribute.

 

If you are REALLY concerned with server space at Groundspeak, one less photo on your cache page would make room for at least a hundred 'Maintenance completed.' logs!

 

Finally, the lackey telling you to post it in the forums is a nice way for them to say they don't want to hear about it, but maybe someone in here will have something to say.

[+Team OPJim]

If my request has truly been deadletterboxed then there really is no point in posting the idea on the forums. I withdraw my idea

[AZcachemeister]

If my request has truly been deadletterboxed then there really is no point in posting the idea on the forums. I withdraw my idea

 

Oh, it's worth discussing.

 

It's just that past experience has show there is not much chance anything will be done.

 

Occasionally we are all surprised and something DOES get done, like when the bookmark list limit was raised from 40 to 100.

 

On the flip-side, there are the suggestions for features that are over two years old, with hundreds of supporters and a note from a lackey that they are 'working on it', but nothing has materialized at our end.

 

Recently, I needed to look at a CO's bookmark lists to see what caches they were using as a basis for a challenge.

I had to scroll through a large list of favorited caches to get to the actual bookmark lists.

I considered posting a suggestion that the favorited cache list should com AFTER the bookmark lists, but then I realized that was self-serving and perhaps more cachers would rather not scroll through a long list of bookmark lists to get to the favorited caches.

 

So, suggest away!

You never know what might show up in the next site update.

[+Don_J]

If my request has truly been deadletterboxed then there really is no point in posting the idea on the forums. I withdraw my idea

 

In the past, ideas directed to the forum that stimulated discussion actually led to new features being introduced. Now, it's really doubtful. Most of us are now under the impression that TPTB are more interested in giving us features that no one has ever asked for, like changing to grey icons that have no contrast, or making the geocache search faster by limiting what it can actually search for, or streamlining the weekly newsletter by removing all of the useful content.

[+wmpastor]

If it 'clutters up the page', delete it.

 

If the clean-up chores are becoming a drag, perhaps there is another problem.

The rationale is simple: the current system wastes time and resources.

Why have two logs when one will do?

Why require 6-8 clicks when 3-4 will do?

Why take up room on the server with two logs (even if one is deleted it is still archived) when one will do?

If the CO is actually willing to check on and do maintenance on their caches rather than ignoring them, why not help them out, rather than requiring a completely useless and unnecessary step?

 

Honestly, I already contacted Groundspeak directly, and the lackey who replied asked me to post it on the forums. I'm not sure why, since the forums seem to generate acrimony disproportionate to the actual importance of the topic. Anyways, I suppose they will let everyone weigh in on their straw poll and then decide based on whatever criteria they use.

 

Fine insight!

[team tisri]

Anyways, I suppose they will let everyone weigh in on their straw poll and then decide based on whatever criteria they use.

 

Yep, and I'm probably not the only one who wonders whether "whatever criteria they use" means "it's been suggested on the forums, let's ignore it and introduce a new twitface integration instead".

[+Darick]

I came here to suggest this very feature... guess I am not the only one thinking it is a good idea. Obviously not a high priority, but perhaps a simple enough change that makes good sense. Thanks for considering the suggestion, Groundspeak

[+MAntunes]

Recently I had to disable two of my caches because I received the notice that they needed the container replaced.

 

When It was possible to perform the maintenance visit, I did it and when went to enable the cache listings I wondered why I have to make two logs to do it (maintenance + enable).

 

Searched the foruns and ...ok, I found one more feature that it is not priority to GS.

Edited November 16, 2015 by MAntunes

[+J Grouchy]

I think it's a terrific idea and it's something that should have been built-in from the get-go.

[+dprovan]

When It was possible to perform the maintenance visit, I did it and when went to enable the cache listings I wondered why I have to make two logs to do it (maintenance + enable).

You have to do the owner maintenance log to explain what you did to return the cache to readiness. You have to do the enable log to put the cache back into action. I don't see any logical reason for combining them based on duplication or effort. On the other hand, many COs don't realize the a OM doesn't enable a disabled cache, it might be helpful to ask the CO if he wants to enable the cache when he enters an OM.

[+niraD]

There's certainly a logic to this idea, although it might be more useful in reverse: a check on enable that says maintenance has been done since there's a common problem with COs enabling a disabled cache and thinking that automatically implies they've done maintenance.

In a way, this is the inverse of making the Needs Maintenance log a checkbox that can be set when posting some other type of log (e.g., a Find, or a DNF, or a Note). We could get rid of the NM and OM logs, and have the state of the NM attribute toggled with checkboxes that are associated with other logs.

[+dprovan]

There's certainly a logic to this idea, although it might be more useful in reverse: a check on enable that says maintenance has been done since there's a common problem with COs enabling a disabled cache and thinking that automatically implies they've done maintenance.

In a way, this is the inverse of making the Needs Maintenance log a checkbox that can be set when posting some other type of log (e.g., a Find, or a DNF, or a Note). We could get rid of the NM and OM logs, and have the state of the NM attribute toggled with checkboxes that are associated with other logs.

I've always been against combining DNF and NM since I think the two distinct logs force focusing on the two distinct activities of describing the search and describing what's wrong with the cache. The Enable log doesn't often have a similar narrative needed beyond "it's fixed", so I find it less important to keep it independent from OM.

[+noncentric]

There's certainly a logic to this idea, although it might be more useful in reverse: a check on enable that says maintenance has been done since there's a common problem with COs enabling a disabled cache and thinking that automatically implies they've done maintenance.

In a way, this is the inverse of making the Needs Maintenance log a checkbox that can be set when posting some other type of log (e.g., a Find, or a DNF, or a Note). We could get rid of the NM and OM logs, and have the state of the NM attribute toggled with checkboxes that are associated with other logs.

I've always been against combining DNF and NM since I think the two distinct logs force focusing on the two distinct activities of describing the search and describing what's wrong with the cache. The Enable log doesn't often have a similar narrative needed beyond "it's fixed", so I find it less important to keep it independent from OM.

 

There are times when "Enable" (and Disable) are independent of NM and OM logs. I'm thinking of seasonal access or construction as examples.

 

If a cache is hidden in a park that is closed for winter, then the CO would Disable it during the closure and then Enable it afterwards. These actions could be done without the CO visiting the cache. Would this new feature require the Enable to be paired with an OM log, or would Enable/OM logs still be available to be logged individually? I suppose one could argue that enabling the cache after winter deserves a paired OM log, but would that really be correct since the CO might not have visited the cache when enabling?

 

In any case, it doesn't seem like a high priority item. There are plenty of other things the devs at HQ could spend their time on that would benefit more members.