Jump to content

Changes to logging, specifically stopping double logs


Recommended Posts

I do not think that that's the reason. I rather think that recurring events are dying out. I have been a fan of recurring events for regular events at inns but with the addition that they are not logged multiple times as attended as I used to think about events as something special and not a cheap +1 which after all is what meanwhile almost all events in my area have come to be about (helped also by the no moving events change).

 

Side note: I tried to figure out what was the biggest geocaching event held so far recently and that turned out to be more difficult than expected due to lots of events with multiple logs for either recycled listings or faked finds for event caches. For this reason alone, I'd actually be happy to see one-event-one-log implemented retroactively. Not that it'll happen, but I fail to see the point of multi-logging like this.

 

For the recurring events: it isn't the same event. If I log the March one and my friend the April one but they are the same listing, we seem to have visited the same event unless you really read the log dates (and assume that people never accidentally log on the wrong date). Since there has never been any problems creating new events, this just creates unnecessary confusion.

 

For event caches: If they are worthy of being noted as finds, then they should have a real listing and be available for users on later days. By just making log-as-event-caches, the "cache" owner is dodging both the maintenance guidelines (caches should be placed for the long term) and the proximity guidelines (since these caches aren't ever reviewed) at the cost of messing up everyone else's statistics.

 

I do know that recurring events do not fit into modern geocaching. When I started with geocaching noone cared about what is the largest event, what is the most found cache, who is the winner of whatever and many of these questions. It was about offering special experiences regardless of whether for normal caches or for events. We intentionally organized locally the regular meetings of the community outside of geocaching and had a geocaching event once or twice a year and that event then was special and lasted several hours and most attendants were present during all this time and noone left for geocaching very early or came very late for these reasons.

 

It's so unfortunate that statistics based arguments have become so important. While some features of project-gc and similar tools are handy, I'm quite unhappy about the reinforced effect these tools had on how some cachers wish to enforce how others should enjoy geocaching. That also happened for challenge caches.

Link to comment

I do know that recurring events do not fit into modern geocaching. When I started with geocaching noone cared about what is the largest event, what is the most found cache, who is the winner of whatever and many of these questions. It was about offering special experiences regardless of whether for normal caches or for events. We intentionally organized locally the regular meetings of the community outside of geocaching and had a geocaching event once or twice a year and that event then was special and lasted several hours and most attendants were present during all this time and noone left for geocaching very early or came very late for these reasons.

 

It's so unfortunate that statistics based arguments have become so important. While some features of project-gc and similar tools are handy, I'm quite unhappy about the reinforced effect these tools had on how some cachers wish to enforce how others should enjoy geocaching. That also happened for challenge caches.

 

I'm all for events lasting more than the minimum half-hour, having activities more than just meeting at a parking lot and people staying for the entire duration. None of that is hindered by using event listings as they are meant to be used; one per actual event. Reusing a listing doesn't add anything apart from confusion.

 

As for challenges, the problem was cachers creating more and more outlandish corner-case challenges, reviewers nixing them and cachers taking them to appeals which caused a lot of work for very little benefit. Having clear guidelines (regardless of the content of the actual guidelines) eliminates this problem caused by people bending the too-vaguely-defined rules too far, and I feel that is a good thing (which is not really the subject here, though).

Link to comment

I'm all for events lasting more than the minimum half-hour, having activities more than just meeting at a parking lot and people staying for the entire duration. None of that is hindered by using event listings as they are meant to be used; one per actual event. Reusing a listing doesn't add anything apart from confusion.

 

I do not regard a monthly event at the same inn at the same time as a geocaching event in its own right. As I said the role of the geocaching listing for me was just to alert the local community that there is a regular meeting. Personally I would prefer to count event attendance not as a geocaching find anyhow.

As the activities are regarded, the event guidelines outrule most almost all interesting types of activities as part of the official event which will in most cases end up as something boring.

 

As for challenges, the problem was cachers creating more and more outlandish corner-case challenges, reviewers nixing them and cachers taking them to appeals which caused a lot of work for very little benefit. Having clear guidelines (regardless of the content of the actual guidelines) eliminates this problem caused by people bending the too-vaguely-defined rules too far, and I feel that is a good thing (which is not really the subject here, though).

 

A lot of the changes had nothing to do with the reviewing and with appeals. Some changed were caused by complaining cachers that did not like certain types of challenge caches or who did not want to invest the work to see whether they qualified while it was exactly this sort of task that others enjoyed very much.

Edited by cezanne
Link to comment

I'm all for events lasting more than the minimum half-hour, having activities more than just meeting at a parking lot and people staying for the entire duration. None of that is hindered by using event listings as they are meant to be used; one per actual event. Reusing a listing doesn't add anything apart from confusion.

 

I do not regard a monthly event at the same inn at the same time as a geocaching event in its own right. As I said the role of the geocaching listing for me was just to alert the local community that there is a regular meeting. Personally I would prefer to count event attendance not as a geocaching find anyhow.

As the activities are regarded, the event guidelines outrule most almost all interesting types of activities as part of the official event which will in most cases end up as something boring.

Then simply just don't log events. Problem solved.

 

What kind of activities does the guidelines outrule? I've been to a lot of events with fun and interesting activities.

Link to comment

The Help Center addresses this in its Logging Etiquette article: "Each geocache should be logged as found only one time by any one geocacher. If you visit the cache again, you should write about your experience by posting a note, not logging another find." This statement was not recently added.

Ah, thanks. "Etiquette." "Things to consider." "Should be." A system that allows additional finds is consistent with these statements.

 

Oh, look, it says on this page "Don't log a find on your own geocache," which goes against my other point, except the link goes to a page that says, "It is considered bad form" instead of saying not to do it.

 

Anyway, I stand by my claim that these changes do not make the behavior more consistent with the guidelines. In fact, it's clear the guidelines will become entirely wrong to even suggest these changes are possible, but I'm sure GS will fix that up when the time comes.

Link to comment

I'm all for events lasting more than the minimum half-hour, having activities more than just meeting at a parking lot and people staying for the entire duration. None of that is hindered by using event listings as they are meant to be used; one per actual event. Reusing a listing doesn't add anything apart from confusion.

 

I do not regard a monthly event at the same inn at the same time as a geocaching event in its own right. As I said the role of the geocaching listing for me was just to alert the local community that there is a regular meeting. Personally I would prefer to count event attendance not as a geocaching find anyhow.

As the activities are regarded, the event guidelines outrule most almost all interesting types of activities as part of the official event which will in most cases end up as something boring.

Then simply just don't log events. Problem solved.

 

Not really because it's still interesting to see which events one attended although one does not want them to be mixed with geocaching finds.

I chose to log the recurring events that existed in my area only once as attended and do not have logged a single cache more than once a find however.

I'm a big fan of nice virtuals too but again I'd like to see them as something separate.

 

What kind of activities does the guidelines outrule? I've been to a lot of events with fun and interesting activities.

 

Everything moving - like a hike, ice-skating etc

The official event is just sitting around. Whatever else takes place if at all can happen before or after the event which is not what I regard as a good idea for an outdoor hobby. I have been at events I enjoyed very much but they took place years ago before the rules have been tightened.

Edited by cezanne
Link to comment

Everything moving - like a hike, ice-skating etc

The official event is just sitting around. Whatever else takes place if at all can happen before or after the event which is not what I regard as a good idea for an outdoor hobby. I have been at events I enjoyed very much but they took place years ago before the rules have been tightened.

I don't see why ice-skating shouldn't be allowed. And hiking is no problem, you just make an event at either the starting point or at the destination, and mention in the description that people can join the hike before/after the event. Problem solved.

Most people I know would then count the hike as a part of the event. You could technically attend without the hike, but that's that persons loss.

 

There's a lot of activities you can do without moving to another place. And for those things you can't get the reviewer to publish, just move it to the time directly before or after the event.

 

We've been to a lot of mega events, and there's usually always a lot to do! The Going APE mega event even include a hike to the APE cache...

Link to comment

Everything moving - like a hike, ice-skating etc

The official event is just sitting around. Whatever else takes place if at all can happen before or after the event which is not what I regard as a good idea for an outdoor hobby. I have been at events I enjoyed very much but they took place years ago before the rules have been tightened.

I don't see why ice-skating shouldn't be allowed. And hiking is no problem, you just make an event at either the starting point or at the destination, and mention in the description that people can join the hike before/after the event. Problem solved.

Most people I know would then count the hike as a part of the event. You could technically attend without the hike, but that's that persons loss.

 

There's a lot of activities you can do without moving to another place. And for those things you can't get the reviewer to publish, just move it to the time directly before or after the event.

 

We've been to a lot of mega events, and there's usually always a lot to do! The Going APE mega event even include a hike to the APE cache...

 

This is a topic in itself which has had many long debates. The key part of the guidelines in question is:

 

An event is a gathering of geocachers, facilitating the social aspect of geocaching. It is organized by geocachers and is open to other geocachers and those interested in learning about the game. It takes place at the posted coordinates, includes start and end times, and lasts at least 30 minutes. Events with several elements, a sequence of events, or events that are near the same time or location and intended for the same audience should be submitted as a single event. Additional waypoints may be added to the event listing for the locations of event activities.

 

You can have activities. Nobody has to sit. But you do need someone to be at the "posted coordinates" for the time listed.

 

This does mean you have to "manipulate" the events a bit if the main idea of the event is to be moving (e.g. a hike, or a stake on a river for some distance).

 

If the event was in a park, and that park had a pond with skating, within sight of the posted coordinates, then I don't think it is an issue. Most likely not everyone will skate so someone will be at the posted coords, but if not they would see everyone skating. Or you could put the posted coordinates in the middle of the pond.

 

With a Mega, there is always someone at the posted coordinates - you generally sign in there. So that is covered, even if the event itself covers a large area with many activities.

 

What you can't do is say: The event runs from 9 to 3. At 9 we hike for the top of the mountain. We plan to reach the top by 12, have lunch, then return. You can say: We have an event at posted coordinates from 8:30 to 9:00. If interested, you can join some of us on a hike following the event.

Link to comment

 

I don't see why ice-skating shouldn't be allowed. And hiking is no problem, you just make an event at either the starting point or at the destination, and mention in the description that people can join the hike before/after the event. Problem solved.

 

This does not change the fact that what ends up as the geocaching.com event is the dull part of standing around while the interesting part can happen but is not part of the official event.

All these 1/1 events out there clearly demonstrate that.

It goes without saying that whatever activities can take place before or after a gc.com event. What counts when it comes to the rules at this site is what this allows and that brings me back to what I see at the centre of this thread.

 

There has been much more flexibility in the earlier years and so much more rigidity entered in recent years most of which I regard as a loss regardless of whether it concerns me personally or not. I do not think that the collateral damage caused by most of these changes (including the one we discuss about in this thread) is worth when compared to what might be won.

Link to comment
Like someone else said, seems like it could be made to accept logging...or to read 'Notes' rather than 'Found it' logs.
One possibility would be to borrow a technique from the FTF tracking systems. Have people include a special string in their Note logs, and then have the system count both Find logs and Note logs that include the special string.

 

For example, posting a Note that reads:

I'm glad this historic cache was not archived.
would not be counted by the system. But posting a note that reads:
[=YOSM=] This is my third survey monument!
would be counted by the system.

 

That's one way finds on a YOSM cache could be counted. For the FTF game, others will create a bookmark list of their FTFs. Others will create a spreadsheet or other type of files on their computer which contains a list of FTFs. Some just edit their profile page and add the GC code for each FTF they get.

 

Somehow, despite the fact that GS doesn't count FTFs and publish the number of FTFs one has on the site, a lot of people continue to enjoy that side game.

 

 

Link to comment

That's one way finds on a YOSM cache could be counted. For the FTF game, others will create a bookmark list of their FTFs. Others will create a spreadsheet or other type of files on their computer which contains a list of FTFs. Some just edit their profile page and add the GC code for each FTF they get.

 

Somehow, despite the fact that GS doesn't count FTFs and publish the number of FTFs one has on the site, a lot of people continue to enjoy that side game.

 

While I do not care about the FTFs of another cacher, I do see extra benefit from what a site like YOSM offers. There you can look at maps for every cacher who logged the cache at least once and you can then have a look at the associated logs which is handy for example when one knows that cacher A has a similar preference than oneself - then looking at the brass caps they visited and the logs they wrote is an interesting thing to do for some cachers.

The YOSM site records the activities of all involved, not only of cachers who happen to include something into their profile.

 

The suggestion made by NiraD would allow to continue with the way the site works while the alternatives you suggest only would only be of personal use.

Link to comment

The YOSM site records the activities of all involved, not only of cachers who happen to include something into their profile.

You don't need to include anything in your profile, but you need to include the YSM number in your log (just like you need to include the FTF-tag in your log). The YOSM site works exactly like the FTF parsing does:

Incorrect or missing red traingle? This could mean the YSM number (YSMxxx) was not found in the log. Please help to increase the data integrity by updating your log(s) to include the YSM number.
Link to comment

The YOSM site records the activities of all involved, not only of cachers who happen to include something into their profile.

You don't need to include anything in your profile, but you need to include the YSM number in your log (just like you need to include the FTF-tag in your log). The YOSM site works exactly like the FTF parsing does:

 

What I wrote was in reply to NYPaddleCacher who suggested that alternative could be used to tagging logs.

Right now the YOSM system only looks at found it logs. If notes are used too, tagging would be required to distinguish between notes that describe a visit and other notes.

Link to comment

It is not possible to log anything on yosm.org.uk

 

Maybe you should follow that quick google search with a slow thoughtful read ? Go back and have a proper look instead of leaping to unfounded conclusions, I'm not wasting my time explaining .

Maybe you should read the previous posts. We know that it's currently not possible. But is it impossible to change that?

 

It does, by the way, look like it's possible to log on this page: http://trigpointing.uk/

 

Here's the precise wording of the post I was replying to, relevant words bolded:

So...a quick google search brings me to this page: http://www.yosm.org.uk/

Looks like not only can you log the finds on that and get a full map of all the locations, you can use the "statpics" utility to post the count to your GC profile.

 

Again, I'm not wasting time with any further explanation which would simply provide further fuel for the keyboard warriors who appear to enjoy that kind of thing.

I'm not here for

,instead I'm going out caching ...
Link to comment

It is not possible to log anything on yosm.org.uk

 

Maybe you should follow that quick google search with a slow thoughtful read ? Go back and have a proper look instead of leaping to unfounded conclusions, I'm not wasting my time explaining .

Maybe you should read the previous posts. We know that it's currently not possible. But is it impossible to change that?

 

It does, by the way, look like it's possible to log on this page: http://trigpointing.uk/

 

Here's the precise wording of the post I was replying to, relevant words bolded:

So...a quick google search brings me to this page: http://www.yosm.org.uk/

Looks like not only can you log the finds on that and get a full map of all the locations, you can use the "statpics" utility to post the count to your GC profile.

 

Again, I'm not wasting time with any further explanation which would simply provide further fuel for the keyboard warriors who appear to enjoy that kind of thing.

I'm not here for

,instead I'm going out caching ...

 

No need for further explanation, the man behind yosm.org.uk described this in detail *before* you posted your reply. And that's why I answered that you should read what's been said already, before telling other people to read before posting...

 

Have fun caching! :)

