coachstahly

You're under the assumption that the container was an issue from the find before yours. What if they were the ones that improperly closed the container, which allowed the water to get inside? What if a critter found it and chewed a hole in it during that gap in time? What if a muggle found it and left it so that it would fill up with water? What if the container was dry when they found it? There are so many variables that can come into play between finds that I rarely fault the previous cacher for any issues I may come upon while out caching. There are some obvious exceptions and the logs generally support those exceptions (repeated notes of a wet log) but sometimes the find between mine and the previous one result in a change in the cache's status that wasn't previously an issue or one that wasn't an issue at the time because the environment wasn't right for that issue to appear. The fact that I also focus more on non-traditional caches means that there's usually a larger gap in time between finds, making it harder to pinpoint a specific time when something occurred that caused the deterioration of the container and the contents inside. Is the log wet because the container is no longer good or is it wet because the container was closed improperly (decon only snapped shut on 3 of the 4 corners, ammo can closed with something sticking out that ruins the integrity of the rubber gasket on the lid) or is it wet because the log was signed in the rain and stayed wet because the container is still doing its job?

I thought that lab caches and/or ALs couldn't be used as qualifiers for challenge caches. I thought I remembered seeing that somewhere here on the forums. Or has that been amended to allow CO's to make the call regarding their acceptance as qualifiers for challenges? The search function hasn't been very helpful as it's been "searching" for a couple minutes now with no returns. And now I got an error page.

Why are you choosing to single out experienced cachers? Why wouldn't these recommendations be better suited to inexperienced cachers? While I appreciate what you're trying to do, there really isn't any new ground being broken here. You're not the first to offer up recommendations that you believe will make it better for everyone, and you won't be the last. However, trying to get cachers to do things the way you believe they should be done is an exercise in futility. Just look at the replies here that don't fully believe in the recommendations you've provided. They may be close but they're not exactly like what you suggest. Some may be "better" variations while some may be "worse", but with so many cachers with their own manner of caching, stating that your recommendations will make things better for all involved sounds like you think you have it figured out while the rest of us need some help. Below are some small differences I disagree with but there's no way I'm recommending that my way is the "right" way. It's just the way I choose to play. I use TFTC in every cache I log, at the very beginning. I also add more to the log than just that, even if it's just a sentence or two. If the CO hadn't placed this cache, then I wouldn't have had the opportunity to make a find so I make sure to thank the CO, even if it is a crappy cache. That may seem reasonable but it's still not your responsibility. How adjacent are you talking? 50 feet? 100 feet? Log it as found, mention the issue in your found log, file the NM and move on. While I do this for every cache I find, I don't think a date needs to be required for everyone. What does a date on the log really accomplish that you can't verify in the online log? Uh....this doesn't make much sense to me. I can't think of ANY cache descriptions that require (or don't require) finders to put a date (or not put a date) next to your signature. I'm sure there might be a few but generally speaking, it's a moot point. The only requirement Groundspeak has in place to claim a find is whether or not the signature is on the log. The date is noticeably absent from that guideline. While I remove old logs when there's no room for a replacement, I don't discard them until at least a month later. I mention it in my found log, I contact the CO directly (email and message) to let them know that I'm happy to mail it to them, bring it to them (if they're close or I'm in the area), or email them a photo of the log. Of the approximately 125 logs I've removed to replace with a new one, I've heard back from about 5 of the COs who want the log, in some manner described above. The large majority of them don't even reply while a slightly larger number of those who want the log reply to thank me. Those caches with room for a replacement log that doesn't require removing the old logs get a replacement log. If the cache is in terrible shape (the logs are soaking wet, which is why a replacement log is needed), then I file the corresponding NM log.

