Jump to content

Moratorium update


Recommended Posts

My understanding is that there is a single checker which handles "word list" challenges and that this checker takes parameters for the number of caches required, whether or not the word can be embedded in another word or must be stand-alone; whether each word can be used more than once for the challenge and the list of acceptable words. So, if there are several "animal name" challenges, the only thing which would change would be the parameters.

 

Would it make sense to have a single "Animal Name" list maintained centrally rather than each CO providing their own list? Obviously, someone would have to provide the initial list, but I'm sure that there are many lists already within the PGC system. There could be several lists "Animal names in English", "Animal names in French" etc. plus "Insect names" "Mammal names" "Australian Animals", "African wildlife". This could also encompass "Christmas words", "parts of the body" or any other list of words one could imagine. The CO would then simply select the "Generic word list checker", the "Animal Names in English" list, 25 caches, embedded words allowed but only one cache per word".

 

If someone tries to qualify for the challenge and finds an apparently allowable word is missing (s)he would submit the request through the normal PGC request mechanism and all challenges using that list would be updated.

What a lot of faffing about for something simple.

The faffing about factor is reduced by my suggestion.

 

Without it, each CO has to faff about creating their own list and anyone with a missing word has to faff about contacting each CO for each such challenge they are working towards and then each CO has to faff about contacting PGC to get their personal list updated and PCG has to faff about updating multiple lists.

 

My way, the CO simply has to select the list and the person with the missing word has one point of contact. Much reduced faffment.

Link to comment

As I understand it, volunteer reviewers on geocaching.com are not permitted to review caches for quality - but will PGC checker writers be permitted to do so?

 

There's a fundamental difference here between "volunteer reviewers" and "volunteer checker writers". Reviewers are "employed" by Groundspeak to do a specific task. It's not a paying job but they do have specific tasks and process requests at least more or less in order. In comparison, there is nothing like that for checker writers. Each checker writer may look at requests for new checkers, or they may not. A checker writer may simply get checker-writing privileges for writing a checker for a personal challenge and then never creating another checker. If your challenge looks convoluted or the checker writer doesn't have time right then, no checker is likely to get done. There is no expectation of things being processed in any special order, or even of any specific request even getting a response. Consider the checker writers you see in the PGC forum the same as the guy you meet at an event. He's probably happy to help you answer questions, but it's not his job to answer any and all of your questions.

 

Which means that order is very important - if we are to avoid wasting the time of a volunteer reviewer in reviewing a challenge cache which might never get a checker written for it.

 

This process should be very effective in ensuring that challenge caches with convoluted requirements run firmly aground in the graveyard of abandoned, checkerless challenges - but it would be good if such challenges didn't waste valuable reviewer time before joining the checker writers ignore pile.

Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

 

That almost certainly wouldn't have been published prior to the moratorium.

Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

 

That almost certainly wouldn't have been published prior to the moratorium.

 

It has been published.

Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

 

That almost certainly wouldn't have been published prior to the moratorium.

 

It has been published.

 

Several times.

Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

 

That almost certainly wouldn't have been published prior to the moratorium.

 

It has been published.

 

Several times.

 

http://www.15ddv.me.uk/geo/chal/resuscitator_challenge_caches.html

Edited by Team Microdot
Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

I don't think there is one, because it would require the checker to have access to all logs on all caches your finders have ever found and I don't think that has been available to Project-GC in the past - whether that will change in the brave new world remains to be seen.

Link to comment

I don't think there is one, because it would require the checker to have access to all logs on all caches your finders have ever found and I don't think that has been available to Project-GC in the past - whether that will change in the brave new world remains to be seen.

Thanks for the reply, hopefully someone will create one as it’s a pretty common challenge.

Link to comment

I don't think there is one, because it would require the checker to have access to all logs on all caches your finders have ever found and I don't think that has been available to Project-GC in the past - whether that will change in the brave new world remains to be seen.

Thanks for the reply, hopefully someone will create one as it’s a pretty common challenge.

But, most say to use one you haven't used for another similar challenge which again is easy for a human impossible for the computer unless you have a database to support it. So no more resus caches unless they are just a simple qualification rule. I reckon there will be many more like this.

Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

 

That almost certainly wouldn't have been published prior to the moratorium.

 

It has been published.

 

I stand corrected.

 

We have lonely challenges around here, but not out to a year. The pool of available caches meeting this varies by region, so there is some discretion reviewers have for what makes sense based on the set of available caches in their region.

 

In the new world of cache checkers, even if the checker had access to all user logs, there is no way to tell who was actually first on a given day. For the extremely lonely 1 year challenge, there might be a group of cachers salivating to get to the cache on day 366. So 10 cachers go, all find the cache on various hours of the day. They all log online randomly. A checker - or human - has no way of telling who was actually first at the cache that day. The checker would need to allow all cachers on the same day to claim the cache as qualified.

Link to comment

The checker would need to allow all cachers on the same day to claim the cache as qualified.

 

Even though all but one of them isn't entitled to claim the cache (or rather the challenge aspect of it) as qualified.

 

Having a checker as final arbiter of qualification will be a great facilitator for armchair logging.

Link to comment

I own a Challenge Cache which requires Cachers to find a Cache that has not been found for at least 1 year (365 days) before the date they found it.

 

I would be happy to add a checker to this cache, does anyone know if there is a checker for this please?

 

As said before, no, if this information is correct.

"A checker can only examine your logs, so cannot see the last log, thus cannot tell the time difference."

 

It would be far too costly for project-gc to load all logs (or an optimized part) for all caches someone found to determine the period of time between finds. Retrieving logs through API is possible, but limited.

Maybe in order to make possible new lonely challenges allow a checker where you have to enter manually the gc-code of the claimed cache so it is only necessary to check logs for this particular cache.

 

You can determine a loneliness-factor from 'number of finds / days since hidden', but that is not the same as 'days since last visit'

 

Up to now determining whether a cachers claim is correct was easy, the challenge owner had a look at the claimed cache and could easily evaluate the online found entries, done.

 

In my opinion for a lonely cache challenge there are also other questions beside the last found-it log date before if you look closer.

 

- What if two or more cachers visit on same day (as a group or seperate)? Would it count

 

* for the cacher that comes first in logbook (you can put your name wherever you want to if you find a space in the logbook and/or pages get torn out sometimes)

* for the cacher that manages to log online first due to better equipment/net coverage

* for both/all of the day

 

- Do all days count only if the cache was present all the time and never disabled?

- Do all days count if the cache was present all the time, but the cache was disabled during 6 months for bat protection?

- Do all days count if the cache was present except during the time for bat protection?

- Do all days count if the cache was missing most of the time without being disabled and a replacement placed without any comment from the owner (by owner, someone else or the finder)?

- Do all days count if the cache was disabled because the container was missing or the location was behind a temporary barrier and the cache was enabled later, but before the find?

- Do all days count if the cache was already archived by a reviewer, but cache is present (and OK, archived because the cache owner is unresponsive to reviewer notes provoked by silly NM OR NA)?

- Do all days count if the cache was already archived by the owner, but cache is present?

- Does it count at all if the found in question it is not connected to an entry in a logbook, if it is clear 'there is no cache, but I have logpermission from owner' 'photolog because no cache/logbook there' let alone pure 'online log not related to a real visit at the cache location'?

- What if a cacher ignores that a cache is disabled with good reason and logs it 'illegally'?

- What if there are fake entries before not connected to a real visit (sometimes invented at arbitrary dates)?

 

So the list of finds of a particular cacher (date and caches) and the current properties of the caches like difficulty, terrain, country, region, county (polygons in project-gc, not geocaching.com), size, cachetype, hidden date, cache title, attributes, favorite points, number of finds ... can be part of a filter for challenge requirements. Found-it dates can be altered and every mentioned property can be changed and is not carved into stone.

 

There are a few additional checkers besides the ones that are connected to the mentioned properties and time/numbers related:

 

* Reviewer-Challenge (pgc determines who has published the caches you found -not for caches until 2005 and where publish-logs got deleted-, if the challenge requires it, Lackeys have to be excluded manually if not already listed on bookmarklist),

* Souvenir-related (a list that is not fixed, new entries added every year),

* polygon-related, if you provide polygons for whatever (cemeteries, battlegrounds, parks, a mountain range, places your favourite poet visited) it should be possible to check whether someone has found caches there

