Keystone

That's correct. Same correct answer if a Reviewer disables a cache and someone "helps out" by replacing the cache with a throwdown container. Once a Reviewer needs to step in because of owner inactivity, only the cache owner can stop the process. That's why there are so many waiting periods built into the process, as was evident in your example.

I see the cache history differently. A problem was reported to the CO in February and a Reviewer archived the cache in November? That's really generous. Had the "bad neighbor experience" been reported directly to HQ, the cache would've been archived in February. Had I disabled the cache, instead of the friendlier local Reviewer here, the cache would have been archived four weeks after I disabled it. Yes, there may now be unmaintained, unmonitored trash out in the wild. The Reviewer didn't cause that result.

This was a terrific post, @Pleu - thank you. I would like to add that the recently retired method also created a lot of extra work for Reviewers. Imagine sitting down on a Monday morning and looking at a queue of "Needs Archived" logs, most of which contained just the generic language. The Reviewer needs to click through to each log in that queue, to see if any of the requests were urgent ("the landowner threatened me at gunpoint") and which ones weren't urgent ("I can't find the cache, so it must be missing"). And, when looking at the queue of caches with Low Health Scores, Reviewers needed to read not only the specially flagged "Needs Maintenance" log, but also the "Found It" or "DNF" log that told the real story. The new logging flow is much easier for Reviewers as well.

This bug was acknowledged earlier in the thread, and HQ is working to fix it.

It would actually be less work if I didn't need to check for event stacking. For the majority of event caches that meet the guidelines upon first submission, it's an extra manual step.

You should follow the current Release Notes thread, where Geocaching HQ acknowledged this bug and said they're working on a fix. As there's already an active discussion, I'm closing this duplicate thread.

You would benefit from the challenge cache functionality at project-gc.com, especially the list of "Challenges signed (but not yet logged as found)" at the bottom of the challenge cache tab in your profile statistics. Looking at that, I see you have three challenge caches that you can log an online find for, if you previously signed the log in the cache. Yay!

The current bug with "old search" is already being discussed in the current Release Notes thread and in the Geocaching.com Website Bug Reporting forum section. Therefore, I'm closing this thread as having been bumped improvidently.

This may or may not be by design - I honestly can't remember. But, if intentional, it's helpful from a Reviewer perspective. Prior to publication, I will ask questions and request the cache owner to post a new Reviewer Note. A surprising number of cache owners (especially new hiders) will miss that instruction, and simply edit their prior Reviewer Note to answer my question. Since there was no new log to trigger a watchlist notification, I have no idea that they've answered my questions, and the review process is delayed.

Please re-read the instructions in the Opening Post on how to "pin" the date to a date of your choice.

As I said in my post that you quoted, the functionality hasn't changed. "Status" logs have always defaulted to the current date (Owner Attention Requested, Reviewer Attention Requested, Owner Maintenance, Enable Listing, Disable Listing, Archive Listing and Retract Listing).

I moved this thread from the "How do I...?" forum section.

Because this bug has been acknowledged in the Release Notes thread, I am closing this duplicate thread.

Both these hides are a very, very short distance from the owner's home coordinates. Like Johannis10 posted, as a Reviewer I cannot see the exact home coordinates, but just by drawing two lines I can take a very good guess at which house the owner lives in, if their home coords were measured right at home. For privacy purposes, it's not necessary to have home coordinates exactly at your residence. Mine are at the end of the street I live on.

This subject is already being discussed in the current Release Notes thread. I am closing this duplicate thread.

I moved this thread from the "How do I...?" Forum section.

This isn't a bug, and carries forward existing functionality in the old logging flow. Defaulting the date to today prevents abuse (backdating a key action like Owner Attention Needed, Owner Maintenance, Reviewer Attention Requested, Disable, Enable and Archive logs).

I moved this thread from the Official Geocaching apps forum section. You may also wish to engage Cachly's support channels. The developer is typically very responsive.

@bd's, you should post details about your experience in the Release Notes thread linked to by Frau Potter in the post above yours. I've been using the new logging flow for 100+ logs, and I haven't had problems with either the log type "sticking" from my drafts, or in uploading images.

I moved this thread from the General Geocaching Topics forum section.

1. Situations like what you described is a big reason why there's never been an absolute rule to find at least X number of geocaches before hiding one. 2. Yes, what you've described has happened before. After a few times, it's likely that the Reviewer will catch on. When we identify sock puppet accounts, we can ask "what's the real account behind this brand new one?" We can also ask HQ to help with researching accounts. And, if a sock puppet is used in a negative way, the account can be suspended by HQ.

An iPhone 7 is relatively ancient, on an Apple timeline. What operating system are you using? The Wherigo app requires iOS 11.0 or later.

For a ten foot move, you could just tweak the coords manually. For example, if the new spot is 8 feet northeast of the current coordinates, add .001 to the latitude and subtract .001 from the longitude. Not perfect, but close enough for such a small move. Common errors in coordinate conversion range from math errors and formatting errors all the way to mixing up hemispheres (watch for those minus signs). The edit screen and update log screen have not yet been modernized like the initial cache submission screen. They still reflect Degrees/Minutes.Decimal Minutes because that's how handheld GPS units were set up when shipped from the factory.

The advice from @barefootjeff is accurate. The Cache Health Score algorithm is quite automated in nature. We would never see a cache in our action queue if the CO logged a "false" Owner Maintenance. The algorithm cannot distinguish between actual onsite maintenance visits and OM logs that say "I'll get to it," and the algorithm cannot tell whether a particular CO is "friends with the local reviewer." A reviewer who slacks off in dealing with caches that appear on our dashboard WILL hear from the team at HQ that oversees our work. Allegations of favoritism are also subject to scrutiny by Geocaching HQ. For most reviewers, myself included, we are probably MORE strict when decisioning issues coming from personal friends, in order to avoid the appearance of bias or favoritism. Don't count on the Cache Health Score to solve all of the geocaching world's problems. Appropriately logging DNF's, "Owner Attention Requested," and "Reviewer Attention Requested" logs is the first line of defense.

First, you would need to be in the drawing to receive a Virtual Reward cache. To do this you would need to hide a new cache that earns three favorite points prior to the end of 2023. Next, you would need to win a Virtual Reward in the random drawing on January 17, 2024, just before leaving on your cruise. Then you would need to hide a cache that meets the Geocache Hiding Guidelines. One issue is commercialism. Can I freely visit the private island without paying money to NCL, a commercial business? If not, then this is a no-go.