Jump to content

Needs Archived Log


Find_the_Cache

Recommended Posts

Not understanding this new logging format.

 

Trying to post a "needs archived" log on a cache but it isn't posting that it needs archived??

It is forcing me to chose Found/Didn't Find or Note. So I'm choosing Write Note and then choosing Needs Maintenance - Cache should be archived but it's just posting a note log??

 

What am I missing?

Link to comment

You have discovered "the new logging experience" which eliminates the options to log a NM or an NA by changing those a a note. I guess the goal is to make it easier for the CO to ignore problems with the cache. In the upper right hand corner you should see an "Opt Out" option, click on that and the page will revert to the old system which still functions for now.

edexter

Link to comment

In the upper right hand corner you should see an "Opt Out" option, click on that and the page will revert to the old system which still functions for now.

FYI - The 'Opt Out' option is not available when logging from the Drafts (field notes) page. It's only available when logging from the individual cache page.

Link to comment

Same for me yesterday - the new workflow/approach is less effective & less efficient from the prior approach.

This afternoon I went thru a few DNF logs of mine that also had DNFs by other cachers before/after me. Some caches are DNFed for a couple months old to 2 years old and all have multiple DNFs. Using the new logging page really is a sub-optimal experience. I need to write a note to select that the cache needs maintenance and either put "See NM log" or put the description in the note with the NM log having the canned text of "Cache might be missing" or whatever "Other" canned text is written. 2 logs needed to accomplish 1 NM and it doesn't even provide the same info in the NM log.

 

So I opted out and did it the "old fashioned" way by writing a NM log with descriptive text. The old logging approach was functional AND efficient.

 

What's the advantage of the new log approach?

Link to comment

Same for me yesterday - the new workflow/approach is less effective & less efficient from the prior approach.

This afternoon I went thru a few DNF logs of mine that also had DNFs by other cachers before/after me. Some caches are DNFed for a couple months old to 2 years old and all have multiple DNFs. Using the new logging page really is a sub-optimal experience. I need to write a note to select that the cache needs maintenance and either put "See NM log" or put the description in the note with the NM log having the canned text of "Cache might be missing" or whatever "Other" canned text is written. 2 logs needed to accomplish 1 NM and it doesn't even provide the same info in the NM log.

 

So I opted out and did it the "old fashioned" way by writing a NM log with descriptive text. The old logging approach was functional AND efficient.

 

What's the advantage of the new log approach?

 

I haven't had the need to file an needs archived log but i did go through the steps needed to try and log one. Not surprisingly, it looks like this useful and needed functionality has been taken away. There was the opt out button but really, it's plain silly to have to use it to do normal everyday caching business. I'm sure this all has to do with the focus on phone usage but even so, it still doesn't make sense.

:blink:

Link to comment

I mean, if you're posting a "NA" log then you'd still have either found the cache or you wouldn't have so I'm not sure what the problem with selecting the correct option is. The CO/reviewer would still get the notification anyway.

My NA logs are almost never associated with an attempt to look for the cache. The whole point of an NA log is that there's no point for the cache to be listed anymore, barring a last minute fix. If I don't think there's any reason for the cache to be listed, why would I think there's any reason to go look for it?

 

