Jump to content

Change In Cache Review/publish Process: Allow Cache Owner To "reveal" Approved Cache.


grnbrg

Recommended Posts

Would it be possible to change the cache approval process to allow the owner to decide when the cache is revealed to the public? ie: Allow a cache to be placed, reviewed and approved by reviewer, but have the final step that allows the cache page to be visible, instant notifications to be published, etc be (even optionally) at the cache owners discretion.

 

This would allow caches associated with a particular event to be published en mass by the event organizers without needing to co-ordinate with the reviewers.

 

It would also allow individual users (Ok, me. I like doing things this way...) to plan out a cache, develope the cache page, go through the full review process (in case there are any changes required) and once the cache is approved, place the container(s) at their sites. Right now I get to race the FTFers to the spot. :unsure:

 

This could be done (for example) by adding a "Ready for Review" attribute, similar to the current "Cache is Active" attribute, and allow reviewers to see any cache marked "Ready for Review", regardless of the "Active" flag. The current logic that prevents general users from seeing caches not marked Active would remain.

 

I do realize the programming headaches such a change might entail, but it's a feature I think would be well recieved.

 

Thanks!

 

grnbrg.

Link to comment

If you just need to edit the page and stuff, you can disable the listing and the reviewers won't see it. When everything is ready, enable the page.

 

If you need the location reviewed, the prefered method is to email your reviewer first. Alternately you can put a "note to reviewer" and ask for it to be published on a given day. They'll do what they can to accomodate you. Just don't ask for something like "publish at exactly 10:07 am." The reviewers are volunteers and have better things to do than sit by the computer at a given time just for you :unsure:

Link to comment

If you just need to edit the page and stuff, you can disable the listing and the reviewers won't see it. When everything is ready, enable the page.

 

Yup.

 

If you need the location reviewed, the prefered method is to email your reviewer first. Alternately you can put a "note to reviewer" and ask for it to be published on a given day. They'll do what they can to accomodate you. Just don't ask for something like "publish at exactly 10:07 am." The reviewers are volunteers and have better things to do than sit by the computer at a given time just for you :unsure:

 

Which is why I think this is a useful feature. If I *want* a cache published at exactly 10:07 am, or if we're kicking off a cache-hiding blitz event, and want to publish 75 caches at 8:00 am on a Saturday morning, it would be nice to be able to do it myself, without having to burden the volunteer reviewers.

 

And I prefer to get approval for my caches before I place the container, because there is a chance that I'll get a response like "Sorry, but there's a multi-cache cache 100 ft from there. You'll need to find another spot."

 

Giving the cache owner the ability to decide when a cache goes public will increase the flexibility for placing caches, and will *reduce* the work required by the volunteer reviewers, who will no longer have to deal with "Please don't publish this before Saturday, as it is related to Event Cache GC1234, and we don't want to give anyone an unfair advantage." requests.

 

grnbrg.

Link to comment

It's an interesting idea, and I can see some merit to it. But it would also require that the reviewer have a way to "lock" all the same information that would normally not be able to be changed after a cache is published -- the coordinates, the cache type, etc. Otherwise, you could get a cache reviewed and ready to be "revealed", and then the owner changes something that the reviewer otherwise wouldn't have approved.

 

I wouldn't mind seeing it on a "wish list" that might be incorporated when code is updated for other changes, but I think there are plenty of things with higher priority.

 

BTW, if you want a cache (or set of caches) published at exactly a particular time, the reviewers are usually very accomodating, as long as you ask nicely, are reasonable, and send chocolate. Even if your local reviewer won't be available at 10:07 on Saturday morning, he/she will usually be willing to arrange for another reviewer to publish at the desired time. But don't forget the chocolate. :unsure:

Link to comment

...But it would also require that the reviewer have a way to "lock" all the same information that would normally not be able to be changed after a cache is published ...

 

That code is in place now...when a cache is approved you can't modify these things. It's "just" a matter of changing when the cache is published/revealed to the community. Of course, I have no idea what would be required behind the scenes, but the locking mechanism upon approval is in place and that would not change. The change would only be that the publishing, notifications, etc. would be triggered by the owner's release vs. the reviewer's approval.

 

Sounds like a good idea to me.

Link to comment

Interesting. This came up at an event cache over the weekend. One cache was accidentally published too soon and there were other finders before the event itself. And now, on Wed, several days after the event, Im still waiting for some to be published to log my finds from the day of the event cache. This is a sticky issue. I hope I dont forget my finds lol.

