Changes to logging, specifically stopping double logs

[+pinkunicorn]

Second, because of their minimal value, COs have the right to delete notes to their content, whether or not they contain 'questionable' content.

 

Here is what the guidelines actually say:

 

6.13. Delete logs

 



Powered by Translate

Cache owners may delete geocache logs if they conflict with our Terms of Use Agreement or fail to meet the logging guidelines.

 

Note the lack of any mention of log type.

Edited April 7, 2017 by pinkunicorn

[+MartyBartfast]

So my original point stands uncontested: no one's given any examples to prove -- or even suggest, really -- that there's an actual problem that this change solves. If you're going to say I'm wrong, at least pretend to be able to back it up with something.

For example, you could point to feature requests that mention duplicate logs in some way, such as:

• Unintentional double logs
  
• Find count number increases with duplicate log entries
  
• Enhancement request: Delete duplicate log if <1 minute
  
• Restore the number of distinct caches to stats
  
• SUGGESTION: Prevent duplicate finds of same cache for 24 hours.
  

 

I don't think any of those request the complete banning of double logging, they are primarily seeking to address the problem that the various apps sometimes double log unintentionally (within < 1 minue or 24 hours). So it seems to me that the problem that needs fixing is within the apps, now I realise GS has no control over the coding of 3rd party apps so it's not within their capability to fix the apps, but I would have hoped that the fix would have been coded into the API to prevent apps multi logging, but leave the website alone so that if someone knowingly and intentionally wants to double log then they could do so.

 

Of course this discussion is now pointless, it's something that could have happened at the design/planning stage of this fix, but it's far too late now. It seems to me the fix they've gone for is over the top, though that might have been done to minimise the coding effort required, or to allow them to get the fix out quicker, whichever it is I think it's unfortunate that some grand old caches have been caught in the crossfire .

[+noncentric]

Second, because of their minimal value, COs have the right to delete notes to their content, whether or not they contain 'questionable' content.

Here is what the guidelines actually say:

6.13. Delete logs



Powered by Translate

Cache owners may delete geocache logs if they conflict with our Terms of Use Agreement or fail to meet the logging guidelines.

Note the lack of any mention of log type.

If CO's can delete Write Note logs, then the CO can validate that only valid logs are 'counted' by an amended YOSM process that reads both Found It and Write Note logs that include specific tags.

If CO's cannot delete Write Note logs, then they could encrypt them - which would presumably break the tagging logic and prevent those WN logs from being 'counted' by an amended YOSM process. The guidelines say: "Instead of deleting a log, you can choose to permanently encrypt it." ETA: The guidelines don't say under what conditions a log can be encrypted.

Edited April 7, 2017 by noncentric

[+thomfre]

I don't think any of those request the complete banning of double logging, they are primarily seeking to address the problem that the various apps sometimes double log unintentionally (within < 1 minue or 24 hours). So it seems to me that the problem that needs fixing is within the apps, now I realise GS has no control over the coding of 3rd party apps so it's not within their capability to fix the apps, but I would have hoped that the fix would have been coded into the API to prevent apps multi logging, but leave the website alone so that if someone knowingly and intentionally wants to double log then they could do so.

The biggest problem is the official app, and even the website. The few double logs I've experienced, was through GSAK. And then the API returned an error message saying the log wasn't saved (GSAK let you see the errors coming from the API). But it was... So the problem is not in the 3rd party apps.

[+eigengott]

leave the website alone so that if someone knowingly and intentionally wants to double log then they could do so.

 

Last Sunday I managed to accidently log a cache four times as found. The website was a bit slow at that time so hit the submit button twice. My crappy mouse sometimes issues an unwanted doubleklick. I catched two of the extra logs and deleted them. I didn't notice third extra log. Fortunately the owner alerted me the next day.

 

So you see, even an experienced user can unintentionally produce multiple "Found it" logs through the website. I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

[cezanne]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

[+Team Microdot]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

Was it meant to?

[cezanne]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

Was it meant to?

 

Most probably not but noone so far has provided any convincing argument for that sort of change.

[+igator210]

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

For me, the most logical reason is database storage and resource allocation. The less information you have to store in the database the easier it is to maintain.

[cezanne]

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

For me, the most logical reason is database storage and resource allocation. The less information you have to store in the database the easier it is to maintain.

 

I'm confused. What changes for the database if the NM log is for example then posted by a second account?

