Re: Auto-disabling of checkers

I've just had a checker auto-disabled for the second day in a row, even though the cache seems to meet all of the requirements - it's an Unknown cache with the word "Challenge" in the title and has the challenge attribute. Is there something wrong with the auto-disabling script?

https://project-gc.com/Challenges/GC903WP/54761 is the checker in question.

I am experiencing the same problem but only when the challenge cache is published without the challenge attribute and the attribute is added to the listing afterwards.
I also noticed that when the cache is used by a cacher, and the checker is active, the auto-deactivation is not kicking anymore.

I had one that did that and I couldn't explain it either. Used the orange self-support button to refresh the cache on PGC and the problem went away. Entirely possible that it could have been something else as well, but it's worth a try?

magma1447 is quite sure it's because they are missing attributes on publish. He will try to improve the PM sent with a specific reason tomorrow.

Thanks for the update.

Yes, he discovered a problem with the notifications when I reported the case I mentioned above. Proper notifications would definitely help to pinpoint the problem.

As pieterix mentioned, I recently discovered an issue when creating the PMs where it didn't always send all PMs. I don't recall the details, but it was something with overwriting my own data before it was sent. It still disabled everything it was supposed to though. That was fixed a few days ago, or maybe a week, I don't recall.

The next issue is that there are a lot of tags getting disabled because they don't look as challenges. I had an idea that maybe I could improve the script to send the specific reason. But it would duplicate quite a lot of code and make less sense in the back-end. Right now there is a single function to fetch all challenges, based on a mix of name, type, attribute and the exceptions list. It doesn't really make sense to duplicate that code.

Instead I have been running the script manually three times, aborting it before it actually does anything. Every single issue it has shown me this far is that the Challenge is missing the Challenge attribute. This is because the reviewers aren't doing their job, at least according to the information I have, they should not publish a Challenge if it doesn't have the attribute.

The big question is how this shall be handled. Is it really something that should take time from checker developers? I don't think so actually. On the other hand, disabling the checker makes sure that the CO actually fixes it.

I asked HQ how this was supposed to be handled when the attribute was new. Their response was to email appeals every time. To me that sounded silly and idiotic. Who should write those emails? Manually, several times per day. The last 10 days there has been 46 unique tags disabled due to this reason.

Other suggestions are welcome.

I will start by informing HQ that they really need to find a better solution/remind their reviewers.

A suggestion from me.

Instead of sending a PM to the checker creator and disabling the checker I could create a list of with all known issues. Checker developers could then go through this list and click either "disable checker" or "Create NA log (with Project-GC's account and pre-determined text)".

PMs could then be sent when there are items on the list, similar to the Challenge Exceptions list.

I guess this would be pretty fail-safe. But it requires work, both to create the interface and to work on that list. Again, the question is if it's worth it. Maybe we should just fight the issue, inform HQ about the issue, and make sure that the reviewers actually are checking the attribute.

Another suggestion is to send a PM to the one who created the tag. Since the creator of the tag probably has contact with the CO in this forum, he (or she) can try to write in that thread, to get the CO to add the attribute.

If the attribute isn't added with 7 days the tag would get disabled automatically by the system.

There could also be a "Post NA log at specific geocache in Project-GC's name" available on the web for the checker creator to use. It would be easier to implement than the whole list-system I proposed in my other comment.

I believe NA is more correct than NM. NM can just be ignored by the CO. NA notifies reviewers. I would have to clear with HQ though, which log type they believe is the best. And in case of NA, they probably want to inform the reviewers about it.