Paradiddle

Woah, guys! It was a tongue-in-cheek comment that I hoped would get some people from other locations to chime in with their thoughts on this matter. Let's bury that one and move on. In essence, so far, some people would like to have auditing available on some caches without having to make them premium member only, and these people have various (non-malicious) reasons why they would find this of help or interest. Others don't like auditing as, for one reason or another, they don't want their viewing of cache pages to be trackable by the cache owner. This group would rather auditing was not available at all, or that any tracking feature was optional and/or clearly indicated. So how to move on and come to a compromise between the two ends of the spectrum? Some suggestions could be.... 1. Have a built in option for visit counters e.g. number of hits over variable periods of time. This would allow the owner to see how often the cache page was being accessed and might help in deciding if the cache should be archived or altered. 2. Have auditing available, but allow each individual to have a setting that will determine the information that is left on the audit trail e.g. Cacher name (as present) or anonymous. An anonymous system could assign you a guest number which would allow the cache setter to see how may times particular guests have accessed the cache without revealing their identity. Any other suggestions?

Judging by the replies in this thread, it only seems to cause angst to people in the USA and Canada One of the reasons for raising this issue was because I know that some people don't like the idea of caches not being accessible to all and therefore they dislike the whole MOC principle. I have indicated why there are some situations when the audit log provided in a MOC cache can be helpful or desirable (there are also other reasons for making a cache a MOC, but that's a separate debate), so in such circumstances anyone that doesn't support the capacity for auditing to be available on non MOCs should not complain about those MOCs being restrictive.

There are 2 situations I have encountered when audit logs are useful… 1. If you set a high maintenance or complex cache (e.g. where stored equipment needs replenishing or stages need regular checking) it is useful to see when people are viewing your cache page, and how frequently they are doing so, as this can help give the cache setter an indication that someone is preparing to do the cache and they can make sure everything is in order. This situation is only likely to apply to a relatively small number of caches. 2. It can be interesting to the cache setter to see who is viewing their cache, especially when a new cache has been released, and particularly with puzzle/mystery caches. If you are part of a highly active local geocaching community it can be fun for the cache setter to be able to see who might be trying to solve their puzzle, and who is in the running for the first to find race. Remember that some geocachers get equal, or more, pleasure from producing well constructed caches and seeing them being solved as they do from the process of seeking caches. It’s a two-way sport involving setter & finder. In such circumstances if you wish to run an audit log you currently have to set the cache as a MOC thereby depriving non-members of the ability to do the cache. It is for this sort of situation I would like to be able to have an audit log but have the cache open to all. In reply to some of the comments posted so far… If a member only cache is ‘muggled’/goes missing, it’s going to be highly unlikely that a paid up member has done this, so looking at the audit log will not be of much value. There may be ways of avoiding triggering an audit entry, but so what? If you wish to view caches in this manner to avoid ‘being seen’ that’s up to you. I suspect it is very rare for people to email someone just because they have looked at their MOC and they live miles away. You were just unlucky.

One of the main benefits I see of premium membership is to be able to set up an audit log on your cache page. However this can only be enabled in cache pages that are restricted to premium members. I would like to see the audit log function made available to the cache setter on all cache pages (i.e. both unrestricted caches and premium member only caches), but for the function to remain accessible only to premium member subscribers.

Perhaps the dilithium cyrstals have recharged, or maybe the people that feed the hamsters that power the site have given them some vitamins; whatever it is the site certainly seems back to full power. Anyone else noticed an improvement in general site update speed (especially accessing travel bug pages) over the past day or so? But then again, it's not the weekend....

Here, here! I second that proposal.

Thanks Keystone for directing this post to the correct page. I see that this issue has been raised already. [Pretty typical, though, isn't it, for a weekend?] Perhaps, but this is a problem that only seems to have arisen over the past week or so. We haven't experienced this sort of delay previously, and we'd never experienced a "time out" on the server until this week. So I think it's definitely a new problem (? could it be linked to the recent site upgrades??)

Hi. Don't know if this is the right place to raise this topic but here goes. Over the past few days the website has been really, really slow, especially when you want to view or edit travel bug pages or move almost anywhere away from the main search pages. I am in the UK. Has anyone else experienced this? It's getting to the point that it's so slow it's very frustrating and if it continues to degrade it will be almost unusable!