Jump to content

Interpretation of the guidelines


Recommended Posts

This post may be seen as controversial and even critical so first off let me say that's not the intention. Rather, I want to stimulate a discussion on some aspects of the guidelines so that we can all - cachers and reviewers alike - better understand the guidelines and therefore make it easier for reviewers as the number of caches and their originality increases. This thread was suggested by Eckington so that the reviewers can receive feedback.

 

We all know that the reviewers do their "job" entirely voluntarily and in their own time, which reviewing 200 caches a week must really eat into. The reviewers deserve our thanks and admiration, and they certainly have mine.

 

Interpretation of guidelines is always difficult - rules would be so much simpler - and there've recently been a few instances where I've wondered "why did the reviewer do that?" or "having done that, why did he then do the apparent opposite?"

 

It could be said that this thread should be in the website forum rather than this one. That is true, but one of the reasons why there are guidelines rather than rules is to allow different interpretations to deal with local conditions. The usual example given at this point is that UK caches often start from or at least recommend a good pub. Such caches are frowned on elsewhere as being commercial. So let's discuss things here first. If, as a result of this discussion, the reviewers think that aspects of the guidelines need further discussion or even changing then that's best done in the reviewers' forum.

 

Why do I care about this? Well, at a certain level we are all reviewers. We all expect cache submissions to be handled in a particular way which fits with the guidelines, and so we plan caches according to those guidelines and expect that others' caches will do the same. A cache which is out of the ordinary can either be an original idea (good) or outwith the guidelines (bad).

 

Here are a couple of recent examples that have caused me to wonder...

 

Cache saturation

 

We all know that the saturation guideline requires that physical caches be, as a rule of thumb, 161m apart. The reason for this is "to reduce the number of caches hidden in a particular area and to reduce confusion that might otherwise result when one cache is found while looking for another". A further reason, though not stated in the guidelines, is often said to be to reduce the environmental impact of having more than one cache in the same spot.

 

A while ago a traditional cache was published which I knew to be within a few tens of metres of the final of a long and well-respected multi. The multi had been placed long before the advent of additional waypoints so the reviewers had no knowledge of the location of the final. I and others advised the reviewers of the problem, and the reviewers decided to leave the new cache as it was. The final was immediately found by almost everyone looking for the new cache, thus amply demonstrating the reason for the guideline.

 

Much more recently, a very similar situation arose, the only difference being that the new traditional cache was hidden so close to the final of a very long multi that it was in the same tree. I and others advised the reviewers and the new cache was immediately archived pending a relocation.

 

The only difference between these two examples is the distance between the new caches and the finals of the multis, but in both cases they were close enough to be well outside the guidelines and to result in a high probability that cachers would find the wrong cache (as happened with one and would probably have happened with the other if it had not been quickly archived). However they were treated very differently and one was allowed to remain while the other was immediately archived.

 

Another example is that of three multis all of which have their finals in the same physical container. The container apparently holds three further containers - one for each multi - which are locked and the keys are obtained from nearby micros which can only be found by solving each multi. The guideline is intended to prevent one cache being found while looking for another. In this case all three caches will, inevitably and intentionally, be found once one is, but can't be logged because the logbook for each is locked away. While this intentional and documented co-location of caches may not cause the confusion that results from accidentally finding the wrong cache, it clearly breaks the saturation guideline and potentially worsens the environmental impact reason because it's likely that cachers will find all three multis on different occasions and therefore visit the same spot three times.

 

Downloading of data

 

This new (Feb 2007) guideline has been much discussed elsewhere without any conclusion being reached, other than perhaps that the guideline is phrased too weakly to achieve anything at all. The guideline says: "In the interest of file security, caches that require the downloading, installing or running of data and/or executables may not be published." That "may" is probably the weakest part of it but for now let's look at the rest.

 

The purpose of this guideline is to try to prevent software problems which might result by viewing a cache page, though it can be seen that its real purpose is to absolve Groundspeak since users must always be responsible for their own security. Nevertheless, Groundspeak's attempt to help us help ourselves should be applauded.

 

In recent months a few local caches have been published which require navigating a maze to obtain clues to the cache. The maze didn't work for me and when I read the instructions I found that it was probably because I don't have Java installed. So for me to do these caches requires that I download and install Java: something which the guideline suggests may prevent the cache from being published.

 