* check against a bookmarklist etc.

Edited by AnnaMoritz
Link to comment

I would say that depends on whether or not the personal, subjective views of the checker writers will come into whether or not they write a checker for a particular challenge.

 

As I understand it, volunteer reviewers on geocaching.com are not permitted to review caches for quality - but will PGC checker writers be permitted to do so?

 

It's all well and good saying that a discussion on quality will go nowhere fast - but it starts to look as though personal judgements of quality might need to be taken into consideration - so I think it's a valid point for the discussion on that basis.

 

If no checker writer wants to write a checker, and the CCO doesn't want to, then it sounds like nope, the challenge won't be published.

Considering how many authors there are, that they aren't fundamentally against the challenge of writing algorithmically complex scripts, I find it highly unlikely that zero authors will make an attempt at scripting a request unless it's pretty much unanimously agreed that it just technically or feasibly cannot be done. In which case the challenge won't be published.

 

I don't think GS wants to worry about whether writers care or not about any particular challenge idea. It's up to the CO to get the script, however they can, and one that works as the challenge describes.

 

You're focusing on the easy, non-contentious decisions. The checker decides if a cache title's word matches one of the words on the checker's list. That's a simple, non-contentious decision. The only problems that probably will arise are rare programming bugs or typos, and there will be very little disagreement about how to fix those few problems. If you want to call the checker the "final arbiter" of those non-contentious decisions, then go ahead.

I'm only focusing objective results. A challenge is qualified if the checker verifies it. If the checker doesn't, but the CO wants to let the qualification stand, the CO needs to adjust/fix the checker. In that simple process, the checker is the final arbiter. If the checker has a bug, the CO has to fix it. If the checker is not consistent with the challenge description, then it's "subject to archival". Doesn't seem complicated or subjective at all to me. Reviewers and appeals only need to get involved if the checker is found to not be consistent with the challenge description, and the CO can't or won't make it work. For publishing, it's much easier to determine if it's a valid challenge - is there a checker linked? Likely also, does its output imply that it does what it's supposed to do? Yes, *pubish*.

After publication, bugs or issues may yet be found, but at least at that point there's enough objectivity (results and evidence, not word of mouth and opinion) that the checker and challenge are not in sync.

 

The key, contentious decisions concern whether a word that properly belongs on the checker's list is missing from that list. Does that word meet the challenge cache's somewhat ambiguous requirement?

In my example, the wording of the rules covered that. If I used the "any animal name" option with the clause that the checker is the final ruling unless as the CO I approve a new word, then there's no ambiguity. If I don't approve the new word (by lack of response or direct decline), and you have the list of approved words, then it sounds like the reviewer will simply say - the checker and challenge are consistent, it says no, so no; find caches that match the approved word list. I think the number of situations where a finder demands that a new word is and should be valid to the COs 'category' and won't let it go with the reviewer/appeals process will be a ridiculously insignificant portion of appeals. (as per their fairly limited description of makeup of appeals they want to reduce)

 

Under Option 3 of your proposal, the challenge cache owner will be the final arbiter regarding these key decisions.

Decision-making, yes. But, again, the checker has to reflect the decision. If it doesn't, the cache is subject to archival. A CO won't be able to say "okay" to person#1 who fails the check, but with the same parameters let the checker's "no" remain for person#2. One of the cachers' results is inconsistent, and the CO has made a subjective call. If that goes to appeals, the way I understand GS's outline of the new challenge process thus far, they're implying the cache will be subjet to archival - because the checker can't be trusted to be accurate.

 

And if the challenge cache owner starts making arbitrary and capricious judgments on these key decisions (e.g., accepting "filly" but not accepting "sow"), then Groundspeak probably will hear about it from some denied challenge finders. Will Groundspeak want to correct these "unfair" situations or will they prefer to ignore them by making the challenge cache owners the final arbiters? I'm putting my money on the former, although I wouldn't object to the latter.

It sounds to me that they will side with what the checker says, and whether the challenge describes it accurately.

eg, if the CO says they'll amend words they believe fit the category, and (really, I think this situation will be so few and far between it'll be a non-issue) the cacher has a word that quite clearly is part of the category, and it doesn't appear that the challenge desrciption provides what is currently and explicitly required for qualification, then GS would make the call - either the CO must add the word (to make the checker show green - again final arbiter), or the cache will be subjective to archival.

 

no matter how you slice it, the checker is not paying the slightest attention to the description.

Right, the CCO has to pay attention to the checker.

 

Appeals are not bad. We already deal with appeals. I cannot believe that appeals caused by a clearly expressed category requirement such as animal names are a significant burden on the system.

I agree.

 

The process for human checking is the same as a script, but it takes a different form, because you know, life and non-life.

But if you want be like that, then no, humans don't run a LUA script in their brain like PGC would, and machines aren't alive. So no, in that case, human checking isn't "just like" machine checking.

I've been reading the comments about how people maintain lists in the head, mental lists. Actually, I think the way word challenges are processed by humans is a bit different than checking against a list. If someone tells me a word, then I don't take that word and compare it to a mental list of animals in my head. Instead, I take that word, think of what it represents, and then decide if what it represents is an animal or not. Maybe I do things differently, but I know I can't keep an open-ended list of animals in my head. This is really tangential to the challenge checker issue though.

Right, which takes us back to my other comment saying to consider it more like an algorithm. In your head, you know what an 'animal' is, you have an understanding and an intangible list of animals you've come across in whatever manner to your knowledge. What if you're provided a word you don't know? It's not in your 'algorithm' (whether it's an explicit list or your knowledge of 'animals'), so you look it up. This is the process a script would use if it could use an external reference service to 'amend' its list/algorithm.

 

--

Per the 1 year lonely challenge - if the API were altered to allow more filters for cache log history retrieval, such as date ranges, or perhaps x logs by type prior to a date, then checking qualifications would be much more feasible, almost trivial. Script has found date for all a user's caches; retrieve last 10 find logs prior to DateFound, or retrieve logs (perhaps in chunks or pages) up to a month period prior to DateFound, repeat as desired/allowed. Some process like that would make date-based find checking more doable.

 

And yeah, order of find logs on a specific day was an issue pre-moratorium as well. And in that case it was challenge wording that made them viable - it's not whether you were the first to find after a year, but whether you were the finder on the date first found after a year. Primarily that was due to group/partner caching, so that not only one of the people could claim the qualification. Caveat, multiple unrelated cachers on the same date could all qualify. Armchair logging? psh, that's already an issue and is only policed by community and COs. No way around that. If you're aiming to find a lonely cache, and someone goes out and finds it one some day, you had better rush out that same day to find it (if of course you have any semblance of integrity and don't 'cheat' with the logging date =P)

Edited by thebruce0
Link to comment

What you describe fits my expectations exactly - that there's no point submitting a challenge cache to a geocaching reviewer unless it already has a checker - but that isn't the order that Palmetto's post says the sequence of events will occur in - hence the related point(s) I raised.

 

I don't think order is important here. When you come up with a challenge concept, you now need to think about if a checker can be written for it. If not, then you don't bother writing up the challenge cache, and you don't submit it, so therefore there is reduced reviewer load.

 

I'd say order is fundamentally important.

 

When I come up with a challenge concept, how should I think about if a checker can be written for it - given that I have no idea where to begin?

 

