New NM/NA system - can I still filter out caches with NMs?

[+dprovan]

Significant or not, there's still an advantage to not having to go back and edit a separate log, possibly separated by days if what I'm hearing is correct. One visit, one date, one log with two parts.

I agree that having to go back to edit the NM log is dumb. But the original process allowed you to enter precisely the log you wanted in the first place, too, so I see the current situation as more than halfway away from there and heading in the wrong direction.

 

I see no advantage to combining the two different logs into a single entity, but go ahead and argue for that completely separate new feature on its own thread. To me, it's yet another idea that only makes sense if you take the new messed up approach as a given and are trying to put lipstick on that pig.

[+J Grouchy]

To me, it's yet another idea that only makes sense if you take the new messed up approach as a given and are trying to put lipstick on that pig.

 

You're assuming that the new system IS a pig. Honestly, I've seen several requests for integrating the NM/NA log as part of a found/DNF/note...so you are merely complaining about something that you personally find objectionable for some reason. Me, I like streamlining stuff. Reducing the need for additional work, additional emails, more unnecessary crap to deal with that contributes (even if in a small way) to sucking joy from an otherwise pleasant pastime.

[+Manville Possum]

But there are a bunch of caches out there in crappy condition. And many novice cachers will just shrug and let them be.

 

So if we don "fix" caches on the fly for CO's we are just novice cachers by letting them be?

 

I'm not in the habit of being a crappy cache enabler and fixin' junk the the CO should take care of, and posting a NM is not letting a cache be, it alerts the owner to take care of their geocache listing.

 

A novice (generalization) will find a cache in crappy condition and log only the find. Someone has to fix the problem. If the CO doesn't, and I can replace a ripped baggy or broken container, or full log, why wouldn't I? Something about "doing a good turn...". Karma... whatever word you want to put...

 

 

I use the word "crappy cache enabler" for people that prop up old junk that the CO neglects. As a cache owner, I want to be the person that maintains my caches, not the general caching public. They are my geocaches and I agreed to maintain them when I asked that they be published to this listing service.

[+WearyTraveler]

Spot on, grouchy. That was the sort of unified NM flag implementation I was envisioning as well.

 

YES! That's a great log! Found and the NM in one post...

[+dprovan]

Honestly, I've seen several requests for integrating the NM/NA log as part of a found/DNF/note...so you are merely complaining about something that you personally find objectionable for some reason.

Not "for some reason". For reasons I've explained at length. Yes, people keep requesting it because they imagine it will be spiffier, but look at it! It turns out to be no easier to use than the old approach.

 

Me, I like streamlining stuff. Reducing the need for additional work, additional emails, more unnecessary crap to deal with that contributes (even if in a small way) to sucking joy from an otherwise pleasant pastime.

That's the point: this isn't streamlined. By the time it does everything you want, it's even more complicated than the original feature, and in the meantime you've lost the advantages of a separate log that I've tried to explain. Just the fact that you can't file an NM or an NA without attaching it to some other log that you might have no earthly reason to file should be enough to reconsider whether this is really the way to go.

[+WearyTraveler]

If you think this thread is "interesting" you should wander over to the 2 most recent threads under release notes. There are some interesting comments about the new found log and he integrated NM etc...

 

Not a lot of love there...

Edited May 2, 2017 by WearyTraveler

[+noncentric]

Halfway there...as in, two parts to one log. Something like this:

 

 

Significant or not, there's still an advantage to not having to go back and edit a separate log, possibly separated by days if what I'm hearing is correct. One visit, one date, one log with two parts.

 

Spot on, grouchy. That was the sort of unified NM flag implementation I was envisioning as well.

YES! That's a great log! Found and the NM in one post...

 

I understand that you 3 think this solution is great. Have you considered the following:

 

(1) NM logs have the date they were submitted/posted, which may be separate from the date of their associated Found/DNF log. If J Grouchy's idea was implemented, then how would the two separate dates be displayed.*