"No offense, but this makes no sense IMO. It's a stage, that's eventually leading you to a container. I have over two dozen multis not completed due to maintenance, with most now archived (been ill...), and the COs used containers at the stages. The best multis I've done had dog tags for stages, with the coordinates to the next stage on each ( a local trackable "proxy" company used to make them) . Simple, and never needed "maintenance"..." Adding on to what Cerberus replied above, sometimes all you can use at a stage is a micro. I found a really neat structure to use as part of one of my multis as I was exploring the undeveloped part of the park, and the only container size that would work on that structure was a micro. There just wasn't any room anywhere on it for a small. The final is an ammo can. Most of my multis close to home are in city parks or on city maintained rails to trails walkways. Micros are sometimes the only thing I could place that wouldn't be easily discovered by some kids just wandering off the trails and into the unmaintained areas. The D/T ratings for those multis is reflected in the higher D/T ratings. A multi with all small or larger containers would subsequently have a lower D/T rating (per my thoughts about how to rate my caches). I've done quite a few multis over my 10+ years and struggle to remember any multi more than 3 stages long that uses small or larger for each stage. Maybe 5?

I can't really add much to what everyone has said. It just depends. I've given a FP to a mundane cemetery hide on a film can because I met the owner of the land who donated the land to his church to use and got a historical background of the area. I gave some FPs to caches in the Sandusky area recently because of the container and the set up of the cache and how well they were done. I gave another FP to another cemetery cache because the time a small group of us were there, a light snow was falling and it had coated the ground, trees, and limbs with a pristine white blanket. The cache itself wasn't anything special but the serenity and the company made it memorable. There are so many factors that go into awarding a FP for each individual that I don't think you can really say it's just one or two things that will automatically earn a cache a FP. I've found quite a few high FP total caches and while some were nice, they weren't FP worthy to me. That doesn't mean they were "bad" caches. It just means that I didn't enjoy them well enough to award my own FP.

138 hides, 50 of which are archived, meaning 88 are active, over my past 10 years and change of caching. Of those active caches, 18 are adopted. The caches I take care of range in age from 1 year old to 19 years old.

And just like that, I'm seeing it. Had to refresh it a few times.

I can't even get the CO dashboard to load. Well, it appears it has completed its page load but I just get a blank white screen. Tried once again and get the same thing that you posted above.

I'll never ask because it's not my business why you didn't do the final cache in the series.

All 6 caches are within a 1 1/2 square mile area, which includes the final. 3 are within .3 miles of each other and the other two are just over a mile away and about .3 miles apart. The final is within that 1 1/2 mile stretch. I live within 4 miles of them and have no problem keeping them maintained and active.

I have a series of 5 traditionals that lead to a final, which can only be found if you opt to play the game I have set up at each traditional cache. It's not even a hard game, for the most part. Each of the traditional caches has specific game pieces in each container (dominoes, cards, dice, Scrabble tiles, bingo balls) and I've done something to one (domino since it has two numbers on each one) or two pieces in each cache that makes them different from the others and you plug the numbers you get into the corresponding formula that leads you to the final. It's not overly difficult at all but I realized, when putting it out, that many cachers probably wouldn't be interested in going after the final (which is a ? cache), despite the fact that all the caches are within a square mile and a half of each other and are rated as 2/2 or less, with one exception, and a higher rated final cache. I also realized that the fact the final is an unknown cache would automatically preclude quite a few cachers from even looking at the cache page, despite the fact that I created a bookmark list that contains all 6 caches on it, mention the final on every cache page, and mention the final in each cache container note (that says not to take the game pieces and provides a reminder about the final). The fact that a cache is listed as an unknown will automatically limit the number of people who will visit your cache page, thereby decreasing the "reach" you may hope to attain. However, you can be certain that they'll read the cache page once they get there. It (the page or the cache) just won't be visited nearly as many times as a traditional cache would be. I had to redo a couple a few times due to them going MIA but for the most part, they've been in place since 2011 and one redone in 2012. Here are the number of finds for each traditional - 124, 137, 152, 184, 112. Here's how many have chosen to play my game and found the final - 23. I expected far lower numbers for the final so I'm not overly disappointed. That's roughly a 1 in 5 to 1 in 8 ratio, which is about what I expected.

