Caches placed to be released for Events

[+CacheDrone]

Hello everyone, and sorry for the long note.... just an item that is overdue.

 

Recently CacheMinder, CacheViewer and I had a discussion about a trend that has been growing in some pockets of Ontario with respect to caches to be released in conjunction with an Event Cache. Some of the results of that discussion are outlined below and we are requesting the assistance from those involved.

 

First and foremost, we all appreciate that people enjoy geocaching and the social aspect that Events afford. We do understand that there is a desire to create some new caches to be enjoyed and discussed. As we have witnessed from our "behind the curtain" position, sometimes this works well and sometimes it is a tedious process for everyone. It is clear to see the main factor for success, and it is summed up in one word.... coordination! While we do not wish to single out any specific areas, having a local organizer to wrangle the potential caches helps to streamline the process.

 

But let's get the heavy handed bit out of the way first - Event Listings should not "encourage" or "reward" people for placing new caches. That could actually be viewed as an Agenda as well as run afoul of the Group Caching concept which is discouraged in Listing Guidelines. In short, if you are hosting an Event then the Event is what your Listing should be focused upon. But as mentioned, we understand that new caches often are placed to be enjoyed at the time of the event and often make the Event a success.

 

Often the biggest issue is proximity to other new caches placed for the upcoming Event and it is really hard to tell people that their new cache is too close to something that they cannot see or find on the website. Try to imagine the frustration and confusion of relocating a cache 5 or 6 times because everyone else is also tying up spots in the same area, and imagine the Reviewers having to say again "Nope, too close to another cache you can't see." Another issue we are seeing is waiting until a few days before the Event to submit your cache. In the Listing Guidelines is this section:

 

If you are placing a large number of caches to be published on the same date (for example, on the day of an event cache), please submit the cache pages for all of the caches at least ten days in advance of the release date. Leave a "note to reviewer" indicating that the cache is to be released on the date specified. This allows your reviewer adequate time to review the submissions or to arrange for help from another reviewer. (Note: Caches placed in connection with an event must be placed with the intention of leaving them in place after the event, temporary caches are not accepted.)

 

One solution that worked incredibly well went like this. Everyone that wishes to have new caches for the upcoming Event would submit all of their coordinates for each of their caches by email to one "Event Coordinator" and as each was received the coordinator would draft a basic cache listing with the coordinates, compare to what already exists and if available then they would use www.geocaching.com/adopt to transfer the listing back to the person wanting to place the new cache. While this does not guarantee success it does have many benefits.

 

What we are asking for is some consideration when it comes to submitting listings for future release dates, often in conjunction with upcoming Events. If you are hosting an Event where this might happen, consider having someone on the Event committee to manage this aspect... and please give the Reviewers lots of time to help get the caches reviewed.

 

CD

Edited October 21, 2009 by CacheDrone

[+swimmrguy]

Thanks for starting up this discussion--as someone who set up an event like this a couple of years ago, I was very appreciative of the willingness of the reviewers to have it work. You raise some very valid points, and I know many would be happy to do anything to make it easier on the reviewers.

 

One solution that worked incredibly well went like this. Everyone that wishes to have new caches for the upcoming Event would submit all of their coordinates for each of their caches by email to one "Event Coordinator" and as each was received the coordinator would draft a basic cache listing with the coordinates, compare to what already exists and if available then they would use www.geocaching.com/adopt to transfer the listing back to the person wanting to place the new cache. While this does not guarantee success it does have many benefits.

 

I am not sure I fully understand this solution, as I think you left out the part of when in this process the cache description is submitted for review. I am assuming that the Event Coordinator needs to be very familiar with the already existing caches in the area (particularly multis and puzzles) in addition to having the coordinates of proposed new caches in order to make the proximity judgments. Once the coordinator thinks it's OK, do they then submit it for review? Or can you adopt the cache back out to the original cache owner even before it has been published? (I can't say that I have ever tried to do that!)

 

Certainly for our events that have caches to be released as part of it, there is usually someone in charge of collecting all the GC numbers to keep a running tally of the caches being submitted. This would not be a difficult step for that person to implement.

 

--SG

[+Keith Watson]