-- Here and here are 2 examples where I logged NM's separately, because I want the NM date to be immediate and I probably won't get around to logging the associated finds for a while. Other cachers should be able to see the issues with these caches without having to wait for me to catch up with my Drafts.

 

(2) Would a CO still receive 2 email notifications, one for the find and another for the NM?

-- If the CO receives only 1 email, then it may take them longer to identify caches with issues because they'd have to read through all of their found logs, rather than benefiting from the current system that lets them surface the 'needs maintenance' emails via email filters.

-- If the CO receives 2 emails, then they'd have to go find the Found log to (hopefully) find details about the maintenance issue. Finding that separate email would be more time-consuming than the current system that encourages putting maintenance issues within the NM log.

 

(3) How would GPSr's and/or geocaching apps display a "two parts to one log" log entry?

-- Does the development time (by GPSr manufacturers and app devs) required to accommodate a presentation that J Grouchy promotes be worthwhile, when the existing system of 2 separate log entries is already accommodated?

-- Would cache finders that are scrolling through a cache's history be able to 'see' the NM log as easily if it is a subtype of another log?

 

(4) More importantly, consider the database needs behind a "two parts to one log" system. Currently, each log entry (Found, DNF, WN, NM) is assigned a unique logid. Including two parts within a single displayed log would requiring restructuring the database to.

 

I'm sorry, but I just don't see how a "two parts in one log" presentation is better than the current "two parts in two logs" system. Either for the cache logger, the CO, or other cache finders trying to glean info about the cache.

 

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

*It might be said that two dates aren't needed. Keystone has already given one example of why NM logs (among others) cannot be backdated.

 

My own example would be if someone visited my cache 3 weeks ago and found a full log and they're logging a find today, then I don't want their "log is full" NM log to have a date of mid-April. I would get the NM notification in my email today, because today is when the NM was submitted with the Found log. I might replace the logsheet tomorrow and post my OM tomorrow, but someone looking at the cache page would see that I replaced the logsheet 3 weeks after the NM log. Backdating NM logs can grossly misrepresent a CO's responsiveness to maintenance issues.

[+noncentric]

Honestly, I've seen several requests for integrating the NM/NA log as part of a found/DNF/note...so you are merely complaining about something that you personally find objectionable for some reason.

Not "for some reason". For reasons I've explained at length. Yes, people keep requesting it because they imagine it will be spiffier, but look at it! It turns out to be no easier to use than the old approach.

My concern is that the full effects of such requests are not considered with a view to the entire workflow, including the backend database requirements necessary to effect such requests. Not just this 'integrated log' request, but also other requests that have been introduced in these forums. Some things sound simple, but are complex to implement.

 

Me, I like streamlining stuff. Reducing the need for additional work, additional emails, more unnecessary crap to deal with that contributes (even if in a small way) to sucking joy from an otherwise pleasant pastime.

That's the point: this isn't streamlined. By the time it does everything you want, it's even more complicated than the original feature, and in the meantime you've lost the advantages of a separate log that I've tried to explain. Just the fact that you can't file an NM or an NA without attaching it to some other log that you might have no earthly reason to file should be enough to reconsider whether this is really the way to go.

Yep, I don't see how the new system is more streamlined. There really needs to be a way of adding details for why an NM or NA is being logged on a cache.

-- Reviewers do not see the details of NA logs within their email notification. Instead, they have to go to the cache itself and find the Find/DNF/WN log submitted by the same cacher that submitted the NA log in order to discover what the issue is. My assumption is that if a Reviewer is emailed an NA notification saying 'the landowner carries a shotgun and doesn't want anyone coming onto his land looking for this cache' then the Reviewer might immediately get online (even on a phone browser) to disable/archive the cache. Something they can do while having dinner or while out caching. With the new system, a Reviewer might miss such an 'urgent' NA request because they'd have to open every cache and search for the reason behind every canned NA response. If they're busy with life, then they may not see the landowner issues until much later. Not sure how that is more streamlined.

