Jump to content

Sharks-N-Beans

+Premium Members
  • Posts

    1092
  • Joined

  • Last visited

Everything posted by Sharks-N-Beans

  1. Just a thought on how I would handle it...If there is a street sign off another road, I would not feel I was trespassing to turn onto the signed road unless there was a barricade or signage to the contrary. Maybe a pic from the OP showing the level of development would help.
  2. No, it's not one of mine and my intent was self knowledge on requirements. I know just enough to know that I will never know what I need to know.
  3. Thanks for the replies. The question stemmed from a finder justifying logging a find w/o signing the log because they spent considerable time searching and ultimately saw but could not physically get to the cache. He said the cache page did not have the required attributes. As stated before, it's a 4T. I was with the CO when he hid it w/o any equipment.
  4. It's been awhile since I posted here, but have a question. Are there any required attributes for types of hides? If part of the cache intent is to bring finders to a spot with multiple very different possible hides, do I need to list the attribute that would give it away? The terrain is listed as a 4.
  5. Holy Big Brother Batman! I never thought about whether sending e-mail via the other "send message" option was secure let alone this new system. Thanks for the heads-up.
  6. We haven't come across that one yet, Larry. Sounds like it could be the work of a cacher that gave us bats, owls, spiders,snow and a plethora of other great hides.
  7. A couple of times a year. We visit more than finders. It would be a shame if that 1 searcher every year and a half couldn't find it due to a maintenance issue...but it still happens.
  8. If you list it as a multi instead of a mystery, it would be nice to put "Field Puzzle" in the name. Notice I did dot say "should", but rather "it would be nice.
  9. Cachers should know when to call it quits. With that said, make sure cachers know if night time is not advised (I had a 9 mo sprain for grabbing a T2 at night next to a river bank that I never knew was there. Also, it's a good idea to note if the T rating is due to GZ or getting to GZ. My senses pick-up the closer I get to GZ (the climb etc.).
  10. This topic is destined to go to a second page...crazy, just crazy. I work at a lab and our source of revenue is chemistry and microbiology analyses. We had a new customer that could not log-in to our site. After about 4 days working w/ their IT, it was determined that the problem was the first 4 letters of the bolded product.
  11. Someone who works for Groundspeak. Or a hamster...depends on who you ask visual representation
  12. Our son just received a DNF on NUR NEDYAH. It's lonely, has a high percentage of DNF logs, but has evidence that he has been checking it once or twice a year. I offer this cache for scrutiny by any reviewers in the spirit of learning through discussion and avoiding the theoretical. Would you (will you for Mr. Olivander ) disable this cache? What are the key drivers behind your decision? I'm particularly interested in understanding if regularly documented CO visits factor into the decision and if the expectation is more often than 1 or 2 a year.
  13. Nothing's been done - I'm just curious. The TOU says that we're responsible for maintaining the confidentiality of our password and I'm curious to know what - if anything - would happen if we didn't - or if our passwords were compromised by one of the myriad malware applications prevalent on the WWW. Say my PC was infected, my password compromised and my account used to send unsolicited email or post abusive logs - could I end up losing my geocaching account? Yes you could.
  14. This advice directly contradicts prior posts to this thread by two primary contributors to the Help Center article on log deletion. Did I miss a memo? I guess *I* missed the memo which indicates that we are not allowed to contradict posts by "primary contributors to Help Center articles". How is it contradictory? Given that you are credited as one of original authors for the log deletion article, could you explain how it is contradictory? Here is what I think are the relevant portions of the page: 8. Cachers may value their DNFs, Notes, and Needs Maintenance logs, don't assume it's okay to delete them. Those logs are part of their caching history. 10. If you are a geocacher and you believe that your log was deleted in error, you will have politely emailed the geocache owner requesting that the log be reinstated. If you require further assistance, please email www.geocaching.com/help. The way I interpret that is that a cache owner should not assume it is okay to delete Note logs as they are part of the cache history and if a CO does delete a note log, the geocacher can ask for the log to be reinstated, and finally that the www.geocaching.com/help page can be used to have GS resolve the dispute. See posts #3 and #4...it's a resource issue.
  15. Penalties? You don't want to find out. Although I'm sure if you could show that someone else did something without your permission, you could appeal a suspension. etc., if you had some kind of proof. How about if I'd given my password to someone and then they did something without my permission? I take it you are not Team Microdot. How did you get the password and what have you done w/ our cacher?
  16. I wasn't aware the guidelines required the CO to respond to each and every DNF, particularly if there's nothing in the contents of the DNF to indicate that the cache needs maintenance. That's what an NM is for, isn't it, or am I just being naive? I believe the important part of the above quote is 'If there is no one to respond'. This discussion continues to focus on the single DNF aspect as the sole reason for disabling.
  17. OK. Now let's consider that instead of "Entrance gate, badges, etc.", the plant has been dismantled and all that's left are the roads that run through the property. I wouldn't hesitate to walk on them. (But then, I have to admit I walk next to active rail lines from time to time to look for benchmarks.) But would you throw a hissy if the cops told you to leave?
  18. 1)Residents know it is RR property. 2)Residents do not like the strangers who have been caching so close to their houses. 3)Residents call cops. Done
  19. That's one more for me!...sorry, that's so appish.
  20. I have nothing against cleansing, I just want it to be driven by the local community, not the reviewers, and I want it to be focused on the status of the cache. Bad caches should go. In my area, they go because people post NMs and NAs. Good caches should not go for some arbitrary reason such as you don't feel like the owner is participating enough. A few geocachers in my area have passed away without their caches being adopted out, but since they were good caches to begin with, they continue to be good, and they'll likely remain good for years to come. I see no reason to kill their legacy just because the they can't answer their e-mail. There's plenty of time to kill a cache after it has a problem. I understand, there is just a lot of built-up neglect out there that the local community, for whatever reason, could not prevent. I believe it will continue to deteriorate. I don't have an answer for legacy caches...wish I did.
  21. Are you seriously suggesting it's OK to kill good caches via friendly fire? If a cache has a problem, I'm all for NMs and NAs that explain why it should be killed it off. But I don't support the idea that caches fitting some arbitrary criteria should be killed off just because they're more likely to have trouble. I might understand this if I could really imagine a cache that was anywhere popular enough that would do harm not being cleaned up, yet doesn't get enough traffic in the logs to justify archiving it with publicly available information. My attitude is that if I think there might be a problem with a cache, and I'm interested in seeing it cleaned up but there isn't already enough evidence in the logs, the very least I can do it go try to find it before I take action. If I'm not willing to do that, then I don't really care enough about the cache to make any suggestions about its future. I'm saying that after 14 years, the game may need a cleansing. I've seen reviewers respond to individual NA logs with a sheepish "there is nothing in the logs that prove to me it is not there" on caches from COs that I know are no longer involved in GC. Once again, from a utilitarian standpoint, a more systematic approach that requires COs to confirm will clear the system of neglected caches while allowing lonely yet maintained caches to remain via a CO reply. I see it as spreading some of the work from the reviewers to the COs. We have a couple of multi's that get very few visits. They could easily fall within the algorithm and I would simply understand that the reviewer's idea of maintenance is a tad more often than my 1, 2 or 3 times a year. Keep in mind that I see the CO requirement as communicated maintenance meaning log periodic visits. Some do not see it that way and the game is left with no one watching the store.
  22. I'm really in the minority here, but I am of the opinion that whatever "algorithm" is being used for this current push, the utility of the action will clean-up (on the system) more dead caches than it will archive well maintained remote caches. Locally, there are some caches that were absolutely fantastic in the day, but some COs have moved-on and the containers/logs/stages are really bad. Whatever the algorithm to post the initial disablement, the CO has the opportunity to address the situation. It seems logical to me that an efficient way to determine if the CO has a desire for the cache to live is to provide him/her with two options...1)respond to the disablement or 2)request unarchival.
×
×
  • Create New...