Using a coordinator is a very good idea. I have seen this done at events in the past. Makes perfect sense. This should eliminate most of the collisions with other caches except for those puzzles and multi's the coordinator does not know about.

 

I don't think having the coordinator "own" all the listings though is needed. If the reviewer is given a list of caches, it should not matter who owns them. Any problems with the caches, the review can just communicate with the coordinator and the coordinator can then relay the information to and from the cache owners. I can see it being more work having them all owned by the coordinator. The owner may want more than a basic listing. I assume the reviewer would have to review the basic listing and then re-review the final listing the owner wants on their listing to make sure it still meets the guidelines. If the reviewer does not want to review the listing twice, then the coordinator would be required to maintain the listings for the individual owners until they can be adopted back.

 

Keep it simple. Each owner lists their own cache with a reviewer note explaining what is going on and have the reviewer work through the coordinator. I think this works be the least amount of work for everyone.

Edited October 21, 2009 by Keith Watson

[+Red90]

....Event Listings should not "encourage" or "reward" people for placing new caches. That could actually be viewed as an Agenda as well as run afoul of the Group Caching concept which is discouraged in Listing Guidelines. In short, if you are hosting an Event then the Event is what your Listing should be focused upon. But as mentioned, we understand that new caches often are placed to be enjoyed at the time of the event and often make the Event a success.

 

Wow, I guess you do not allow CAR events in Ontario then!!! The whole point of CAR event is to encourage cache placement.

 

Could you point me to the guidelines that discourage group caching? I have not seen that before. Thanks.

 

edit: I see what you are talking about. With all due respect, I think you are stretching the intent.... http://www.geocaching.com/about/guidelines.aspx

In addition, an event cache should not be set up for the sole purpose of drawing together cachers for an organized hunt of another cache or caches. Such group hunts are best organized using the forums or an email distribution list.

 

The SOLE purpose of the event is NOT to go out and find certain caches. As long as the event is still an event which has other components besides caching, it should be fine...... Also the guideline does not discourage group caching. It is saying that getting a group together to go and find a cache or caches is not an event unto itself.....

Edited October 21, 2009 by Red90

[+chris-mouse]

As an example of a system that seems to work very well, here's what happens when planning for one of the BFL Boot Camp night caching events.

 

About the beginning of August, a location and date will be chosen for the event. At this time, members of the BFL Crew will be asked if they want to place caches for the event. Those who volunteer to set up a cache are added to a private mailing list for event organizers.

 

Cache placers figure out what area they'd like to place a cache, and post a notice on the list saying things like "My cache will be along the Bruce Trail west of 8th line." If any two people want the same area, they know they will have to get together and coordinate the details so the two caches don't interfere with each other. This usually happens within a week or two of the original request for volunteers.

 

Cache placers scout the area for their cache, and locate the cache hiding spot as well as parking, posted coordinates and any stages needed. This information is posted to the mailing list so that conflicts can be checked. The cache placer also creates a cache page with minimal description, and submits it for review with a note to the reviewer indicating that this is a work in progress for the event and that it is not to be published until the night of the event. This allows plenty of time to fix any problems, and also holds the spot so cachers not involved with the event don't try to place another cache in the middle of everything.

 

If the reviewer has any issues with the location, these issues get dealt with at this time. Once the location is cleared, the cache placer gets the cache itself ready as well as any reflectors/props/stages that will be needed. This gets placed out in the woods at least two weeks before the event. The cache placer also updates the cache page with the full description of the cache with all the story and instructions that are to be public. A copy of this information is sent to the event organizer and the cache page is resubmitted for final approval by the reviewer.

 

During the last two weeks before the event, the BFL crew takes the public cache descriptions out into the woods and does a beta test of all the caches to catch things like math errors or confusing descriptions. During these beta test, the cache placer hangs at the back of the group and gives no help in solving problems unless specifically asked. If the cache placer has to be asked, there's something that needs clarifying, so the cache description gets updated to fix the issue.

 

The elapsed time from the first announcement to the day of the event is typically something like two months, during which time we are all constantly keeping each other informed of what's going on with our caches. The key to all of this is communication. Without it, it would be impossible to put a dozen new caches into an area a couple of kilometers across without constantly stepping on each others cache placements.

