Archiving Popular Caches

[+Corp Of Discovery]

All right, Keystone...get it back on topic, or I'll shut this thread down!! I mean it!!!

Now THATS irony. j/k

 

I'm not NORM, I'm ABNORM.

[+Team GPSaxophone]

Ahhhh.... July 2002.... such fond memories of the days when Mitsuko ruled the forums, I was a newbie bragging about my 25th cache find, and Mopar was busy kissing the collective behinds of TPTB.

 

18 months later, half the people on the forums don't know who Mitsuko is, I'm now a forum moderator disciplining wet cats with 25 cache finds, and Mopar .... well, at least some things never change.

Sparky only has 22 cache finds.

 

Just thought I'd point that out, you may continue your discussion now.

 

 

 

 

Oh, and I remember who Mitsuko is

[+CacheCreatures]

...know who Mitsuko is...

 

Anyone know if she's still available? I'd love to get her phone number.

 

The wayback machine can be found here by the way: Wayback Machine

[MOCKBA]

I don't think that archiving the YJF really solved the performance issue explained by Keystone. The cache won't be queried for PQs but the same did-the-user-ever-found-it question should exist in searches by userid (which do show archived caches).

[+mtn-man]

Then there is this cache, which has also been archived for no apparent reason.

No apparent reason? Looking at that cache and at the hider's other caches it appears he abandoned his caches. He has one cache that sat for 18 months after it was reported missing, and when a different admin archived that one, he mentioned the hider hadn't even logged into the site for 4 months. I suspect the virtual you mention probably got complaints about it not being maintained, or else I doubt it would have been archived.

And as you can see he responded to the archiving of the cache I mentioned on the very day it was archived. It seems to me there is a thread regarding holding the cache hider responsible for maintaining their caches. The starter suggests to have the hider be required to post a note every 4 months to show that they are taking care of their caches. It seems that most people who posted to that topic would be opposed to that. That is all well and good, BUT the admin specifically mentions that maybe now a traditional can be placed, that to me shows a bias that MAY have had to do with it being archived- and THAT would be wrong.

 

Does anyone know that there is a SPECIFIC requirement to log onto this site to keep your caches from getting archived?

 

KA- thnx for the info, that should clear up any questions anyone may have.

I have to say that I am personally offended by your post. I have made my feelings well known regarding virtual caches. I like them, I have created them and I find them. I also adhere to the guidelines as far as my virtual caches go. I answer every email every time. I hear so many people say they never get an answer back when they email the required answers. People thank me often for my replies and have mentioned that few people write back.

 

I stated very clearly why I archived the cache. The cache owner let two of his three caches that have been clearly logged that they are in bad shape go unattended for months. One had a Should Be Archived (SBA) note posted to it (which the cache owner has now deleted). It was archived per the SBA request. I looked at his other three caches and saw that he has yet another cache that has also been in bad disrepair since August 2003. People have been requesting a new container since May 2003, over 8 months. Since I do know the guidelines I decided to archive his virtual cache since he appears to have abandoned his caches. Suddenly he pops out of the woodwork! It is amazing that archiving the cache will suddenly get the cache owners attention. Well, its not that amazing. He emailed me about his virtual cache. I told him that he needs to take care of his traditional caches that have been in disrepair for far too long before the virtual could be unarchived. He never wrote back. How amazing is it that he suddenly logged all of his cache pages with notes on the same day the virtual was archived. It is not that amazing to me. He has done nothing with the cache that is full of water in almost two weeks. He does not seem to be that interested in maintaining his caches. In fact, he has not visited the site again since his little flurry of notes on January 14. If he was worried about the caches he has placed then he would take care of them.

 

I don't archive caches on a whim. I am offended that you think that.

 

I guess it is unfortunate that you picked such a poor example for your argument.

[MOCKBA]

Mtn-Man,

what a funny post, really! "The owner wouldn't maintain a cache. So to punish him, I archived his OTHER cache, which by the way didn't have any maintenance problems".

The truth was better than fiction, thanks. I feel really sorry for the s*ckers who support this site and these attitudes with their money.

[+Lazyboy & Mitey Mite]

I love everyone, even moderators, I do.

 