I asked the reviewers for their thoughts and their view is that Java is a universally accepted application and therefore isn't something that the guideline was intended to prohibit. That may be true but isn't the end. It's not Java itself that's the problem: it's the user application that Java runs which potentially poses the greater risk. Even if I were to install Java I still wouldn't be able to solve these caches without further downloading of data. An analogy is that Word, Excel and Outlook are all universally accepted applications, but it's the documents that carry the problems. I doubt many people would follow a link on a cache page to a Word document.

 

So I'm puzzled as to how this guideline is intended to help. As I've said, users are responsible for their own security and if I choose to download something to solve a puzzle cache then that's up to me. However, the guideline may prevent such a cache from being published, but isn't doing so.

 

To summarise, I believe there needs to be consistency in how caches are reviewed and in the actions taken if a problem isn't noticed at the time. The guidelines are intended to be flexible and open to interpretation, but they have to be seen to be used consistently and with respect to their intentions.

 

Finally, a reminder. This thread is intended to stimulate discussion on how we as cachers would like to see the guidelines interpreted, in order to better inform the reviewers and ourselves. I am not, and any reply should not be, critical of the reviewers or any other cacher. Nor should we discuss the specific caches I mention: they are examples, nothing more.

Edited by Alan White
Link to comment

Lets bring an example the latter noted caches in question into the open, so others can see the problem.

 

http://www.geocaching.com/seek/cache_detai...ec-306d4a1e1b91

 

I personally hate java on windows, it's fine in linux. These sort of puzzle caches allow greater chance of reverse engineering - I found a java decompiler very helpful for this series.

Edited by Edgemaster
Link to comment

Of course we all have a choice here ... we can choose not to run applications that caches such as these demand ... we can choose not to solve or search for any cache we care to.... we can choose not to play this game at all

 

We all play for different reasons, many play by different rules and have different ideas about what is fair or right, but who is to say that any other is wrong or less tolerable ... its a game, thats all, enjoy it....

 

Happy Caching

 

Bob / JollyJax

Edited by JollyJax
Link to comment

the trouble is that it is far easier to discuss individual situations as they arise. other wise you end up with guidelines/ rules that aren't flexible and tend to be overpowering due to the fact that they have to deal with very different situations.

 

i personally prefer fairly vague guidelines that can be stretched to fit if that makes sense. the three nutters we have interpreting them seem to be making a fair job of it. the problem arises when someone doesn't get what they want.

 

unless we then want to try and run this as a democracy with votes on each problem as it arises ......

 

it ain't broke don't try to fix it. ( and just be ready to jump to the support of the three if they are attacked.)

Link to comment

I really couldn't give two hoots about this (I'm being polite!!)

 

The guidelines are there as just that - GUIDELINES... our reviewers are both experienced cachers AND reviewers, and they know what they're doing - which is why we entrust them with the job of reviewing.

 

What we have to remember is that this is a hobby... not a job, not something rigid and boring... which is why it's so much fun. You don't HAVE to do EVERY cache within an area... that's what the Ignore button is for...I use it regularly - I live on a penninsula and don't want to have caches that are apparently 4 miles away come up on my 1st page... you could always do the same!

 

At the end of the day - what has the OP gained by posting this thread, excpet maybe a headache? Chill out, go caching and enjoy it!

Edited by HazelS
Link to comment

the trouble is that it is far easier to discuss individual situations as they arise. other wise you end up with guidelines/ rules that aren't flexible and tend to be overpowering due to the fact that they have to deal with very different situations.

 

i personally prefer fairly vague guidelines that can be stretched to fit if that makes sense. the three nutters we have interpreting them seem to be making a fair job of it. the problem arises when someone doesn't get what they want.

 

unless we then want to try and run this as a democracy with votes on each problem as it arises ......

 

it ain't broke don't try to fix it. ( and just be ready to jump to the support of the three if they are attacked.)

 

I have to agree, the guidelines are vague in most instances and do require the reviewers to make judgment calls. Seems to work fine most of the time. There are the odd problems one of my multis ended with another cache 60 foot away no big deal.

 

I think the reviewers discuss potentially problematic caches and we should leave them to deal to get on with it.

Link to comment

Alan started this thread at the reviewers' suggestion so we welcome discussion.

 

Just to clarify, it was suggested that the restriction on downloading "data" would best be carried on in a thread in the main forum which was already discussion this issue. We felt it better to have the discussion there as it has wider implications than just the UK. However feel free to continue it here if you want to.

 