Should I contact a volunteer checker writer (or whatever we're calling them) and spend a lot of our time coming up with a checker only to discover that the reviewer rejects the cache on some other basis?

 

Or should I contact volunteer reviewer and spend their time only to later discover that a checker cannot be written?

 

Whose time is more important? Who has more time to work with me to enable my challenge cache ideas?

 

Or maybe I should take your advice and just not bother because I really don't want to waste anybody's time - including my own, if I'm honest. That seems to be what you think I should do.

 

I had a post responding to this and realized it was probably not what was needed. Personally, I think you were reading Palmetto's post a bit too literally with regard to the process. I didn't read it the same way you did - if A, then B, then C. I just saw it as a list of all three steps a CC would go through. All I know is that without the checker, it WILL NOT get published. If I were Groundspeak, I'd be certain to tell my reviewers that they don't reply to ANY challenge cache questions (other than a proximity request) until the CO provides a link to a checker that works and is complete, not one that's almost done or still in the process of being written. I would think that would help reduce the workload a bit. No checker, no submission, workload reduced again.

 

As to your first question, I hope that was rhetorical as it was mentioned where you can go for help in this thread in the original post and in this post. Both of them have links that shed further light on how to get a checker written. The second has a link that takes you directly to the page you need.

Link to comment

What you describe fits my expectations exactly - that there's no point submitting a challenge cache to a geocaching reviewer unless it already has a checker - but that isn't the order that Palmetto's post says the sequence of events will occur in - hence the related point(s) I raised.

 

I don't think order is important here. When you come up with a challenge concept, you now need to think about if a checker can be written for it. If not, then you don't bother writing up the challenge cache, and you don't submit it, so therefore there is reduced reviewer load.

 

I'd say order is fundamentally important.

 

When I come up with a challenge concept, how should I think about if a checker can be written for it - given that I have no idea where to begin?

 

Should I contact a volunteer checker writer (or whatever we're calling them) and spend a lot of our time coming up with a checker only to discover that the reviewer rejects the cache on some other basis?

 

Or should I contact volunteer reviewer and spend their time only to later discover that a checker cannot be written?

 

Whose time is more important? Who has more time to work with me to enable my challenge cache ideas?

 

Or maybe I should take your advice and just not bother because I really don't want to waste anybody's time - including my own, if I'm honest. That seems to be what you think I should do.

 

I had a post responding to this and realized it was probably not what was needed. Personally, I think you were reading Palmetto's post a bit too literally with regard to the process. I didn't read it the same way you did - if A, then B, then C. I just saw it as a list of all three steps a CC would go through. All I know is that without the checker, it WILL NOT get published. If I were Groundspeak, I'd be certain to tell my reviewers that they don't reply to ANY challenge cache questions (other than a proximity request) until the CO provides a link to a checker that works and is complete, not one that's almost done or still in the process of being written. I would think that would help reduce the workload a bit. No checker, no submission, workload reduced again.

 

As to your first question, I hope that was rhetorical as it was mentioned where you can go for help in this thread in the original post and in this post. Both of them have links that shed further light on how to get a checker written. The second has a link that takes you directly to the page you need.

 

Let's have a re-read...

 

Review will be as ever, starts with physical cache meets physical requirements, challenge requirements meets challenge cache guidelines, and has checker.

 

Yeah - it is kind of vague - but it does say that the process starts with the geocaching reviewer who, it seems, won't publish a cache that doesn't have a checker - and it seems that a checker can only be linked to a published cache - so how's that gonna work? :rolleyes:

 

I also note that Palmetto's post has been edited. I'm pretty sure it originally read:

 

Review will be as ever, starts with physical cache meets physical requirements, challenge requirements meets challenge cache guidelines, and then has checker.

 

I'll have to make sure I quote people directly more often so that I don't need to try to remember what was originally said <_<

 

The point of the first question was related to the loop described in the above paragraph and the fact that as someone with no experience in the requisite programming discipline(s) I don't know how to start thinking about whether a checker can be written for the challenge concept I just came up with - I'm completely in the hands of someone else who may or may not be able to come up with a way of doing it - I doubt all checker writers are created equal.

Link to comment

Review will be as ever, starts with physical cache meets physical requirements, challenge requirements meets challenge cache guidelines, and has checker.

 

Yeah - it is kind of vague - but it does say that the process starts with the geocaching reviewer who, it seems, won't publish a cache that doesn't have a checker - and it seems that a checker can only be linked to a published cache - so how's that gonna work? :rolleyes:

 

A checker can be linked to an unpublished cache. A checker can in fact be linked to no cache at all and still used, for testing purposes. That's a non-issue.

Link to comment

Review will be as ever, starts with physical cache meets physical requirements, challenge requirements meets challenge cache guidelines, and has checker.

 

Yeah - it is kind of vague - but it does say that the process starts with the geocaching reviewer who, it seems, won't publish a cache that doesn't have a checker - and it seems that a checker can only be linked to a published cache - so how's that gonna work? :rolleyes:

 

A checker can be linked to an unpublished cache. A checker can in fact be linked to no cache at all and still used, for testing purposes. That's a non-issue.

 

That's good to know :)

 

I thought I'd read previously that it couldn't - maybe I'm mistaken.

Link to comment
Each checker writer may look at requests for new checkers, or they may not. A checker writer may simply get checker-writing privileges for writing a checker for a personal challenge and then never creating another checker. If your challenge looks convoluted or the checker writer doesn't have time right then, no checker is likely to get done. There is no expectation of things being processed in any special order, or even of any specific request even getting a response. Consider the checker writers you see in the PGC forum the same as the guy you meet at an event. He's probably happy to help you answer questions, but it's not his job to answer any and all of your questions.

 

As much as I admire PGC, this is exactly why I fear this whole experiment is going to be a dismal failure.

Link to comment

I don't know if you're being deliberately obtuse, but I'll spell it out for you even more...

 

You're focusing on the easy, non-contentious decisions. The checker decides if a cache title's word matches one of the words on the checker's list. That's a simple, non-contentious decision. The only problems that probably will arise are rare programming bugs or typos, and there will be very little disagreement about how to fix those few problems. If you want to call the checker the "final arbiter" of those non-contentious decisions, then go ahead.

I'm only focusing objective results. A challenge is qualified if the checker verifies it. If the checker doesn't, but the CO wants to let the qualification stand, the CO needs to adjust/fix the checker. In that simple process, the checker is the final arbiter. If the checker has a bug, the CO has to fix it. If the checker is not consistent with the challenge description, then it's "subject to archival". Doesn't seem complicated or subjective at all to me. [boldface added]

You seem to misunderstand the concept of "objective" versus "subjective." Something is objective if it is "based on facts rather than feelings or opinions." Something is subjective if it is "based on feelings or opinions rather than facts." When you say something doesn't seem "subjective at all to me," then you're saying that it is based entirely on facts; opinions don't enter the picture at all.

 

An objective decision is made when a bug-free checker compares a cache title to a list of acceptable words. The title either contains a word on the list or it doesn't. The checker is great at making these kinds of objective decisions. If you want to call the checker the "final arbiter" of these kinds of decisions, you can.

 

Now, let's suppose a challenge finder uses a cache whose title includes the word "filly" but the checker rejects that cache because "filly" is not on its list of approved "animal" words. And let's further suppose that the challenge cache owner decides that "filly" is an acceptable "animal" name and adds it to the checker's list of approved words. You claim the cache owner's decision is not subjective at all, but you're wrong.

 

Whether "filly" is an "animal" in the context of a challenge cache requirement isn't a simple yes/no fact; it's an opinion. And two different people can have very different opinions about what an "animal" is in this context. The owner of this animal challenge cache might agree with the finder that a "filly" is an "animal" in the way she meant "animal" when she established this challenge. But the owner of another animal challenge cache might have intended that only more generic animal names (e.g., "horse") meet his requirement; gender- or age-specific animal names (e.g., "filly," "stallion," "colt") are not in the spirit of his challenge requirement. Two different cache owners have two different opinions, so deciding what is an acceptable word is a subjective decision.

 

Please note that it's not the checker that's making the decisions regarding what words do/don't belong on the approved word list; it's the cache owner. The checker has nothing to say regarding these kinds of decisions; it has no idea whether a word that's not on the approved word list should be put on that list. For these kinds of subjective decisions, it's the cache owner (under your scheme) who is the "final arbiter."

 

Also, please note that adding "filly" to the checker's list of approved words doesn't magically convert this subjective decision into an objective decision. The decision of whether "filly" was an acceptable "animal" word was still a subjective decision. And whether future proposed words are acceptable "animal" words will still remain subjective decisions.

 

Reviewers and appeals only need to get involved if the checker is found to not be consistent with the challenge description, and the CO can't or won't make it work.

You kind of mangle this sentence, but I think I agree. If a challenge finder believes the checker is inconsistent with the challenge requirement and the challenge owner disagrees, then the finder can bring the matter to a Groundspeak reviewer and/or appeals and let them make a determination of whether or not the checker is incorrectly ignoring certain word(s)...at least if you don't usurp Groundspeak's authority to make these kinds of decisions.

 

For publishing, it's much easier to determine if it's a valid challenge - is there a checker linked? Likely also, does its output imply that it does what it's supposed to do? Yes, *pubish*.

After publication, bugs or issues may yet be found, but at least at that point there's enough objectivity (results and evidence, not word of mouth and opinion) that the checker and challenge are not in sync.

The decision to publish open-ended word challenges will remain a subjective decision. It's not as simple as confirming that there is a checker that produces what it's supposed to (which is itself a subjective decision).

 

Suppose I submit a challenge cache that requires finding 25 caches whose titles include orange-ish, round-ish, soft-ish things. Further suppose I use an existing word-list checker and write an initial tag that includes the following list: ball, carrot, face, hat, pumpkin, slug. Now I have a linked checker that outputs what it's supposed to. Should a reviewer publish it? No! The challenge requirement is too subjective and is likely to lead to lots of disputes. How orange-ish must the thing be? How round-ish must the thing be? How soft-ish must it be? Does the entire object need to be soft-ish? Can just a small portion of it be soft-ish? Soft-ish relative to what?

 

The existence of a linked, valid checker doesn't magically convert a challenge cache requirement into an objective statement.

 

The key, contentious decisions concern whether a word that properly belongs on the checker's list is missing from that list. Does that word meet the challenge cache's somewhat ambiguous requirement?

In my example, the wording of the rules covered that. If I used the "any animal name" option with the clause that the checker is the final ruling unless as the CO I approve a new word, then there's no ambiguity. If I don't approve the new word (by lack of response or direct decline), and you have the list of approved words, then it sounds like the reviewer will simply say - the checker and challenge are consistent, it says no, so no; find caches that match the approved word list.

Assuming that Groundspeak allows you to usurp their authority to determine what new words properly meet the challenge requirements, then the process has no ambiguity. But the challenge requirement is still somewhat ambiguous. Unless you decide to never consider any new words (which makes this a closed-ended word list), you still have to make subjective decisions about what words adequately meet the somewhat ambiguous challenge requirement. And challenge finders might disagree with your subjective decisions. They might have no recourse under your proposal, but they might still feel that you (and Groundspeak) treated them unfairly (which is why Groundspeak might not cede their appeals authority to challenge cache owners).

 

Under Option 3 of your proposal, the challenge cache owner will be the final arbiter regarding these key decisions.

Decision-making, yes. But, again, the checker has to reflect the decision. If it doesn't, the cache is subject to archival. A CO won't be able to say "okay" to person#1 who fails the check, but with the same parameters let the checker's "no" remain for person#2. One of the cachers' results is inconsistent, and the CO has made a subjective call. If that goes to appeals, the way I understand GS's outline of the new challenge process thus far, they're implying the cache will be subjet to archival - because the checker can't be trusted to be accurate.

Right, if you allow your friend to use "filly" as an "animal," then you must allow all finders to use "filly." But simply keeping the checker up-to-date isn't sufficient. If you allow your friend to use "filly" but then deny me the use of "sow," then Groundspeak appeals might question why you are allowing gender-specific animal names for horses but rejecting gender-specific animal names for pigs. Or if you allow your friend (who recently visited Texas) to use the word "Dallas" as an animal name, then Groundspeak appeals might ask whether you're showing favoritism in making your subjective decisions.

 

Simply adding a new word to the checker's list of approved words doesn't magically convert your subjective decisions regarding acceptable words into objective decisions.

 

And if the challenge cache owner starts making arbitrary and capricious judgments on these key decisions (e.g., accepting "filly" but not accepting "sow"), then Groundspeak probably will hear about it from some denied challenge finders. Will Groundspeak want to correct these "unfair" situations or will they prefer to ignore them by making the challenge cache owners the final arbiters? I'm putting my money on the former, although I wouldn't object to the latter.

It sounds to me that they will side with what the checker says, and whether the challenge describes it accurately.

But the question of whether or not the challenge cache requirement accurately describes what the checker accepts is a subjective question that needs Groundspeak appeals to make a judgment call. On what logical basis does the checker accept "filly" and reject "sow?" If you added "filly" to the checker's approved words list simply because your friend had found a cache that included "filly" in its title, then Groundspeak appeals probably would side with the challenge cache finder who had "sow" rejected by the checker.

Edited by CanadianRockies
Link to comment

The checker would need to allow all cachers on the same day to claim the cache as qualified.

 

Even though all but one of them isn't entitled to claim the cache (or rather the challenge aspect of it) as qualified.

 

Having a checker as final arbiter of qualification will be a great facilitator for armchair logging.

Most Lonely Cache (aka Resuscitator) challenges that I've seen, which have all been in the USA, have allowed this. I'm not familiar with requirements of Lonely/Resuscitator challenges in other countries.

Edited by noncentric
Link to comment

Firstly, I'm going to stop using "arbiter" because I think that may be a point of confusion as it implies decision making rather than objective rulings, which has always been what I've been meaning by saying the checker is the "final arbiter" - the result of the checker is final. Arbitration happens at reviewer/appeal level, betwene a CO and a finder. Continuing...

 

You seem to misunderstand the concept of "objective" versus "subjective." Something is objective if it is "based on facts rather than feelings or opinions." Something is subjective if it is "based on feelings or opinions rather than facts." When you say something doesn't seem "subjective at all to me," then you're saying that it is based entirely on facts; opinions don't enter the picture at all.

We are talking across meanings. I'm not saying the decision is objective, or that the checker is subjective. I'm saying the final "yes or no" for qualification is based on the objective checker. The checker doesn't make any decisions (as in choices, not logic gates). The CO makes decisions, and subjective ones. But where there is no CO involvement, the listing's challenge description and checker are 100% objective. Therefore someone completing the challenge must abide by the checker result.

If at that point the finder believes the checker should be changed, they can contact the CO who may then subjectively decide to alter the checker so that it objectively returns "Yes" instead of "No" for the finder, as well as ensure that the challenge description and the checker are consistent so that the cache does not become subject to archival.

 

Now, let's suppose a challenge finder uses a cache whose title includes the word "filly" but the checker rejects that cache because "filly" is not on its list of approved "animal" words. And let's further suppose that the challenge cache owner decides that "filly" is an acceptable "animal" name and adds it to the checker's list of approved words. You claim the cache owner's decision is not subjective at all, but you're wrong.

No, the CO made the judgement - subjective by definition - to alter the checker and challenge description so that the finder can then run that checker test again, and the checker would then objectively spit out "Yes" so they can post the find. This is not dancing around words. The final qualification validation must always rest with the checker, if we are interpreting GS's limited announcement correctly. Because if the checker spits a different answer than the CO allows as a Find/Qualification, then the checker is considered incorrect or buggy, and the cache is subject to archival.

 

Whether "filly" is an "animal" in the context of a challenge cache requirement isn't a simple yes/no fact; it's an opinion.

That decision occurs outside the scope of the checker. Until a decision made, the checker is still the final word (even if the CO says they may decide to amend an acceptable word list). If the CO does nothing, the finder does not qualify. If the CO says no, the finder does not qualify. If the CO says yes, the CO must then update the listing and the checker, then the checker says yes, and the finder qualifies.

 

Please note that it's not the checker that's making the decisions regarding what words do/don't belong on the approved word list; it's the cache owner. The checker has nothing to say regarding these kinds of decisions; it has no idea whether a word that's not on the approved word list should be put on that list. For these kinds of subjective decisions, it's the cache owner (under your scheme) who is the "final arbiter."

First part - Yes, exactly. Last sentence - we're saying the same thing in different ways, as described above. The CO can make all the subjective decision he wants until the cows come home. The checker must reflect the challenge, and the checker's result is the final ruling.

 

If a challenge finder believes the checker is inconsistent with the challenge requirement and the challenge owner disagrees, then the finder can bring the matter to a Groundspeak reviewer and/or appeals and let them make a determination of whether or not the checker is incorrectly ignoring certain word(s)...at least if you don't usurp Groundspeak's authority to make these kinds of decisions.

Agreed.

 

The decision to publish open-ended word challenges will remain a subjective decision. It's not as simple as confirming that there is a checker that produces what it's supposed to (which is itself a subjective decision).

Of course the reviewer will always have to make the judgement call. There are plenty of other factors involved in the review. But as others have been exchanging in this thread, it sounds like the first requirement is that there is a checker that does what the proposed challenge requires. Will there need to be a way for the CO to prove that the checker isn't buggy? I dunno, how can one test every scenario that finders may present? To me it seems that the only option is that essentially, 'there is a checker linked that provides results implying exactly what the challenge describes'. If that step is seen as valid by the reviewer, then it passes the checker-check portion of the review, whatever kind of challenge it may be.

 

Suppose I submit a challenge cache that requires finding 25 caches whose titles include orange-ish, round-ish, soft-ish things. Further suppose I use an existing word-list checker and write an initial tag that includes the following list: ball, carrot, face, hat, pumpkin, slug. Now I have a linked checker that outputs what it's supposed to. Should a reviewer publish it? No! The challenge requirement is too subjective and is likely to lead to lots of disputes. How orange-ish must the thing be? How round-ish must the thing be? How soft-ish must it be? Does the entire object need to be soft-ish? Can just a small portion of it be soft-ish? Soft-ish relative to what?

I agree, and in my vision of a sample challenge like this that I posted earlier, the wording in this case would be providing the accepted word list (or showing how to view it via PGC), and that if the checker fails for a finder, to contact the CO and request certain words be added. If I were the CO publishing this, it means I'm willingly taking on the added responsibility of maintaining that list. However the wording also states that if I don't approve the new words, then the checker's "No" is final (and that is consistent with the challenge - words aren't in the accepted word list). The finder can insist and take that to appeals if they want. But the cache is already published (which has already reduced the reviewing work for challenge caches)

 

In the current way, this is the same process excepting that a cacher can currently just post the Find, after which point the CO has the option to review and delete the find if he judges a word invalid. Under this new system, the checker would objectively indicate non-qualification, so the CO can point to that when deleting a Find. If that cacher contacted the CO requesting new words, then we go back to the first paragraph in this post about subjective CO decision making coming back to amending the checker.

 

Assuming that Groundspeak allows you to usurp their authority to determine what new words properly meet the challenge requirements, then the process has no ambiguity. But the challenge requirement is still somewhat ambiguous.

Exactly. And if the process is clear, but the described requirement is ambiguous, then the checker can't be trusted (or the CO is problematic), and the cache either wouldn't be published in the first place or appeals may decide the cache would be subject to archival.

 

Unless you decide to never consider any new words (which makes this a closed-ended word list), you still have to make subjective decisions about what words adequately meet the somewhat ambiguous challenge requirement. And challenge finders might disagree with your subjective decisions. They might have no recourse under your proposal, but they might still feel that you (and Groundspeak) treated them unfairly (which is why Groundspeak might not cede their appeals authority to challenge cache owners).

But if the checker checks from a [current] list, and the challenge requires qualifying caches to use words found within the word list (despite the CO saying they can choose to amend the list), then the finder will be judged to not qualify.

As I said in a previous comment, I can only see a really legitimate appeal happening if a very insistent finder complains that the CO's category must obviously contain the requested word, and perhaps the CO has amended before but isn't now, and in that case GS might judge that the CO is not being responsible with their challenge cache; then either require them to make the change, or face potential archival. That's a valid appeal, but I also don't think that would be anywhere near a remotely significant quantity of appeals.

 

Remember the scenario:

FinderA fails the checker, requests "filly" as a valid word and logs the find. CO says "ok" but doesn't fix the checker.

FinderB comes along, sees FinderA used "filly" but the checker still says "no". B Contacts the CO, who denies the Find. uh oh. *Appeals!* Checker is found not consistent with the challenge. Evidence: Two finders both failing the checker, but one was approved by the CO anyway. "Hey CO, fix your checker, or your cache is subject to archival."

Easy appeal process.

 

Alternate:

FinderA fails the checker, requests "red" be added as a valid word in the category "colour". CO says no, points to challenge wording that says the CO will decide whether to accept a new word but that the checker is final. In this case, FinderA complains to appeals that it's clear "red" should be an acceptable word. Now appeals has a legitimate judgement call to make one way or another. There was no way for a reviewer to know how the CO would actually handle new word requests, despite saying they may choose to add valid words to the list if requested. So passing review, it was published, but now it could face archival.

 

Alternate:

FinderA fails the checker, requests "gooose" [sic] be added to a valid word list of animals. CO says no, it's not correct spelling, points to challenge wording that says the checker is final. In this case, FinderA complains to appeals that it's clear a goose is an animal and should be accepted. CO says the misspelling is not acceptable as it's not in the word list. What would GS decide? I'd wager appeals would rule in favour of the CO. "gooose" is not an animal. "goose" is. And the challenge description is consistent with the checker.

 

In each of these cases, the cache was published with little appeals headache because the CO provided a checker that did exactly what the challenge description stated.

 

If I as the CO were unresponsive to the Finders' requests for words, then it would still go to appeals, and they'd have exactly the same judgements to make based on the evidence presented, and to me it seems the result of the above would be exactly the same.

 

If I, as a CO, take on the responsibility of an amendable list challenge, then I'd be expected to make decisions within reason. If my decisions are reasonable, appeals from finders would be rejected in favour of the checker result. If my decision is judged unreasonable, then either I'll be required to update my checker or face archival.

Is that something we disagree on? It honestly doesn't sound like it.

 

But the question of whether or not the challenge cache requirement accurately describes what the checker accepts is a subjective question that needs Groundspeak appeals to make a judgment call.

Presumably this would be part of the review process. If it's published, the reviewer has already deemed the checker to be sufficiently accurate to the challenge. If anything changed, then there's objective evidence that can be presented showing that the checker output and challenge are not consistent, at which point an appeal would decide the fate of the CO/cache. The reviewer can't know if the CO will keep his word, the reviewer can only judge that the checker appears to be consistent with the challenge description. And that is what seems to be the primary benefit of requiring the checker to reduce reviewer/appeals workload during challenge cache publishing. Additionally, while that may 'push' some issues to post-publish disputes, making the checker the final ruling on qualification cuts down on much more of the reviewer and appeals headaches.

Link to comment

So to get a challenge approved you have to ask project gc to write you a macro first? What about challenges that are easily proven with the statistics provided by geocaching.com?

 

"At this time, Project-GC is the only website approved to host challenge checkers."

 

Presumably that means public GC statistics are allowed (ie, the checker would be "as visible on your statistics page") and any sites that provide approved checking processes (at this point only PGC does).

 

I hope this means they may be opening the API development door again.

Does this mean they won't allow MyGeocachingProfile or GSAK Macros?

Link to comment

Wow. You still just don't get it. (Or you do and you're just semantically tap, tap, tapping around.) I won't waste my time explaining all the problems with your statements. Instead, I'll just focus on what might the crux of your "misunderstanding."

 

