Problem With Cache being denied

[+Renegade Knight]

...BTW, the other cacher, "shmair", has contacted me and graciously moved the eventual location of his puzzle cache to allow ours to be listed, so we will just wait for the all clear sign from the reviewer....

 

Excellent.

[+BoggyWoggy]

Grrrr...can't we all just get along?

 

I think it's unfair to put "holds" on cache locations. Why a "work in progress?" Get the work done first...submit the cache request and cross your fingers. If there's a glitch, fix it. If you're making a cache that's so tough to lay out, due to trying to be oh-so crafty with a puzzle, think about backing off a bit and doing some traditionals. I am on the side of those who place a cache, after doing research on geocaching.com/Google maps and acting in a timely, respectful manner. If we're going to have "on hold" locations, then they must somehow be communicated to potential hiders.

I appreciate the moderator replies, but I also think you might want to consider that premium members are paying for this service. We'd pay more, if asked, in order to keep things flowing well. The reviewers in our area (Corvallis, Oregon) ROCK! I've never had to wait more than 24 hours for a reply/posting/publish. I guess I'm spoiled.

[+TotemLake]

Grrrr...can't we all just get along?

 

I think it's unfair to put "holds" on cache locations. Why a "work in progress?" Get the work done first...submit the cache request and cross your fingers. If there's a glitch, fix it. If you're making a cache that's so tough to lay out, due to trying to be oh-so crafty with a puzzle, think about backing off a bit and doing some traditionals. I am on the side of those who place a cache, after doing research on geocaching.com/Google maps and acting in a timely, respectful manner. If we're going to have "on hold" locations, then they must somehow be communicated to potential hiders.

I appreciate the moderator replies, but I also think you might want to consider that premium members are paying for this service. We'd pay more, if asked, in order to keep things flowing well. The reviewers in our area (Corvallis, Oregon) ROCK! I've never had to wait more than 24 hours for a reply/posting/publish. I guess I'm spoiled.

That ignores the fact a cache may have already been placed and the cache page is being worked on... maybe even going through with issues with the reviewer. There other reasons for it but that is the most obvious.

[+TheWonderStuff]

I understand. But the geocaching rules specifically state that the cache should not be logged until it is ready to be hunted. So if I follow the rules, I have to find the location, plan and make the cache, hide it, and then wait and find out if there are other, incomplete caches in that area. I understand that puzzle caches need some time to make (which is what I ran into) and you don;t want someone planning one and have their location snapped up, but the rest of us need some warning that the area is claimed before we hide the physical cache, as some are heavy! And if we log it before we hide the cache, we violate the rules posted on the Website! I just don;t know how to stop this from happening again.

 

BTW, the other cacher, "shmair", has contacted me and graciously moved the eventual location of his puzzle cache to allow ours to be listed, so we will just wait for the all clear sign from the reviewer.

 

Also, this is not ment to be a slam at a particular reviewer (that is why I did not use their username). I just wanted some help on an appropriate course of action, as we are relative noobies.

 

I sometimes send my reviewer gps cords of a GZ I have in mind before setting up my cache to be sure Im far enough away from any other caches ( pesky puzzles), and it saves the frustration that you are facing at the moment

 

I suggest you keep this in mind for future hides you maybe planning

[+TheWonderStuff]

I submitted cords to my reviewer to " Hold" an area for me. It was a cache outside TEAM NZ's HQ( Americas cup - you guys heard of that ) and I wanted the cache listed either on the day NZ won, or the Day we lost ( So I could get the correct details in my cache page )

 

He gave me 2 or 3 weeks I think.

 

Also did it on a fire tack night cache I did, where it took me 2 or 3 weeks of setting up the fire tacks, testing etc, last thing I wanted was someone to plop a trad down in that area after all the work I had put into it.

 

Common sense in my eyes

[+longwayround]

What the heck is this "hold" policy? That's what I'm concerned about. This should definitely be in the guidelines because I have not idea what it is and who is allowed such privileged status.

 

Why would you want to keep the caching community in the dark?

 

If it's not published (the "hold"), how can it prevent another from placing a cache there? This stinks....

So, cacher A places a cache but there's a problem with it. Suppose he put in a pocket knife, which he wasn't supposed to do, but everything else about the cache is OK. All he needs to do is to go back and remove the knife in order to have his cache published. Cacher B places a cache 50' away the next day not knowing about the other cache. You're saying cacher B should get the spot instead of cacher A?

 

Now suppose cacher A doesn't get back to his cache for (some arbitrary time period). Cacher B contacts the reviewer. The reviewer contacts cacher A who says he just can't get out there to fix the problem. The reviewer publishes cache B instead of cache A.

 

Where's the problem?

 

If cacher A put the knife in the cache then it means that he either didn't read the guidelines or chose not to follow them. IMO, that cache should be taken out of the queue completely and have to be resubmitted by the owner after he fixes the problem.

 

It is obvious to anyone who has read the rules that it is truly foolish to place certain items in a cache. Cacher A acted with undue haste in placing the cache without first engaging brain. Cacher B placed a cache having previously considered such factors as location and contents.

 