Link to comment

Well the problem is, it's not nearly as innocuous as you seem to imply, as evidenced by many examples in this very thread.

I must have missed those examples. Could you point them out?

 

Guess I missed them too, all the examples I have seen are pretty trivial and totally innocuous.

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache. Unfortunately, there are indeed a few extremely rare, beloved, old caches that make use of this logging loophole ("bad form" but not enforced) which GS has decided can no longer make use of said loophole. That doesn't equate to "ARCHIVE!" unless the CO decides so.

In YOSM's case, its 'charm' is reduced, but if the enjoyment of the cache is not merely about the +1 Smiley, then there A] are other means to locate and log visits to the markers, and B] is still reason to keep it active for people to find even just once, at whatever marker it may currently sit. Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

Link to comment

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache.

 

Recurring events for example happened with the full knowledge of Groundspeak including multiple logs - the same happened for moving caches. It's not about loopholes in these cases - it's about restricting flexibility that Groundspeak once allowed.

 

The guidance that can meanwhile found in the help centre has never been part of the guidelines. Until a few years ago the guidelines were concise and available as a single file. It was clear what was part of the guidelines and what not. Now they use to add many help center articles and this does not seem to happen in a very coordinated manner. Often the help center articles respond to questions or concerns that have often been raised, but they are not really guidelines. This by the way also holds for the famous briansnat quote about location - if it were a guidelines, Groundspeak could not go on publishing power trails.

 

 

Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

 