Or if the cache owner posts a note saying that they could not find their own cache?

[+Team Microdot]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

Was it meant to?

 

Most probably not but noone so far has provided any convincing argument for that sort of change.

 

Hardly a counter-argument to the point raised then. Irrlevant in fact. At least that explains why it didn't make sense.

[cezanne]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

Was it meant to?

 

Most probably not but noone so far has provided any convincing argument for that sort of change.

 

Hardly a counter-argument to the point raised then. Irrlevant in fact. At least that explains why it didn't make sense.

 

It was not intended to be a counter argument. The counter argument was made in the first sentence if you want to use that term. This thread is about all changes to the logging process and so the second sentence is relevant to the thread too.

[+Team Microdot]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

Was it meant to?

 

Most probably not but noone so far has provided any convincing argument for that sort of change.

 

Hardly a counter-argument to the point raised then. Irrlevant in fact. At least that explains why it didn't make sense.

 

It was not intended to be a counter argument. The counter argument was made in the first sentence if you want to use that term. This thread is about all changes to the logging process and so the second sentence is relevant to the thread too.

 

But irrelevant to the point originally made by eigengott, yet offered as if it was relevant.

 

Bill : I don't like cheese

 

Ted : Many, many people do like cheese and, moreover, a wheelbarrow functions perfectly well with only one wheel.

[+thebruce0]

So my original point stands uncontested: no one's given any examples to prove -- or even suggest, really -- that there's an actual problem that this change solves. If you're going to say I'm wrong, at least pretend to be able to back it up with something.

For example, you could point to feature requests that mention duplicate logs in some way, such as:

• Unintentional double logs
• Find count number increases with duplicate log entries
• Enhancement request: Delete duplicate log if <1 minute
• Restore the number of distinct caches to stats
• SUGGESTION: Prevent duplicate finds of same cache for 24 hours.

Yes, at least!

To wit: I trusted the comments in this thread mentioning the issues this change was meant to address. I wasn't personally looking for written, explicit examples of those issues. So I pointed to earlier in the thread to which your response was implying there were no examples, which seemed to me ridiculous, since they were mentioned in this thread. I never desired the level of validation of looking up actual situations for which these issues existed. So really, my bad for not looking up any threads dealing with the cited problems (I really didn't have the desire to do that much work for the argument anyway). That said, I can't agree with your hand-waving that these are essentially non-issues. Groundspeak has deemed them to be issues, along with those who are affected by them, and so they are dealing with them.

 

Even if no one complaining about them actually said "GS should ban all double-logging!", with the amount of time GS has likely been searching for a solution, it appears that they felt this was their most feasible solution moving forward. ...Even though (as usual) feathers are getting quite ruffled in certain cases.

 

Of course, I appreciate yours the most, since you proposed a solution -- going back to counting caches found and found logs as two separate things -- that makes more sense and avoids killing other people's fun.

In a previous comment I highlighted a number of different areas of the website where terminology for "Finds" varies between what could be understood as find logs as opposed to found caches. This needs to be consistent with the number it represents. GSAK stats, for one, distinguishes unique caches found from number of find logs. The two numbers are of course readily available by any parsing of find logs - but their presentation by Groundspeak needs to be clarified and made consistent.

 

Second, because of their minimal value, COs have the right to delete notes to their content, whether or not they contain 'questionable' content.

Here is what the guidelines actually say:

6.13. Delete logs

 

Cache owners may delete geocache logs if they conflict with our Terms of Use Agreement or fail to meet the logging guidelines.

Note the lack of any mention of log type.

Right, and I read that TOU as including 'abuse' - whether it's questionable content, or intended extraneous use of posting (such as intentional duplication of logs, trolling a CO, perhaps even posting what the CO can defend as such in the case of invalid notes; at this point it gets pretty subjective though and may go to appeals if it gets bad - at which point again they may say "figure it out yourselves" because the YOSM tags would be yet another "side game") at least until the situation delves into the area of 'problem users' where GS might consider a ban or two.

 

----

(hmm, so now I dive into the guidelines to explore this interesting situation about CO deletion of Note logs)

Relevant guideline content I could find:

 

4.7 Delete logs from geocache pages: Geocache and trackable logs can be deleted by the log owner, cache or trackable owner, and Geocaching HQ staff. Deleted logs disappear from the cache page and from the log owner's profile. They cannot be restored by the cache or trackable owner or log owner.

 