The checker doesn't make any decisions (as in choices, not logic gates). The CO makes decisions, and subjective ones. But where there is no CO involvement, the listing's challenge description and checker are 100% objective.

For open-ended word challenges, the challenge cache requirement (which is an essential part of the listing's challenge description) almost always has a subjective element to it. The subjectivity is in the nature of the wording; it doesn't depend on whether or not the cache owner takes some sort of action.

 

A challenge requirement to find 25 caches with an animal name being part of their titles is not 100% objective. Even if no challenge cache finder ever disputes the checker's result. Even if the challenge cache owner never gets involved after publication. The challenge requirement still is somewhat subjective.

 

You can claim "The Godfather" is the best movie ever. That's a subjective statement, based on your opinion. Even if (amazingly) nobody disputes your statement, it's still a subjective statement. Subjectivity depends on wording, not on anybody's actions (or reactions).

Edited by CanadianRockies
Link to comment

So to get a challenge approved you have to ask project gc to write you a macro first? What about challenges that are easily proven with the statistics provided by geocaching.com?

 

"At this time, Project-GC is the only website approved to host challenge checkers."

 

Presumably that means public GC statistics are allowed (ie, the checker would be "as visible on your statistics page") and any sites that provide approved checking processes (at this point only PGC does).

 

I hope this means they may be opening the API development door again.

Does this mean they won't allow MyGeocachingProfile or GSAK Macros?

My assumption is no and no:

-- MyGeocachingProfile requires running a My Finds PQ, which is not available to Basic Members.

-- GSAK requires a Windows machine, which is not available to Mac users.

Link to comment

Firstly, I'm going to stop using "arbiter" because I think that may be a point of confusion as it implies decision making rather than objective rulings, which has always been what I've been meaning by saying the checker is the "final arbiter" - the result of the checker is final. Arbitration happens at reviewer/appeal level, betwene a CO and a finder. Continuing...

I think this sums up what I see as the part you're differing with others. The checker is a tool that lets the finder know if he qulifies for the challenge - it doesn't tell the CO who has or hasn't qualified. The checkers I've seen and played with will, once you've qualified, give you a list to show the CO your qualifications. THAT is what the CO sees that tells him you've qualified, not that you've passed a checker. Example: The challenge says "find one hundred caches with a animal name in title. Use a bookmark list, or list in find log, those caches." Nowhere is there anything about passing the checker - only listing the caches that show your qualifications. So if someone has a list that doesn't pass the checker, but the finder believes still qualifies him, he submits his list to the CO and logs. The CO looks at the list and either accepts or regects the find. Where is this "final say" the checker is supposed to have? The qualification proof goes to the CO, not a checker.

 

Not just a question to you, but can a CO - or anyone else for that matter - run a checker against someone else's name?

Link to comment

 

"At this time, Project-GC is the only website approved to host challenge checkers."

 

Presumably that means public GC statistics are allowed (ie, the checker would be "as visible on your statistics page") and any sites that provide approved checking processes (at this point only PGC does).

 

I hope this means they may be opening the API development door again.

Does this mean they won't allow MyGeocachingProfile or GSAK Macros?

My assumption is no and no:

-- MyGeocachingProfile requires running a My Finds PQ, which is not available to Basic Members.

-- GSAK requires a Windows machine, which is not available to Mac users.

 

The statement from Groundspeak was

All future challenge caches must include a web-based challenge checker.

 

That clearly states that GSAK is not an option since it is not web-based. That word clearly didn't end up there by accident. I'd say it's specifically put there to not allow GSAK as a valid checker provider.

 

My interpretation is that no, MyGeocachingProfile is not allowed *at*this*time* (where "at this time" means "once challenges are allowed for publication again" rather than actually "now" since the latter would be pointless). As has been pointed out, MyGeocachingProfile requires that you upload a MyFinds PQ. That means that it's only available to premium members of geocaching.com which would be a limitation. I don't think that in itself would be an obstacle, necessarily, for it to be a viable source of challenge checkers. However, since it relies on the MyFinds PQ it also means that I can only check *my* stats. I can't, as a challenge cache owner, check someone else's stats. That, in my mind, would make them a bad choise as a challenge checker provider.

 

I won't be surprised if alternatives to Project-GC as challenge checker providers will appear, but I wouldn't expect anything like that in the near future and definitely not before challenges are allowed again.

 

With that being said, I don't forsee any problems with people using these methods (GSAK, MyGeocachingProfile, etc) to figure out whether they are qualified for a challenge or not, and using output from them for their verification logs. The limitation on having to use a Project-GC challenge checker is on the cache owner when creating a challenge cache, not on the loggers. And, for that matter, the cache owner doesn't have to run the checker for every single log that comes in. S/he can check the logger's statistics on geocaching.com (or wherever) if that's easier (as it may be for things like filling up the D/T grid).

Link to comment
Each checker writer may look at requests for new checkers, or they may not. A checker writer may simply get checker-writing privileges for writing a checker for a personal challenge and then never creating another checker. If your challenge looks convoluted or the checker writer doesn't have time right then, no checker is likely to get done. There is no expectation of things being processed in any special order, or even of any specific request even getting a response. Consider the checker writers you see in the PGC forum the same as the guy you meet at an event. He's probably happy to help you answer questions, but it's not his job to answer any and all of your questions.

 

As much as I admire PGC, this is exactly why I fear this whole experiment is going to be a dismal failure.

 

I think we rather should think of PGC as a host of challenge checkers and a host of a forum where experienced checker writers are around that offer help. I do not think that there is any right to get a checker done. So of course those who either can write their own checker or come up with ideas that are appealing to a checker writer, will have an advantage. The rest will have to be content with challenge caches for which checkers already exist. It's clear anyway that the new approach favours cachers who either have done programming themselves or have at least some understanding of what can be done by a computer and what cannot be done. Look at the group participating in this thread - the big majority of them have at least some experience in writing code.

 

The tiresome part will definitely be to explain to those with no background at all what cannot be done by automatic checkers.

Link to comment

-- GSAK requires a Windows machine, which is not available to Mac users.

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator.

 

Monopolies are very bad and I think proven not to work. Variety seems a good idea to me so why not allow GSAK which makes some checking easier.

 

I suggest The fundamental issue here is that not everyone has to be able to find every cache which seems to be forgotten quite often.

Link to comment

-- GSAK requires a Windows machine, which is not available to Mac users.

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator.

 

Monopolies are very bad and I think proven not to work. Variety seems a good idea to me so why not allow GSAK which makes some checking easier.

 

I suggest The fundamental issue here is that not everyone has to be able to find every cache which seems to be forgotten quite often.

 

Desktop software is dead, or dying, for many people.

 

I believe the average new user uses only mobile apps, probably never opened geocaching.com on their computer or even know there is a site, and likely use a phone or tablet for 90% of their internet.

 

Using a desktop application for verification is antiquated. There should be nothing it can do that an online checker can't do now or in the future.

Link to comment

So to get a challenge approved you have to ask project gc to write you a macro first? What about challenges that are easily proven with the statistics provided by geocaching.com?

 

"At this time, Project-GC is the only website approved to host challenge checkers."

 

Presumably that means public GC statistics are allowed (ie, the checker would be "as visible on your statistics page") and any sites that provide approved checking processes (at this point only PGC does).

 

I hope this means they may be opening the API development door again.

Does this mean they won't allow MyGeocachingProfile or GSAK Macros?

My assumption is no and no:

-- MyGeocachingProfile requires running a My Finds PQ, which is not available to Basic Members.

-- GSAK requires a Windows machine, which is not available to Mac users.

 

If MyGeocachingProfile and GSAK are additional options as checkers I don't see how those constraints are an issue. While GSAK is a windows application it also has web website that could host checkers. Both are official geocaching partners with access to the API and both could provide an additional service (hosting challenge checkers) independent of their existing services.

 

 

Link to comment

-- GSAK requires a Windows machine, which is not available to Mac users.

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator.

 

There are three ways to run GSAK on a MAC. A MAC can boot Windows using one of the dual boot applications. In that case, the mac isn't running an emulator but is actually running the windows O/S. The second option is to use a virtual machine container. That's not emulating windows either. The third option is to use a application called WIne. Wine will take an existing windows application and rewrite the system calls to MacOS calls. With Wine, the machine is still running MacOS and it's not actually running Windows, but just emulating some of the windows application code so that it can run on a mac.

 

 

Link to comment

-- GSAK requires a Windows machine, which is not available to Mac users.

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator.

 

Monopolies are very bad and I think proven not to work. Variety seems a good idea to me so why not allow GSAK which makes some checking easier.

 

I suggest The fundamental issue here is that not everyone has to be able to find every cache which seems to be forgotten quite often.

 

Desktop software is dead, or dying, for many people.

 

I believe the average new user uses only mobile apps, probably never opened geocaching.com on their computer or even know there is a site, and likely use a phone or tablet for 90% of their internet.

 

Using a desktop application for verification is antiquated. There should be nothing it can do that an online checker can't do now or in the future.

 

I accept that many people mostly use the internet mostly on phones/tablets and might have no need of desktop software. I suggest that the use of laptops/netbooks hasn't quite died out yet and nor will it. Sadly the logical corollary to your comment is that we should junk any reference to PC software which seems a little extreme.

Link to comment

I accept that many people mostly use the internet mostly on phones/tablets and might have no need of desktop software. I suggest that the use of laptops/netbooks hasn't quite died out yet and nor will it. Sadly the logical corollary to your comment is that we should junk any reference to PC software which seems a little extreme.

 

Junk - no. But it shouldn't be the only way of verifying a challenge. If a challenge cache owner wants to provide a project-gc checker and a GSAK checker, and accepts both, fine. But logging a cache shouldn't require a windows download of a commercial application (last I checked it was nagware).

Link to comment

The tiresome part will definitely be to explain to those with no background at all what cannot be done by automatic checkers.

 

If someone (like me) isn't very code literate, I'm not going to understand the reasons why it cannot be done. I'm not going to want an explanation because I would have no understanding of the technical reasons. A simple yes or no is all I need. The "why", at this point in time, doesn't matter. As I get more literate, then perhaps I'll ask for more clarification and even understand some of the processes and language necessary to write a checker.

Link to comment

-- GSAK requires a Windows machine, which is not available to Mac users.

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator.

 

Monopolies are very bad and I think proven not to work. Variety seems a good idea to me so why not allow GSAK which makes some checking easier.

 

I suggest The fundamental issue here is that not everyone has to be able to find every cache which seems to be forgotten quite often.

 

Desktop software is dead, or dying, for many people.

 

I believe the average new user uses only mobile apps, probably never opened geocaching.com on their computer or even know there is a site, and likely use a phone or tablet for 90% of their internet.

 

Using a desktop application for verification is antiquated. There should be nothing it can do that an online checker can't do now or in the future.

 

As a database admin, that makes me sad.

 

It does seem that as we trudge towards the future, more and more people are afraid of computers. So many new hires barely even know how to use a spreadsheet or word doc.

 

I'll only partially agree that a web checker should be able to do what a desktop application can do. It is only a valid statement if the database is 100% open. If my stats on Project-GC matched 100% with my stats at Groundspeak, I would be much more willing to accept web checkers as the end all beat all arbitrator.

 

Having a central database that is free from data manipulation is a wonderful concept. But all databases have errors. The information in the database is only as good as what people put into it. When someone comes to me and says the query didn't return the predicted result, I have to investigate. Most times there is either a spelling mistake or mismatched information. When I correct the error that someone else made, the query works fine.

 

In GSAK, I can make notes of irregularities.

 

If I created a challenge cache to "find 10 caches that have the word 'cemetery' in the title", that is something that is very easy to design: If [Title] Like "Cemetery" Then Acceptable. A perfect use of a checker to scan the database quickly. But, what if the title has "Cematery" or "Cemetary" or some other spelling mistake. The query would skip over those, even though they should be acceptable. GSAK lets me manually flag those caches, throw them into my log and I can add a footnote explaining the spelling mistakes, that someone else made.

 

False positives and false negatives are bound to happen and I'm interested in how that is going to be handled.

Link to comment
The checker is a tool that lets the finder know if he qulifies for the challenge - it doesn't tell the CO who has or hasn't qualified. The checkers I've seen and played with will, once you've qualified, give you a list to show the CO your qualifications. THAT is what the CO sees that tells him you've qualified, not that you've passed a checker.

There was a comment earlier, if I recall correctly, that said it's possible for someone to check against another finder's name. I was going on the conceptual basis that the CO could use the checker to verify the finder's qualification. And honestly it seems half pointless if only the finder can do the verification of their own data, and I would think that with the new system especially the CO would be have that ability. =/ Who knows, maybe not. But that's my basis for all this recent back and forth.

 

Example: The challenge says "find one hundred caches with a animal name in title. Use a bookmark list, or list in find log, those caches." Nowhere is there anything about passing the checker - only listing the caches that show your qualifications. So if someone has a list that doesn't pass the checker, but the finder believes still qualifies him, he submits his list to the CO and logs. The CO looks at the list and either accepts or regects the find. Where is this "final say" the checker is supposed to have? The qualification proof goes to the CO, not a checker.

You know what, in this case, thank you - I think you just explained succinctly where the difference in our premise may actually be. That paragraph helped :)

 