I do not agree at all. Accidentical multi-logging and these type of things are not a real problem for me apart from the fact that a more reliable data connection and the question "Do you really wish to post a second log?" would be able to handle these issues just as well. For me already the loss to the UK community is higher than whatever the benefits of the change could be and I ignore there the changes like no NM logs for cache owners.

Edited by cezanne
Link to comment

One possibility would be to borrow a technique from the FTF tracking systems. Have people include a special string in their Note logs, and then have the system count both Find logs and Note logs that include the special string.

 

For example, posting a Note that reads:

I'm glad this historic cache was not archived.
would not be counted by the system. But posting a note that reads:
[=YOSM=] This is my third survey monument!
would be counted by the system.

 

That strikes me as a good idea. Perhaps somewhere such as Project GC could be convinced to add that to one of their incredibly useful menu options?

Link to comment

Well the problem is, it's not nearly as innocuous as you seem to imply, as evidenced by many examples in this very thread.

I must have missed those examples. Could you point them out?

 

Guess I missed them too, all the examples I have seen are pretty trivial and totally innocuous.

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache. Unfortunately, there are indeed a few extremely rare, beloved, old caches that make use of this logging loophole ("bad form" but not enforced) which GS has decided can no longer make use of said loophole. That doesn't equate to "ARCHIVE!" unless the CO decides so.