6.13 Delete logs: Cache owners may delete geocache logs if they conflict with our Terms of Use Agreement or fail to meet the logging guidelines. If you delete a log in error, ask your local reviewer to restore the log, or contact us. Before or immediately after you delete a log, email the log owner to explain your concerns. If the log or photos contain spoilers, invite the log owner to edit the log. If you have already deleted the log, invite them to post another log without spoilers.

 

If a log contains obscene or threatening language, delete it immediately. If you prefer not to email the log owner, contact us for assistance.

 

4.1 Geocacher disagreement - log deletion: If your "Found it" log has been deleted by the cache owner because they disagreed with your comments, repost a neutral log without the commentary. If you have feedback that may be helpful, you can contact the cache owner privately.

 

Geocaching HQ can only reinstate "Found It" and "Attended" logs on cache pages. Before sending us a request, check that your log follows our Terms of Use and review our logging guidelines about specific cache types

 

TOU, D (restrictions): (many points, but notably...)

v. Abuse or exploit bugs, undocumented features, design errors or problems in our services.

xvii. Violate any of the guidelines or policies associated with our services.

xviii. Interfere with the ability of others to enjoy our services.

xix. Stalk, harass, or otherwise harm another user of our services, Groundspeak employee or third party.

 

 

So from that I glean:

* Everything is intended to provide enjoyment for all users; intentional interference with others' enjoyment is cause for attention as potential TOU violation

* Offensive content (ie language) gets its own mention outside the TOU (6.13), so it's of higher priority than potential non-offensive log content abuse (eg, redundant Note posting)

* 4.7 applies to all log types

* 6.13 applies to Find logs, set by the "Logging Guidelines" (link) referring to "logging" Finds on physical and non-physical caches; it doesn't mention any other log type

* 4.1 specifically refers to log types and what can/can't be restored

 

~ Since there's no explicit mention of what the CO is allowed to delete apart from Found It logs (you are correct), only what can be deleted, and what constitutes valid deletion, one can extrapolate that the TOU applies to all logs (per the use of GS system and services), and so the CO's ability to delete logs extends to all their available log types.

~ Improper deletion of Found It logs specifically could be appealed for restoration, but other log types can't be restored. So by further extrapolation, any continued disagreement about deleted log types that are not Found It logs if/when appealed remain an issue that Groundspeak would have to choose to deal with based on their enforcement of the TOU.