I'd be curious to know how many of these are still active. We had an influx of new players and new hiders in 2020 but I'd say about half of them have already left the game, leaving behind caches that need maintenance (and will never be maintained by the CO) or have already been archived. My numbers aren't nearly as high in my immediate area but they follow the trend described by most people on here, highest from 2012-2015, a tailing off after that and an uptick in hides in 2020, although my area's cache totals barely made it to triple digits from 2012-2015. The larger metropolitan city to the south, however, has larger numbers but follows the same trend as above.

I suggest you ask the CO directly about what changes, if any, they'd be willing for you to make on what used to be their cache (which includes the cache page). If they don't care, then it's free game to change up whatever you want. They may have some specific things they want to remain the same or they may not want you to change anything. Even though they are my caches now, I still don't feel right altering anything too much from what it was like when I adopted all of them. I think it's because they were someone else's "creation" before they were mine. On most of the caches I've adopted, I've managed to keep everything pretty much the same, with a couple exceptions due to muggling and one I returned to the original container and size (it was a decon when I adopted it but the original container was an ammo can). One of the other things we talked about upon adopting it was if they ever got back into geocaching, then they might want it back, including one that was adopted out previously (I'm now the third CO). It's never happened and I don't expect it to, but the understanding we had is still there.

So now you're an advocate for armchair OM logs? You do realize that the portion of the quote from niraD is an explicit reference to specific situations when an automated program sends out false positives. A false positive, by definition, is an incorrect conclusion that the program has made that suggests something might be wrong with the cache when there's nothing actually wrong. I've had at least one email (maybe 2?), a false positive with the cache in question in good shape. Are you telling me that my prior frustration (even though it was minimal, it was still frustrating) was unwarranted and I need to get over it? If the program that thinks there might be an issue with your cache is wrong, then why should the fix be an attitude adjustment of the CO rather than the fixing of the program that got it wrong? It's not an infallible system that guarantees that there's an issue. It makes mistakes, just like cachers can. I hide my caches so I have to do as little maintenance as possible - good containers in locations that aren't apt to be visited by muggles with logs that hopefully will last a long time- not hide them and then think that they will never need maintenance because of the container, the location, and the size of the log. I would rather rely on the logs of those that actually visit the area where the caches are located than an automated program that can't differentiate between DNF logs that show they were actually there and DNF logs that show they never made it to the area where the cache is hidden and that every DNF, regardless of the validity, counts as a negative mark against the score of the cache. I realize that receiving a CHS email isn't that big a deal. For most of my caches, it's an easy thing to head out and visit the cache to verify that everything is OK or verify that there truly is something wrong with the cache. I've not received a CHS email since my last one (I can't even tell you how long ago it was but at least a few years) so it appears that it was tweaked in some manner to address that, at least as it applies to my caches. One of my biggest issues with the CHS is that there's no way for anyone to report a false positive should they get an email that's incorrect. We're able to do something about it if it IS correct (OM log on the cache in question) but nothing to notify those that monitor the algorithm that, in this case, it was wrong. I know the OM will reset the score, clear the "flag", and allow you to post a note saying that the CHS got it wrong, but the goal should be to help make the CHS a more accurate program, not one that sends out emails for caches that are fine and have no way to provide feedback that lets them adjust the parameters to minimize those types of errors. Let's examine this "potential problem" that the CHS sees when a DNF is logged. The CHS seems to view a found log as an affirmation that the cache is in place and awards either a positive bump up in points or doesn't remove any points (which is it? I can't remember). It's not awarding points because it's in good shape, a fun hide, or a neat gadget cache. It's awarding points (or at the very least not removing points) because it was found and therefore proven to be in play (even false found logs). The only real thing we can garner from a DNF causing points to be removed, then, is that the CHS views it as a cache that's not in play, and therefore a deduction from the overall score. While you claim it's not because the CHS sees it as missing, I don't see any other reasons for why the CHS assigns a negative value to a DNF. It can't be because of potential maintenance on a cache that's in bad shape. That would be a found log along with what I hope would be the accompanying NM log (or NA log if appropriate), which falls into its own category within the CHS. What other reason could the CHS have for deducting points for a DNF? You keep saying it's not because it assumes it's missing but I can't recall you offering up any other reasons for why a DNF automatically has a negative point value. What other valid reasons would support a DNF having a negative effect on the health score of a cache? What other valid reasons would support a find having a positive (or a net 0) effect on the health score? It basically boils down to this for the CHS . Find - good ; DNF - bad. I'm using bad/good only as it pertains to what the effect is on the score of a cache, not whether or not the action is good or bad in a moral sense. What's the only thing an automated program can ascertain about these two choices and the subsequent point actions taken when each of these two log types are filed? It will either add (or net 0) points for when it receives a "good" log or subtract points for what it receives a "bad" log to the CHS of an individual cache. It's not programmed to weigh the value of a DNF as to whether or not it MIGHT be missing, at least as far as I know. Those two variables can't take into account the maintenance status of the cache in question. They CAN take into account the D/T rating and make the point removal less impactful for higher D/T caches and more impactful for lower D/T caches when a DNF is logged. However, the CHS still removes points since it sees a DNF as a negative score adjustment and a find as a positive score adjustment (or net 0) since it sees them as "bad" and "good" only. The only assumption for an automatic negative score reduction associated for a DNF is that the CHS assumes a worst case scenario. Rightfully so, the CHS can't act unilaterally, even if it assumes the cache is missing. That's left to the reviewer, if the CO chooses not to act on it first. Also, keep in mind that typically we're talking about accumulated DNFs, not single instances of a DNF being filed and triggering the CHS. I'm sure that happens but it's been quite some time since anyone has posted anything quite like that.

I don't think your previous standards of ownership can be written into an algorithm that tracks the health of a cache. The CHS is automated so I don't see how it could take your prior maintenance into account. However, I do agree that your past can, and probably does, have some influence with your local reviewer regarding maintenance issues that might arise on one's caches, including how a reviewer will choose to deal with your cache should it run afoul of the CHS.

Feel free to send me what you've got. I only have 3 out but happy to help out, if you want someone to give it a once over.

It's listed by default so I guess I should have said I don't purposely create waypoints for stages/zones that are to be visited. I will for trailheads or parking, which will help for maneuvering around.

So there's no bonus cache. It's only the final. By stating that there are cachers not signing the bonus cache, the implication is that there's an additional physical cache they should be finding, on top of the already required physical final stage. You're saying that there's only the final physical cache that they need to find and sign to claim the log. That's not a bonus cache - that's just the final. Their name isn't on the final log, you can delete their find (assuming they claimed the find online). Personally, I don't list a waypoint for the final, hidden or otherwise. It just potentially adds to any confusion, like here. I also don't list waypoints for other stages that they're going to visit. That's all contained within the cartridge so I see no need to add it to the cache page.

Let's see if I've got this right. At the end of playing the Wherigo, the final zone is where "final" is located (which they sign) and then you also direct the player (with coordinates?) to an additional waypoint/cache to help "prove" they completed it?

At which point in time, assuming you did those things correctly, you go out and find a "typical" geocache and get credit for a find on the site. Part of the issue with these bonus caches, at least as I see it, is that the thing you do before being able to go look for it (playing the AL) allows you to claim multiple finds (5 or perhaps more) for things that aren't visible on the standard site and then you get another find once you find the AL bonus. 6 finds for the 1 cache that appears on the map. There are a few on here that claim that we're attempting to spoil everyone else's fun but all we're actually pointing out is the irregularity that exists between ALs and all other cache types. It doesn't sit right with me (or others apparently) but that doesn't mean we want them removed. There's been enough interest in the community that they appear to be popular and enjoyed. Perhaps it's the find count that makes them popular or perhaps it's the newness that makes them popular. Most likely it's a combination of a variety of factors and not just one singular reason. I don't think they're going away anytime soon but the implementation of them just doesn't have the same allure for me that all the other cache types do. Personally, I would prefer they follow one of two paths. 1 - they get integrated into the site as a new cache type and also follow the standard 1 cache, 1 find set up. 2 - If they can't get integrated into the site, they should be put onto their own platform (as they already are) and the find count shouldn't be included in the find count maintained on the site for all other geocaching types. That's just how I see it and hope that it might be updated. I'm not holding my breath and yes, I've chosen to ignore them by not downloading the app to see what they're about.

I don't disagree with this but it's my understanding that adopted caches are adopted in order to keep them going and allow a new CO of the adopted cache the opportunity to own and maintain caches that the original CO put out and can no longer find the time to care for as needed. If the goal was new caches, decline the adoption, place a cache along the trail and wait for the original CO to archive them (or the local reviewer if it gets to that point). So it's OK for only some of the community to value and enjoy this new cache but it's necessary for the entirety of the community to value and enjoy an adopted cache in order to keep it going? It seems like the +1 (or if you prefer, the opportunity to find a new cache) is the main factor behind this thought. And the original CO, knowing (for whatever reason) that they weren't able to maintain them as needed, opted to put them up for adoption, hoping for someone else to maintain them. This newly adopted cache now has a strong probability of being maintained and not falling into disrepair. This is correct but the adoption process is what allows caches like this to be maintained properly, in order to avoid archival. If the goal is to put out new caches along the trail, then the caches should go through the process in place and potential COs should wait until they're archived before putting out new ones. All of this discussion is irrelevant and hypothetical because we don't know what type of understanding exists between the OP and the CO that gave up the caches for adoption. It appears that the OP and the original CO may not have had that discussion, at least based on what I'm reading in the original post. Knowing that dynamic will either make new caches a realistic choice or no choice at all, at least as I see it.

Any reviewers care to chime in? @Keystone? It's obvious they can't post-publication. What about pre-publication?

It appears, at least to me, that the line above the "Scan QR" is where you would input the answer needed to advance to the next zone. While not exactly the same as my previous examples, it's close enough. It appears that you aren't able to tap on the screen at the line to enter your answer. Is that what you're telling us?

I don't think they can for individual caches that are submitted for publication, based on Keystone's reply from a different thread. I think they're limited, per GS guidance, to procedural issues, not subjective issues like D/T ratings. Of course they can encourage the COs in their respective areas to attempt to rate their caches as accurately as possible in a general sense but I don't believe they're able to make those types of suggestions on individual caches that are submitted for publication. If they can't guarantee that a 1 T cache is truly wheelchair accessible based on their personal experiences and beliefs as a reviewer, then the extended implication is that they can't request a CO to change the D/T rating for any other cache, even if they believe it to be faulty or incorrect. I don't necessarily think that's a good thing but I think it makes a reviewer's job much easier because they wouldn't even need to consider that as a determinant for publication.

That depends upons the agreement between the adoptee and the original CO. If the original CO says, "Please keep the cache going.", then yes. If the CO says "Do what you'd like.", then no. I have adopted a cache from the second CO to "own" it and was told that there was a slim possibility that the original CO might want it back. That mandates, at least to me, that I'm supporting that cache until such time as the first CO wants it back or the area is developed and the cache isn't viable anymore. If you're against maintaining a cache that wasn't yours to begin with because it apparently has no value to the community, then why would you support someone placing a new cache and maintaining it when the entire community won't value it either. Why can't just some of the community value the cache and find it a viable cache to keep going? That's well and good but I, like many of the earlier posters, wonder what the purpose of adopting these caches is if you have no intention of keeping them going and refreshing/maintaining them. Did you and the CO have any sort of talk about the original CO's desires regarding these caches?