TikvaNZ

A few weeks back I logged a draft FTF as I was outside internet coverage. Once I got into coverage, I edited the draft and tried to send. It appeared to send but it didn't appear in the logs, either in the app or online. The app showed a smiley. I tried to do another log, but I didn't have the choice to log another 'found it' log. I restarted my phone, and then a short while later, I logged another find (without doing a draft first), and that log was successful. The previous log then also showed up as expected. I assumed I must have been in marginal coverage when I sent the original and that the log had been 'sent' (or registered in the app as sent), but hadn't fully got through to the web site, and was somehow stuck in limbo on my phone (out of sight). When the next log was sent, the previous one went too and both succeeded. Today I had a similar thing occur. I found another FTF while out of internet coverage. I initially did a draft, and when I was in range I sent it. It appeared to work, but it hadn't got through - I didn't realise until a few hours later. I then tried to send another previously drafted log for an earlier find, and that also didn't go through. I then did some write notes, and they didn't go through either. I have now rebooted my phone, and done a couple more write notes and they have succeeded, however my previous logs and notes have still not gone through. The only thing I haven't tried this time is another fresh found it log (because I haven't yet found another cache).

I've done many challenge caches and can't think of any that should be archived. Therefore it must be only a small percentage that are 'no good'. I'd be keen to know examples of challenge caches that others think shouldn't exist, or are problematic. Why 'penalise' the majority because of the minority?

Personally I don't agree with this. Some people are very clever at coming up with challenges (e.g. the Geocaching Licence Series in New Zealand). This can take years to qualify for all of them. Many of us are enjoying the challenge of working through them, and some have completed it. I suspect at the time of publishing the CO hadn't qualified, but may have done so by now. If they had waited till they had qualified it may be a very long time between conceptualising the challenge and finally getting it published and the rest of miss out on the challenge in the mean time. I know CO's with challenges who are committed to attempting them. Similarly, if there is no 366 day streak challenge cache in an area for example, then why not allow someone who hasn't achieved it to place it? At least they are willing to put the effort in to place it. On the other hand I would prefer challenges to be placed by experienced cachers, rather than newbies. This is where reviewers come in to make judgements. e.g. if there is already a 366 challenge in an area then if someone wanted to place another one in the same area then the reviewer could decline it, providing the reason, and possibly providing alternatives suggestions. e.g. if there wasn't a 200 day challenge then that would likely be acceptable. There would be subjectivity and published guidelines would be useful. Maybe the criteria could be: Are there any cachers who have achieved the challenge, who would qualify to find it? But even this would be limiting. e.g. There is a cacher in the state who is approaching 2000 days in a row. It would be great (in my opinion) if a challenge cache was placed by anyone to recognise the achievement when that cacher gets there so they can find it as a reward to recognise and celebrate their achievement. In this case the CO may never have a hope of qualifying. In my mind that doesn't matter at all.

I agree that archiving and recreating would be a pain for COs and finders. As a CO, I'd copy and paste the old one to the new one leaving the physical cache as is. As a finder, I'd want to go and find the new ones, which in reality would very likely be the same cache as the archived one. If so (i.e. the final co-ords are the same) then there is the temptation to log the new one as found (with the original find date), without going out and finding it again. The log book would confirm the find. This would effectively mean double counting the find as it isn't really a new cache. Personally I wouldn't do this because it would change past milestones, etc .... To be true, I'd end up refinding the cache, once I'd requalified if necessary. I'd rather not have to though. Therefore grandfathering is preferable. But, the down side of grandfathering is that ones stats for the new Challenge type caches wouldn't include all the old challenge caches. There would effectively be pressure on COs to relist (archive and recreate) so that they would be counted as the new cache type. In my opinion, grandfathering is therefore effectively the same as archiving and recreating and isn't the best solution either. This leaves the options of adding an attribute to existing caches, or having the ability to change them to a new cache type. The ultimate is to make them a new cache type (perhaps by the CO submitting a list to a reviewer who would have the ability to make the change). The downside is this would restate one's past statistics. e.g. If a challenge cache required so many mystery caches it may now appear that they hadn't actually qualified. This can be overcome by including mystery and challenge together when checking qualifications. Maybe the new Challenge type could be a subset of "All Mystery caches" in the same way as specific event types are a subset of All Event caches? Adding an attribute rather than having a new cache type, has the advantage of not upsetting existing stats, but given the popularity and growth of challenge caches, having them as a specific cache type is my preference.

That question falls under "Here are some things community members have indicated they don't like about challenge caches." So one of the things some community members don't like is that some challenge caches result in them feeling they have to hurry to find caches in a specific time period. By agreeing with the "I have to hurry to find caches in a specific time period" statement, you're agreeing that you don't like hurrying to find caches in a specific time period in order to qualify for a challenge cache. The way question 9 was worded was very confusing. Agreeing or disagreeing with a statement as worded is not the same as liking or disliking the statement. I'm afraid I ended up answering agree/disagree for all of them, not whether I liked or diskliked them. e.g. The first few statements I agreed with and I like that about challenge caches. Amongst my fellow geocachers it has been 50/50 which way they answered, therefore the results can't be relied on in my opinion. If the intention was as stated above above then the wording was very poor. If it was worded "I don't like having to hurry to find caches ..." then it would have been much clearer how to answer.

Updated automatically to the new app yesterday. The new look is fantastic. So I tried it out this morning (9 August 2013 at about 0830 NZ time) - I logged a find (GC4H8ED) using the app rather than waiting till I got home and logging the find via www.geocaching.com on the computer. The first thing I noticed is that there still doesn't appear an option to select the log date. I decided to log anyway (hoping that the app would at least log with the found date based on the local time rather than UTC (I presume) time. I then checked the Recent Activity using the app to view the log and it did display with the correct date (9 August 2013). Great. But when I got home and checked on the the website using my computer the log showed I found the cache on the 8 August 2013. Unfortunately this issue means I will use the app to navigate but will not use the app to log my finds. (The app hasn't crashed for me at all as others have reported. I use a Samsung Galaxy S4 running Android 4.2.2) I did notice a couple of other issues: 1. It would be great to be able to search by cache name/title 2. When I tried to search by GC Code for GC4H8ED I got the message 'We couldn't find that location ...'.