Mtn-man has approved every cache I've ever submitted when he's active doing it. Never had a problem, never expect one. Ya gotta pick someone else to take shots at.

[+CacheCreatures]

The truth was better than fiction, thanks. I feel really sorry for the s*ckers who support this site and these attitudes with their money.

 

You do realize you're supporting a placer that has, in every way, disrespected what this is all about, don't you? Normally, I'd be offended at someone calling me a sucker, but in your case its just comical.

 

mtn-man, this caching couple thinks it was your right, and responsibility to act as you did.

 

CacheCreatures

 

edit(s): spelling

Edited January 26, 2004 by CacheCreatures

[+Team GPSaxophone]

Mtn-Man, I fully support your archiving that guy's virtual based on the evidence you gave. If he's not willing to maintain his caches, he shouldn't list them here.

[+fizzymagic]

I told him that he needs to take care of his traditional caches that have been in disrepair for far too long before the virtual could be unarchived.

Mtn-man, I know you and I respect you, but I am concerned about this decision. To date, the approval status of any cache has only been dependent on the condition of that cache, not on the condition of other caches owned by the same person. Changing that is a very significant modification of the approval process.

 

The problem is not that there wasn't adequate reason to archive this cache, but rather that the system will lose credibillity if it becomes apparent that the approvers archive caches of people on their "blacklists." While none of the current approvers might abuse such an ability, I think that even the perception that they could is poisonous.

 

Personally, I think a system should be implemented whereby cachers gain "points" for good hides, and earn more latitude in their hides as they gain experience. Such a system must be completely even-handed, or it will fail. So my concern is not so much for this one case, but for the precedent that it sets. Please consider only archiving specific caches for which there have been specific complaints that the hider has not addressed.

[+New England n00b]

The problem is not that there wasn't adequate reason to archive this cache, but rather that the system will lose credibillity if it becomes apparent that the approvers archive caches of people on their "blacklists."

 

The bigger problem (as I see it) is the loss of credibility for the caches listed here if the caches are not consistently maintained. I think, in this instance, with evidently all their caches in neglect, the decision was a wise one, and better for the overall health of GC.com

 

In the long run, noone is going to be happy with every decision, but you do what you have to do to try to ensure the integrity of the caches listed as best you can.

 

I know that if many of the caches I visited were worthless, I might opt to find another use for my GPS and time. So they gotta do it.

 

That's all I got.

Edited January 26, 2004 by New England n00b

[+mtn-man]

To date, the approval status of any cache has only been dependent on the condition of that cache, not on the condition of other caches owned by the same person.  Changing that is a very significant modification of the approval process.

Fizzy, I understand. This cache was not up for approval. It was an existing cache that failed according to the guidelines.

Virtual Cache Maintenance Guidelines

 

Although the virtual cache is not something you physically maintain, you must maintain your virtual cache's web page and respond to inquiries and periodically check the location. You should also return to the Geocaching.com web site at least once a month to show you are still active. Virtual caches posted and "abandoned" may be archived by the site.  The poster will assume the responsibility of quality control of logged “finds” for the virtual cache, and will agree to delete any “find” logs that appear to be bogus, counterfeit, off topic, or not within the stated requirements.

A cache owner has one cache stolen and does not even disable the cache or log a note of any kind and leaves it that way for months. They have another cache where "The cache had water in it and the top off. The top wouldn't fit so I left it upside down to try to keep the water out." It is also in disrepair for months. It does not seem fair to leave an unmaintained virtual cache active when other active and responsible cachers could make a new cache.

 

I do understand the big picture aspect of your post. I've never heard of this cacher before someone requested that his clearly unmaintained cache be archived. There would be no blacklist and I know that you know me well enough to know that I am fair. Despite MOCKBA's misquote post that he attributed to me, if he placed a cache that is within the guidelines I would approve it in a second. If I don't, then I will be quickly removed as an admin for abusing the system. We walk on eggshells enough as it is since any slight mistake is pointed out (maybe that is actually a bed of broken glass ).

[+Corp Of Discovery]

Mtn-man: I surely meant no disrespect. It might have been better to just leave out the part about a traditional being able to be placed in your archive note. Please also see my subsequent posts in response to Mopars posts.

[ju66l3r]

Then there is this cache, which has also been archived for no apparent reason.