In YOSM's case, its 'charm' is reduced, but if the enjoyment of the cache is not merely about the +1 Smiley, then there A] are other means to locate and log visits to the markers, and B] is still reason to keep it active for people to find even just once, at whatever marker it may currently sit. Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

 

It's hard to see how any of those examples could be described as harmful, injurious or offensive (see dictionary definition of innocuous), though I can see that some people are determined to be offended at any opportunity so perhaps...

 

In any case I don't have a problem with programmatically preventing multiple logging but I don't see why they need to throw the baby out with the bathwater. As it's being done programatically they could code in exceptions for the few long standing caches which have always used multi-logging, once coded it wouldn't need a lot of maintenance as virtuals and moving caches are nolonger allowed and so would there would be no need to add future caches to the exclusion clauses, though multi-logging events could be a different case (does anyone still create these?),

 

It seems to me that we're losing a long established, well loved, and somewhat quaint aspect of the game in the name of "progress", and I can't help wondering what's next? The ability for members to log PM caches I would guess...

Link to comment

Well the problem is, it's not nearly as innocuous as you seem to imply, as evidenced by many examples in this very thread.

I must have missed those examples. Could you point them out?

 

Guess I missed them too, all the examples I have seen are pretty trivial and totally innocuous.

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache. Unfortunately, there are indeed a few extremely rare, beloved, old caches that make use of this logging loophole ("bad form" but not enforced) which GS has decided can no longer make use of said loophole. That doesn't equate to "ARCHIVE!" unless the CO decides so.

In YOSM's case, its 'charm' is reduced, but if the enjoyment of the cache is not merely about the +1 Smiley, then there A] are other means to locate and log visits to the markers, and B] is still reason to keep it active for people to find even just once, at whatever marker it may currently sit. Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

 

It's hard to see how any of those examples could be described as harmful, injurious or offensive (see dictionary definition of innocuous), though I can see that some people are determined to be offended at any opportunity so perhaps...

 

In any case I don't have a problem with programmatically preventing multiple logging but I don't see why they need to throw the baby out with the bathwater. As it's being done programatically they could code in exceptions for the few long standing caches which have always used multi-logging, once coded it wouldn't need a lot of maintenance as virtuals and moving caches are nolonger allowed and so would there would be no need to add future caches to the exclusion clauses, though multi-logging events could be a different case (does anyone still create these?),

 

It seems to me that we're losing a long established, well loved, and somewhat quaint aspect of the game in the name of "progress", and I can't help wondering what's next? The ability for members to log PM caches I would guess...

 

What some folks find 'innocuous', others may find 'annoying' or 'frustrating'. Who are you to denigrate those who do? Personally, I find many things bothersome that others do not...and there are things that bother others that I don't really take issue with.

 

I don't imagine they take system-wide changes lightly, so I have to assume the issue became big enough to make them move on it.

Link to comment

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache.

Recurring events for example happened with the full knowledge of Groundspeak including multiple logs - the same happened for moving caches. It's not about loopholes in these cases - it's about restricting flexibility that Groundspeak once allowed

...even though it was always considered "bad form".

Now "bad form" is being restricted because the loopholes are considered to have become worth closing.

 

Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

I do not agree at all.

Okay. You're wrong though. :P

 

Accidentical multi-logging and these type of things are not a real problem for me...

Precisely.

 

What some folks find 'innocuous', others may find 'annoying' or 'frustrating'. Who are you to denigrate those who do? Personally, I find many things bothersome that others do not...and there are things that bother others that I don't really take issue with.

 

I don't imagine they take system-wide changes lightly, so I have to assume the issue became big enough to make them move on it.

Precisely x2.

Link to comment

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache.

Recurring events for example happened with the full knowledge of Groundspeak including multiple logs - the same happened for moving caches. It's not about loopholes in these cases - it's about restricting flexibility that Groundspeak once allowed

...even though it was always considered "bad form".

 

No, it wasn't in those cases. It was even what has been suggested to do.

 

 

Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

I do not agree at all.

Okay. You're wrong though. :P

 

I do not think that this something anyone can be right or wrong about. It's subjective.

Link to comment

What some folks find 'innocuous', others may find 'annoying' or 'frustrating'. Who are you to denigrate those who do? Personally, I find many things bothersome that others do not...and there are things that bother others that I don't really take issue with.

 