[+The red-haired witch]

One solution that worked incredibly well went like this. Everyone that wishes to have new caches for the upcoming Event would submit all of their coordinates for each of their caches by email to one "Event Coordinator" and as each was received the coordinator would draft a basic cache listing with the coordinates, compare to what already exists and if available then they would use www.geocaching.com/adopt to transfer the listing back to the person wanting to place the new cache. While this does not guarantee success it does have many benefits.

 

I think this would work great when organizing an event in a relatively small area (for example, with all caches within walking distance) where there are relatively few existing puzzles and multis.

 

Around here, when we place caches for an event we spread them around a huge area where there are hundreds of existing puzzles and multis, so the coordinator wouldn't be all that useful in determining if caches interfere (unless the coordinator was a reviewer ). The chances of having an existing "cache you can't see" interfere with a cache planned for the event are much higher than the chances of having two of the planned caches interfere with each other.

 

As for asking people to place the caches long in advance to give plenty of time to the reviewer, we did remind everyone, but not everyone listened. I must say that the reviewers might be encouraging this disobedience by being too efficient and publishing on time caches that were submitted long after the deadline

 

Oh, and I totally agree with not offering a reward to incite people to place caches. A prize to win (for placing the most caches for example) would increase the chances of people placing caches they can't/don't really intend to maintain. I think most people who placed a cache for our recent event would have placed one anyway, we just suggested a date to them so that all those caches got published on the same day. There always seems to be a large drop in the number of caches published here in the weeks before and after the event, so in effect we are just concentrating one month's worth of new caches into one day... one crazy day

[+CacheDrone]

Perhaps there are a few factors that as a reviewer I am still trying to understand, and my fellow reviewers all have a slightly different opinion on how to handle these unique times. Partially because of where we live and have done most of our caching, but also because we see these differences across the province (and in some cases around the world).

 

It would be great if people could help me see a different viewpoint than the conclusion that I've come to based on what I'm about to describe. Please understand that in no way am I commenting on the quality of the caching or experience provided (I fully admit to have enjoyed myself immensely at all examples provided ). There seems to be, if I may generalize, four different styles used. They would be small, medium and large in area and stand alone.

 

1- Stand alone is the basic event where people meet at a point (restaurant, park, etc) for a short period of time and talk with or without food. From a reviewer standpoint there is nothing really to say... I hit the publish button and move along.

 

2- Small area events, like GAGAFAP or COG SPRING FLING, are self-contained which typically include new caches placed within the park that is the site of the event. Basically it is a day long event at a park and when you arrive you receive a package of activities that you can participate in. Some will become permanent caches after the event.

 

3- Medium area events, like BFL and CLARINGTON WINTER THAW, start or end at a restaurant and a handful of caches are placed within an area set aside by the event host and populated with caches from an event committee or group. These caches are unveiled just before or just after the event and typically share a theme.

 

4- Large area events, like GAG and KAG, start or end at a restaurant and in the weeks preceding the event anyone that wants to can go out and places some caches to be unveiled a day or two before the event. The caches are placed across the city and each cache seems to stand on its own except for the time it becomes availability.

 

In my opinion, which is why I am hoping to get feedback from people, it would seem better to publish them as soon as possible. This would let people know what areas have already been used, to download them in advance, begin to start solving any puzzles, and shift the decision of when to find any of the caches to those that are going to be enjoying them. If people wish to save them for a special date, like the day of the event, they would have that option. Being honest based on what I've seen, most people attending the event would want to save finding them until the day of the event anyway.

 

So here's my question...

 

Are there reasons why the caches that are to be enjoyed on the day of the event cannot be published at the time they are reviewed?

[+Keith Watson]

Are there reasons why the caches that are to be enjoyed on the day of the event cannot be published at the time they are reviewed?

 

I don't see any reason not to publish the caches ahead of time. If people going to the event want to do them at the event, they can just wait till the event.

[+Dr. House]

So here's my question...

 

Are there reasons why the caches that are to be enjoyed on the day of the event cannot be published at the time they are reviewed?

 

The only semi-valid reasons that immediately come to mind would be:

 