It would be excessively harsh to remove cache A from the queue completely but it should, IMHO, be moved to the back of the queue. If cache B were then found to have a flaw, it would be moved behind cache A.

 

The very fact that this system would cause inconvenience to those who cock up is its advantage.

[+Sapience Trek]

We don't need more guidelines. The more guidelines we have the less flexible the reviewers can be in evaluating each cache based on it's own merits and local land policies. Putting rules in place around this means eventually you have to cover every permutation of problem that can come up. The guidelines would get huge and even less people would read them than read them now.

 

- CacherA has a event coming up 2 months from now, and wants to get a few event caches out for it. They submit the caches 2 months ahead of time to make sure everything is ok for the 100 people coming to the event. Is that too far ahead of time?

 

- CacherB and CacherC both submit a cache the same day at/near the same location. Who gets the spot? (answer - lower GC number)

 

- CacherD submits a cache that is too close to another existing cache. It takes them a few weeks to get out. CacherE submits a new cache that has no issues and wants it published a week from now. In the meantime before it is reviewed, CacherD moves their cache near CacherE's cache. CacherD has the lower GC#, but CacherE had the spot first. Who gets it? (I don't know - hopefully CacherE but that has to be evaluated based on other factors.)

 

- CacherF submits a cache in a state park but has no permit (required in NY at least.) While he is getting a permit, CacherG submits a cache in the same state park nearby and has the required permit. Who gets the spot, since CacherF has the earlier GC#? Probably CacherG since they already have the ranger's approval, even though CacherF has a lower GC#.

 

In the review of 4000+ caches, I can think of only 1 or 2 times where this actually came up. It's not a problem, so lets not constrain the guidelines by listing you can hold a spot for 2 days, a week, a month, whatever. Let's not encourage people to create bogus cache listings that are disabled so they can hold the spot for a future unplanned cache.

 

The system works now.

[+tozainamboku]

We don't need more guidelines. The more guidelines we have the less flexible the reviewers can be in evaluating each cache based on it's own merits and local land policies. Putting rules in place around this means eventually you have to cover every permutation of problem that can come up. The guidelines would get huge and even less people would read them than read them now.

 

- CacherA has a event coming up 2 months from now, and wants to get a few event caches out for it. They submit the caches 2 months ahead of time to make sure everything is ok for the 100 people coming to the event. Is that too far ahead of time?

 

- CacherB and CacherC both submit a cache the same day at/near the same location. Who gets the spot? (answer - lower GC number)

 

- CacherD submits a cache that is too close to another existing cache. It takes them a few weeks to get out. CacherE submits a new cache that has no issues and wants it published a week from now. In the meantime before it is reviewed, CacherD moves their cache near CacherE's cache. CacherD has the lower GC#, but CacherE had the spot first. Who gets it? (I don't know - hopefully CacherE but that has to be evaluated based on other factors.)

 

- CacherF submits a cache in a state park but has no permit (required in NY at least.) While he is getting a permit, CacherG submits a cache in the same state park nearby and has the required permit. Who gets the spot, since CacherF has the earlier GC#? Probably CacherG since they already have the ranger's approval, even though CacherF has a lower GC#.

 

In the review of 4000+ caches, I can think of only 1 or 2 times where this actually came up. It's not a problem, so lets not constrain the guidelines by listing you can hold a spot for 2 days, a week, a month, whatever. Let's not encourage people to create bogus cache listings that are disabled so they can hold the spot for a future unplanned cache.

 

The system works now.

Then we're not asking for new guidelines> We would just like Groundspeak to publish the process you describe here for arbitrating conflict between two or more caches placed but not submitted to the review queue. Clearly the process leaves some flexibility because of the unusual cases you described. The reviewers may know they are being fair in applying the processs, but until it is in writing some people may think the reviewers are playing favorites when their cache is denied because someone else has a work-in-progress. The average geocacher does not see the direction the frog gives to the reviewers. The average geocacher does no see what gets discussed in the reviewer forum. The average geocacher does spend all day reading the forums to see the few times a reviewer posts examples like you gave here. A few sentences explaining the process in the guidelines does not have to restrict the flexibility the reviewers now have. It would let cachers know what is going on when they submit a cache for review. It could explain to cachers what they could do in preparing and submitting caches to make the process go smoother and ultimately result in less work for the reviewers.

 

It's really quite simple:

 

When reviewing your cache submission the reviewer will check the proximity of your cache to other caches including stages of multis, actual location of puzzles, and unpublished caches having a lower GC number. The reviewer has discretion to determine if the the other cache is actively being worked or if that cache owner is just sitting on the spot and may approve your cache if the other cacher is not actively working on getting his cache approved in a reasonable length of time.

 

Since cachers cannot see other caches that have not been published and may not be able to solve all the puzzles or multis in the area, a cacher may contact a reviewer with provisional coordinates and see if these are available before hiding a cache. By creating a cache page with these coordinates but not checking the cache is active box, a cacher may hold these coordinates for a reasonable period while they are working on the cache.