Yes, if the CO is the one who looks at a checker's result (trusting that the user hasn't made any modifications) and isn't able to use the checker to test the results themselves, then the CO would indeed be the final judge making the ruling of whether the finder qualifies.

 

And... actually... now that I think about it... my position had a drawback. If instead the checker is the final ruling, then there would need to be a statute of limitations of some sort. If as the CO I ran the checker a month after a finder claimed qualification, but something changed, then they might no longer qualify, when they did at the time they posted qualification. ...Then what? It would come down to comparing the results the finder posted initially with the current results of the checker, then going through and finding what changed, and then deciding if the finder is still qualified. But in theory at that point the checker would never return qualified again. And that could cause more problems for appeals if they are to judge whether the checker and challenge are consistent.

 

Jester, thanks for a reasoned and non-personal response that hit the crux of the matter on the nose. I'm stepping back a bit from my position... I don't believe GS ever stated the checker would be the CO's way of confirming qualification; that was how I interpreted the announcement that the checker would be a requirement, but I can see good reason as well why that wouldn't be the case.

 

I did mention earlier, however, that one way around that change-in-qualification-over-time would be to provide a code or some form of lookup to verify that a user who ran the checker and qualified actually had qualifying data, even if they don't now. As per the case above, as the CO I could come back to the finder's log a month after posting, and if I were to run the checker they'd fail; but if I were to use the reference code they posted with their log, I could use the trusted report from PGC itself to confirm that the user's log is correct - they did in fact qualify at that time and didn't "fudge" their checker report (eg, claiming something changed and they should qualify).

 