If we abolish everything in geocaching that annoys someone, nothing will remain. If I lived in the UK, I would not have chosen to log multiple finds for the brass cap cache but I feel that taking away the option to log multiple finds for this cache and similar ones is plain wrong and is not compensated by what is won which is mainly on the bookkeeping and formal level in my opinion and I never thought the inspiring part of geocaching to be about that level.

 

I don't imagine they take system-wide changes lightly, so I have to assume the issue became big enough to make them move on it.

 

I'm not so sure. For example, when it comes to not confusing newer cachers, I rather think what would be needed is a system that enforces a certain form of education for cache owners. I'm not a fan of asking for a certain number of finds before someone can hide a cache. However putting restrictions on the usage of NM logs for cache owners, is something which should not be motivated by the wish not to confuse new community members. They could have a compulsory quiz about the meanings of log types that everyone needs to pass before being allowed to hide a cache. And then owner written NM logs are usually something which will typically not come up at the very beginning of a cache either so that gives newer members a quite long time to learn.

 

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

Edited by cezanne
Link to comment
I do not regard a monthly event at the same inn at the same time as a geocaching event in its own right. As I said the role of the geocaching listing for me was just to alert the local community that there is a regular meeting. Personally I would prefer to count event attendance not as a geocaching find anyhow.quote]

+1 Yep. :)

 

Since '09 or so, we've logged less than half the events we attended..

Some I consider similar to family dinners, with the same folks, same subjects discussed, same location.

Fun to talk with friends, but (to me) not that big a deal.

Others just seemed to be only about another "smiley" on their way to a cache run, as most (except for the host) leave after signing the log.

One bragged once that he hit over a dozen events in one day (sign n scoot).

Those (to me) aren't events...

Apparently many aren't familiar with guidelines either, or they'd be waving from their cars. :D

Link to comment

Clearly "innocuous" is quite subjective. All the concerns such as accidental multi-logging, drama induced by COs deleting duplicate logs and the cacher not realizing, people using the multi-log ability to increase their numbers, yadda yadda. They may be innocuous to you, but they were raised as legitimate examples of problems that are being addressed by limiting to one find per cache.

By innocuous, I mean important enough to block someone else from doing something they enjoy.

 

You've shown what I'm complaining about. You haven't listed a single example, yet you're convinced you've proved this is serious and must be stopped no matter who it hurts. Let's look at your list.

 

Yes, accidents happen, but you can't just say "accidents happen, so we'll stop them." You have to actually show that the accidents cause problems that are worse than the other problems your solution cause. I've seen a few accidental multi-logs, but I've never seen them cause any problem more serious than a head shake.

 

There might be the occasional drama with CO's deleting redundant logs, although I suspect this is imagined way more often than it actually happens. I asked for examples, but you're only presenting a conjecture. But even if I stipulate that it happens regularly, it's not the multi-logs that are creating the drama. Arguing to stop multi-finds because of a single case where a CO tries to do something nice for someone and getting a negative reaction is like arguing to ban certain words because they can be misinterpreted and anger people. Indeed, if there is a seeker that doesn't get that the CO's trying to help him out, this kind of drama where the CO can easily point out that this isn't a confrontational action might actually be beneficial in that it can help the seeker realize COs and seekers are on the same side. (Besides, if GS were really serious about this problem, they could add the often requested feature that let's the CO explain why he's deleting the log which would help reduce the drama in all cases instead of just this one.)

 

And while everyone's all concerned about people padding their numbers with multiple logs, I'm not sure it's ever happened, and if it did, I think it would be easy and practical for GS to step in to deal with the fake finds, assuming the CO doesn't do anything. Besides, padding numbers has no real impact on other geocachers, unlike the proposed solution.

 

So, yes, innocuous in the sense that the non-example examples don't actually prove there's any problem at all, let alone prove that the problem is sufficient to stop other people from having their harmless fun in their own way.

Link to comment

I don't imagine they take system-wide changes lightly, so I have to assume the issue became big enough to make them move on it.

I can't argue with you, as your point seems consistent with GS's actions, but I find it annoying as heck to think that they have really, really good reasons for doing this that they aren't willing to explain to us. Instead they mumble of about confusing newcomers.

Link to comment

Just a couple thoughts here. If you own a cache, why would you need to claim a smiley on it? You'll still be able to adopt a cache you've already found, and you'll be able to claim you attended an event you own. Do you need to let other cachers know there's an issue with a cache you own? Instead of throwing up a red wrench, just disable the cache. Check out the 2017 West Bend Cache Bash, someone has already logged with "Attended" even though the date of the log is last October. They'll be pretty upset that they can't log the proper attended log this coming August when the event happens. Double logs in general, I actually know a guy who claimed a second smiley on a cache but didn't realize it. . .this was on a day we were caching together, but we never went there. I made sure he deleted the duplicate log. As far as caches I own, I make sure to delete duplicates, and recently did this on an event I hosted.

 

-The Happy Hodag!

Link to comment

The YOSM site records the activities of all involved, not only of cachers who happen to include something into their profile.

You don't need to include anything in your profile, but you need to include the YSM number in your log (just like you need to include the FTF-tag in your log). The YOSM site works exactly like the FTF parsing does:

 

What I wrote was in reply to NYPaddleCacher who suggested that alternative could be used to tagging logs.

Right now the YOSM system only looks at found it logs. If notes are used too, tagging would be required to distinguish between notes that describe a visit and other notes.

 

I was only elaborating on what niraD suggested regarding an automated way to keep track of YOSM visits. The point is that even though GS doesn't keep track of and display FTFs that those that enjoy the FTF game work around it using whatever method works best, and somehow that hasn't seemed to ruin the FTF game for those that play it. That would all be moot if the CO decides to archive the YOSM cache.