We agreed that Alan's concerns about the UK Reviewers' conduct in applying the "Saturation" guidelines, wrongly in his view, would benefit from an open discussion here.

 

So please continue the discussion and be assured that all three of us reviewers are most interested to hear what you think.

Link to comment

I think the guidelines are probably best left as they are. The more experienced geocachers amongst know what the rules are, sometimes we make a slight error, get queried on it (thanks Decaengi! :tired: ) and the cache gets published.

 

Each time guidelines are reviewed by Groundspeak, and we have to start working to them, don't forget the upheaval that seems to cause. People complaining about change etc, and at the moment, we have a system that works. The situation you mentioned about the Trad ending very close to the final of a multi, like you say, probably wouldn't happen now because of waypoint features. You mentioned that the two caches were treated differently, the second one being archived. This is probably because Reviewers learn too and they may have thought 'Oooo, I / we think we could have handled that better/differently. So that's what they did the second time round.

 

Overall it works, as Stuey says, nearly 20,000 caches out there, so it kinda proves something must be right!

Link to comment

I think the reviewers do a great job and would like to thank them for all their hard work. :tired:

 

I took a look at one of the caches in question and couldn't view the maze as I don't have the right piece of equipment in my lappie ... end of story, I ain't bovvered.

 

We all take decisions on which caches we shall attempt and which we shall not ... if you like to think of it this way, every cache is a challenge from the setter ... it is up to you whether to accept that challenge or not, nobody says you have to do this or have to do that.

 

Of course it is nice to clear and area near ones home and so on, but we all at some level make decisions about what we shall try and what we can't be bothered to try. Perhaps I do this more than most, filtering out ones that will probably not be worth the effort to me physically ... again it doesn't bother me.

 

I was looking at the logs of folks who attended the Swanage cache meet this weekend and found it fascinating what combinations of caches folks chose to complete ... the novelty of our game, which is probably the oxygen to its very existence is diversity, I would hate to see that be snuffed out.

Link to comment

On the downloading/running of data/executables.

 

Clearly, we're all downloading data to do any cache. Accessing the geocaching.com web site results in the download of data - the cache page itself, for example, and maybe some additional jpgs. So that guideline cannot be taken literally. And some caches have sound files, some have video files, some have pdfs. Maybe some have Word documents (I can't remember seeing one) or other kinds of data.

 

But it's a good idea to be wary of executables.

 

Ah, but. On these computers, there's no clear distinction between data and execuables. For example, one might have thought that a word document was pure data; in fact it's a mixture of data and executable. The winword.concept virus, released in 1995, demonstrated that.

 

[Omits long academic discussion involving terms like Univeral Turing Machine, the Halting Problem and Fred Cohen's doctoral thesis]

 

"I doubt many people would follow a link on a cache page to a Word document."

 

I disagree - I think that many people would indeed do that. And since that could, potentially, lead to problems ... but probably it wouldn't.

 

"users are responsible for their own security" - true enough, but there's so many caches that warn you "look after your children because this is along a canal" or suchlike. Although people are responsible for their own security, it can be good to help them with doing so. Hence the warning. And, likewise, hence the undesirability of giving executables for download.

 

So I think that, given the risk, but the non-distinction between data and executables, it's going to be a judgement call each time. And, maybe not everyone will agree with each call.

Link to comment

I couldn't bring myself to read it all tbh.

 

In the instance of caches being set too close to other caches, particularly the final solution to a multi, I think the fault lies entirely with the setter of the second cache. They're the ones that should have local knowledge of the area in which they're setting a cache. It sounds quite odd that they're setting a cache in the area of an established cache at all. Maybe that's just me.

Link to comment

I have to agree with scanker - I also didn't read ALL of the mammoth sized OP.

 

I think that considering our reviewers are volunteers, and spend a great deal more time (their OWN time) at the task than most of us realise, that criticism should be extremely well considered...and then not given!!!!

Link to comment

On the "cache saturation" issue: there doesn't seem to be a problem, based on your examples. There has to be a little room for manoeuvre due to local circumstances.

 

For instance, it's rare in the UK for geocaching to have any significant environmental impact - only in a very sensitive area would a cacher visiting the same spot three times be a problem (probably the cache wouldn't get permission in such a site). Many caches are placed in areas popular with dog walkers where there are perhaps a thousand visits in a month, of which half a dozen are by geocachers. So if there is a situation as in your last example (where three caches exist at the same coordinates), it's up to the reviewer to be satisfied that there's little chance of cache confusion: I wouldn't expect that the wear and tear to the area would be a major factor. And as the cache setter has gone to some trouble to ensure that the caches wouldn't cause confusion, I'd expect the reviewer to allow the guidelines to be ignored in this case.

 