-- If cachers want to add details to their NM/NA logs, then it takes many more steps in the new system. ChileHead has noted the necessary steps in post #45. He noted 14 steps, whereas the 'old' logging experience requires only 4: Log a visit, select NM, enter your text to describe the issue, submit it. Ten additional steps doesn't seem more efficient to me. Of course, cachers don't have to edit their NM to add details about the maintenance issues or they could mention the maintenance issues in their found/dnf log. In that case, their NM would still require 2 steps (click on needs maintenance, click on canned issue). Saving 2 steps, with a resulting product that's inferior to a 4-step process, doesn't pass a cost-benefit test for me.

 

This isn't an issue of streamlining every found log or even every DNF log. The canned response is supposedly streamlining NM/NA logs that are already infrequent. It may seem to streamline the process for cachers logging the NM/NA, but we should also consider whether the new logging process streamlines things for CO's and Reviewers.

[+thebruce0]

(1) NM logs have the date they were submitted/posted, which may be separate from the date of their associated Found/DNF log. If J Grouchy's idea was implemented, then how would the two separate dates be displayed.*

-- Here and here are 2 examples where I logged NM's separately, because I want the NM date to be immediate and I probably won't get around to logging the associated finds for a while. Other cachers should be able to see the issues with these caches without having to wait for me to catch up with my Drafts.

I don't think the NM should only be restricted to a subset of another log type. It should still be postable as an independent log.

 

(2) Would a CO still receive 2 email notifications, one for the find and another for the NM?

-- If the CO receives only 1 email, then it may take them longer to identify caches with issues because they'd have to read through all of their found logs, rather than benefiting from the current system that lets them surface the 'needs maintenance' emails via email filters.

-- If the CO receives 2 emails, then they'd have to go find the Found log to (hopefully) find details about the maintenance issue. Finding that separate email would be more time-consuming than the current system that encourages putting maintenance issues within the NM log.

No the notification for the email flagged with NM would contain everything pertaining to that entry, including the appended NM info. Main properties (like subject) can even identify NM flags for easy filtering.

 

(3) How would GPSr's and/or geocaching apps display a "two parts to one log" log entry?

-- Does the development time (by GPSr manufacturers and app devs) required to accommodate a presentation that J Grouchy promotes be worthwhile, when the existing system of 2 separate log entries is already accommodated?

-- Would cache finders that are scrolling through a cache's history be able to 'see' the NM log as easily if it is a subtype of another log?

That's more like it

As a web dev, this is a good design question. I could theorize a number of possible ways to go about handling "sub" logs, as it were; the web display can be different than the raw data. At worst, the logs could still come through separately for backwards compatibility, but any resource knowing that the two logs are "tied" could display them together. At other worst, the API version would be bumped a bit since if as a single log there'd need to be a new attribute or flag stating whether NM is flagged; of course, for the independent NM log this flag would also be on. Resources wouldn't look for NM logs, they'd look for NM flags on any logs. Who knows. Various methods could handle the functionality.

 

My own example would be if someone visited my cache 3 weeks ago and found a full log and they're logging a find today, then I don't want their "log is full" NM log to have a date of mid-April. I would get the NM notification in my email today, because today is when the NM was submitted with the Found log. I might replace the logsheet tomorrow and post my OM tomorrow, but someone looking at the cache page would see that I replaced the logsheet 3 weeks after the NM log. Backdating NM logs can grossly misrepresent a CO's responsiveness to maintenance issues.

Extend it as such... Visitor finds it 3 weeks ago, and with a wet log. They log it today as found, after others have also reported the wet log, and after you've already maintained it. Their 'double log' is flagged as NM, but there is already posted a followup OM - thus their prior NM (attached to their 3 week old find) is moot. Currently, it would be posted as a new NM as of today, and you'd have to check it again (even if only to remove the unnecessary NM status).

 