- to reduce the amount of last minute cache submissions to the reviewer queue by those hoping to prolong a find on their cache until as close to the event date as possible

- to minimize potential negative caching experiences as a result of compromized or damaged placements/stages (whether by muggles or cachers) in advance of the event that the cache was designed for

 

To me, a person places caches to be enjoyed on the day of the event as an extension and augmentation of the event itself, thus my preference would be to continue to have the option to hold a cache in queue after submission and review.

 

This discussion makes me wonder whether an opportunity exists on the GSP side to provide an option in the toolkit that will allow reviewers to set an auto-publish date/time on groups of caches that request a "hold for publish". Provided nothing changes on the cache page from the standpoint of co-ordinates, this solution would seem to negate the need to ask the above question.

Edited October 26, 2009 by Dr. House

[+Tequila]

Sadly, I think the main reason for holding off publication of caches till the event, is to allow for FTF's to occur during the event.

 

In the past I have attended events where one individual scooped all of the FTF's in the early morning hours prior to the event. And that individual didn't even attend the event. Some cachers feel the need to claim FTF's as some sort of glory award.

 

I like Dr. House's idea of an auto-publish feature. That or a database wide delete of the term "FTF".

[+Keith Watson]

Sadly, I think the main reason for holding off publication of caches till the event, is to allow for FTF's to occur during the event.

 

In the past I have attended events where one individual scooped all of the FTF's in the early morning hours prior to the event. And that individual didn't even attend the event. Some cachers feel the need to claim FTF's as some sort of glory award.

 

I like Dr. House's idea of an auto-publish feature. That or a database wide delete of the term "FTF".

 

I would hope that caches listed on the site are available for all to visit, with the exception of the members only limitation. By holding off publishing caches so attenders of an event get first to find is rewarding people for attending the event.

[+Red90]

For events like this http://www.geocaching.com/seek/cache_detai...6e-3d85aa28c4f5 publishing them just in advance adds to the fun of trying to be FTF. It also means that when you meet up, they are all "new". The newness makes the event more interesting as you talk about all of the interesting caches that came out for the event. In addition, there are no past logs to help people in the hunt, leveling the finding field. If they had all been around, you would know much more about them taking a lot away from the event.

[+The red-haired witch]

To me, the main interest of having them all published at the same time, about 24 hours before the start of the "official pre-event caching", is the additional challenge of puzzle solving and then planning the actual caching in a limited time. The Thursday night before a GAG is usually a fun evening of puzzle solving madness.

 

Most of the time, that limited time factor also helps to convince cache hiders not to put insanely difficult puzzles. Most of the time...

[+The red-haired witch]

I would hope that caches listed on the site are available for all to visit, with the exception of the members only limitation. By holding off publishing caches so attenders of an event get first to find is rewarding people for attending the event.

 

The fact that the caches are only published on the date of the event certainly doesn't stop anyone from going look for them, no matter if they plan to go to the actual event or not.

 

And saying that having caches published near an event is a reward to event attendees would be stretching the definition of reward, I think...

 

Giving someone "early access" to a cache before publishing is allowed AFAIK, no matter if its for beta-testing or other reasons (birthday caches, proposal caches, event caches, etc)

 

I think event organizers should be free to decide if they want publishing after the event, days before the event or weeks before the event...

 

It seems to me that having people submit the caches over a period of several weeks and ask for a specific publication date makes the jobs of the reviewers easier than having a bunch of people all trying to submit their caches all on the same day to try to get it published on a specific date.

[+stagunner]

 

I think event organizers should be free to decide if they want publishing after the event, days before the event or weeks before the event...

 

It seems to me that having people submit the caches over a period of several weeks and ask for a specific publication date makes the jobs of the reviewers easier than having a bunch of people all trying to submit their caches all on the same day to try to get it published on a specific date.

 

I agree with this but would it not make it a bit easier if there was some way Groundspeak could make it a lot easier. The reviewers have a lot to do for this type of activity and I am sure they to would like an easy way to do it.

 

I suggest that Groundspeak consider some oprions

 

1. place a software button on the cache page where the Cache owner could set it as ACTIVE of NOT Active when the batch of caches need to be,

 