Where there's likely to be major confusion (e.g. two caches inadvertently placed in the same tree) then the guideline would doubtless be enforced. In the other example, where two caches are inadvertently set fairly close together, it's the reviewer's judgement whether a problem is likely to occur - sometimes he'll get this wrong, but it's necessary to have this leeway otherwise we'll get very silly and unnecessary arbitrary cache refusals (sometimes the cache setter will have no idea that there's part of a multicache nearby).

 

I had experience of the latter in Germany last year, where a new cache was set up less than the minimum distance from another. The cache setter thought that the guidelines would be applied rigidly, and sought to circumvent them by posting false coordinates, then mentioning the correct ones in the text. The trick was spotted eventually, and there was a lot of negotiation before the new cache was unarchived! I've been to both caches, and there's no chance of cache confusion: one is up a steep hill in an old part of town, the other is fifteen minutes walk away, in a river. I think that the guidelines are still being" breached" in this case, but with local knowledge, there's no problem.

Link to comment

Well our reviewers seem to be able to manage these issues quite well. Its certainly true that in cities and towns its more than likely that you'd find two (or more) really good cache locations not that far apart.

 

In fact .... I've just had a bright idea ..... hmmmmm

Link to comment

I think the OP raises some interesting questions.

 

The three-into-one multi sounds fine to me, can't see much of an issue regarding 'saturation' as meant by the guidelines since no one is going to get confused because this is the point of the cache.

 

Generally, I think distance needs to be flexible if, for eg caches are nearby but on different sides of a river or other major obstacle.

 

The problem of new caches near multi end points is probably caused by the new cache setter not knowing that the multi ends there. I'm happy for the reviewers to use their judgment as to whether it's an issue in a particular case and no doubt 'additional waypoints' will make things easier for them.

 

I think a difficult area, and one that's been discussed before is a definition of a 'power trail' and whether they are a problem or not. A micro every 500' along a canal seems fairly pointless to me but I might enjoy having a go on one because it would be different and I've not tried one yet. But do we need lots of concentrations like this? Not sure there's a clear view about these as some like them and some don't.

 

I think the example I don't like is the one going off from the cache page to another site cos until you get there it's hard to know if there's any risk or not, especially to us non-technical folk. I would support a guideline that says all the info has to be on the cache page, and people then need to be creative within whatever limitations that imposes, ie what Groundspeak allows. Pics and text still leaves loads of room for creative caches.

 

The joy of people is that there's a lot of creativity out there so there is always pressure to push the limits of what's involved in a cache, which must cause problems for the reviewers at times. Somewhere it becomes something other than the original concept of hide a box-find a box. I think it doesn't want to become too convoluted - stick to the basic idea - and the guidelines are useful in defining some generally agreed parameters. There's a lot of diverse caches set already so it seems to be working at the moment.

 

I also think the reviewers do a fine job and should get an immediate 10% raise! :D

 

Cheers

Martlakes

Link to comment

Executables should be permitted, although maybe the reviewers should insist on a disclaimer.

 

Remember Vinyl

Don't Mention The War!

Subaru Impreza

 

All require installation of software (however, Subaru has a PDF attachement which is pretty standard form anyway, and GC.com creates PDFs on the fly anyway).

 

I'd like to see more variety permitted, and let the end user make their mind up whether to solve the puzzle / open the file, etc etc.

Link to comment

With almost 20,000 active UK caches, I think a small number of problems with proximity is excusable.

 

Correction, with OVER 20,000 active UK caches....

 

On the OP subject, I can't get excited about it I'm afraid. I think the reviewers do a fine job, and we must accept that there will be occasions where their interpretation of the guidelines doesn't exactly match our own, and there will be occasions where they simply make a mistake and get it wrong in which case a mail to the reviewers and/or the owners concerned will probably rectify things.

Link to comment

With almost 20,000 active UK caches, I think a small number of problems with proximity is excusable.

 

Correction, with OVER 20,000 active UK caches....

 

Stuey did make that post 2 days ago, so lets stop the pedantary and lets go out and find these caches.

 

Guidelines are just that open to interpretation they're not hard and fast rules and that isn't what geocaching is about to me and shouldn't be for everyone else, lets just agree to go out there and play this the way we feel is right instead of stopping every 5 minutes to ask people's approval of whether what we are doing is right.

 

If it feels right to you go and do it, if it doesn't feel right to you, then don't do it.

 

This whole conversation is like a broken record.

 

Whilst you lot are busy arguing over the guidelines , I'm going to go and find some tupperware. :blink:

Link to comment

Fair point Wizzie but there's only 2 questions there - do we want a change on proximity issues, and do we want a change on the use of external apps.

 

I would like external apps to be useable for cache listings, and down to cache finder discretion. At the mo this isn't the case, so it's worth discussing if there is the chance of change. :blink:

Link to comment

Interesting thread.

 

Not only do our UK reviewers do a good job (natch) but I think Groundspeak do a good job in producing guidelines that have to be internationally applicable under the different circumstances that apply around the world. Can't be easy.

 

While the proximity/power trail issues in the US may not be such an issue here, the changes that have been brought in to address these issues there haven't caused much of a problem here. The only issues seem to have arisen from older multis that don't have additional waypoints, and a few minor problems here and there aren't a big deal.

 

Guidelines are just that open to interpretation they're not hard and fast rules and that isn't what geocaching is about to me and shouldn't be for everyone else, lets just agree to go out there and play this the way we feel is right instead of stopping every 5 minutes to ask people's approval of whether what we are doing is right.

Well ... that's not entirely the case. When it comes to the specific issue of cache placement the placer has to make sure the cache is within the guidelines, and the reviewer has to verify this. So in this case it's not just up to what we "feel is right". Otherwise we could well end up seeing an accretion of geo-garbage, placed without permission in inappropriate places.

Link to comment
however I do think the saturation thing should be set in stone,

Sorry - I disagree - I think they should remain as guidelines. I've been thinking of setting a multi that has it's final only 200 feet from an existing cache.

However, they are 200 very wet feet, and to get from one to the other means driving at least 9 miles.

It'd be nice to think that the reviewers would have some allowance to apply the guidelines as they see fit - and not be rigidly bound by a set of rules.

Link to comment
however I do think the saturation thing should be set in stone,

Sorry - I disagree - I think they should remain as guidelines. I've been thinking of setting a multi that has it's final only 200 feet from an existing cache.

However, they are 200 very wet feet, and to get from one to the other means driving at least 9 miles.

It'd be nice to think that the reviewers would have some allowance to apply the guidelines as they see fit - and not be rigidly bound by a set of rules.

As we are interested to know how people feel the reviewers have kept out of this discussion. However just to clarify, in the situation described above the cache is almost certain to be allowed despite it being 200ft away from another. The key here is the obstacle in between and the guidelines already take allowance of this.

Link to comment

I am fairly admiring of the White family pursuit of caches - but being dozy had missed this thread.

 

Many useful issues raised and laregly I sympathise with Alan. The cache density issue really is a geographical one - much easier now with Google Earth. Same tree .... oooops, same hedgerow ..... hmmmm, other side of same gorge or on other side of motorway ..... prob ok. I know TPTB do gaze down with GE and I trust their judgement.

 

The prob on multis is that many folk havent updated to include final coords in the waypoints for TPTB. Common sense says local knowledge of a prob should be listened to.

 

As for other software ... as long as its infrequent (very) I dont really care, but I can see the reason for it.

 

Generally I think TPTB manage a large and difficult situation well.

Link to comment

As this thread has resurfaced I thought I'd read through it again. I have to say that what could so easily proved a contentious subject has been discussed in a gratifyingly adult manner and almost everybody has aired their thoughts in a constructive manner.

 

I do wonder if such a discussion could have been held in other forums. Many thanks to all concerned. <_<

Link to comment

I have set two caches where there is a stage/final location within 161 metres of an existing cache. In both instances the themes of the cache lended themselves to the chosen location and there was some kind of barrier between the existing and new cache. Being able able to use the notes to reviewer on the cache submission page was very useful in allowing a discussion about the chosen location. In one instance it allowed me to point out which side of a river gorge the cacher should be for the existing cache as several previous searchers appeared to have carried out a hazardous river crossing having found themselves on the wrong bank.

 

As for the issues of older multi/puzzle caches I have been slowly working through mine and adding in the additional waypoints, which is also a good place to hide notes to myself so that I can give cryptic responses to questioning emails from those who have been seeking the caches.

 

Top marks to our amazing triumvirate and the the great job they do interpreting the guidlines. <_<

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...