It could be as simple as the checker result providing a GUID with the result output, which when looked up would return the finder's username, date, and challenge GC. An objective verification. Sort of like the Wherigo completion code (not that that system is perfect, but conceptually similar)

 

Alas, that's all more development work between GS and PGC, and just an idea on my part :P

 

Not just a question to you, but can a CO - or anyone else for that matter - run a checker against someone else's name?

Yes. Anyone can run any Project-GC challenge checker for any username.

Hm, so that's great, but then yeah the check can be only be run against current data, which doesn't help with "un"qualification over time. The CO would need to check and verification as soon as possible after a finder claims qualification. How would GS plan to deal with disputes from unqualification? Or will they just accept that and leave it up to the CO to be reasonable? :P

Edited by thebruce0
Link to comment

I accept that many people mostly use the internet mostly on phones/tablets and might have no need of desktop software. I suggest that the use of laptops/netbooks hasn't quite died out yet and nor will it. Sadly the logical corollary to your comment is that we should junk any reference to PC software which seems a little extreme.

 

Junk - no. But it shouldn't be the only way of verifying a challenge. If a challenge cache owner wants to provide a project-gc checker and a GSAK checker, and accepts both, fine. But logging a cache shouldn't require a windows download of a commercial application (last I checked it was nagware).

We will have to agree to differ. My point is that some caches might require the application, some might require Project GC, some might allow both. Other applications might be acceptable in the future. If you can't have/don't want the application you may not be able to log the challenge cache just like any other cache that is not possible for you to get to for other reasons.