We could come up with use cases either way - and that's great testing; what works and what doesn't, and how do we address them, if we do at all? I benefits and drawbacks to both systems, which is why I'm not specifically advocating that something should change in this aspect, only that that's how I'd envision the system to work

[+frinklabs]

[FEATURE] Cache maintenance "stars"

 

Then you could filter out degrees of questionable caches.

[+hzoi]

[FEATURE] Cache maintenance "stars"

 

Then you could filter out degrees of questionable caches.

A solution in search of a problem.

[+NanCycle]

And on a related note, Community Volunteer Reviewers still learn about "Needs Archived" requests just like before. (The content may not be as helpful, however. Remember - after the automated logs are generated, the log owner can go back into them and edit the logs to expand upon the "canned" content.)

Unfortunately, the CO and anyone watching the cache will see only the "canned" message in the email notification. Assuming the person who logged the issue bothers to go back and edited the "canned" message in the first place.

If the person knows how to go back and edit the canned message, and if the person thinks about going back to edit the canned message. After they get past those two blocks, you get to "bothers to go back".

 

By the way, you mention the CO and anyone watching, but I assume the notification the reviewers get will also be that pre-edit message.

I can see how you would reasonably make that assumption. But, I assure you, that is not how the system works. When I learn of the "Needs Archived" log, I will be reading its current text, not the original (canned) text. Using my daughter's account and one of the caches owned by my player account, I just tested it to be certain.

 

Like you said, though, I worry whether people will bother to edit the canned text. It will take me more time to decide how to act on requests when fewer details are given.

 

As we're in testing mode, I wrote a note for GCM2FW. I chose "Other" as the explanation of the NM.

 

I deleted my logs as I posted the NM without having been anywhere near Pennsylvania.

[+Manville Possum]

I deleted my logs as I posted the NM without having been anywhere near Pennsylvania.

 

I'm sure that volunteer reviewers deal with actions like from users in several States away by holding their noses.

[+dprovan]

My concern is that the full effects of such requests are not considered with a view to the entire workflow, including the backend database requirements necessary to effect such requests. Not just this 'integrated log' request, but also other requests that have been introduced in these forums. Some things sound simple, but are complex to implement.

I know from experience that your concerns about the implementation are likely valid, but I find that only of secondary interest, only in the sense of realizing how much time someone might waste implementing this change only for us to realize that not only is it not an improvement, it makes things worse from all angles. All because some people can't understand the difference between logging a find and reporting a problem, so they think it makes sense to mush them together.

[+noncentric]

(1) NM logs have the date they were submitted/posted, which may be separate from the date of their associated Found/DNF log. If J Grouchy's idea was implemented, then how would the two separate dates be displayed.*

-- Here and here are 2 examples where I logged NM's separately, because I want the NM date to be immediate and I probably won't get around to logging the associated finds for a while. Other cachers should be able to see the issues with these caches without having to wait for me to catch up with my Drafts.

I don't think the NM should only be restricted to a subset of another log type. It should still be postable as an independent log.

Good. We agree that NM's should be available as independent logs. Unfortunately, the 'new logging experience' requires a Found/DNF/WN log be submitted in order to flag a cache as NM/NA.

 

(2) Would a CO still receive 2 email notifications, one for the find and another for the NM?

-- If the CO receives only 1 email, then it may take them longer to identify caches with issues because they'd have to read through all of their found logs, rather than benefiting from the current system that lets them surface the 'needs maintenance' emails via email filters.

-- If the CO receives 2 emails, then they'd have to go find the Found log to (hopefully) find details about the maintenance issue. Finding that separate email would be more time-consuming than the current system that encourages putting maintenance issues within the NM log.

No the notification for the email flagged with NM would contain everything pertaining to that entry, including the appended NM info. Main properties (like subject) can even identify NM flags for easy filtering.

Okay, so CO's would receive 1 less email for each NM log they receive. I wonder how many emails that really saves, compared to the effort required to implement such changes.

 