Link to comment

The YOSM site records the activities of all involved, not only of cachers who happen to include something into their profile.

You don't need to include anything in your profile, but you need to include the YSM number in your log (just like you need to include the FTF-tag in your log). The YOSM site works exactly like the FTF parsing does:

 

What I wrote was in reply to NYPaddleCacher who suggested that alternative could be used to tagging logs.

Right now the YOSM system only looks at found it logs. If notes are used too, tagging would be required to distinguish between notes that describe a visit and other notes.

 

I was only elaborating on what niraD suggested regarding an automated way to keep track of YOSM visits. The point is that even though GS doesn't keep track of and display FTFs that those that enjoy the FTF game work around it using whatever method works best, and somehow that hasn't seemed to ruin the FTF game for those that play it. That would all be moot if the CO decides to archive the YOSM cache.

 

I understood what you said as saying that there are alternatives to niraD's suggestion which do not require a systematic tagging on the side of the loggers. There are cachers who collect their FTFs in different manners and do not make use of the project-gc tagging. For the YOSM it would be important that everyone tags their logs.

Link to comment
If you own a cache, why would you need to claim a smiley on it? You'll still be able to adopt a cache you've already found, and you'll be able to claim you attended an event you own.
I recall two reasons that others have cited:
  • A cache that the owner adopts before finding, where the owner wants to log the first (post-adoption) visit as a Find.
  • A challenge cache that the owner wants to log as a Find after completing the challenge.

 

Do you need to let other cachers know there's an issue with a cache you own? Instead of throwing up a red wrench, just disable the cache.
What if it's a problem that doesn't warrant disabling the cache, but that you still don't want to forget about? For example, if the camouflage is starting to fail and needs to be replaced soon, but the cache is otherwise fine.
Link to comment

> ...even though it was always considered "bad form".

 

No, it wasn't in those cases. It was even what has been suggested to do.

Not "in those cases". It's bad form according to the guidelines. They are universal, no exception to individual regions or communities. The local community decided for themselves that it was ok to do it because it was technically doable (that's why it's a loophole) despite being "bad form". Them doing it didn't seem to hurt anyone - no one's disputing that.

But the practice has always been considered abnormal, not as intended, bad form. So, it's now being closed. Anyone who didn't practice such "bad form" (even if individuals didn't consider it bad form themselves) won't be affected by this change. ie, people who only ever log caches once will not be affected by this change.

 

>>> Thus, it seems the drawbacks from this new rule being programmatically enforced are far outweighed by the benefits (despite resolving issues you may feel are 'innocuous').

 

>> I do not agree at all.

 

> Okay. You're wrong though. :P

 

I do not think that this something anyone can be right or wrong about. It's subjective.

What is subjective? The statement was about what Groundspeak has decided, not what you feel.

Groundspeak has weighed the benefits and drawbacks of closing the loophole. They have determined that it is sufficiently worth their attention to close, despite any drawbacks or collateral damage. You can't "not agree" with that. It wasn't a statement about your feelings or opinions, it was a statement about what GS has decided. Disagree all you want, but that's a fact, that's why they did it. So yes, you're wrong on that.

 

You are not wrong about your feelings on the matter, of course, you can't be wrong about that - they're your feelings.

 

They could have a compulsory quiz about the meanings of log types that everyone needs to pass before being allowed to hide a cache. And then owner written NM logs are usually something which will typically not come up at the very beginning of a cache either so that gives newer members a quite long time to learn.

And all of those things people learn about logging are now being applied to the API's capabilities - they are now being consistent. They just haven't deemed it necessary to provide exceptions. (as I've repeated, I felt it would be worthwhile to provide exceptions for a handful of grandfathered caches, but apparently GS didn't, for whatever reason).

 

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

I completely agree about educating new cachers better. As a programmer, if the documentation explains you do one thing and not another, you don't still allow the other thing to be done just because it can even if harmlessly. There can be mis-uses, intentional or mistaken, and/or exploits. In the case of GC finds, the exploits were people making use of the technical capability despite being considered "bad form". Arguing from ignorance about 'bad form' (ie, not being 'educated' about the logs) likely wouldn't be a sufficient argument for reversing the decision to have consistency between the guidelines and the programming.

 

By innocuous, I mean important enough to block someone else from doing something they enjoy.

At the expense of anyone else who is affected? ..of any bugs in the system that people can take advantage of? Nope, innocuous applies across the board. And the change is not dealing with an issue that a portion of the community finds "innocuous" - they are dealing with an issue which they have deemed sufficiently problematic in the grand scheme, which we aren't privy to, yet they have alluded to by providing example situations that have occurred. (unless of course you don't believe the reports as cited in this thread which you seem to consider insignificant)

 

You haven't listed a single example

blink.gif

 

Yes, accidents happen, but you can't just say "accidents happen, so we'll stop them." You have to actually show that the accidents cause problems that are worse than the other problems your solution cause.

*I* don't have to. Groundspeak has deemed they are worth stopping. They have their reasons. Some people don't like those reasons. That happens with every update they roll out, it seems. Can't please everyone.

 

...might be the occasional drama...

Reductionist... Hand waving away problems by minimizing the effect on people or the importance of the issues to anyone other than from your own perspective isn't helpful. There is drama, as you here admit (based on examples provided in this thread), and Groundspeak has deemed that resolving the problems outweigh the drawbacks of that resolution. Can't please everyone.

 

The point is that there are problems which Groundspeak has weighed and felt necessary to address with a technical patch, in spite of there being instances of practices that are not directly harmful at all, which will also be affected.

As with any major update, GS is under no obligation to detail out every reason or example for every decision they make.

