Jump to content

dprovan

+Premium Members
  • Posts

    7479
  • Joined

  • Last visited

Posts posted by dprovan

  1. On 9/29/2021 at 12:38 PM, hxdimpf said:

    In the tool of my choice I want to....

    Thanks for the detailed explanation. More power to you if you want to do that and can find beta testers willing to do all that work. Personally, I think it's overkill, beyond anything I would consider a geocache beta test, and way beyond anything I would ask anyone to do for me. Do you have professional geocache beta testers where you are? I've never seen a geocache that would require this level of scrutiny, so I suppose that's why I can't imagine it.

     

    Geocaches don't have to be perfect. The detailed problems your beta tester is looking for are just bugs that, as a CO, I would have no trouble fixing after publication. The fact is, most of what your beta tester finds that you missed will be something caused by the difference in your equipment, so it's just as likely more, similar problems will be found after publication by still others using still different equipment.

    • Upvote 1
  2. On 9/29/2021 at 1:28 PM, geckoboy49 said:

    I didn't post NM notes but in every case stated that the CO needed to check on the cache. Seemed a more courteous first response.

    You came to us and explained that these caches need maintenance. By definition, that means you should post a Needs Maintenance log. I don't know why you don't think you can post a courteous NM, and I don't understand why you're talking as if there's going to be anything but a "first response" for any of these caches.

    • Upvote 2
  3. On 9/29/2021 at 1:43 PM, frostengel said:

    I think there should be something considering both the posts quoted above. As long as a cache owner proves to be able to maintain his caches he should be allowed to own more with no limit - in this case I see no problems. But if it is clear that someone is not able to he shouldn't be allowed to own more caches. So let's say if several of a cache owner's hides get archived by the reviewer due to missing maintenance (for a long time - don't forget that cache owners usually have plenty of time to maintain there caches) than a rule should kick in allowing the reviewers to decline his hides. Of course this "negative score" should heal be time if he starts maintaining his caches.

    I don't understand why you say this considers the quote, "Perhaps there should be a hide limit??" Nothing in your proposal involves how many caches the CO has hidden.

     

    On 9/29/2021 at 1:43 PM, frostengel said:

    So it is hard to give a certain number how many caches one person - or team? don't forget this possibility - can maintain.

    It's not just hard, it's nonsensical. Some people can maintain their caches, some can't. In my experience, the more caches a CO owns, the *better* maintained the caches are. I recognize several factors that cause this, but I think it boils down to experience.

    • Funny 1
  4. 1 hour ago, geckoboy49 said:

    It seems that unless someone writes a note using the May Be A Problem rubric, goecaching.com does very little about this problem.

    So the solution is to post NMs and NAs. As kunarion points out, there now is an automated system, but it would have been easier and more effective if people had just followed the original plan of people posting appropriate logs. How many NMs did you post on all these caches that need maintenance?

     

    1 hour ago, geckoboy49 said:

    About half these hides were missing and most had several prior DNFs. One of the guilty cachers has more than 1000 hides and can't even maintain the ones close to their home, much less the more remote. Perhaps there should be a hide limit??

    Why? Do you find this more common for people with lots of hides? I don't. Some of the best COs in my area have thousands of caches and have no trouble keeping them up. I would be outraged if you blocked them because of some experience you had on your mini-road trip through an area that has a poor standard of cache maintenance. Besides, I think you've misidentified the problem: the most common maintenance failures I see are the caches of people with only a few hides.

  5. First, of course this is a logical and useful idea. But, on the other hand, I'm not at all surprised to see Bl4ckH4wkGER about this being a much bigger effort than an outside observer might guess. So I'll take for granted it's not going to happen in the pure form of simply opening up the pre-publication web page to designated others. So let's go a little deeper into what you want this for to see what kind of solutions are possible.

     

    6 hours ago, hxdimpf said:

    Today this is frequently done by having the listing owner create a PDF from the listing and send that to betatesters. The big disadvantage: The cache data cannot be exported into tools such as Locus Map, tools that show waypoints on the map, tools that can automatically parse formulas and assist with assigning values to variables and calculate the coordinates for the next waypoint. So in essence,  the batatester can't do the real life workflow as he/she would if the listing was published.

    Can you be more specific about what is lost when you send the puzzle in PDF? Why can't you use a better format, perhaps just sending text and pictures without packaging them up in PDF? I have to admit, I have no idea why a tool would be easier to apply to geocaching description on the web than it would to any other format you might send.

  6. 1 hour ago, Calypso62 said:

    I was waiting for a communication with the responses to logging tasks from a finder of one of my earthcaches. No email notification from them. I go to the Message Centre and there's no communication from them. OK, they're new players, I guess they're unsure of what to do. I decided to send a message explaining the procedure so clicked on their name to go to their public profile. I then clicked on the Send Message link and up pops their communication sent two days ago! I only looked at the Message Centre earlier in the afternoon and nothing was there!

     

    I've also been communicating with another newbie and wondered why I didn't get a response from them to my last message. It turns out my message, sent a week ago, didn't arrive in their Message Centre inbox. It wasn't until she clicked on my name that my message suddenly appeared.

     

    Definitely a bug there somewhere!

    One thing I've seen is that I look at a conversation, and need to scroll down to see new messages. I can miss that for days because the indication that you aren't looking at the end of the conversation is quite subtle, just that the scroll bar way off on the right isn't at the bottom of the slider. I'm mentioning that just in case, 'cuz other things you say make me doubt that's your problem. But whether it is or isn't, it's still a bug: it should be more obvious when you aren't looking at the end of the conversation.

  7. 1 hour ago, Goldenwattle said:

    Here, FTF is strongly competed for. No one is waiting for anyone. People down knifes and forks, etc, jump in their cars, on their bikes, etc, and head straight off. First there gets it. People who arrive at the same time and search together, do tend to share the FTF though. The FTF is often claimed, only a few minutes after publication. No waiting.

    That's the way it is here, too. Except for tribute caches. For tribute caches, they defer to the honoree.

    • Surprised 1
  8. 8 hours ago, cerberus1 said:

    How long would folks be required to wait ?   A day?   Ten? 

    No one's required to wait. They just wait. Or they call the honoree and offer to accompany them. When you say "required", you're overthinking it.

     

    And the sword cuts both ways. Others don't rush out for the FTF, true, but if the honoree isn't on the ball and snoozes, he can still lose.

     

    It's just a game among friends.

    • Upvote 1
    • Funny 1
    • Surprised 1
  9. 13 hours ago, CatandVinnie said:

    Maybe if a CO gets a lot of logs per day (either having placed a load of caches or some getting a lot of finds - or both!), they might not read each one? I would assume they look at DNFs more closely than regular logs to try and suss out if there's a problem, but if they're getting hundreds of notifications a day, perhaps if there's a string of DNFs they assume there's a problem without reading all of them in detail?

    It's fine with me if they want to run out and fix a cache that isn't broken.

  10. 20 hours ago, Desertal said:

    This topic has been discussed many times when with fellow cachers at events etc.

    While on a Geocaching adventure trip in remote areas, mountainous, forest or desert trail walks etc... you pass by a cache that has a couple of DNF`s and has not been found for a long time. Not possible to contact CO  for various reasons eg. no comms, no answer etc.. after thorough search do you claim a FIND and help with the maintenance by replacing container and log sheet then message CO later hoping to get an answer.? or is more correct to just DNF and move on knowing that due to remote position, maintenance will definitely not be done any time in the near future?

    If you saw the two DNFs and were thinking of replacing it, you should have talked to the CO *before* you left home. In the case you describe, just DNF and move on. And, by the way, you didn't find the cache one way or another, so it's not reasonable to claim the find of your unauthorized replacement even if you left one.

    • Upvote 4
    • Helpful 1
  11. 4 hours ago, Deepdiggingmole said:

    For me a DNF is an indicator that you searched for the cache at GZ and did not find it - for a CO this could, along with other DNFs, be an indicator that the cache may be missing. You can not say how your search went as you didn't do one. Many COs do not read the actual logs but do watch how many DNFs appear so you doing a DNF may be a false indicator

    While I can see your point -- I don't agree with it, but I understand it -- do COs really get the "false indicator" and then run out to fix the cache? Or do they use the false indicator to read the logs more carefully and discover what, if anything, needs to be fixed?

     

    Just by the way, it's a little disconcerting that "many COs" don't bother to read the logs people post to their caches. That implies I should stop wasting my time writing decent logs, whether I found the cache or not.

    • Upvote 3
    • Helpful 1
  12. Wow, thanks for pointing this out. I never would have realized this had anything to do with flipping a simple, unambiguous switch even though, now that you mention it, I've had a few times in the last week were I couldn't find an adventure that I thought should be there.

  13. 15 hours ago, arisoft said:

    Some coordinate systems are too inaccurate. I have heard that using a such system is not allowed. W3W is good enough.

    The cache coordinates need to be accurate. There's no rule against using an inaccurate coordinate system as long as, in the end, the seeker ends up with accurate coordinates.

     

    Not that's relevant here: w3w is accurate to thousandths of minutes, just like geocache coordinates.

  14. 14 hours ago, Keystone said:

    The thread title is “geocaching while black,” which is a fundamentally different experience than “geocaching while white” when it comes to law enforcement encounters.

    That assumption, that geocaching while black is fundamentally different do to external forces, is what's being questioned. Do people react to black geocachers differently than other geocachers, or do black geocachers perceive the same adversity differently than other geocachers? Is it really off topic to say, "Yeah, that happens to me, too," or is that just shouting down a view that's not to be considered?

    • Upvote 6
    • Surprised 3
  15. 7 hours ago, barefootjeff said:

    I'm just curious, if the description says that the container is well-camouflaged, or even if that's inferred by its D rating, would you log a WN if you can't see through its disguise? What's the difference between being defeated by the known camo and being defeated by the known terrain? Either way, you were trying to find the cache but didn't succeed.

    I have a hard time understanding why you'd think they're at all similar. The camo is intended to thwart my attempts to find it, so if it succeeds, I Did Not Find it. The terrain is an obstacle that might prevent me from looking for it. If I cannot deal with the terrain, I did not even look for it.

     

    I see that before I saw this, the discussion has proceeded onto a discussion of terrain vs. difficulty, but I think that's a red herring. A field puzzle might have a high difficulty, and if I cannot solve it, I'll often log a note instead of a DNF. That example's more fuzzy than terrain, but I don't the there's a conceptual difference.

    • Upvote 2
  16. 10 hours ago, TommyGator said:

    Perhaps someone can give some examples where sequentiality was central to the "experience the CO wanted to provide" which might justify some seemingly awkward driving?

    I think it's obvious how it could be used well. I'm pretty sure I gave some hypothetical examples in this thread. But I think you're insisting on an actual adventure to prove it can be done?

     

    But to me, the main point here is that there's no reason whatsoever for the AL creator to take "seemingly awkward driving" into account. That's your priority, but there's no reason for it for the ALO to consider it a priority. Even in your examples, the problem tends to be that you were driving left to right but the AL was laid out right to left, so you wouldn't even be able to complain if you'd happened to approach the AL from the "correct" direction.

  17. 1 hour ago, terratin said:

    Yes, I tend to see it like that as well. Where do you draw the line? If you arrive at gz and see the cache is in a tree or underneath a bridge and you don't feel confident to climb it: is that a dnf? What about the last 100m to the cache require walking over a 30cm wide 'path' with a 50m drop to one side? (on that note, I nearly gave up on a cache on a plateau with a 650m drop, but then found a kind of safe route to it. Would have been a dnf for me if I'd given up). If 100m is still a dnf, then is 200m of high terrain? 500m? etc?

    I consider both of those examples matters of personal taste or perhaps local standards, but for me, when I'm blocked by a known terrain issues such as a tree climb, I normally post a note, but if I'm blocked by an issue that the CO didn't tell me about such as dense brush above the terrain rating, I'll tend to file a DNF. When I encounter unexpected dense brush, I consider two possibilities: either the brush is something that's grown up since the CO planted the cache in which case my DNF is somewhat akin to not finding a cache because it's buried under a ton of fallen leaves, or there's a route to the cache appropriate to the terrain rating that I Did Not Find.

     

    How close I got to the cache has very little to do with it. I could be standing at GZ and still be facing either of those issues.

     

    I don't really think it makes that much difference since, after all, I'm going to explain in the text of the log, anyway. If my DNF is misinterpreted by something or someone that doesn't take my explanation into account, then that something is broken or that someone is making a mistake. When a cache is disabled and then archived because of my "couldn't get to GZ" DNF, then it's both: the CHS flagged it and then the reviewer did not properly provide the human oversight that proponents of the CHS assure us make CHS failures not a problem.

    • Upvote 1
  18. 10 hours ago, Keystone said:

    The local reviewer disabled the cache on 11/4.

    So this was a mistake, right? Obviously the reviewer didn't look at the log or he would have seen that the health score was wrong. Kunarion wasn't a bad cacher for posting his perfectly legitimate DNF that implied nothing about the cache being in trouble. This cache was brought up to make the implication is that Kunarion caused the cache to be archived, but your timeline makes it clear that problem was elsewhere.

×
×
  • Create New...