~ Thus, if YOSM is considered a 'side game' (such as with FTF), they'll most likely wish to take a hands off approach to moderating the dispute initially, unless there's a clear violation of the TOU by any party which they can enforce. And who knows what reasoning they could use to vindicate either the CO or the logger (anywhere from hindering enjoyment to abusing the logging system, I'd guess)

[+thebruce0]

But irrelevant to the point originally made by eigengott, yet offered as if it was relevant.

 

Bill : I don't like cheese

Ted : Many, many people do like cheese and, moreover, a wheelbarrow functions perfectly well with only one wheel.

Rufus: Wrong. A wheelbarrow doesn't work in water, and I like wheelbarrows.

 

Good robot us's: *grind*twist*salute*

 

Station: STATION!

 

Death: I love show business.

[+Team Microdot]

But irrelevant to the point originally made by eigengott, yet offered as if it was relevant.

 

Bill : I don't like cheese

Ted : Many, many people do like cheese and, moreover, a wheelbarrow functions perfectly well with only one wheel.

Rufus: Wrong. A wheelbarrow doesn't work in water, and I like wheelbarrows.

 

Good robot us's: *grind*twist*salute*

 

Station: STATION!

 

Death: I love show business.

 

I believe our adventure through time has taken a most serious turn.

[+hzoi]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

[+The Happy Hodag!]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

+1 !!!!!

[+Viajero Perdido]

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

I don't want to live in a society, or play in a game, where you can only do that which is explicitly allowed.

 

What next - a prescribed format for puzzles?

 

Slippery slope.

[+TeamRabbitRun]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

[+hzoi]

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

I don't want to live in a society, or play in a game, where you can only do that which is explicitly allowed.

 

What next - a prescribed format for puzzles?

 

Slippery slope.

"Slippery slope" is a logical fallacy often used in arguments by people who can't adequately demonstrate the harm of what's happening now.

 

What do the remaining logs not do for you that only an owner NM or DNF log can?

[+hzoi]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

 

It's an example, but not a very convincing one that an owner NM log is "the best solution."

 

I looked to your caches to see if there was a better example of your argument in action, but I didn't find one. Your hides appear to get finds about once a month on average. Please show me where your note logs have ever gotten lost quickly. (I also don't see that you've ever left a NM log on any of them, but perhaps you deleted them.)

[+TeamRabbitRun]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

 

It's an example, but not a very convincing one that an owner NM log is "the best solution."

 

I looked to your caches to see if there was a better example of your argument in action, but I didn't find one. Your hides appear to get finds about once a month on average. Please show me where your note logs have ever gotten lost quickly. (I also don't see that you've ever left a NM log on any of them, but perhaps you deleted them.)

 

Why in the world would it matter if I've had that situation in real life? We discuss possible situations and solutions here, not just relate war stories.

 

That's a little creepy, friend, to investigate whether I've ever actually DONE what I suggest MIGHT be a reason to do things, and then to snidely suggest that I delete logs, well, don't bother to respond. Conversation's over.

[cezanne]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Necessary might not be the right term. Everything can be conveyed with notes.

 

If I wanted to write a DNF log for one of my caches, I would of course add a different log in addition too.

It would be just for a complete recording of the history.

 

If I happen to come across a cache that I have found previously and where I pass later again and know for sure that the cache is gone, I do write a DNF log too and not an NM log (or if I do not only a NM log) or a note or an e-mail to the cache owner.

 

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

I have come across several cases where cachers wrote messages to the cache owners and told them that a cache needs maintenance and even more cases where such minor cases are mentioned in a normal log. There are many cachers out there who do not want to use NM logs.

(That's one such example

https://www.geocaching.com/geocache/GC5NZ4B_marchen-krimi-bonus?guid=ee3253e6-337f-4a62-9301-6840d55ab603

- the log is in German but you can read German.)

 

In quite a number of these cases writing a NM log made perfect sense and even more so if the cache owner asked the cachers that might visit the cache before him/her for some assistance (could be something minor like please send me

a photo of ....., or please add a pencil if you do not mind).

 

Of course the same message can be conveyed with notes as well but then why have NM logs at all? (Personally, I can do without them perfectly well and I would never have introduced them. Howeever if they are there, a restriction like the present one does not make sense.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

I do not think that a cache should be disabled if a pencil got moved out of the cache, a magnet has become weak, only three additional info sheets are available or whatever of that type.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Tell me a really convincing argument for having different log types at all. There is a workaround for nearly everything.

The real question is why to restrict cachers and impose on them rules for their workflow and preferences based on the individual preferences/points of views of others.

 

It's quite clear that some cachers like you come from the pragmatic/functional side which is not the real issue here.

 

At some point someone else might come along and argue that we do need the option to write multiple DNF logs and that one suffices and that further such logs could be done as note and that a single DNF log suffices to mark caches as attempted but not yet found. They could argue that multiple DNFs serve no further purpose and that if someone wants to express concern that a cache got lost, they could file a NM log.

 

I would want to have the option to file even 20 DNF logs for the same cache over time. For me it's about recording my experience in the way which seems best suitable to me.

Edited April 7, 2017 by cezanne

[+L0ne.R]

...this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

I have seen a couple examples of why some cache owners have logged such on their own caches, but they are unconvincing. For the life of me, I don't see the necessity. If I'm looking for my own cache and I can't find it, I either replace the cache on the spot if I have one (and then leave an "Owner Maintenance" log stating so), or if I don't have the means to replace the cache, I disable it (again, there's a log for that).

 

Similarly, if one of my caches really needs maintenance, I am an adult who can remember things and can make a note of it somewhere, or if it's really that bad, I can disable the cache.

 

Disabling a cache that needs maintenance or has gone missing also gives me incentive to get my butt back out there and fix or replace the cache before a reviewer gets involved, rather than just stringing people along with "Yeah, I'll get to it eventually" and trying to hide the cache's true state from the reviewer.

 

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

 

It's an example, but not a very convincing one that an owner NM log is "the best solution."

 

I looked to your caches to see if there was a better example of your argument in action, but I didn't find one. Your hides appear to get finds about once a month on average. Please show me where your note logs have ever gotten lost quickly. (I also don't see that you've ever left a NM log on any of them, but perhaps you deleted them.)

 

Why in the world would it matter if I've had that situation in real life? We discuss possible situations and solutions here, not just relate war stories.

 

That's a little creepy, friend, to investigate whether I've ever actually DONE what I suggest MIGHT be a reason to do things, and then to snidely suggest that I delete logs, well, don't bother to respond. Conversation's over.

 

Examples and facts help to support an argument.

[+Manville Possum]

Examples and facts help to support an argument.

 

And without facts, it's just made up BS.

[+narcissa]

Examples and facts help to support an argument.

 

Viciously auditing someone's profile and caching history does not help to support an argument.

[+MartyBartfast]

 

It's an example, but not a very convincing one that an owner NM log is "the best solution."

 

 

TeamRabbitRun gave an example which justifies allowing owner NM logs. Can you present better example or justification as to why NM logs should NOT be allowed? If you can then I might come down on your side of the argument, but at the moment TeamRabbitRun has my vote.

[+Team Microdot]

Examples and facts help to support an argument.

 

Viciously auditing someone's profile and caching history does not help to support an argument.

 

Yep - glancing at someone's publicly viewable stats is positively inhumane! Quick - stop it before someone gets badly hurt!

[+hzoi]

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

 

It's an example, but not a very convincing one that an owner NM log is "the best solution."

 

I looked to your caches to see if there was a better example of your argument in action, but I didn't find one. Your hides appear to get finds about once a month on average. Please show me where your note logs have ever gotten lost quickly. (I also don't see that you've ever left a NM log on any of them, but perhaps you deleted them.)

 

Why in the world would it matter if I've had that situation in real life? We discuss possible situations and solutions here, not just relate war stories.

 

That's a little creepy, friend, to investigate whether I've ever actually DONE what I suggest MIGHT be a reason to do things, and then to snidely suggest that I delete logs, well, don't bother to respond. Conversation's over.

 

You wrote your example like you'd actually done it. The word "might" appears nowhere in that quote. I looked to see it in action and it hadn't happened.

 

If you find it creepy that I was able to confirm or deny that fact by looking at things you voluntarily posted online, perhaps the internet is not for you.

 

edit to add: If you're finding an accusation in my statement that perhaps you deleted logs you put on your own caches, then my apologies, because I didn't intend one. I've deleted notes on my own caches plenty of times. And assuming arguendo that I felt the need to post a NM log on one of my caches as a heads up or a reminder, I'd probably delete that log once I cleared the NM attribute with an owner maintenance log, because it adds nothing to the cache history once it's served its purpose.

 

Tell me a really convincing argument for having different log types at all. There is a workaround for nearly everything.

The real question is why to restrict cachers and impose on them rules for their workflow and preferences based on the individual preferences/points of views of others.

 

It's quite clear that some cachers like you come from the pragmatic/functional side which is not the real issue here.

 

At some point someone else might come along and argue that we do need the option to write multiple DNF logs and that one suffices and that further such logs could be done as note and that a single DNF log suffices to mark caches as attempted but not yet found. They could argue that multiple DNFs serve no further purpose and that if someone wants to express concern that a cache got lost, they could file a NM log.

 

I would want to have the option to file even 20 DNF logs for the same cache over time. For me it's about recording my experience in the way which seems best suitable to me.

 

Fair enough, and thank you for responding.

 

It's an example, but not a very convincing one that an owner NM log is "the best solution."

 

TeamRabbitRun gave an example which justifies allowing owner NM logs. Can you present better example or justification as to why NM logs should NOT be allowed? If you can then I might come down on your side of the argument, but at the moment TeamRabbitRun has my vote.

 

The argument that owner NM logs shouldn't be allowed appears to be moot -- unless Groundspeak changes their position, they're going away. I didn't have an opinion as to whether they should have been eliminated, but now that they appear to be going away, I don't think it's a great loss to geocaching. I'm not looking to win or lose an argument, just discussing a point.

 

Viciously auditing someone's profile and caching history does not help to support an argument.

Viciously auditing? narcissa, that's just specious. Guy's got three caches. I took a quick look at them and saw one NM log, not left by him. Elapsed time, maybe thirty seconds.

 

Grossly distorting facts does not help to support an argument.

 

Put another way:

 

 

----------------

 

My apologies to all for interjecting my thoughts and briefly trying to change the course of what has become another long and tiresome back and forth among the usual suspects. You've provan your point. Y'all have at it. </sarcasm>

Edited April 7, 2017 by hzoi

[+Manville Possum]

Examples and facts help to support an argument.

 

Viciously auditing someone's profile and caching history does not help to support an argument.

 

Yep - glancing at someone's publicly viewable stats is positively inhumane! Quick - stop it before someone gets badly hurt!

 

It's all in how you state it. "Viciously auditing someone's profile and caching history" sounds really bad, and has intent to cause drama like selling a newspaper.

 

"I looked at your geocaching profile and history" is not interesting, just a truthful statement.

[+SwineFlew]

Where are we going with this thread? That black hole is very deep.

[+noncentric]

This thread is about all changes to the logging process and so the second sentence is relevant to the thread too.

Really? Based on the title of the thread, I thought it was about "specifically stopping double logs". Double logging, not NM/TD/etc.

 

A topic specifically about the NM logging was started here.

[+noncentric]

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

There's a whole other thread regarding the CO logging NM on their own caches. I thought this thread was specifically about double logs, per the topic title.

 

ETA: Added link to other thread.

Edited April 7, 2017 by noncentric

[+TeamRabbitRun]

If someone has a really convincing argument on why cache owners still need to be able to log DNFs and Needs Maintenance on their own caches, I'd be curious to see it.

 

Ten pages of posts are hard to get through, but I'd direct you to some of my earlier comments, where I cited examples such as the case where I learn something about a cache of mine and develop plan to fix it. I wouldn't want to disable it if it's a minor problem, or a temporary environmental situation, etc.

 

In the meantime, I want to alert potential seekers that there's an issue. A 'Note' log gets lost quickly if DNF's start to pile up. The best solution is to file a NM that says that you know about it and will get to it. The presence of the Red Wrench will alert anyone who's paying attention that there's something more to look at.

 

That's one example.

There's a whole other thread regarding the CO logging NM on their own caches. I thought this thread was specifically about double logs, per the topic title.

 

ETA: Added link to other thread.

 

Oh, yeah - I thought that one was this one.

[+NYPaddleCacher]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

We don't know how this is going to be implemented. On the web site, when logging a cache one clicks on a "Log Geocache" button (or "Log your visit" for an event) which renders the form for submitting valid log types. Depending on the type of cache or event the select list for the types of logs is different. (e.g. Events have an "Attended" log, Webcams have "Webcam photo taken"), so the system could render the form such that "Found It" or "Attended" wasn't an option as a Log Type. It could also render a "You have already Found this cache" to the right of the "Type of Log" select list. Apps which use the API could work the same way. That would prevent instances of someone typing out a long log intended to be posted as a "Found It" out in the field or at a desktop only to have it disappear when submitted.

 

 

Moreover, this sort of argument does not explain at all why cache owners cannot log any longer NM and DNF logs for their caches.

 

As is the case for any piece of functionality on the site, or in the Apps, or guidelines, there are going to be advantages and disadvantages in how it's implemented. I think many, if not most of the people that have responded in this thread recognize the advantages of preventing duplicate Found It/Attended logs and there have been certainly been a few posts illuminating a disadvantage. To me, this whole change boils down to weighing the advantages and disadvantages, and, to me, the advantage of not allowing multiple found it/attended logs outweighs the disadvantage associated with a couple of rare exceptions. I agree with you that it doesn't make a lot of sense to not allow owners to log NM or DNF logs on their own caches. What are the benefits?

[+dprovan]

Last Sunday I managed to accidently log a cache four times as found. The website was a bit slow at that time so hit the submit button twice. My crappy mouse sometimes issues an unwanted doubleklick. I catched two of the extra logs and deleted them. I didn't notice third extra log. Fortunately the owner alerted me the next day.

 

So you see, even an experienced user can unintentionally produce multiple "Found it" logs through the website. I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

What I see in your example is a rare mistake that causes no trouble and is easily corrected, not a terrible scourge that must be prevented in all cases no matter who it hurts.

[+Mudfrog]

I have a more serious question to ask,,

 

 

 

 

Where's my blankie?

[+dprovan]

To wit: I trusted the comments in this thread mentioning the issues this change was meant to address. I wasn't personally looking for written, explicit examples of those issues. So I pointed to earlier in the thread to which your response was implying there were no examples, which seemed to me ridiculous, since they were mentioned in this thread.

You are talking about examples of duplicates happening, but no one denies they happen. I'm asking for examples of duplicates causing a problem. I don't consider needing to clean up a rare mistake or seeing duplicates in a log once in a while to be problems. We'll always have to deal with mistakes and excess logs even after we've eliminated this one source, so I don't see that as justification for taking away these caches.

[+Team Microdot]

To wit: I trusted the comments in this thread mentioning the issues this change was meant to address. I wasn't personally looking for written, explicit examples of those issues. So I pointed to earlier in the thread to which your response was implying there were no examples, which seemed to me ridiculous, since they were mentioned in this thread.

You are talking about examples of duplicates happening, but no one denies they happen. I'm asking for examples of duplicates causing a problem. I don't consider needing to clean up a rare mistake or seeing duplicates in a log once in a while to be problems. We'll always have to deal with mistakes and excess logs even after we've eliminated this one source, so I don't see that as justification for taking away these caches.

 

Taking away which caches?

[+Team Microdot]

Where are we going with this thread? That black hole is very deep.

 

Piffle

[+noncentric]

To wit: I trusted the comments in this thread mentioning the issues this change was meant to address. I wasn't personally looking for written, explicit examples of those issues. So I pointed to earlier in the thread to which your response was implying there were no examples, which seemed to me ridiculous, since they were mentioned in this thread.

You are talking about examples of duplicates happening, but no one denies they happen. I'm asking for examples of duplicates causing a problem. I don't consider needing to clean up a rare mistake or seeing duplicates in a log once in a while to be problems. We'll always have to deal with mistakes and excess logs even after we've eliminated this one source, so I don't see that as justification for taking away these caches.

It sounds like what you really need is for TPTB to provide you with a business case for why they're eliminating the option of logging multiple "Found It" logs on a single cache. After all, they are the ones that made the decision.

 

As you've already mentioned, it's known that duplicate finds do happen on caches that are not designed to have multiple finds. Some cachers may consider them to be annoying, while others may consider them to be problematic. It depends on each cacher's definition of "problem".

 

I'd hope that you'd also acknowledge that we, in the forums, do not have full visibility to the communications that GS receives about different things.

-- How do we know that CO's haven't complained directly to GS about cachers logging multiple finds on their caches?

-- How do we know that cachers that have had duplicate Finds deleted haven't complained directly to GS saying that the system allows them to log another find, so why can't they revisit the cache and get another find? I even recall a non-newbie forum poster that suggested, recently, that he could log duplicate finds on a cache and if the CO deleted his dupe find then he could appeal to GS and GS would reinstate his dupe find.

 

Really, assuming that what we see in the forums constitutes the entirety of examples that occur IRL seems faulty. I'm sure GS had their reasons for allocating resources to this re-programming. I'm also sure that they would never be able to get all cachers, especially forum posters, to be in agreement with their reasons.

[+cerberus1]

Changed my mind... thanks.

Edited April 7, 2017 by cerberus1

[+dprovan]

It sounds like what you really need is for TPTB to provide you with a business case for why they're eliminating the option of logging multiple "Found It" logs on a single cache. After all, they are the ones that made the decision.

OK, first I want to thank you for a cogent response. I'm getting a little tired of the responses that are suggesting I'm just ignoring "The Obvious".

 

If GS would say, "We're doing this for business reasons we don't want to disclose", I'd accept that even though I wouldn't find it satisfying. But they don't do that. They make vague but unconvincing claims of actual reasons, and then everyone else it the forum just takes it as gospel without even entertaining a discussion of whether there's a valid case for the additional restriction.

 

As you've already mentioned, it's known that duplicate finds do happen on caches that are not designed to have multiple finds. Some cachers may consider them to be annoying, while others may consider them to be problematic. It depends on each cacher's definition of "problem".

I guess my basic problem is that these "problems" are equivalent to actual events which have no solution because they're entirely reasonable. COs that don't like bogus logs have to delete them whether they're redundant or whether they're just someone posting a find to the wrong cache. Multiple redundant logs also happen in the entirely acceptable case of a group finding the cache and posting all their individual finds but without anyone having anything unique to say about the find. We have to live with those cases, so I don't like the idea of throwing these benchmark seekers under the bus just to get rid of a few other similar cases.

 

I'd hope that you'd also acknowledge that we, in the forums, do not have full visibility to the communications that GS receives about different things.

I acknowledge that we don't know what GS is thinking, but they're free to actually present with arguments. I see no purpose in us simply accepting hypothetical arguments that we might possibly accept as justification. If they aren't willing to present their justification, then I'm not going to accept it on faith, and I don't think you should, either.

 

-- How do we know that CO's haven't complained directly to GS about cachers logging multiple finds on their caches?

Sorry, not sufficient. The COs would have to complain and give a good argument for why dealing with the multiple finds was a burden. If they did that, then that burden could be presented as a justification. But that doesn't happen. So I'd expect GS to be able to say something like "We get lots of complaints, and, in fact, all the complaints are about a lot of finds that it really is unreasonable for the CO to just delete." Again, I wouldn't be satisfied, but I couldn't really object to their decision if they made that argument. The problem is that they don't.

 

-- How do we know that cachers that have had duplicate Finds deleted haven't complained directly to GS saying that the system allows them to log another find, so why can't they revisit the cache and get another find? I even recall a non-newbie forum poster that suggested, recently, that he could log duplicate finds on a cache and if the CO deleted his dupe find then he could appeal to GS and GS would reinstate his dupe find.

How would we know? They'd tell us! Although I wouldn't even find that particularly satisfying since, after all, they'd be saying that they're restricting a feature because they're sick of dealing with the people making mistakes using it. But at least I'd have an explanation.

 

Really, assuming that what we see in the forums constitutes the entirety of examples that occur IRL seems faulty. I'm sure GS had their reasons for allocating resources to this re-programming. I'm also sure that they would never be able to get all cachers, especially forum posters, to be in agreement with their reasons.

OK, so I'll admit that part of my problem is that I don't believe this. What I've seen from GS over the last year or two is that they react to complaints even when the complaints aren't really justified. Too often I think the squeaking wheel is getting the grease at the expense of people that have no complaint and, in fact, don't like the "solution".

[+edscott]

Second, because of their minimal value, COs have the right to delete notes to their content, whether or not they contain 'questionable' content.

 

Here is what the guidelines actually say:

 

6.13. Delete logs

 



Powered by Translate

Cache owners may delete geocache logs if they conflict with our Terms of Use Agreement or fail to meet the logging guidelines.

 

Note the lack of any mention of log type.

 

Exactly.. none of the caches I own have multiple logs by any player. Must be because all the cachers around here are careful not to double log.

Edited April 8, 2017 by edscott

[Keystone]

I have a more serious question to ask,,

 

 

 

 

Where's my blankie?

It turns out there is a moratorium on blankies, due to the difficulties experienced by the moderators in assessing the eligibility of potential blankie recipients. Geocaching HQ and the Forum Moderators are currently revisiting the standards for the issuance of blankies to worthy forum posters. Watch for a User Insights Forum survey. That will be followed by secret internal debate: should the sizes of the blankies be adjusted? Will there be color choices? Should we offer the "Classic Blankie" for $9.99, or instead have a model for delivering free blankies that only have around 10% of the warming factor of the Classic Blankie?

 

The results should be available in June.

 

(I did not say which year, just "June.")

Edited April 8, 2017 by Keystone

[+colleda]

Logging finds such as on this event will no longer be possible. Good thing I think.

 

https://www.geocaching.com/geocache/GC6PXMH_3rd-annual-berea-chamber-geocaching-weekend

[+cerberus1]

Logging finds such as on this event will no longer be possible. Good thing I think.

 

https://www.geocaching.com/geocache/GC6PXMH_3rd-annual-berea-chamber-geocaching-weekend

Wow! That's nuts !

[+Team Hugs]

I'm glad that this error will be prevented in the future. Just like with Needs Archived and Temporarily Disable logs, which you can't post when the listing is already archived or disabled.

 

There would have been easier and less invasive ways to achieve that - like being asked "Do you really want to submit a second found it log?".

 

 

Because that works so well when cache owners click on the box that says "I have read and agree to the Terms of Use Agreement and the Cache Listing Requirements Guidelines" when submitting a new cache placement ...

[+The Jester]

To wit: I trusted the comments in this thread mentioning the issues this change was meant to address. I wasn't personally looking for written, explicit examples of those issues. So I pointed to earlier in the thread to which your response was implying there were no examples, which seemed to me ridiculous, since they were mentioned in this thread.

You are talking about examples of duplicates happening, but no one denies they happen. I'm asking for examples of duplicates causing a problem. I don't consider needing to clean up a rare mistake or seeing duplicates in a log once in a while to be problems. We'll always have to deal with mistakes and excess logs even after we've eliminated this one source, so I don't see that as justification for taking away these caches.

 

Taking away which caches?

Short memory loss? The brass caps in Canada, and the YOSM in UK.