Link to comment
The checker is a tool that lets the finder know if he qulifies for the challenge - it doesn't tell the CO who has or hasn't qualified. The checkers I've seen and played with will, once you've qualified, give you a list to show the CO your qualifications. THAT is what the CO sees that tells him you've qualified, not that you've passed a checker.

There was a comment earlier, if I recall correctly, that said it's possible for someone to check against another finder's name. I was going on the conceptual basis that the CO could use the checker to verify the finder's qualification. And honestly it seems half pointless if only the finder can do the verification of their own data, and I would think that with the new system especially the CO would be have that ability. =/ Who knows, maybe not. But that's my basis for all this recent back and forth.

 

I've looked at the code for several of the checker and everyone I've seen so far has the following:

 

profileName = args[1].profileName

 

That line would read the geocaching user name as a argument to the script.

 

One of the issues that has come up in the past regarding challenge caches is attainability and whether or not the challenge cache CO has completed the challenge themselves. With a mandatory automated checker it would be real easy for a reviewer to check of the CO has completed the challenge.

 

Check out this geochecker: http://project-gc.com/Challenges/GC3C1NX/165

 

It's for a challenge for obtaining some number of souvenirs. Note that page has a form element for entering a profileName. It's real easy to check if any user qualifies for a challenge using the checkers (both you and I qualify for this one).

 

 

Link to comment

The tiresome part will definitely be to explain to those with no background at all what cannot be done by automatic checkers.

 