Forcing NM reports to be attached to another kind of log is misguided, but at least there's a logical argument for it. It's completely illogical for NAs. (Well, illogical from a functional point of view: I think the main reason they've done this is so the NM and NA choices aren't "cluttering up" the list in the log type dropdown. I don't think that's a good reason, but I concede that it's a logical argument.)

Link to comment

Is there any real good reason that we now need 2-3-4 extra clicks to log an NA?

 

Why can't you just add it to the log types, rather than make us jump through various hoops?

 

And while you're at it, please lose that "A geocacher reported" nonsense. I wanna be able to write what I thing is the issue without having to edit my log.

Link to comment

Is there any real good reason that we now need 2-3-4 extra clicks to log an NA?

 

Why can't you just add it to the log types, rather than make us jump through various hoops?

 

And while you're at it, please lose that "A geocacher reported" nonsense. I wanna be able to write what I thing is the issue without having to edit my log.

It's a bit misleading to say that a NA needs as many as 4 extra clicks.

This week I logged an NA on a cache that I had logged NM some time ago. Nothing had been done by the CO so all I needed to do was a WN explaining the reason for the NA then click the NA within the WN log. All done.

Edited by colleda
Link to comment

Is there any real good reason that we now need 2-3-4 extra clicks to log an NA?

 

Why can't you just add it to the log types, rather than make us jump through various hoops?

 

And while you're at it, please lose that "A geocacher reported" nonsense. I wanna be able to write what I thing is the issue without having to edit my log.

It's a bit misleading to say that a NA needs as many as 4 extra clicks.

This week I logged an NA on a cache that I had logged NM some time ago. Nothing had been done by the CO so all I needed to do was a WN explaining the reason for the NA then click the NA within the WN log. All done.

Of course, the Reviewer will have to go through more clicks to determine whether it's an issue they need to address ASAP or not.

With the old method, the Reviewer would see the reason for the NA in the notification they receive for the NA log.

With the new method, the Reviewer won't see the reason for the NA until they open the cache page and find the WN/Found/DNF log that is from the same cacher that logged the NA. In the case where NA is attached to a Find/DNF, then it's possible the Find/DNF was several days ago and then it's even more work to find the corresponding Find/DNF log that explains the reason for the NA log. NA/NM logs receive the date they were submitted, which is good, even though the corresponding WN/Found/DNF log can be backdated.

Link to comment

Is there any real good reason that we now need 2-3-4 extra clicks to log an NA?

 

Why can't you just add it to the log types, rather than make us jump through various hoops?

 

And while you're at it, please lose that "A geocacher reported" nonsense. I wanna be able to write what I thing is the issue without having to edit my log.

It's a bit misleading to say that a NA needs as many as 4 extra clicks.

This week I logged an NA on a cache that I had logged NM some time ago. Nothing had been done by the CO so all I needed to do was a WN explaining the reason for the NA then click the NA within the WN log. All done.

Of course, the Reviewer will have to go through more clicks to determine whether it's an issue they need to address ASAP or not.

With the old method, the Reviewer would see the reason for the NA in the notification they receive for the NA log.

With the new method, the Reviewer won't see the reason for the NA until they open the cache page and find the WN/Found/DNF log that is from the same cacher that logged the NA. In the case where NA is attached to a Find/DNF, then it's possible the Find/DNF was several days ago and then it's even more work to find the corresponding Find/DNF log that explains the reason for the NA log. NA/NM logs receive the date they were submitted, which is good, even though the corresponding WN/Found/DNF log can be backdated.

I would assume that the reviewer would go to the cache page anyway and check the history of logs and would not take any action without doing so. A reviewer could confirm this and comment whether the new logging system for NAs is causing more 'work' for them.

Link to comment

I mean, if you're posting a "NA" log then you'd still have either found the cache or you wouldn't have so I'm not sure what the problem with selecting the correct option is. The CO/reviewer would still get the notification anyway.

My NA logs are almost never associated with an attempt to look for the cache. The whole point of an NA log is that there's no point for the cache to be listed anymore, barring a last minute fix. If I don't think there's any reason for the cache to be listed, why would I think there's any reason to go look for it?

To confirm that it's not there or that it's in such a state of disrepair as to warrant removal or replacement? I thought that was basic GS policy, if not courtesy, just like it is with DNFs or NMs.

 

But if there is a string of NM logs then I can see your point, that you probably wouldn't need to go searching.

Link to comment

Is there any real good reason that we now need 2-3-4 extra clicks to log an NA?

 

Why can't you just add it to the log types, rather than make us jump through various hoops?

 

And while you're at it, please lose that "A geocacher reported" nonsense. I wanna be able to write what I thing is the issue without having to edit my log.

It's a bit misleading to say that a NA needs as many as 4 extra clicks.

This week I logged an NA on a cache that I had logged NM some time ago. Nothing had been done by the CO so all I needed to do was a WN explaining the reason for the NA then click the NA within the WN log. All done.

Of course, the Reviewer will have to go through more clicks to determine whether it's an issue they need to address ASAP or not.

With the old method, the Reviewer would see the reason for the NA in the notification they receive for the NA log.

With the new method, the Reviewer won't see the reason for the NA until they open the cache page and find the WN/Found/DNF log that is from the same cacher that logged the NA. In the case where NA is attached to a Find/DNF, then it's possible the Find/DNF was several days ago and then it's even more work to find the corresponding Find/DNF log that explains the reason for the NA log. NA/NM logs receive the date they were submitted, which is good, even though the corresponding WN/Found/DNF log can be backdated.

I would assume that the reviewer would go to the cache page anyway and check the history of logs and would not take any action without doing so. A reviewer could confirm this and comment whether the new logging system for NAs is causing more 'work' for them.

As mentioned in my post "whether it's an issue they need to address ASAP or not". In cases of landowner or extremely dangerous conditions (eg, homeowner came out of their house with a gun because cache was on his property) then the Reviewer would see that emergent issue with the initial notification. Rather than getting a few NA logs and having to go through each one to find the log that has the NA reasoning, if there is one, to notice that one of those needs to be dealt with immediately.

 

If all NA logs were just "the CO hasn't fixed it yet", then sure, no need to save time by having the details in the NA log - just scroll through every cache's history of logs. But my post was specifically about highlighting emergent issues to aid in prioritizing NA requests.

 

The point being, since Reviewers are alerted to NA's, then at least let the canned text be editable while logging - rather than having to search for the corresponding WN/Found/DNF log. Having a separate NA log incentivizes the logger to insert details in the NA log. See the logging of NM/NA in the official app as an example.

 

Hopefully, a Reviewer will provide some insight into this.

Link to comment

My NA logs are almost never associated with an attempt to look for the cache. The whole point of an NA log is that there's no point for the cache to be listed anymore, barring a last minute fix. If I don't think there's any reason for the cache to be listed, why would I think there's any reason to go look for it?

To confirm that it's not there or that it's in such a state of disrepair as to warrant removal or replacement? I thought that was basic GS policy, if not courtesy, just like it is with DNFs or NMs.

I don't know if there's a GS policy to that effect, but if so, it's wrong. I don't need to confirm whether it's there or the state of its disrepair. I'm almost always posting the NA specifically because all that's spelled out in the log already. There's no reason for me to doubt what someone else has reported.

 

And that's just considering the logical reasons for filing an NA. When you stop to think about it, your posited GS policy would mean that to get NAs posted, you have to meet two contradictory conditions: the cache is so worthless that there's no reason to leave it on the books causing people to go to GZ, yet at the same time depending on someone going to GZ in order to confirm the situation. No one would bother, so NAs would never get filed.

 

But if there is a string of NM logs then I can see your point, that you probably wouldn't need to go searching.

If there are multiple NMs for the same issue, normally that means someone doesn't understand NMs. If an NM has been posted, and nothing's done about it, then an NA follows, not another NM repeating what's already been said.

Link to comment

And that's just considering the logical reasons for filing an NA. When you stop to think about it, your posited GS policy would mean that to get NAs posted, you have to meet two contradictory conditions: the cache is so worthless that there's no reason to leave it on the books causing people to go to GZ, yet at the same time depending on someone going to GZ in order to confirm the situation. No one would bother, so NAs would never get filed.

I don't see it as contradictory; rather you're confirming the cache isn't worth seeing or is non-existent so no one after you will go there.

Edited by Furrhan
Link to comment

It always baffles me why people always try to fix things that aren't broken.

 

They are called Meddlers.

And we'd still be driving T Fords.

There is a difference between meddling with something that works and making something new. Henry Ford came up with something new, the mass production line. He did not meddle with how the car worked.

 

You need a better analogy.

Link to comment

It always baffles me why people always try to fix things that aren't broken.

 

They are called Meddlers.

And we'd still be driving T Fords.

There is a difference between meddling with something that works and making something new. Henry Ford came up with something new, the mass production line. He did not meddle with how the car worked.

 

You need a better analogy.

No, I think his analogy's fine. The implication is that if no one tinkered with the technology, whether it needed tinkering or not, we'd all still be using hundred year old car designs.

Link to comment

I have changed my opinion on the new logging scheme. I was concerned that by not offering a choice to log an NM it would discourage doing so, but what I have noticed is that folks are making use of the Needs Maintenance button when they log and that it posts a very bland "This geocacher reports this cache needs maintenance" . There is also a choice to log an NA log as one of options. Having recently been "yelled at and called names" by a CO for posting an NA when I spelled out why I was posting one (no finds in 9 months, 6 consecutive dnfs, no CO response to an NM log posted three months ago) I'm thinking maybe bland is better. Just a suggestion to all you busy COs out there: the thing to do when you get an NM or NA log is to respond to it. Takes 10 seconds, lets folks know you care about the cache and their experience of it. Being too busy to do maintenance at times is completely understandable: ignoring NM and NA logs, not so much. Post a note indicating when you might check on it, or why you think it's just fine, or temporarily disable it if it's going to be months before you can go. Heck, maybe even ask for help. You never know who might assist you. Communication...

Edited by edexter
Link to comment

I have changed my opinion on the new logging scheme. I was concerned that by not offering a choice to log an NM it would discourage doing so, but what I have noticed is that folks are making use of the Needs Maintenance button when they log and that it posts a very bland "This geocacher reports this cache needs maintenance" . There is also a choice to log an NA log as one of options. Having recently been "yelled at and called names" by a CO for posting an NA when I spelled out why I was posting one (no finds in 9 months, 6 consecutive dnfs, no CO response to an NM log posted three months ago) I'm thinking maybe bland is better. Just a suggestion to all you busy COs out there: the thing to do when you get an NM or NA log is to respond to it. Takes 10 seconds, lets folks know you care about the cache and their experience of it. Being too busy to do maintenance at times is completely understandable: ignoring NM and NA logs, not so much. Post a note indicating when you might check on it, or why you think it's just fine, or temporarily disable it if it's going to be months before you can go. Heck, maybe even ask for help. You never know who might assist you. Communication...

Communication indeed, but as a CO, getting an NM that just says "This geocacher reports this cache needs maintenance" isn't much help, particularly if it takes a considerable amount of time and/or effort to get to GZ. I'd really like to know what the problem is before making the trek out there. Surely there are better ways of addressing the problem of COs "yelling and calling names" than making NM and NA logs dysfunctional.

Link to comment

One would hope so, but...

As a CO, what I typically do if I get a log that suggests a problem but doesn't contain enough detail is contact the cacher and ask for more information. There are a certain percentage of CO's who react to an NM or NA log with defensive anger and resentment and there's no cure for that, but I think the blandness of the log might encourage more folks to "click the button" so the NM log get posted in the first place. We'll see.

From my perspective, the more information I have about a problem, the better, and I agree with your point that "this cache needs maintenance" doesn't provide enough. My perspective, which appears similar to yours, is that of a CO who wants to know if there is a real problem so I can go fix it. Unfortunately, based on what actually happens in the field, this is a minority view. The statistical reality is that the majority of NM logs eventually result in the cache being archived without any response from the CO. The odds of an NM log being ignored or objected to by the CO are much higher than the CO responding with a "Thanks, I'll check it out..."

Edited by edexter
Link to comment

I went back and left a note to add a "needs maintenance" tag on a cache after I forgot to tag it as such when logging. Language then appeared on the logging page asking me to provide specific details in order to let the cache owner what was wrong with the cache. I don't remember seeing this when the "new logging experience" first rolled out, so this would appear to be geared to addressing the concerns raised here and elsewhere.

Link to comment

I went back and left a note to add a "needs maintenance" tag on a cache after I forgot to tag it as such when logging. Language then appeared on the logging page asking me to provide specific details in order to let the cache owner what was wrong with the cache. I don't remember seeing this when the "new logging experience" first rolled out, so this would appear to be geared to addressing the concerns raised here and elsewhere.

You surmise correctly. :)

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...