All new challenge caches MUST have a challenge checker

Question

Groundspeak have announced that as part of bringing back challenge caches all new challenge caches MUST have a challenge checker and have identified Project-GC as the only current website providing this service.

Whilst this is good news in that it might drive further traffic to the site and provide visibility of the site cachers who are unaware of the facilities available, there is a downside.

At present the system works on tagging a checker to a cache. However the new guidelines will presumably mean that a reviewer won't allow a challenge to be published without a checker. I fear this creates a catch 22 as if the cache is unpublished then it won't be visible to the tagging system so that the cache can be tagged with a checker and if it's not tagged with a checker then the review won't publish it.

How can this situation be resolved?

Comments

Announcement was at http://forums.groundspeak.com/GC/index.php?showtopic=338632

---

Another possible downside, that hopefully won't occur, is that PGC concentrates on the checkers to the detriment of the stats and tools that are the main reason I use this site. Creating checkers could use a great deal of resources that could be used elsewhere. Did Groundspeak discuss this with PGC before making this announcement?

Answer 1

I don't believe there is an issue actually.

A tag can be created without a GC-Code. I made one myself this week actually (linked in the FAQ).

I am fairly sure a tag can be created for a GC-Code that doesn't exist (is unpublished) as well. The only thing that will happen is that the cache name will be a question mark. At least this is how it worked from the beginning, if it's not like that anymore, it will be fixed.

So the expected flow will be something like this:

1. A geocacher gets a great challenge idea.
2. The geocacher registers a geocache and writes the description.
3. The geocacher writes a challenge checker, or asks someone else to do it, providing what details is needed (requirements), preferably a copy of the cache description.
4. The geocacher (or the helper) tags it to the GC-Code the geocacher has, but isn't published.
5. The geocacher adds the link to the checker in the description so that it's available for the reviewer.

Now, I hope it's obvious that Project-GC have had some discussions with Geocaching HQ about the whole Challenges + PGC checkers thing. We have not discussed the details of the work flow yet, but I see no reason to that it will not work more or less like I described above.

As Groundspeak has said themselves. Not every detailed is ironed out yet, they/we are still working on details, but in the whole we know where we are heading. Basically they are focusing on the future guidelines and Project-GC is working on making it as smooth as possible for everyone to handle the checkers.

Comments

Thinking about it I'd push GroundSpeak to amend the API to flag new challenges without a checker. Eg: if they amend the cache submission page for challenge checkers to have a "request checker" facility. If this then showed up in the API as a feed of all NEW challenge caches without a checker you could then have this as a to do list here for us checker writers to work through.

Even better if they have a facility on the API that once the checker is tagged it sends back the checker code so that it gets integrated into the cache page without the CO having to correctly cut and paste anything.

These sorts of changes of the API would mean that the system of dealing with the new challenges could be largely reduced to an automated queue. We tag and submit back to the CO the CO is tasked with checking they are happy and if they confirm they are then they can submit for review. All of that is work Groundspeak need to do on the cache edit page over here all that would be needed is a visibility of the outstanding queue of challenges needing a checker.

If they implement this sort of API changes you could largely eliminate the whole user request for checker system that is so prone to user error at present. You might also get them to introduce some other much requested API functionality at the same time.

---

Checkers can be created with a GC code that pgc dont know about and it will be correct with the name when the challenges is published. It worked that way when i helped someone with a checker before publication.
I suspect it works and i will test it with a regular mystery cache i just submitted

---

As a programming illiterate, how would I learn where to go to create the information or the "language" to write a checker for a challenge cache that I would like to place?

---

There are 2 problems I see with anything to do with the API flagging a challenge without a checker to request a checker be made.

1. The challenge cache would show as an unpublished cache and as such you still could not see what is required. If it was changed to show any of this it would defeat the purpose of it being an unpublished cache. Also since a checker will be required for a challenge cache to be published, this would be a catch 22.

2. Even assuming a way around the first point, this means a CO could potentially just start creating any number of weird and wonderful challenges expecting people to just create checkers whether the challenge is practical or not.

It is quite possibly a good idea that it is not automated and that a CO wishing to place a cache needs to work with someone to create a checker OR create a challenge where a suitable checker already exists.

Just my thoughts :)
Joel

---

Not quite. I am arguing for an API change that makes it practical to implement. I've discussed this elsewhere with my local reviewer and her suggestion was that once the reviewer ok'd the nature of the challenge then the reviewer would be the one to flag requiring checker. This then means the reviewer is happy it's an acceptable challenge and the location meets guidelines etc etc. So it filters out the crap before we see it.

The API would need to expose the GC code, the flagged status (checker exists or not), the COs name (as a link for contact purposes) and the description of the cache.

Note because this would be a new feature for the API it would only need expose this specific information (any any other info REQUIRED for creating a checker). When thinking about API changes you aren't constrained by what already exists. So the problem you imagine in part one simply isn't an issue. You just design the API as required. Now most of what's needed already exists so this would simply be a special case.

If you imagine a presentation layer API that presents info to Project GC. Then project GC creates page uses that info to present a list of challenges needing checkers. You see the list click on one read the description and any other info and tag the challenge. Once tagged it could send an email to the CO to confirm they are happy with the checker and flag to the API that checker xxxxx has been tagged against this challenge. Then when the CO is happy they submit for review again and the reviewer can approve knowing that there's a checker attached.

The whole point is that by a couple of very minor API tweaks you could create a very smooth system that is easy for reviewer, CO and challenge checker writers. On Project GC the system just looks like a list and challenge checker writers could just work through the list. To the CO they submit for review and get an email to say a checker has been attached, they check it and can communicate with the challenge checker writer via forum. To the reviewer they are doing what they currently do and simply ticking a box to say needs checker, then when it's resubmitted they see it has a checker.

All potentially very smooth, just needs the API tweaks. Given ganja1447 is in discussions with GroundSpeak it's entirely possible that after pointing out how much smoother this could be with minor API tweaks that they would add this to their system.

So it is perfectly possible and by making the flagging a reviewer thing then you overcome your major objection. It requires a bit of tweaks on both sides but it could have major benefits. Particularly to project GC as it would remove a lot of the whining asking for checkers on challenges that already have them. Communication would be with the CO who is the ultimate arbiter if what the intention of the challenge was. That would be a dramatic improvement as one of the major accusations thrown at Project GC is that checkers are added without the COs knowledge or consent and are sometimes not what they intended so cause them more problems.

---

Go-pher-it you wouldn't need to learn to write anything as per my suggestion above. You would write the cache page and submit for review. The reviewer once happy it was a valid challenge and the cache placement was ok would tag as needing checker.

As a CO you could get a notification it was in the queue and would see feedback for it. Once a checker had been tagged you could try it out eg: running it for individuals you know have completed the challenge eg: yourself as usually good challenges are ones you have done. Once you are happy with the checker you submit cache for review and reviewer sees its got a challenge checker and approves it. All very straightforward from everyone's point of view, assuming the couple of tweaks I've suggested are implemented by Groundspeak.

---

Wow, just when I thought that creating a few more challenges or duplicates of challenges that are in other states was going to be next to impossible y'all help to make my day!  I haven't placed any on purpose because of this.  Now I feel like there's hope for me to be able to place a few challenge type caches in the next few weeks or so, pending the weather.  Thank you so much!
Go-pher-It