If someone (like me) isn't very code literate, I'm not going to understand the reasons why it cannot be done. I'm not going to want an explanation because I would have no understanding of the technical reasons. A simple yes or no is all I need. The "why", at this point in time, doesn't matter. As I get more literate, then perhaps I'll ask for more clarification and even understand some of the processes and language necessary to write a checker.

 

If someone has absolutely no background at all, it's not about understanding technical details - it's about not understanding what a computer can do in principle and what not. I simply forsee many complaints where people will get upset about a no.

Link to comment

The checker is a tool that lets the finder know if he qulifies for the challenge - it doesn't tell the CO who has or hasn't qualified.

 

All checkers at project gc can be run for every account, not only one's own.

This would also allow to provide the reviewers with an automatic system to see how many cachers in a region have already qualified.

 

 

The checkers I've seen and played with will, once you've qualified, give you a list to show the CO your qualifications. THAT is what the CO sees that tells him you've qualified, not that you've passed a checker.

 

The CO can also doublecheck. Some cachers can fake the lists and it is easier to run the checker again instead of checking whether all caches listed in the qualifying list are valid finds.

 

Example: The challenge says "find one hundred caches with a animal name in title. Use a bookmark list, or list in find log, those caches." Nowhere is there anything about passing the checker - only listing the caches that show your qualifications. So if someone has a list that doesn't pass the checker, but the finder believes still qualifies him, he submits his list to the CO and logs. The CO looks at the list and either accepts or regects the find. Where is this "final say" the checker is supposed to have? The qualification proof goes to the CO, not a checker.

 

I'm not sure whether the intended new system will not simply allow a cache owner to delete a log if the checker test is not passed. If not, there will not change anything with respect to appeals.

 

Not just a question to you, but can a CO - or anyone else for that matter - run a checker against someone else's name?

 

Everyone can. A paying number of PCG can make an arbitary number of checks per day - others can make at most 10 checks per day (for whichever account and on which ever challenge cache for which a checker exists). This has been the case since the very beginning.

Edited by cezanne
Link to comment

-- GSAK requires a Windows machine, which is not available to Mac users.

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator.

 

Monopolies are very bad and I think proven not to work. Variety seems a good idea to me so why not allow GSAK which makes some checking easier.

 

I suggest The fundamental issue here is that not everyone has to be able to find every cache which seems to be forgotten quite often.

 

Desktop software is dead, or dying, for many people.

 

I believe the average new user uses only mobile apps, probably never opened geocaching.com on their computer or even know there is a site, and likely use a phone or tablet for 90% of their internet.

 

Using a desktop application for verification is antiquated. There should be nothing it can do that an online checker can't do now or in the future.

 

I accept that many people mostly use the internet mostly on phones/tablets and might have no need of desktop software. I suggest that the use of laptops/netbooks hasn't quite died out yet and nor will it. Sadly the logical corollary to your comment is that we should junk any reference to PC software which seems a little extreme.

Agreed! I understand that i'm in the minority and prefer using my desktop and stand alone gpsr. My smart phone doesn't cut it for me. It's both sad and irritating knowing that i'll have to eventually go from a system that works perfectly fine to something i'm not at all interested in.

 

On providing a website based checker, seems obvious, at least one of the reasons, why this has come into play. Some are comfortable with this as they can actually accomplish it. I feel that for majority of us though, this is more designed to kill our motivation to place challenge caches. It may be a way of reducing workload and headaches for gc.com but imo, it's not the right way.

 

Just another couple of nails in the coffin i suppose.

Edited by Mudfrog
Link to comment

I feel that for majority of us though, this is designed to killed our motivation to place challenge caches. It may be a way of reducing workload and headaches for gc.com but imo, it's not the right way.

 

Just another couple of nails in the coffin i suppose.

 

If that's the case, I'd have to wonder what's in it for PGC and the checker writers.

 

Doesn't exactly sound like an inspirational process to be involved in.

Link to comment

I feel that for majority of us though, this is designed to killed our motivation to place challenge caches. It may be a way of reducing workload and headaches for gc.com but imo, it's not the right way.

 

Just another couple of nails in the coffin i suppose.

If that's the case, I'd have to wonder what's in it for PGC and the checker writers.

 

Doesn't exactly sound like an inspirational process to be involved in.

The fun of coding. I'm a web app developer by profession, so if I had time and better LUA knowledge I'd love to write checkers. It's another challenge. If it can be done, I'd do it. I already do, essentially, but using tools I'm familiar with.

 

You may not find it an inspirational process, but others may. As long as they do, yay!

Link to comment

Not just a question to you, but can a CO - or anyone else for that matter - run a checker against someone else's name?

Yes. Anyone can run any Project-GC challenge checker for any username.

Which brings up the question of privacy. Right now, individual geocachers can tell both Groundspeak and Project-GC that they don't want their statistics to be viewed by the public. Does Project-GC have any restrictions on the type of information that checkers can output?

 

For example, a 366-Day Find Calendar checker might output a simple: "You passed"/"You failed." A more verbose checker could output something like: "You still need to fill 46 days of your calendar." Or it could output a list of the 46 days you still need to fill: Jan. 5, Jan. 17, Feb. 9, Feb. 29, ... Or it could output a complete calendar with all the cells filled in with the number of finds you have (like the one that appears on Groundspeak's Statistics page or on Project-GC's Profile Stats page).

 

The first checker's output does the best job of protecting a geocacher's privacy, but it isn't very helpful if that geocacher wants to know which days they still need to fill (although they could find that information on their GS Statistics page). The final checker's output might be the most helpful, but it's least protective of privacy.

 

If the last type of output is permitted, then another checker could output a geocacher's complete "Cache Types I've Found" table. Or a "Container Types I've Found" table. Or a completely filled in D/T (Fizzy) Table. Or a "Distances to Finds" table.

 

Eventually, I might be able to run a suite of challenge checkers on another geocacher and be able to see almost all of the information that that geocacher currently is hiding on their GS Statistics Page and Project-GC Profile Stats.

Edited by CanadianRockies
Link to comment

What if the detail of the checker output is limited to pass/fail for other cachers? Even a CCO checking a finder would only receive a confirmation or not. But the finder running the checker can get the optional detailed breakdown. The former would be universal, the latter would be as it currently is but only for the cacher being checked.

 

It would take a lot of work for a checker writer to write a bunch of scripts to 'battleship' a user's detailed caching statistics if they only get pass/fail for each.

Edited by thebruce0
Link to comment

I feel that for majority of us though, this is designed to killed our motivation to place challenge caches. It may be a way of reducing workload and headaches for gc.com but imo, it's not the right way.

 

Just another couple of nails in the coffin i suppose.

If that's the case, I'd have to wonder what's in it for PGC and the checker writers.

 

Doesn't exactly sound like an inspirational process to be involved in.

The fun of coding. I'm a web app developer by profession, so if I had time and better LUA knowledge I'd love to write checkers. It's another challenge. If it can be done, I'd do it. I already do, essentially, but using tools I'm familiar with.

 

You may not find it an inspirational process, but others may. As long as they do, yay!

 

While I realise that the urge to simply disagree with me may be high, take a breath, read it again and ask yourself - did he mean what I think he meant? <_<

 

You may respond differently.

Link to comment

...I need more coffee. The small quote thread didn't include the part about desktop vs mobile software for checkers. Getting the thread strands mixed up. :laughing:

 

While I realise that the urge to simply disagree with me may be high

You're wrong on the internet.

Link to comment

What if the detail of the checker output is limited to pass/fail for other cachers? Even a CCO checking a finder would only receive a confirmation or not. But the finder running the checker can get the optional detailed breakdown. The former would be universal, the latter would be as it currently is but only for the cacher being checked.

 

It would take a lot of work for a checker writer to write a bunch of scripts to 'battleship' a user's detailed caching statistics if they only get pass/fail for each.

If Groundspeak and Project-GC were serious about protecting privacy, then that would be a reasonable approach to take. But current Project-GC checkers already output some pretty verbose information about any geocacher I want to learn about, so I'm guessing they aren't too concerned about privacy. And if they did impose such a restriction today, then there are a lot of existing checkers that would need to be modified.

 

Maybe Groundspeak imposed some stricter privacy restrictions upon Project-GC when they made the recent challenge checker deal with them, but I doubt it. Will they do so in the future? I'm not holding my breath.

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