(3) How would GPSr's and/or geocaching apps display a "two parts to one log" log entry?

-- Does the development time (by GPSr manufacturers and app devs) required to accommodate a presentation that J Grouchy promotes be worthwhile, when the existing system of 2 separate log entries is already accommodated?

-- Would cache finders that are scrolling through a cache's history be able to 'see' the NM log as easily if it is a subtype of another log?

That's more like it

As a web dev, this is a good design question. I could theorize a number of possible ways to go about handling "sub" logs, as it were; the web display can be different than the raw data. At worst, the logs could still come through separately for backwards compatibility, but any resource knowing that the two logs are "tied" could display them together. At other worst, the API version would be bumped a bit since if as a single log there'd need to be a new attribute or flag stating whether NM is flagged; of course, for the independent NM log this flag would also be on. Resources wouldn't look for NM logs, they'd look for NM flags on any logs. Who knows. Various methods could handle the functionality.

I agree that dev time can be spent accommodating a "two parts to one log" system, or another system that an ingenuous cacher might come up with. My core concern is - why bother when the existing system already works? J Grouchy promoted his presentation as a method that would streamline the process. I'm not convinced that it would be streamlined or better in any other regard. It's a system that would require quite a bit of dev work (see my point #4 quoted post), while the benefit seems questionable.

 

My own example would be if someone visited my cache 3 weeks ago and found a full log and they're logging a find today, then I don't want their "log is full" NM log to have a date of mid-April. I would get the NM notification in my email today, because today is when the NM was submitted with the Found log. I might replace the logsheet tomorrow and post my OM tomorrow, but someone looking at the cache page would see that I replaced the logsheet 3 weeks after the NM log. Backdating NM logs can grossly misrepresent a CO's responsiveness to maintenance issues.

Extend it as such... Visitor finds it 3 weeks ago, and with a wet log. They log it today as found, after others have also reported the wet log, and after you've already maintained it. Their 'double log' is flagged as NM, but there is already posted a followup OM - thus their prior NM (attached to their 3 week old find) is moot. Currently, it would be posted as a new NM as of today, and you'd have to check it again (even if only to remove the unnecessary NM status).

 

We could come up with use cases either way - and that's great testing; what works and what doesn't, and how do we address them, if we do at all? I benefits and drawbacks to both systems, which is why I'm not specifically advocating that something should change in this aspect, only that that's how I'd envision the system to work

Yes, let's say that I fixed the wet log because other cachers reported it (without logging an NM). I go to clean up the cache and post an OM on 5/7. Then a log (dated 4/15) is posted with the NM flag attached. Will the red wrench created by the 4/15 NM be cancelled by the 5/7 OM that was posted after it? Depends on how the system works and is something that would need to be tested.

 

I wonder how often people post NM's that are delayed by an extensive amount of time? I know at least some cachers will look at the cache page to see if a problem wasn't fixed after their visit, before posting a delayed NM log on a cache. Also, the current system asks for confirmation from a cacher before their NM log is submitted - and that confirmation screen shows that their backdated log will be tagged with Today's date, rather than the backdated date they initially selected. So I think it's less likely to have backdated NM's in the 'old' systems vs the 'new' system. Of course, there's no way to 'prove' that.

 

Now, all of this is to say that I don't agree with the "two parts to one log" scenario. I'm not opposed to the concept of streamlining NM/NA logging, but only if that streamlining doesn't degrade the resulting product. I see the 'new logging experience' with its canned maintenance issues as inferior to the 'old' system. I hope that GS will make changes to the experience before removing the option to Opt Out.

[+noncentric]

My concern is that the full effects of such requests are not considered with a view to the entire workflow, including the backend database requirements necessary to effect such requests. Not just this 'integrated log' request, but also other requests that have been introduced in these forums. Some things sound simple, but are complex to implement.

I know from experience that your concerns about the implementation are likely valid, but I find that only of secondary interest, only in the sense of realizing how much time someone might waste implementing this change only for us to realize that not only is it not an improvement, it makes things worse from all angles. All because some people can't understand the difference between logging a find and reporting a problem, so they think it makes sense to mush them together.

Time wasted that could've been spent fixing real, long-standing issues.

[+WearyTraveler]

Halfway there...as in, two parts to one log. Something like this:

 

 

Significant or not, there's still an advantage to not having to go back and edit a separate log, possibly separated by days if what I'm hearing is correct. One visit, one date, one log with two parts.

 

Spot on, grouchy. That was the sort of unified NM flag implementation I was envisioning as well.

YES! That's a great log! Found and the NM in one post...

 

I understand that you 3 think this solution is great. Have you considered the following:

 

(1) NM logs have the date they were submitted/posted, which may be separate from the date of their associated Found/DNF log. If J Grouchy's idea was implemented, then how would the two separate dates be displayed.*

-- Here and here are 2 examples where I logged NM's separately, because I want the NM date to be immediate and I probably won't get around to logging the associated finds for a while. Other cachers should be able to see the issues with these caches without having to wait for me to catch up with my Drafts.

 

(2) Would a CO still receive 2 email notifications, one for the find and another for the NM?

-- If the CO receives only 1 email, then it may take them longer to identify caches with issues because they'd have to read through all of their found logs, rather than benefiting from the current system that lets them surface the 'needs maintenance' emails via email filters.

-- If the CO receives 2 emails, then they'd have to go find the Found log to (hopefully) find details about the maintenance issue. Finding that separate email would be more time-consuming than the current system that encourages putting maintenance issues within the NM log.

 

(3) How would GPSr's and/or geocaching apps display a "two parts to one log" log entry?

-- Does the development time (by GPSr manufacturers and app devs) required to accommodate a presentation that J Grouchy promotes be worthwhile, when the existing system of 2 separate log entries is already accommodated?

-- Would cache finders that are scrolling through a cache's history be able to 'see' the NM log as easily if it is a subtype of another log?

 

(4) More importantly, consider the database needs behind a "two parts to one log" system. Currently, each log entry (Found, DNF, WN, NM) is assigned a unique logid. Including two parts within a single displayed log would requiring restructuring the database to.

 

I'm sorry, but I just don't see how a "two parts in one log" presentation is better than the current "two parts in two logs" system. Either for the cache logger, the CO, or other cache finders trying to glean info about the cache.

 

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

*It might be said that two dates aren't needed. Keystone has already given one example of why NM logs (among others) cannot be backdated.

 

My own example would be if someone visited my cache 3 weeks ago and found a full log and they're logging a find today, then I don't want their "log is full" NM log to have a date of mid-April. I would get the NM notification in my email today, because today is when the NM was submitted with the Found log. I might replace the logsheet tomorrow and post my OM tomorrow, but someone looking at the cache page would see that I replaced the logsheet 3 weeks after the NM log. Backdating NM logs can grossly misrepresent a CO's responsiveness to maintenance issues.

 

I liked the way it was together - not two separate and differently dated logs.

 

As a CO I'd like to see the find and NM together simply because of the way the current NM displays the canned text.

 

As a CO I don't want to get a NM dated today and have to go through pages (ok - my caches aren't that popular....) to find the "found" log and hope that the finder had the wherewithal to include the NM reason in the find log.

 