Dude, that is really uncool, mtn-man.

 

Let me expand on that after reading the rest of the thread...

 

That is really uncool *that the virtual cache is still archived*. It is clear that any cache which requires maintainance and is left unattended should be archived (and the container/contents put in the local forum for someone to retrieve if the owner is incommunicado).

 

But each cache should be judged in and of its own rights. Since a virtual cache's maintainance is simply "is the object of the cache still available to the finders and is the hider still responding to verification mail" and both of these seem to be in order for this specific virtual cache, then it should not be archived (and the part in the rules about logging in every 4 months should be removed).

 

As RK pointed out, logging in does not equal responsible for their caches and vice versa is also true. Since a hider's cache logs are mailed to them, there is nothing that requires logging in. I'm sure if you asked the last 2 finders or even sent a note to the hider, you would have found out that the virtual is still well attended even when the physicals are not.

 

I'd ask that you reconsider the archival of that virtual and reinstate it.

 

As for the greater issue in this thread, a well organized relational database is clearly what is required here and if PQs are wandering through every log entry until they find your's then there's seriously something wrong with that program.

 

Caches and finders are a many-many relationship and there are much more efficient ways for extracting information from the db than scanning every log entry to determine if the user found a specific cache. Hopefully, the current revamp of the codebase will take care of this, because if not, then all the $3 fees in the world won't buy the servers necessary to handle that sort of load.

 

Seriously though, you *can* program a quarter-billion record relational database with proper indexing on a cluster of simple desktop computers and slam it a few million times a month and not have many problems at all.

Edited January 26, 2004 by ju66l3r

[+robert]

18 months later, half the people on the forums don't know who Mitsuko is, I'm now a forum moderator disciplining wet cats with 25 cache finds, and Mopar .... well, at least some things never change.

25?!?!? Since when!?!?

[+Sparky-Watts]

Juggler, thanks for getting the thread back on topic.

 

Now I need to be a tad off-topic:

 

Mtn-man has the right to defend his actions concerning the other cache. I applaud him for stepping up and doing so. I have heard in other discussions about cache approval that the approver is also asked to take a look at the placer's other caches in making their decision to approve. This has been brought up most in the discussions about vacation caches, however, I feel it's appropriate to look in all cases. Is it appropriate to make decisions based solely on other caches placed by that person? Of course not, otherwise, no one would ever get their first cache placed. But showing a lack of response on other caches indicates a lack of maintenance on all of them.

 

For further discussion of that cache and the decisions made by mtn-man, please open a new thread. This thread is centered on the archival of the YJF cache, it's ramifications, and possible solutions.

[+Mopar]

Seriously though, you *can* program a quarter-billion record relational database with proper indexing on a cluster of simple desktop computers and slam it a few million times a month and not have many problems at all.

Except that in Grizzly's example, it was one decktop PC, not a cluster, and it's probably closer to millions of times a day, not a few million a month. Still doable?

Edited January 26, 2004 by Mopar

[+GrizzlyJohn]

Except that I don’t think this site is getting millions of page views per day. You said 30 mil page views per month. That is 1 million page views per day, so traffic would have had to double before it got to millions per day. Maybe it has I don’t know. But it does not really matter anyway.

 

No I don’t think the app I was running was getting a million page view per day. But the best I can tell the databases I was using were larger than here. But to be honest it is not a number that really mattered to me anyway. I kept on eye on how well the database was performing. Page views do not mean anything to the amount of work the database is doing. Not every page view means that something is being done on the database. So if a site did have millions of page views a day but only rarely has to hit a database what does that have to do with any kind of relation to the database and the growth of the site? The opposite is also true some sites are very database intensive in producing pages and can start to lag with very few hits.

 

The number of new users also really does not mean much either. Again that does not imply anything as to the amount of usage of the database. And also the question here is PQs, which are available to paid members and number which we have no idea about the amount of growth. And then how many PQs those people are running. My best guess is that about 100 new PQs are being created everyday but that really does not tell us how many are being run a day.

 

But even all of that said none of it should really matter. The web server should be its own box. The database server should be its own box. The PQs, from my understanding, runs on its own box. The email should be running on its own box. In fact it is again my understanding that the database used by PQs is not the same database used to generate the rest of the web site.

 