For their own sake though they always have to deal out some damage control, but that's not an obligation - that's a desire to do what they feel is best for the community and the hobby they are responsible for shaping via the website.

 

(Besides, if GS were really serious about this problem, they could add the often requested feature that let's the CO explain why he's deleting the log which would help reduce the drama in all cases instead of just this one.)

I agree. They could still do that :P

Link to comment

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

 

Some of whom have used the website for many, many years without contributing a single bean to its upkeep and development yet somehow still feel empowered to dictate precisely how that website should operate <_<

Link to comment

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

 

In which case I must have imagined or dreamt about those little educational videos that have been added to the app.

 

And the little popup reminders on certain log types - like the one which pops up on initiating a log on an EarthCache for example, reminding you to submit your answers to the CO - that must have been an hallucination :unsure:

Link to comment
If you own a cache, why would you need to claim a smiley on it? You'll still be able to adopt a cache you've already found, and you'll be able to claim you attended an event you own.
I recall two reasons that others have cited:
  • A cache that the owner adopts before finding, where the owner wants to log the first (post-adoption) visit as a Find.
  • A challenge cache that the owner wants to log as a Find after completing the challenge.

1. There are a few alternatives in that case (though I'm not sure I understand the value of the cited practice). For the adopter's sake, log the find before adopting; or, take someone with them when visiting the cache (maintenance run for the new owner, a Find for the friend). I do presume that by "to log the first visit as a Find" you mean the goal here is for the adopter to verify the cache's condition publicly with a successful Find log (and not merely to gain a smiley for themselves). But that can also be accomplished by the OM log, post-adoption. If not, then what really is the value/goal of the adopter in desiring to log a smiley on their cache post-adoption?

 

2. I can understand this, but I also understand the taboo nature that's always been around about logging your own caches as Found (ie, 'bad form'). I suppose in the case of challenges now, since you can only publish a challenge you already qualify for, then posting a Find log on your own challenge would merely be for the smiley, which is not a concern considered important in this programming change. The same argument as for challenges can be made for earthcaches; any cache with an ALR which the owner has themselves accomplished. It seems Events are the only listing type that GS has deemed okay for an owner to log themselves.

 

 

Do you need to let other cachers know there's an issue with a cache you own? Instead of throwing up a red wrench, just disable the cache.
What if it's a problem that doesn't warrant disabling the cache, but that you still don't want to forget about? For example, if the camouflage is starting to fail and needs to be replaced soon, but the cache is otherwise fine.

Personally speaking, I've never even thought about the possibility to log a NM on my own cache.

 

Apart from instances where someone else has logged the NM, if there's ever a concern with one of my caches that warrants my attention but isn't significant enough to warrant a disable, at worst I add it to my personal to-do list to tend to it when I'm able, just as with other things in life I have to get to.

As suggested earlier, you could also have a bookmark list with caches you need to tend to and plop it there (with or without the NM flag; and you can even describe the problem in its bookmark entry). I would think that if it's not a concern over which it's worth disabling the cache, then at most for the sake of finders a note would be sufficient to let them know.

 

Anyway, I'm not personally as concerned about the NM log restriction - I could go either way on that particular one based solely on the definition of "Needs Maintenance". It's just the practice had never even occurred to me, to log NM on my own caches. Maybe I would have, dunno. But it just didn't make sense (to me) since owners are provided other means of identifying/dealing with their cache problems.

Link to comment
Do you need to let other cachers know there's an issue with a cache you own? Instead of throwing up a red wrench, just disable the cache.
What if it's a problem that doesn't warrant disabling the cache, but that you still don't want to forget about? For example, if the camouflage is starting to fail and needs to be replaced soon, but the cache is otherwise fine.

Personally speaking, I've never even thought about the possibility to log a NM on my own cache.

 

Apart from instances where someone else has logged the NM, if there's ever a concern with one of my caches that warrants my attention but isn't significant enough to warrant a disable, at worst I add it to my personal to-do list to tend to it when I'm able, just as with other things in life I have to get to.

As suggested earlier, you could also have a bookmark list with caches you need to tend to and plop it there (with or without the NM flag; and you can even describe the problem in its bookmark entry). I would think that if it's not a concern over which it's worth disabling the cache, then at most for the sake of finders a note would be sufficient to let them know.

 

Anyway, I'm not personally as concerned about the NM log restriction - I could go either way on that particular one based solely on the definition of "Needs Maintenance". It's just the practice had never even occurred to me, to log NM on my own caches. Maybe I would have, dunno. But it just didn't make sense (to me) since owners are provided other means of identifying/dealing with their cache problems.

 

I have posted NM's on my own caches on several occasions.

 

I do this as a reminder to myself that it needs tending to and I keep the email it generates in my inbox as a daily reminder.

 

I also do it in a bid to educate / encourage others to make appropriate use of NM logs. I'll often include in the log something like 'Thanks to X for letting me know in their log that this cache needs attention - a Needs Maintenance log is appropriate here'.

 

Unfortunately in my area we seem to have an element who think it clever to cry caching police at every opportunity and to dissuade the use of NM logs if they possibly can, mostly because they have too many caches of their own to maintain properly, so I feel the need to counteract that poor behaviour by promoting appropriate use of NM logs when opportunities arise.

Link to comment

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

 

Some of whom have used the website for many, many years without contributing a single bean to its upkeep and development yet somehow still feel empowered to dictate precisely how that website should operate <_<

 

If you mean me, I do not dictate anything. I'm not affected by the changes they are implementing now but I feel with those who are affected and I do not share the opinion that there are more benefits than losses.

Link to comment

> ...even though it was always considered "bad form".

 

No, it wasn't in those cases. It was even what has been suggested to do.

Not "in those cases". It's bad form according to the guidelines. They are universal, no exception to individual regions or communities.

 

Show me the spot where this has been said in the guidelines at the time when these caches have been published.

It has not been there and it has not been considered as bad form. It was part of the concept to log moving caches and recurring events multiple times. That's not the same as logging an event multiple times to log temporary caches that existed only on the day of the event. The latter has always been based on exploiting a loophole by some local communities while the former was a whole different story.

Link to comment

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

 

In which case I must have imagined or dreamt about those little educational videos that have been added to the app.

 

And the little popup reminders on certain log types - like the one which pops up on initiating a log on an EarthCache for example, reminding you to submit your answers to the CO - that must have been an hallucination :unsure:

 

Does this happen for needs maintenance too? if so, why should it then be confusing if a cache owner can use this log type too?

Link to comment

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

 

In which case I must have imagined or dreamt about those little educational videos that have been added to the app.

 

And the little popup reminders on certain log types - like the one which pops up on initiating a log on an EarthCache for example, reminding you to submit your answers to the CO - that must have been an hallucination :unsure:

 

Does this happen for needs maintenance too? if so, why should it then be confusing if a cache owner can use this log type too?

 

Doesn't look like it.

Link to comment

I'm one of the few cachers in my area who actually pays attention to what people say in their logs, regardless of type. My way of handling maintenance would be to at least post a note in response to someone else even if they don't post an NM log of their own. That way, I can go to my logs in the last 30 days and see what caches of my own are there for future reference. When I end up performing the needed maintenence, I log an owner maintenance log to say I performed the necessary maintenance. There have also been times I've had to disable a cache as well. Upon enabling later, I put up an owner maintenance log as well.

 

-The Happy Hodag!

Link to comment

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons.

 

I did not have the slightest hope that GS will change something on the basis of this thread. Parts of the discussion might have an effect on the discussed special caches as maybe they could continue to exist with a sort of log tagging as has been suggested here.

 

What I found once again revealing is something which does not concern GS but cachers out there. When I read wishes like that all multiple logs should retroactively deleted (not that I believe that this will ever be implemented) just to allow some cachers e.g. to determine which event had the most participants makes me shudder and it is even worse if some of these requests come from people who are attached to statistics sites like project-gc and others as this might give them a higher priority at GS as they should have.

 

I'm missing the willingness to accept slight inconveniences as price of not destroying the enjoyment of others.

Link to comment

I'm missing the willingness to accept slight inconveniences as price of not destroying the enjoyment of others.

 

Absolutely priceless! :laughing:

 

Most if not all of your posts amount to your lack of willingness to accept slight inconveniences! And that of 'many' geocachers who apparently would rather throw in the towel than accept them.

 

Talk about double standards :ph34r:

Link to comment

I'm missing the willingness to accept slight inconveniences as price of not destroying the enjoyment of others.

 

Absolutely priceless! :laughing:

 

Most if not all of your posts amount to your lack of willingness to accept slight inconveniences! And that of 'many' geocachers who apparently would rather throw in the towel than accept them.

 

Talk about double standards :ph34r:

 

I guess you then misread my statements. I usually write either about my preferences or what I observe in the local community and not what I want the site to prescribe on others.

 

It's quite easy to make someone leave geocaching who is not any longer attached to it and who just keeps some caches for the enjoyment of others. There small things then can suffice to make yet another one leave.

Those who are still very attached to geocaching are rather in a position where one could hope that they are willing to accept compromises and also see the needs of others within the activity.

Link to comment

What you can't do is say: The event runs from 9 to 3. At 9 we hike for the top of the mountain. We plan to reach the top by 12, have lunch, then return. You can say: We have an event at posted coordinates from 8:30 to 9:00. If interested, you can join some of us on a hike following the event.

 

Or you can post an event at the top of the mountain at 12 and say in the description that for most people that would mean that a reasonable time to start is 9, and that you yourself plan to do that. You won't have the hike technically be a part of the event, but probably more people would take part in it than if the event was allowed to be both at the start and the end (since people would then not be able to just come to the start, log, and leave).

Link to comment

One key issue seems to be that GS does not have a way to educate cachers that enter caching via the apps and never use the website. This is something they should take care by redesigning the app and not by restricting those who have used the website for many, many years.

 

Except for in-app tutorials, which they have in the official app. The "problem" is people starting out with geocaching without help from anyone with experience, and without using the official app.

Link to comment

Anyway, I'm not personally as concerned about the NM log restriction - I could go either way on that particular one based solely on the definition of "Needs Maintenance". It's just the practice had never even occurred to me, to log NM on my own caches. Maybe I would have, dunno. But it just didn't make sense (to me) since owners are provided other means of identifying/dealing with their cache problems.

 

I'm not majorly concerned about it, I just don't understand it.

 

I see a NM has 2 main purposes:

 

1. To flag to the CO there is an issue needing attention.

2. To flag to cachers (who may want to find it) there is an issue needing attention.

 

As the CO already knows there is an issue, you could say there is no need to log a NM for #1. (Though it can still be a useful reminder). But case 2 is still is valid. If the issue is major, I'll disable the cache until I can fix it. But if the issue is minor, I might want to raise a NM.

 

Again not a big deal, but I can't see what the problem with allowing owners to raise NM is.

Link to comment

All of this back and forth, end of the day, nothing will change, just as what happened with the new map icons. I am sure rule #2 of HQ is stay away from the toxic forums.

 

That #2 rule is part of the problem. Whether GS reads the forums or not, the company routinely chooses to keep quiet and ignore its customers. I would say this is what gets the toxicity going a lot of the time.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...