As a finder, if I'm stuck with the new logging system, I'd like a text block to give the CO information, and if it's a pita to edit the NM log I'd prefer to put it in the found log. So when they're together, that solves my issue with the new logging system.

[+Ruru_nz]

Is there really any need to go back and change the log?

Simply out the details in the found/DNF log eg "Found this blah blah significant story blah blah. Cache needs maintenance - log is full and struggled to find a space to sign"

Assuming that this generates the NM log then the details are right there in the found/DNF log (assuming they are not too far apart, but then it is usually easy to search the page for the other log by the cacher).

 

I do have another issue - puzzle log, DNF's are not unusual, last found last August, DNF recently by a new cacher and generated a NM

New cacher only just in double digits (if that) when DNF logged. Nothing other than trads found. Where they at the right place? Have now moved so cannot check if it is actually there.

My solution was to post a detailed note and hope that someone finds it soon so I can post an owner Maintenance to get rid of the spanner.

 

And on further looking it seems that as my app is not longer supported I'll still be doing 2 separate logs. Other than that, it's a great app.

[+NanCycle]

I deleted my logs as I posted the NM without having been anywhere near Pennsylvania.

 

I'm sure that volunteer reviewers deal with actions like from users in several States away by holding their noses.

 

In this case I'm not concerned about the reviewer, as I mentioned that the log was posted in the spirit of a test of the system, but I didn't want other cachers (such as yourself?) to get the wrong idea. :laughing: (laughing with you)