Yes my example did use a desktop PC, it can be done. Maybe a cluster would be better for this web site, but for me there are too many unknowns to say that. Yes all applications are different so one can’t always make general statements. But the basics are always true, and that is where a scalable solution starts. Indexing the databases, writing efficient stored procedures and just in general good programming practices, these will take you a long way in delivering a scalable product. I happen to think that all of those things should be milked before throwing more hardware at the problem.

 

But certainly just stopping taking entries is not an answer. How does that become acceptable in anybody’s mind? Is there anybody here that would think they would still have a job if that is how they did things? Is there anybody that would find that answer acceptable on any other site than this? I would be embarrassed if that was my answer. I would have to make up something else. And the users of this site should also have to really wonder about it if that is how the problems are answered and TPTB think people are that willing and or dumb to just accept that answer. Oh but as others have pointed out there is an upgrade on the way. All problems will be solved. It will be great. Stop complaining things are going to get better soon. We have been hearing that for I am guessing nearly a month. TPTB have done little to nothing in getting us any kind of ETA or what features to expect. Just that they are working on it. If nothing else I think we are starting to see just a large amount of frustration. And I can’t blame anybody and TPTB don’t really seem to care. But hey I am just a martyr what do I know.

[+Mopar]

All very valid points, GJ, and I don't think anyone but a few people know the full answer.

 

I do know that one reason YJF was archived was due to PQ issues, and that fact made me rethink how some of my PQs are setup. I admit I had (past tense, I deleted them last nite) several 500 cache PQs running every Fri. and Sat. for no reason. They were set up for a caching trip to another state back before Xmas. Since they are currently only selectable as a weekly thing, I was still getting those 1000 caches, 2x every weekend, when server load is highest, and deleting the email when it came.

I bet I'm not alone.

I know the PQ section of the site is a high priority, but maybe if we all deleted or disabled all those PQs we aren't using, the strain of popular caches like YJF wouldn't be so noticable. Just a thought.

[Swagger]

Ditto what GrizzlyJohn said. The solution is to develop a more efficient database structure/queries/stored procs/etc.

 