Link to comment
and we don't want to give anyone an unfair advantage."

Speaking of unfair advantage, I can see ways where this could also be abused. A hider could "reveal" his cache at a key time to enable his friend to get FTF, or conversely, at a key time to prevent someone else from getting a FTF.

 

I would support an automated way for the reviewers to set a time for a given cache to be published, but I don't think that control should be in the hands of the hiders themselves.

Link to comment
and we don't want to give anyone an unfair advantage."

Speaking of unfair advantage, I can see ways where this could also be abused. A hider could "reveal" his cache at a key time to enable his friend to get FTF, or conversely, at a key time to prevent someone else from getting a FTF.

 

I would support an automated way for the reviewers to set a time for a given cache to be published, but I don't think that control should be in the hands of the hiders themselves.

You can already do that. Tell your friend what the coordinates are; you can even print a copy of the pending cache page and hand it to him. There's certainly no rule that says you can't let people find the cache before it's published.

Link to comment

It's a good idea as long as the data is frozen.... exactly what WascoZooKeeper said (p.s. Love your tag line)

 

Options could be.... "Submit to Reviewer" or "Save and Not Submit" (actually Waymarking has this already, in some form (can't recall accurately at the moment)).

 

After it is submitted and reviewed then approved it would be FROZEN.

 

You would then have a few choices... "List Cache" or "Edit and Resubmit to Reviewer". That also would solve the issue of the "NEW CACHE" labelling and making Event Listings, Series Listings and Partnership Listings flow easier and relieve the actual Reviewers from this juggling that they are kind enough to entertain as long as it's not exploited.

 

Up until you click "Submit to Reviewer" there should not be any GC# assigned to the cache, so that when it is ultimately Submitted the resulting GC is fairly inline with the current pool of ID's. I dunno about anyone else, but I can spend days getting the cache page exactly how I want it, or get all the details in place. But I write it in Word now, so I've already got a work around for the GC#. Plus I have a 'unused' GC that I use to view before I create the real listing.

 

:unsure: The Blue Quasar

Link to comment
and we don't want to give anyone an unfair advantage."

Speaking of unfair advantage, I can see ways where this could also be abused. A hider could "reveal" his cache at a key time to enable his friend to get FTF, or conversely, at a key time to prevent someone else from getting a FTF.

 

I would support an automated way for the reviewers to set a time for a given cache to be published, but I don't think that control should be in the hands of the hiders themselves.

 

It would also be useful as the request comes up quite often. To list caches the day after an event, just in time for the event, or in time for someones birthday.

 

My personal favorite would be:

 

Monday: "Marry" is approved.

Tuesday: "Me" is approved.

Wednesday "Shiela" is approved.

 

Of course let's hope Shiela knows who asked.

Edited by Renegade Knight
Link to comment

Speaking of unfair advantage, I can see ways where this could also be abused. A hider could "reveal" his cache at a key time to enable his friend to get FTF, or conversely, at a key time to prevent someone else from getting a FTF.

 

I would support an automated way for the reviewers to set a time for a given cache to be published, but I don't think that control should be in the hands of the hiders themselves.

 

By the same token it is often said that the caches belong to the hiders. If that is tuly the case, what's wrong with hiders releasing them as they see fit for whatever reasons they may have?

 

Sure, it could be abused to some extent, but so could having it scheduled for a certain time. If a hider requests a cache to be released at 10 am on a particular day all he has to do is give his buddy a heads up to be watching near that time.

 

That being said, a timed or scheduled release option for the reviewers is also a good idea that merits some consideration.

Link to comment

 

And I prefer to get approval for my caches before I place the container, because there is a chance that I'll get a response like "Sorry, but there's a multi-cache cache 100 ft from there. You'll need to find another spot."

 

grnbrg.

 

If you do your home work you would never have this problem. The guidelines are very clear on this:

Your cache should be in place and ready to hunt at the time your cache page is submitted for review. If for any reason it is not ready, please either disable your cache page so that it won’t be seen by the reviewer until ready, or include a “note to reviewer” to explain your special circumstances (for example, waiting for a permit from a land manager)

 

You have to make a trip back there after the cache is listed your way. If you put it in place first like you are supposed to you would only have to make a trip back if it was not listed. That will work out to less trips for you. No need to race out to beat the FTF AND you would be following the guidelines. Always a good thing to do.

Link to comment

In addition to changing the contents of the cache page after review but before release, another possibility for increased abuse would be waiting for months with a pre-authorized cache. The hidden cache would unfairly block someone else who hides a cache 400 feet away a month later. They *thought* there were no caches in that park. Since in cache dense areas we already have frequent examples of two caches hidden near each other by different hiders on the same weekend by coincidence, I think that problem would only get worse.

 

Based on my experience I would vote for Lil Devil's option for the reviewer to set up the date and time of the publication, if this were technically feasible. There are higher priorities.

Link to comment
another possibility for increased abuse would be waiting for months with a pre-authorized cache. The hidden cache would unfairly block someone else who hides a cache 400 feet away a month later. They *thought* there were no caches in that park.
No problem. If somebody puts a cache one meter from the first cache and the new cache is published before the first one, the first one automaticly gets the approval revoked.

 

Second the option to publish the cache myself after it has been approved. :laughing:

Link to comment

In addition to changing the contents of the cache page after review but before release, another possibility for increased abuse would be waiting for months with a pre-authorized cache. The hidden cache would unfairly block someone else who hides a cache 400 feet away a month later. They *thought* there were no caches in that park. Since in cache dense areas we already have frequent examples of two caches hidden near each other by different hiders on the same weekend by coincidence, I think that problem would only get worse.

Although experience also shows that if you have a good reason for a reasonable delay between review and publication, the reviewers will work with you. For example, last fall I had six people placing 26 new caches which were to be published in connection with an event; the reviewer agreed that we could start having them reviewed 4 weeks prior to the event, which of course effectively "blocked" those areas for almost a month for other new caches. This was all arranged in advance with the reviewer, of course.

 

And simple courtesy goes a long way. Even before the four week period, I spotted that one of the local cachers had started placing a number of new caches. I just dropped him a polite note, told him what we were doing about caches for our event, and suggested he get in touch with the person in our group who was placing caches in his area so they wouldn't "step" on each other. He was more than happy to cooperate with us.

Link to comment

There can be VERY good reasons to block other caches in certain areas.

I have had to do this on several occasions while negotiating for permission to plant a cache to prevent another cache bieng placed.

 

I agree with the OP we like our caches to go live ready for the weekend to increase the chances of different people obtaining the FTF as all of our early caches were found first by the same cacher his advantage being he works nights and needs no sleep during the day. :laughing:

To be able to time the release ourselves would be a nice value added feature that removes the need to ask reviewers to hold caches till the weekend etc etc which is how we currently manage this.

Link to comment

... another possibility for increased abuse would be waiting for months with a pre-authorized cache. The hidden cache would unfairly block someone else who hides a cache 400 feet away a month later...

 

An expiration date or time liimt function could be built in so that if the cache is not released within a certain period after approval, then it is autmaitcally archived and would have to be resubmitted, but the 2nd time without the hider release option.

Link to comment

You could always have a field for the publish time on the cache page. The approver would be approving that publish time with the cache. That way they can have rules for how far in advance is okay. That and the system will then automatically publish the cache at that time, removing the need for the owner to do it.

Link to comment

Up until you click "Submit to Reviewer" there should not be any GC# assigned to the cache, so that when it is ultimately Submitted the resulting GC is fairly inline with the current pool of ID's.

I produce FTF prizes that are cache specific and include the GC#. Unless I know what it is in advance then I can't do this so I disagree with what you've just said :D

Link to comment

... another possibility for increased abuse would be waiting for months with a pre-authorized cache. The hidden cache would unfairly block someone else who hides a cache 400 feet away a month later...

 

An expiration date or time liimt function could be built in so that if the cache is not released within a certain period after approval, then it is autmaitcally archived and would have to be resubmitted, but the 2nd time without the hider release option.

Wow. :D

 

How complicated can we make this? :D

 

I haven't seen much discussed so far that can't be handled simply by having a dialog (or dialogue, if you prefer :D ) with the reviewer. Why is that such a problem?

 

Personally, instead of doing a lot of work for a relatively small number (and percentage) of new caches, I'd rather see programming resources spent on getting WAP to work seamlessly. :D

Link to comment

Up until you click "Submit to Reviewer" there should not be any GC# assigned to the cache, so that when it is ultimately Submitted the resulting GC is fairly inline with the current pool of ID's.

I produce FTF prizes that are cache specific and include the GC#. Unless I know what it is in advance then I can't do this so I disagree with what you've just said :D

 

For my last several hides, I have started the cache page before hiding the cache. I wanted to do this to make sure that the page was right before submitting it. As a result I had the gc# before making the hide. In fact some reviewers advise doing it this way. Just remember to uncheck the box that says the cache is available. Why is it so important to keep the gc#s in any kind of order? There are other more important things to worry about than the order of the gc#s.

Link to comment

Wow. :D

 

How complicated can we make this? :D

 

Just kickin' around ideas. Ain't that kinda what a forum is for?

 

I haven't seen much discussed so far that can't be handled simply by having a dialog (or dialogue, if you prefer :D ) with the reviewer. Why is that such a problem?

 

I don't think anyone said it was a particular problem, but part of the discussion has been to relieve the reviewer of dealing with this kind of stuff and put some of it the cache owner's hands. But I guess then if it got screwed up, the owner wouldn't have the reviewer to blame. :D

 

Personally, instead of doing a lot of work for a relatively small number (and percentage) of new caches, I'd rather see programming resources spent on getting WAP to work seamlessly. :D

 

I'm holding out for a simple solution to caches along a route via PQ! :D

Link to comment

Up until you click "Submit to Reviewer" there should not be any GC# assigned to the cache, so that when it is ultimately Submitted the resulting GC is fairly inline with the current pool of ID's.

I produce FTF prizes that are cache specific and include the GC#. Unless I know what it is in advance then I can't do this so I disagree with what you've just said :D

 

You can create a cache page without enabling it. If you're concerned that your reviewer is so on the ball that they'll list your submission in the few seconds it takes you to disable the page, submit it with useless infor such as coordinates in the middle of the Atlantic or something. Then edit the page at your leisure. Enable when the cache and the First To Find prize is ready and in place...

 

In this instance, 'Submit to Reviewer' is another way of saying 'Enable so it's in the Queue'.

Link to comment

Up until you click "Submit to Reviewer" there should not be any GC# assigned to the cache, so that when it is ultimately Submitted the resulting GC is fairly inline with the current pool of ID's.

I produce FTF prizes that are cache specific and include the GC#. Unless I know what it is in advance then I can't do this so I disagree with what you've just said :D

 

You can create a cache page without enabling it. If you're concerned that your reviewer is so on the ball that they'll list your submission in the few seconds it takes you to disable the page, submit it with useless infor such as coordinates in the middle of the Atlantic or something. Then edit the page at your leisure. Enable when the cache and the First To Find prize is ready and in place...

 

In this instance, 'Submit to Reviewer' is another way of saying 'Enable so it's in the Queue'.

Even easier -- uncheck the box on the "New Cache" form:

 

activenew.jpg

Link to comment

yup that's what I've done with 2 caches I have in progress. Made the pages a few days ago, there's stages, but the final is still here in my room, it and the last stages will be placed over the weekend. I made the page up early so I could fix it up the way I wanted, I made a few changes along the way as well.

 

If you want to see if your coords are ok, just email your reviewer, I did that and mine was more than happy to check them for me.

Link to comment

Personally I think this is a great idea. It takes a bunch of work load from the reviewers and allows activation times which suit the owner.

 

Most of my caches I prefer to activate on a Friday afternoon or evening to give people with weekday jobs the same advantage of a FTF as those who do not. As the review process can take a week or more around here, you currently need to ask the reviewer to release at the correct time. I find this being a big ask for a volunteer as it forces them to be at a computer at a certain time.

Link to comment

Personally I think this is a great idea. It takes a bunch of work load from the reviewers and allows activation times which suit the owner.

 

Most of my caches I prefer to activate on a Friday afternoon or evening to give people with weekday jobs the same advantage of a FTF as those who do not. As the review process can take a week or more around here, you currently need to ask the reviewer to release at the correct time. I find this being a big ask for a volunteer as it forces them to be at a computer at a certain time.

But your local reviewer doesn't have to be the one to push the "Publish" button. If you make a reasonable case as to why your cache should be published at a specific time, I am confident that your reviewer will make a reasonble effort to accomodate you. If they can't publish it themself, they'll ask another reviewer to do it at the designated date/time.

 

But be reasonable about it. Don't just insist "all my caches must be published at precisely 8:00 AM on Saturday morning". Asking for "Saturday" will probably get by. Asking for "early on Saturday" would probably be OK. And be willing to give a little -- if your reviewer says, "I'm out of town on Saturday, would Sunday be OK?" -- "Yes, thank you very much" is an appropriate response.

Link to comment

 

But your local reviewer doesn't have to be the one to push the "Publish" button. If you make a reasonable case as to why your cache should be published at a specific time, I am confident that your reviewer will make a reasonble effort to accomodate you. If they can't publish it themself, they'll ask another reviewer to do it at the designated date/time.

 

But be reasonable about it. Don't just insist "all my caches must be published at precisely 8:00 AM on Saturday morning". Asking for "Saturday" will probably get by. Asking for "early on Saturday" would probably be OK. And be willing to give a little -- if your reviewer says, "I'm out of town on Saturday, would Sunday be OK?" -- "Yes, thank you very much" is an appropriate response.

 

Which is the primary reason for the feature request. There are a number of very legitimate reasons to have "all 17 caches published at exactly 7:04am on Saturday morning", and this is an unreasonable request to make of the reviewers.

 

The reviewers job is to make sure all submitted caches are within the published guidelines, and are not too close to existing caches. Anything beyond that is an inconvenience that they need not worry about, although most are quite happy to accomodate.

 

Since *when* a cache is published is not likely to somehow change whether or not a cache *should* be approved, why not give the option to do so to the cache owner, who arguably would have more interest in when a cache is published than anyone else?

 

grnbrg.

Link to comment

You could always have a field for the publish time on the cache page. The approver would be approving that publish time with the cache. That way they can have rules for how far in advance is okay. That and the system will then automatically publish the cache at that time, removing the need for the owner to do it.

This would encourage people to submit caches that they haven't actually placed yet. You've set the cache to be published at 6pm, because you're going to put it out right after work. But then life, which cares nothing about your plans, intervenes, and people are out at 6:09pm looking for a cache that isn't there.

Link to comment

I actually don't object to having an ability to launch certain caches - a countdown of sorts. The issue here is that there are so many places where cache data is displayed that it would be difficult to go back and make sure that we closed each and every hole where a cache could be viewed before its time.

 

It could be abused, but much of things can already be abused. It's the implementation of this which would be a big challenge. I will give it some thought and as we move forward will look into at least making this option available sometime in the future. At that point we can deal with the consequences of having such a feature.

Link to comment

 

Up until you click "Submit to Reviewer" there should not be any GC# assigned to the cache, so that when it is ultimately Submitted the resulting GC is fairly inline with the current pool of ID's. I dunno about anyone else, but I can spend days getting the cache page exactly how I want it, or get all the details in place. But I write it in Word now, so I've already got a work around for the GC#. Plus I have a 'unused' GC that I use to view before I create the real listing.

 

 

I don't like that idea at all - I have on occasion used the GC number as an intergral part of the puzzle for a puzzle cache and knowing it while working on the cache description and the details of the puzzle itself (or, on one occasion, the physical cache container) is very useful.

 

The minimal benefit of having numbers "fairly inline with the current pool of IDs" doesn't seem a particularly strong reason for doing this.

 

Back to the OP - I agree that some feature that minimises the reliance on volunteer reviewers to be at their computer at a particular time could help a lot of people and, as far as I can tell, harm none.

Link to comment
There are a number of very legitimate reasons to have "all 17 caches published at exactly 7:04am on Saturday morning"

 

What are these reasons????

 

Two concrete examples:

  • We're having a CITO event on Saturday, and in conjunction with this, there are four new traditional caches that will be the 'targets' of the CITO drive.
  • Another organization held a "Hide and Go Cache" event, where members hid caches in a week or two leading up to the event, which were published en masse.

And a few speculative examples:

  • I could run a cache-based contest where I want to publish several game caches, one at a time at specific (ie: daily, or weekly) intervals.
  • I might want to create an aniversary/birthday/holiday cache, and want it to be published on a specific date.
  • I might want to give more people a shot at the FTF, and publish on a Saturday afternoon.
  • I might want to publish a cache at a time where I know *I* can show up as it is published to laugh at those trying to find it. (An enjoyable passtime, actually...)

Yes, all of this can currently be done by nicely asking the reviewer to publish at a specific time, but some of the reasons are hardly compelling, or important, just 'nice'. And fufilling some of them (like the 'Hide and go cache' event) can be a fair sized organizational burden for the reviewer.

 

grnbrg.

Link to comment
There are a number of very legitimate reasons to have "all 17 caches published at exactly 7:04am on Saturday morning"

 

What are these reasons????

I cited an example earlier in this thread, although not that exact. We had 26 new permanent caches placed for a breakfast event. We made the coordinates and other information available to people at the event, and wanted the attendees to have first chance at finding the caches.

 

We asked the reviewer to publish them on the evening of the event, though not at a specific time. He quite graciously obliged.

Link to comment
There are a number of very legitimate reasons to have "all 17 caches published at exactly 7:04am on Saturday morning"

 

What are these reasons????

 

Two concrete examples:

  • We're having a CITO event on Saturday, and in conjunction with this, there are four new traditional caches that will be the 'targets' of the CITO drive.
  • Another organization held a "Hide and Go Cache" event, where members hid caches in a week or two leading up to the event, which were published en masse.

And a few speculative examples:

  • I could run a cache-based contest where I want to publish several game caches, one at a time at specific (ie: daily, or weekly) intervals.
  • I might want to create an aniversary/birthday/holiday cache, and want it to be published on a specific date.
  • I might want to give more people a shot at the FTF, and publish on a Saturday afternoon.
  • I might want to publish a cache at a time where I know *I* can show up as it is published to laugh at those trying to find it. (An enjoyable passtime, actually...)

Yes, all of this can currently be done by nicely asking the reviewer to publish at a specific time, but some of the reasons are hardly compelling, or important, just 'nice'. And fufilling some of them (like the 'Hide and go cache' event) can be a fair sized organizational burden for the reviewer.

 

grnbrg.

 

None of your reasons explain the need for EXACTLY 7:04 AM on a Saturday. You have stated you have reasons that show why it needs to be done at exactly a certain time. I am asking to see those reasons. The reviewers are not complaining about the work load. Its not broken. Lets not fix it.

Edited by CO Admin
Link to comment

Here's my 2 cents. I think the idea is a good one, with some "conditions". There should be a limit on how far in advance you can place the cache before it is published, after all, someone is likely to see some great spots, and decide to "save" them and not get around to actually using them for a few months. Let's say no more than 3-4 weeks. It will take some of the workload off of the reviewers, let's face it, they are volunteers, and I'm in favor of anything that helps lighten the load for them. Also, if the reviewer in the area usually publishes caches around the same time each day, it won't take long for the FTF hounds to figure out when they need to be online to check, this would help to spread out the chances for an FTF. I can also see some inventive cachers using this feature to add a new twist to the game.

Link to comment
and we don't want to give anyone an unfair advantage."

Speaking of unfair advantage, I can see ways where this could also be abused. A hider could "reveal" his cache at a key time to enable his friend to get FTF, or conversely, at a key time to prevent someone else from getting a FTF.

 

I would support an automated way for the reviewers to set a time for a given cache to be published, but I don't think that control should be in the hands of the hiders themselves.

 

Yeah and then we have the problem of the wide spread use of telephones and cell phones. <_<:(:huh:

Link to comment

Would it be possible to change the cache approval process to allow the owner to decide when the cache is revealed to the public? ie: Allow a cache to be placed, reviewed and approved by reviewer, but have the final step that allows the cache page to be visible, instant notifications to be published, etc be (even optionally) at the cache owners discretion.

 

This would allow caches associated with a particular event to be published en mass by the event organizers without needing to co-ordinate with the reviewers.

 

It would also allow individual users (Ok, me. I like doing things this way...) to plan out a cache, develope the cache page, go through the full review process (in case there are any changes required) and once the cache is approved, place the container(s) at their sites. Right now I get to race the FTFers to the spot. <_<

 

This could be done (for example) by adding a "Ready for Review" attribute, similar to the current "Cache is Active" attribute, and allow reviewers to see any cache marked "Ready for Review", regardless of the "Active" flag. The current logic that prevents general users from seeing caches not marked Active would remain.

 

I do realize the programming headaches such a change might entail, but it's a feature I think would be well recieved.

 

Thanks!

 

grnbrg.

 

Of course it is possible. Don't expect to see it during your lifetime. :huh:

Link to comment

My previous suggestion was not intended to shut out people that create prizes, or even label their caches with GCID's (which is a good idea to do IMHO). It was just an option that crossed my mind related to the specific question posed.

 

However.. I like the "Release Date and Time" option that was proposed. And the argument that people could exploit this feature is not valid since that already happens without this enhancement. People get caches approved that aren't actually in place.

 

With the "Release Date and Time" proposal, you are getting both the control to have it come online at the right time, without having to make arrangements with the Reviewer or remember yourself (especially if you are 'away from the keyboard' when you need it released)

 

The Reviewers job doesn't change, since it is still in the Database and they can see that there is a cache 'primed for launch' that would interfere with any new cache that comes down the pipe.

 

But there would have to be a time limit, like there is for Events... example, "You must set a Release time within the next 14 days" and there could be a checkbox with "Now"

 

I know CO ADMIN said that the Reviewers aren't complaining about this, but like someone else said, and we did this too... We placed three caches for our CITO today, and asked our Reviewer to hold them till tomorrow (Sunday) which he agreed to. But with this option, he wouldn't have to remember or even have to deal with it. He would be right back to Reviewing and Listing.

 

It's about enhancing the process for everyone involved. But I can see how this could be an additional drain on resourses, and of course the occational debate about why a new cache cannot go in because a 'timed cache' is already there. But those happen now too.

 

:laughing: The Blue Quasar

Link to comment

Now this is a great (at least I think so :)) example of why the OP (or maybe someone else, can't remember and don't want to go through 45 other posts) has such a great idea. Having a date and time would work.

 

What if I wanted to have a post in, say, 30 minutes in reply to my above post saying "Just kidding!".....?

 

It's the same idea as with the caches. Probably not the greatest example, but I got nothing else to work with. :)

 

I think it should be an automated system, though. If the hider had to manually add it when they saw fit, you couldn't release it for an event, because you'd have to be at the event.

 

However, times might be slightly different on the site compared to your watch or home clock. If you wanted it posted at 8:34 and your time zone setting is an hour off, it might post it at 7:34 or 9:34.

 

Also, it would absolutely kill the servers (bandwidth) figuring out "Okay, it's 3:00 here, they're in CST, that's 4 hours ahead, that's 7:00, gotta post it in 2 minutes". Just multiply that by around 2,000... Yeah, you get the idea.

 

Overall, I think that the OP's idea is the best, but he (or someone) should work with Jeremy and try and figure out how to do it.

 

Of course, another way of looking at it is: Jeremy said he'll work on it, so this is done. So :laughing: to all of you. :) :)

 

EDIT- With a post this long, how can you not have an error?

Edited by icefall5
Link to comment

Just a relvant followup regarding our CITO event this weekend.... :lol:

 

The event itself went very well, with four different caches being placed and cleaned up -- nearly 70 bags of trash collected, and mention in the local paper, and even a brief spot on the news.

 

However, because the organizers weren't sure that the four CITO caches would be published at a given time, they decided not to mark them as 'active', and just distributed printouts of the unreviewed cache pages at the initial meet-up on Saturday morning, letting people know that the caches would be published in the next day or two, when the reviewers got to them.

 

Three of the four were published properly Sunday morning. The other turned out to have multi-cache waypoints nearby, and needs to be moved.

 

Admittedly, the organizers could have done this somewhat differently, activated the caches before the event for review, but they didn't. Giving the owner some control over the release (such as being able to specify a release time, as has been suggested in this thread) would have prevented this.

 

grnbrg.

Link to comment
Giving the owner some control over the release (such as being able to specify a release time, as has been suggested in this thread) would have prevented this.

But they already *do* have control. All they have to do is ask for them to be published at a certain time. It even says so in the guidelines.

 

If you are placing a large number of caches in connection with an event cache, to be released on the day of the event, 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 for an event, and 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.

Just because the organizer of the CITO event failed to take advantage of the existing system does not mean that the existing system is broken.

Link to comment
Giving the owner some control over the release (such as being able to specify a release time, as has been suggested in this thread) would have prevented this.

But they already *do* have control. All they have to do is ask for them to be published at a certain time. It even says so in the guidelines.

But this is the whole reason this post was started. This feature would remove the need of the reviewer to be at the computer at 8:00 AM on Sunday morning. If the reviewer can't be there and can't find another reviewer who can, then its too bad for you, can't do it.

Edited by icefall5
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...