This way the reviewers could do their part by reviewing and approving the caches and then the cache owner would activate the cache at the appropriate time

 

This would be a one time thing for any cache needed to be placed for cache placement event,

 

2, place a DATE field on the cache page so when the cache is being create a date "When Active" is entered.

 

then the database automatically releases it after it is reviewed and ready to go.

 

I understand that this might take some time to do but it would make things work a lot easier,

 

We like doing this type of event in Atlantic Canada and have great gatherings, and I would like to do more, and have it done with less work on both parts of the approval process

[+Keith Watson]

It looks like there are three types of cache placing going on in relation to events. All are permanent.

 

1) There will be an event in the area and local cachers will be placing caches outside the event site for visitors to visit before and after the event.

 

2) There is an event and caches are placed with in the event site and are intended to be found by event guests during the event as well as other activities.

 

3) An event for the sole purpose of finding caches published on mass.

 

For number 1, the caches need to be published before the event and therefore should be published when reviewed.

 

Number 2 would require some coordination to make sure the caches do not collide with each other and prevent other cachers from placing caches that confict. The event should be about getting together and not finding caches so I see not reason that the caches should only be made available to the cachers attending the event and then to the public later. These types of caches are generally a reward to the cachers attending because they get to do the caches before anyone not attending the event.

 

Number 3 would require all the caches to be published at once. If you have a reviewer that will do this for you, you have a very nice reviewer. I can understand why they all must be held till a specific day.

[+Dr. House]

Sorry... I think I may have unintentionally derailed the OP's intent for this thread by suggesting a solution that may benefit both reviewer and participant for the above-mentioned scenario.

 

May I suggest that CD's question still stands largely unanswered, IMO. Almost like we're seeing solutions, but not too many "real" reasons to have those solutions.

[+coman123]

Would placing a cache with out a log book be allowed, and on the cache page in the discription be,

This cache has been placed for the bla bla bla....event

 

You may seek this cache before (insert date here) however the official log book for this cache will be placed in it on (insert event date here)

[+swimmrguy]

For events like this http://www.geocaching.com/seek/cache_detai...6e-3d85aa28c4f5 publishing them just in advance adds to the fun of trying to be FTF. It also means that when you meet up, they are all "new". The newness makes the event more interesting as you talk about all of the interesting caches that came out for the event. In addition, there are no past logs to help people in the hunt, leveling the finding field. If they had all been around, you would know much more about them taking a lot away from the event.

 

This would be my reason for holding off publication of caches for events like GAG, KACHE, etc. Even when you know that the FTF is gone, there is something about going and getting the new caches--and wondering who you might run into while on the hunt, since it is highly likely you will!

 

We appreciate that this type of mass cache publication is a lot of work for reviewers (and let me give a huge thank you to CacheMinder from the Kingston community for the recent work on KACHE 2. I don't think anyone would have anticipated that there was 116 new caches placed--that was truly above and beyond!). It was clearly well appreciated in our community--with over 100 people attending the after-caching event, and with many more out on the hunt during the day.

[+CacheDrone]

One of the principle reasons for my question is that these large amounts of unpublished caches begin to conflict with each other. It's a sort of geo-minefield where at the beginning it is fairly easy to find an available spot but with each new unpublished cache that is held, the number of times a newer cache will get too close.

 

In this case, publishing them at the time of review would solve that problem and just like Keith Watson pointed out in post #8 and partially in post #11, I then feel it does skew a bit unfair IMHO. Keith Watson's "solution" in post #8 is how I view it too. If finding it as part of the event is important to you, then wait till the appropriate time. This also would cover the comment by The Red-Haired Witch in post #13. If, in her case, GAG people are getting the cache listings published two days in advance but are asked to wait till 6pm two days later then it is the same if they are published a week or two in advance. I understand the idea of "Christmas Caches" as a fun way to launch a bulk at once, but on a city-scale this idea to me has gotten out of hand. Again, the geo-minefield analogy applies.

 

3) An event for the sole purpose of finding caches published on mass.

 

Number 3 would require all the caches to be published at once. If you have a reviewer that will do this for you, you have a very nice reviewer. I can understand why they all must be held till a specific day.

 