If searching through the logs to look for a certain user was a problem (1200 records isn't exactly a lot for a database to search through, but whatever), I propose a new table in the DB. Two columns - one with the userID, the other with a comma-delimited list of the GC#s of their found caches. With that, the PQ generator wouldn't have to touch a cache's logs except to grab the 5 most recent.

 

Just a thought. Something needs to be done to FIX the problem, as it's not going to go away and archiving popular caches is only going to raise the ire of a large number of cachers.

[ju66l3r]

Except that in Grizzly's example, it was one decktop PC, not a cluster, and it's probably closer to millions of times a day, not a few million a month. Still doable?

I do not know for sure obviously, but I'm willing to guess that "30 million in a month" also took into account the forums.

 

The number of times the cache database was hit for anything bigger than a single log entry (like a PQ) is still limited to hundreds of thousands a month in my estimation. Also, as GJohn pointed out, most of the database look-ups for webpage hits should not be search-intensive. There should be few if any table joins so it's not like the database should struggle if everyone tried to look at their five closest caches at once. If people are asking bad PQs, then that is a different problem. It sounds more like PQs don't really expire and are limited only to the imagination in what they can ask for from the database. The answer isn't to kill YJF-sized caches, it's to cap the crazy PQs and require users to renew their selections every month or so.

[+Mopar]

I don't think anyone, especially TPTB said that archiving caches when they reached 1200 logs was the perm solution. We already know they are redesigning the behind scenes side of the site, and we already know that the PQ section is being redone as we type. I would like to think these issues are on the list of things to fix. If we see a new PQ section come online and nothing is fixed, then complain away.

[+cacheKidds]

Dude, that is really uncool, mtn-man.

 

 

I agree with that. Absurd.

[+mtn-man]

Mtn-man: I surely meant no disrespect. It might have been better to just leave out the part about a traditional being able to be placed in your archive note. Please also see my subsequent posts in response to Mopars posts.

Yes, your point did indeed hit home and will be taken into consideration in the future. That wording was not correct and I will avoid it in the future. No worries.

 

ju66l3r, he never wrote back after I sent a reply. The cache owner either appears not to care or does not follow up on email as well as he says on the cache log.

 

Sorry Sparky. I agree this is a discussion belonging in another topic.

[+Sparky-Watts]

Not a problem, mtn-man. Smurf-boy has opened a thread on that discussion here. Anyone wanting to discuss it can do so in that thread, I'll keep this one open for discussions on the archival of YJF.

[+Team GPSaxophone]

Not a problem, mtn-man. Sax Man has opened a thread on that discussion here. Anyone wanting to discuss it can do so in that thread, I'll keep this one open for discussions on the archival of YJF.

Maybe Locationless PQ's shouldn't look to see if you've found it or not. Unless you've found a lot of them, you'd probably know when looking at the list. There is a Locationless cache checklist out there, just print it out and keep it with your cache supplies.

[+Corp Of Discovery]

In a brief search it appears that Water Towers (1065 logs as of today) and US Flag (926 logs as of today) would be next on the watch list to be archived for too many logs. There were a few others with 700 or more and alot with 200 and more logs.

 

Is there an easier way to search for the number of logs other that to look at each one?

[+E = Mc2]

The Saxy Smurf wrote:

There is a Locationless cache checklist out there, just print it out and keep it with your cache supplies.

You can access one such page by clicking here. This page is broken down by type of cache. Would be nice if they'd also list the GC designation too, but it's a SpaceA thing. Of course, one could always load the page into Plucker and get all of them at once! I'm sure there are other similar pages, but this is the one I use.

 

Now I know why my father hasn't been able to find this cache after I told him about it!

[+mtn-man]

Locationless caches are an interesting study.

 

For the water tower one, the cache owner says,

2 rules, you can only log this cache once and it has to be a recent picture, not an old vacation photo or internet download. Each tower may only be logged once.

Well, on November 17, 2003 three cachers all logged the same water tower with a find. Two of them did not even post pictures and only wrote, "See OzGuff's log below." Even more interesting are these two logs.

 

December 18, 2003

May 23, 2002

 

Yes, it is the same water tower with photos a year and a half apart.

 

Um, and three cachers have logged this cache twice and yet another has logged it three times (though one was a duplicate). One cacher has logged it five different times (so far), with all of them on different days within a three week period and three of them three days in a row.

 

The cache is so overloaded at this point that the cache owner apparently either doesn't care about the guidelines they have established for the cache or they can't keep the incoming submission straight. I think it is great that some set up database files to keep these things straight. The water tower cache does show that these can become totally unmanageable (three logs for the same tower on the same day being allowed).

 

BTW, I found all this in about 20 minutes using excel and just doing a quick scan with different sorting methods despite having 1066 logs.

 

Just an observation...

[+Corp Of Discovery]

Mtn-man: thats why I was bringing up the point that locationless have no mention of guidelines for maitaining them like virtuals do. That is clearly poor maintenance.

 

BTW, I have logged that cache as another cacher from my town has also done, but we do have 2 different water towers in our town and we each logged different ones!

 

I always go thru the lists before trying to find locationless and so far I don't think I've logged wrong.

[+Sparky-Watts]

Everyone seems to be doing a good job of getting out ideas and answers here, and I appreciate that.

 

Jeremy, I'm still waiting for an official word from you. Sorry, I don't think the obligatory "I'm workin' on it" will suffice.

 

I know you're busy working on the site, and rebuilding the virtual side of it, but is there any word you can give here that won't compromise the secrecy surrounding the "new and improved" site in relation to the topic of this thread?

[+Team GPSaxophone]

Everyone seems to be doing a good job of getting out ideas and answers here, and I appreciate that.

 

Jeremy, I'm still waiting for an official word from you. Sorry, I don't think the obligatory "I'm workin' on it" will suffice.

 

I know you're busy working on the site, and rebuilding the virtual side of it, but is there any word you can give here that won't compromise the secrecy surrounding the "new and improved" site in relation to the topic of this thread?

He hasn't answered? well Tough Nuts!

[+Sparky-Watts]

Dang worthless Moderation Options drop down.....not a thing about snippity smurfs......

[+Team GPSaxophone]

Dang worthless Moderation Options drop down.....not a thing about snippity smurfs......

Not a thing about wet cats either, but you don't hear me complaining!