[+WearyTraveler]

Is there really any need to go back and change the log?

Simply out the details in the found/DNF log eg "Found this blah blah significant story blah blah. Cache needs maintenance - log is full and struggled to find a space to sign"

Assuming that this generates the NM log then the details are right there in the found/DNF log (assuming they are not too far apart, but then it is usually easy to search the page for the other log by the cacher).

 

I do have another issue - puzzle log, DNF's are not unusual, last found last August, DNF recently by a new cacher and generated a NM

New cacher only just in double digits (if that) when DNF logged. Nothing other than trads found. Where they at the right place? Have now moved so cannot check if it is actually there.

My solution was to post a detailed note and hope that someone finds it soon so I can post an owner Maintenance to get rid of the spanner.

 

And on further looking it seems that as my app is not longer supported I'll still be doing 2 separate logs. Other than that, it's a great app.

 

I think that you may have missed my point. Ideally there'd be information in the nM log itself. But in the new system that wound require the logger to actually go back and update the canned message that GS puts in an NM. Sadly, on one of my caches and numerous of the caches on my watch list, that's not the case - and this is by experienced catchers.

With the old system NMs required the logger to at least input some text. This didn't guarantee that the CO got sufficient information to make an informed decision whether or not to actually go to the cache. But a lot of times it did.

 

In the new system - if nothing else, I'd hope that the logger would explain the NM in the find log (since going back to the NM log is more work) but in the cases I've watched (including one of my own) that's not the case.

 

If the finder is forced to enter text in the found log, hopefully they'll mention the soaked log as well. And keeping the 2 logs together makes it easier on the CO.

Edited May 11, 2017 by WearyTraveler

[+redsox_mark]

I think it would be helpful if when someone clicks on "Needs Maintenance" in the new system, as well as multiple choices they are given a message saying "Please include any details of the issue which would help the cache owner in your log".

 

I would do that anyway, but maybe not everyone will.

[+WearyTraveler]

I think it would be helpful if when someone clicks on "Needs Maintenance" in the new system, as well as multiple choices they are given a message saying "Please include any details of the issue which would help the cache owner in your log".

 

I would do that anyway, but maybe not everyone will.

 

That's the point - the new system doesn't give you the option (under the NM sub link) to do that. The only place where text can be input is under the found / not found / note selection.

 

And many that I've seen don't put details in the found text block. If they would , we probably would be arguing about something else in these forums...

[+Manville Possum]

I deleted my logs as I posted the NM without having been anywhere near Pennsylvania.

 

I'm sure that volunteer reviewers deal with actions like from users in several States away by holding their noses.

 

In this case I'm not concerned about the reviewer, as I mentioned that the log was posted in the spirit of a test of the system, but I didn't want other cachers (such as yourself?) to get the wrong idea. :laughing: (laughing with you)

 

I have posted NM's and NA's while on vacation, and seems it took almost a month before the reviewer reacted. We have far too many missing caches locally with stacks of DNF's, so I totally agree that someone needs to do a cleaning sweep. I have seen local reviewers do this once a year or so, but there are too many owner less listings for me to filter. I just search for new listings locally.