AFAIK, all of the reviewers are fine with publishing a bulk of caches all at one time. However, none of us should be publishing an event for the sole purpose of finding caches. I think I'm misunderstanding your post.

 

For events like this http://www.geocaching.com/seek/cache_detai...6e-3d85aa28c4f5 publishing them just in advance adds to the fun of trying to be FTF. It also means that when you meet up, they are all "new". The newness makes the event more interesting as you talk about all of the interesting caches that came out for the event. In addition, there are no past logs to help people in the hunt, leveling the finding field. If they had all been around, you would know much more about them taking a lot away from the event.

 

This would be my reason for holding off publication of caches for events like GAG, KACHE, etc. Even when you know that the FTF is gone, there is something about going and getting the new caches--and wondering who you might run into while on the hunt, since it is highly likely you will!

 

We appreciate that this type of mass cache publication is a lot of work for reviewers (and let me give a huge thank you to CacheMinder from the Kingston community for the recent work on KACHE 2. I don't think anyone would have anticipated that there was 116 new caches placed--that was truly above and beyond!). It was clearly well appreciated in our community--with over 100 people attending the after-caching event, and with many more out on the hunt during the day.

 

Personally I don't believe either to be true. As was pointed out, if that is the experience that you are wanting then it should not matter when the caches are published. What matters is when you go to find them. Ottawa's method proves this. I think that it can be expanded upon to actual remove the "hold" step all together.

 

I'm not asking for a reduction in the number of caches being placed nor am I commenting on quality... but what I am asking for is some valid justification for not immediately publishing caches. Yes, definitely get them in more than 10 days in advance if they are for some upcoming event because sure enough if we get bombarded with more caches than we can process at the last minute then people will be disappointed. but I still think it unfair to "invisibly" block locations for extended periods of time especially when it is an area where everyone else is out trying to also place new caches that will also be "invisible" for some time.

[+swimmrguy]

What matters is when you go to find them. Ottawa's method proves this.

Ottawa's method (for GAG) had publication of the caches held until two days prior to time the cache hunt was to start. I don't think that proves that publishing caches 10+ days before the event would be equivalent.

 

It is apparent that the organizers of such cache hunts desire that the publication of these caches be held to a time close to the date, otherwise they wouldn't request it. I can only attest to my rationale for requesting this for the hunt I organized for our community three years ago. My reasons were as outlined in post #19 above.

 

The question is not whether the reasons are true, but rather if they are sufficiently compelling to justify the workload it confers on the Reviewers. It would appear that the case has not been made convincingly.

[+ace862]

Personally, I like the mass publication a day or two prior to the event. I think it adds that extra excitement and anticipation to the hunt. I guess it's the "Christmas Cache" effect that CacheDrone referred to. I guess I'm still a kid that way. The other thing I like about the day or two before hand publication, is that I believe that it keeps the playing field relatively even. If you were to publish them as soon as they were submitted, say 10 days in advance, I know we can say, "please don't look for this until xxx" but at the same time I know you can tell some kids not to go snooping for their Christmas gifts but you know they're going to snoop anyway. With a cache sitting there published and just waiting, I think some people may be tempted to just "scout" a location. And yes, I know they could do that as well a day or two before hand, but I think with less time between publishing and being able to find the cache, it's less likely to happen. In the big picture should it really matter if someone wants to "cheat"? No not really I guess. It's just one of those things that would rub me the wrong way.

 

Now, on the other side of the coin, if I'm placing a cache to coincide with an event, I know that I'm walking into that "geo-minefield". I accept that. I know that there are a number of other hiders out there looking to place caches and I understand that prime real estate is at a premium. I don't have a problem with being told that the spot I've chosen is in conflict with something else that I can't see right now. That is one of the side effects when you do things like this for an event. Are people getting upset when these issues arise? I would think that they should expect things like that to happen.

 

This is just my two cents. Take it for what it's worth.

Cheers!

[+CacheDrone]

Thanks to everyone that participated in this discuss or took the time to read it.

 

I have the answers that I was looking for. Caches placed with the request to be published in the future will continue to be reviewed and processed as has always been done.

 

CD