Souvenirs don't get removed...

[team tisri]

You guys are going around and around and around about something that doesn't much matter. If you get a souvi that you don't want, then you can get rid of it. Problem solved.

 

The discussion is about souvenirs not being removed when a bogus log is deleted - the issue under discussion is how best to automatically remove souvenirs from people who no longer qualify to prevent cheating.

 

pssh... programmers don't care. It's a problem to solve. Even if it's never used, it's a thinking exercise, hones the logic centers of the brain ;D and it's fun!

 

... and for probably the first time in this thread I agree with you 100%

[+Corfman Clan]

You guys are going around and around and around about something that doesn't much matter. If you get a souvi that you don't want, then you can get rid of it. Problem solved.

 

pssh... programmers don't care. It's a problem to solve. Even if it's never used, it's a thinking exercise, hones the logic centers of the brain ;D and it's fun!

Too many programmers have a bad habit of over complicating the problem. That's what I see happening here. Also, if I have found a single cache in Oklahoma and get an Oklahoma souvenir, should the souvenir really be taken from me if the cache is moved to Texas? I would hope not since I did find a cache in Oklahoma.

[team tisri]

Not if there's a souvenir based on any other property. And rather than hard coding triggers for specific properties based on an ever-evolving list of souvenirs, queue the revalidation of all cache-data souvenirs for existing finders when a cache is edited.

 

Fair call, if we had a future souvenir based on finding different cache sizes in June it wouldn't just be down to location.

 

It could still be addressed by a quick check to say "what souvenir(s) does the new-look cache generate" and "what souvenir(s) does the the old-look cache generate" and if there's a difference any souvenirs not in both lists get revalidated.

 

Sure, prioritizing the queue could be a factor in the system. I wouldn't build in the 'run now' or 'queue for later' thing (imagine forum angst when someone sees that other users' souvenirs are updated before theirs so they're left waiting 'unfairly' =P) ok that's tongue-in-cheek. Anyway, point, prioritization of queued tasks is an independent function that can be implemented into the queuing system, rather than hard-coding two explicit options (run-now or add to queue).

 

Sure, I guess a very low-load process can be put in a fast-track queue.

 

"shouldn't" doesn't cut it for me. We don't know what souvenirs could be added in the future, and we don't know how complex the system is to run checks on existing souvenirs, other than the awarding; we also don't know how high they prioritized server tasks and where they'd put general re-validation in that list. So, regardless of whether it 'should' make a difference, I'd rather be objective and accommodate for worst-case, or near-worst-case at least. That means, by their admission that such a system would be a burden, I'd take that into account. Exponential potential increase in server load based on souvenir count, user count, and global logging activities.

 

Also a fair call - I'd been working with souvenirs as they are now rather than thinking of just how complex a souvenir they might think of in the future.

 

No see that's hard-coding in algorithms into the system logic for specific souvenirs, and means it's no longer self-contained and easily maintained. You could take it a step higher and say if the Location property is changed, then run Location-specific souvenirs, but again it depends on the existence of location-specific souvenirs; and cache type specific souvenirs; and cache size specific souvenirs; etc. My suggestion is at the next to highest level - cache-data specific souvenirs. Not a full algorithmic check to see that every cache-data souvenir should be rewarded, but only create the list of souvenirs that should be checked (reducing say 100's to 10's). Just as the meta-souvenir (user-profile data souvenir) list would reduced 100's to (at the moment) <10's, plus exclude checking those souvenirs for cache-data specific souvenir checks. etc.

Classify souvenirs on a large-scale grouping factor with minimal processing, so that the more intensive processing (explicit validation of souvenirs) occurs on a much smaller scale. And avoid hard-coding souvenir-specific checks and algorithms into the website functions itself.

 

I see no need to build full validation triggers on specific cache property edits, find log creations, find log edits, profile updates, plus allowing for triggers on any other future souvenir 'ideas' data updates.

 

I didn't word my comment about PA and OH very well. If it's processed with the questions "what souvenirs did the old version award" and "what souvenirs does the new version award" then only the ones that aren't in both lists need to be revalidated. So a cache moving from PA to OH would have "PA" on the first list and "OH" on the second, and so would revalidate both.

 

Queue users' souvenir validations based on souvenir relevancy to an action - cache update, log update, or profile update. Minimal alteration to the main web system, and addition of an independent optimized process to algorithmically check, as requested, souvenir lists.

 

Seems they have a 'terminology' issue between the intro app and the paid app as well. But my theory is they're testing the flexibility of the souvenir system as a system to potentially replace/augment the Challenge Cache concept.

Imagine being able to create your own <strike>souvenirs</strike> badges for completing a challenge cache you've set up? A CO could validate a user's Found It log and reward the badge. Or, potentially, a system to auto-check user stats for a custom algorithm based on your challenge, and reward the badge. (just thinking of this I can already imagine huge issues, but I'm just thinking out loud =P).

Point, it feels like 'souvenirs' are becoming a badge system for achievements; moving towards potential rewards in the region of the Challenge Cache idea.

 

That will probably just generate a whole load more angst if someone earns the souvenir/achievement/whatever-else-its-called-today for something like filling the D/T grid only to find a cache is changed and the souvenir disappears.

 

My idea somewhat addresses that.

If the souvenir is for finding a cache in VT, then it could be flagged log-specific but check cache data. On finding, the algorithm would reward it. If the cache were moved to a new state, the souvenir wouldn't be flagged for re-validation. If the user edited the log, it could be told not to revalidate since the data is not log-specific, only the trigger (even though the algorithm itself checks cache data).

If the souvenir is for find a cache in VT (minor distinction), then it could be flagged cache-specific. On finding, the algorithm would reward it. If the cache were moved to a new state, the souvenir would be flagged for re-validation.

 

How would you differentiate these if a cache moved? You'd need to be able to differentiate an "update coordinates" that meant the CO got the coordinates wrong, from "update coordinates" that meant the CO moved the cache to a different hiding place.

 

I missed correcting that point - "a validation check on all souvenirs" should be changed to (based on other points I made in the comment) "all relevant souvenirs" (after the classification).

 

So we're agreed on another point

 

Indeed, that's a good optimization option - defer the relevant souvenir filter scan so that a cache edit (1) revalidates the set list of relevant cache-data specific souvenirs, then updates that list based on the new cache data. The only issue would be new souvenirs created since last save. In that case, either a) GS creation of a new cache-specific souvenir needs to check itself against the entire database of caches and add to relevant caches, or on editing a cache, after finishing (1) it also checks against new souvenirs that were created since the last list update.

 

ugh, on second thought that's getting more complicated too. Merely by the size of the cache database. Keeping a dynamic list of relevant souvenirs to check per cache isn't clean-cut, as it needs to be synchronized with the list of existing and relevant souvenirs.

 

... which all seems to come back to the question of whether souvenirs have been properly thought through, or whether they started as a bit of fun and turned into a tangle of code because the whole thing just grew without any particular planning.

 

My only issue with real-time is that it requires hard-coding functions and triggers explicitly based on an ever-evolving list of souvenirs with no definable limit to qualifications. In an independent queued environment, it's self-contained and easily maintained; if there's a problem it can be disabled or removed with no loss. The only drawback is that it's not real-time

 

I think the idea of having high and low priority queues will address this. A high priority queue is probably sufficiently close to realtime processing - my concern was that a simple "do I still get the Kansas souvenir having deleted a Find log in Kansas" would be lost somewhere in the queue behind "this cache from 2001 just crossed the state line from Georgia into Alabama and now every single person who found it in the last 13 years needs two souvenirs revalidated".

 

Thinking through again, with a few changes...

Souvenirs:

* Trigger options: log/cache/profile update (independent flags; all could be set)

* Persistent? (rewarded at the trigger, or based on current data?)

* Validation Algorithm (function, returns whether souvenir should be rewarded or not for a user)

Cache:

* On create/edit, trigger function: retrieve finder list, queue validation of users' triggered-by-cache-update souvenirs, if not already queued

Logging:

* On create/edit/delete, trigger function: queue validation of user's triggered-by-log-update and triggered-by-cache-update souvenirs, if not already queued

Profile:

* On any profile property update (not stats), trigger function: queue users' triggered-by-profile-update souvenirs, if not already queued

 

On execution from queue:

* Retrieve list of relevant souvenirs to revalidate (by supplied trigger - log/cache/profile update)

* Reduce to souvenirs that are Persistent, or not yet rewarded for the user (souvenirs both persistent and rewarded shouldn't be removed)

* Execute the validation algorithm for each souvenir (don't change the user's custom-set visibility flag if the souvenir is already rewarded)

* If any souvenir was rewarded or removed, queue the user's triggered-by-profile-update souvenirs

 

Optional:

* profile triggered souvenirs could be classified further to souvenir-triggered souvenirs, since that trigger would only occur after validating (and altering) a user's souvenir list.

 

Note:

* log-triggered souvenirs would be for souvenirs exclusively based on find log properties (eg Date). cache-triggered souvenirs would also need to be triggered with log post/edit/delete.

Example: Cache found in VT would be flagged as cache-specific, but triggers cache-souvenirs when Found by the user. If cache is moved to NH, cache-triggered souvenirs are queued for all current finders; if find log is edited to not found, cache-souvenirs are queued for that user.

Example: Cache found within 10km of Eiffel Tower flagged as cache-specific (by Location). Log posted as DNF mistakenly; edited to Found, cache-souvenir check is queued for that user. If moved beyond 10km, cache-triggered souvenir check is queued for all finders, unless marked as Persistent (once-off reward).

Example: Cache found 1.2km from Eiffel Tower flagged as cache-specific (by Location). User logs as found, cache-souvenirs triggered for check; but souvenir not rewarded (interestingly, this souvenir check does even occur in the current system for finds worldwide; but actions are filtered out likely first based on Country; that is, if I post a Find on a cache, the current real-time action checks all souvenirs to see if any are relevant; including this Eiffel Tower one, were it to exist). If cache moved within 1km of Eiffel Tower, cache-souvenir check is queued for all current finders.

* Remember: a check for a user based on a trigger is only queued once - multiple enqueue calls doesn't add stress to the system, or lengthen the time before souvenir validation. Calling a full cache-specific souvenir revalidation scan on a single cache edit isn't excessive - queuing the request actually trades the current real-time check for fewer souvenir algorithm calls.

 

Seriously, I'm kind of wanting to build this system now

 

I was loosely thinking about an extra table linked to the logs table, so that each log could store what souvenir(s) it generated. So my list of souvenirs would be little more than "select distinct souvenir.name from logs, souvenirs where logs.logid = souvenirs.logid and logs.username = 'team tisri'". That would address issues relating to editing or deleting a log, and if a cache changed any souvenir updates could be rippled through based on finding logs associated with the cache and updating the souvenir(s) associated with each log.

 

If extra information about the cache were saved and associated with the log it would also overcome the issue of people filling their D/T grid only to have a cache rerated and a gap appear. Of course the flipside is that it would let people cheat by creating a liar's cache and constantly changing the D/T rating while finding it once for each combination. That would want some form of sanity check to see how many times the cache had been found before.

 

It's certainly interesting to think about how the assorted side games could be processed, although it inevitably requires making some assumptions about how the database is structured. I just figure things based on how I'd structure it, with tables for things like users, caches, logs etc.

[team tisri]

You guys are going around and around and around about something that doesn't much matter. If you get a souvi that you don't want, then you can get rid of it. Problem solved.

 

pssh... programmers don't care. It's a problem to solve. Even if it's never used, it's a thinking exercise, hones the logic centers of the brain ;D and it's fun!

Too many programmers have a bad habit of over complicating the problem. That's what I see happening here. Also, if I have found a single cache in Oklahoma and get an Oklahoma souvenir, should the souvenir really be taken from me if the cache is moved to Texas? I would hope not since I did find a cache in Oklahoma.

 

That's one of the issues we're discussing. If the coordinates move the the souvenirs would be processed differently based on whether the coordinates were updated because they were wrong (i.e. it was always in Texas but incorrectly listed as being in Oklahoma) or because the cache moved (i.e. it was in Oklahoma and when it was moved 100 feet to a better hiding spot it happened to cross into Texas).

 

In the first situation you shouldn't have an Oklahoma souvenir and should have Texas, in the second your Oklahoma souvenir should be preserved.

[+Corfman Clan]

That's one of the issues we're discussing. If the coordinates move the the souvenirs would be processed differently based on whether the coordinates were updated because they were wrong (i.e. it was always in Texas but incorrectly listed as being in Oklahoma) or because the cache moved (i.e. it was in Oklahoma and when it was moved 100 feet to a better hiding spot it happened to cross into Texas).

 

In the first situation you shouldn't have an Oklahoma souvenir and should have Texas, in the second your Oklahoma souvenir should be preserved.

Do you realize that the cache's coordinates have nothing to do with what state it is in? It's all up to the cache owner to specify the state. For example, I can hide a cache in Arizona and set the state to Maryland.

Edited August 21, 2014 by Corfman Clan

[jholly]

Do you realize that the cache's coordinates have nothing to do with what state it is in? It's all up to the cache owner to specify the state. For example, I can hide a cache in Arizona and set the state to Maryland.

 

Now you done it.

[+thebruce0]

1. Re: cross-reference tables generated as of a date for quick souvenir lookups - the problem is they need to be constantly synchronized, or when scanned the process also needs that as-of date to check 'new' souvenirs. More data to manage, rather than just an optimized sequence of functions.

2. -New- souvenirs need to be addressed as well. If GS creates a new souvenir, should it trigger an automated scan of every single user's qualifications? Because depending on its relevance, it would be revalidated as soon as user's queue is executed. (GS dealt with this when first creating country/state souvenirs - complaints about people getting, getting delayed, or not getting souvenirs for past finds, for example). Rather, if it's a new cache-specific souvenir that was just created, then the system could enqueue all users' revalidation of cache-souvenirs. It would only append the users who aren't already queued up for revalidation. No additional overhead, and piggybacking on the existing system -- a passive souvenir creation that's already programmed to eventually filter in to every user's stats. As opposed, again, to creating specific hard code within the main site's general functions (as with editing cache data, or logs, etc)

 

if we had a future souvenir based on finding different cache sizes in June it wouldn't just be down to location.

 

It could still be addressed by a quick check to say "what souvenir(s) does the new-look cache generate" and "what souvenir(s) does the the old-look cache generate" and if there's a difference any souvenirs not in both lists get revalidated.

I see this is an adjustment to perhaps the set of souvenir classifications. That is, where log/cache/profile triggers represent the only hard-code inserts to the main site, the souvenir-trigger class is an example of another potential hard-coded trigger. So yes, it could be possible to write specific triggers for cache Location, Type, Size, etc. Based on the followup steps I outlined in my last post, the same results would occur, but with tighter filters -- if changing a cache location, then instead of queuing a check on all cache-specific souvenirs, it would only queue a check on all cache-location-specific souvenirs. I can grok that. Because the queuing structure would allow for that level of additional precision with minimal impact to processing (just an additional hard coded trigger)

 

I didn't word my comment about PA and OH very well. If it's processed with the questions "what souvenirs did the old version award" and "what souvenirs does the new version award" then only the ones that aren't in both lists need to be revalidated. So a cache moving from PA to OH would have "PA" on the first list and "OH" on the second, and so would revalidate both.

Fair enough. One property I did almost add in my last post, but decided to remove because it seemed extraneous, was an additional function to determine relevancy of a souvenir to its trigger class. Currently, an edit would trigger queuing to check a class of souvenirs (log/cache/profile) for a user - not specific souvenirs. The queue request then wouldn't include which data update triggered the request (and can't, really, unless you keep another list of related actions that triggered the request, until the queued request is handled, since the trigger class is only queued once). My thought was that, as you said, on editing a cache, it could determine which specific souvenirs should be rechecked for the current finders. But if that's so, then the queue needs to include a reference to the edited cache so when it's executed it'll know how to determine if the souvenir should be checked.

That sounds backwards...

 

Ok, wait... It is still possible. So if the souvenir has a Relevance function that's called before and after saving the changes, then before adding the cache-triggered check to the queue, it would know whether that's even necessary.

Sample relevance function on one souvenir: A cache(-location)-souvenir for a find 10km from the Eiffel Tower would check that the GPS coordinates of the cache are within x/y degrees/minutes of its GZ. If not, that's a quick verification that the souvenir is not relevant to the cache. That knocks out 99.9% of cache edits queuing up a souvenir check for all its users. Do that for each cache(-location)-souvenir, and we'd know whether any souvenir re-check is in order for its finders.

Let's even add in your cross-reference data for cache souvenirs so the functions don't have to be called twice (old/new)...

 

Example process for saving a cache:

1) save the updated cache, note what data has changed (which triggers are relevant; in this example, location),

2) if a list of past/current relevant souvenirs exists for the cache, use it (if not, eg cache creation, all current relevant souvenirs will be checked in the next step and considered 'new'), then

3) loop through applicable cache(-location)-triggered souvenirs, calling the relevance function for each on the new data. If there is any difference between old and new relevant souvenirs, then queue all finders' cache(-location)-souvenirs check.

So, per your example, moving a cache within the same state will filter by relevance to only the souvenir for that state, an unchanged relevance and so ignored, and won't trigger a souvenir re-check for anyone. Moving a cache so it's in a different state will show the old state souvenir differing from the new state souvenir, and trigger a cache(-location)-souvenir re-check for all finders, eventually correcting both states' souvenirs.

 

How would you differentiate these if a cache moved? You'd need to be able to differentiate an "update coordinates" that meant the CO got the coordinates wrong, from "update coordinates" that meant the CO moved the cache to a different hiding place.

I don't think there's a way to get around that. Not unless you implement a 'revalidate souvenirs' option when saving a cache as a CO. There's no way to know if a CO made a 'mistake' or physically moved a cache. That would be a downfall of the system that I think would have to be fundamentally accepted, and I'm sure long ago GS decided not to care whether a cache update was due to a mistake or a physical move.

 

If extra information about the cache were saved and associated with the log it would also overcome the issue of people filling their D/T grid only to have a cache rerated and a gap appear. Of course the flipside is that it would let people cheat by creating a liar's cache and constantly changing the D/T rating while finding it once for each combination.

If that DT grid souvenir is saved as Persistent - ie, a once-off accomplishment - then revalidation wouldn't remove it once earned. A cache's DT altered leaving a hole wouldn't take that souvenir away from people. Not an issue. Also, the user stats will show what the current collection of their found caches' DT grid is at. In theory, you could compare your Find Stats' DT grid with your souvenirs, and determine if caches have been changed causing you to 'unqualify' (or qualify unexpectedly) for the fizzy . If you previously qualified, you'd have the souvenir badge even if your stats show a hole (presuming your queue executed before the CO changed the offending cache's DT).

[+thebruce0]

Do you realize that the cache's coordinates have nothing to do with what state it is in? It's all up to the cache owner to specify the state. For example, I can hide a cache in Arizona and set the state to Maryland.

 

Now you done it.

 

 

d'oh... yes. Well then, still irrelevant. The souvenir would be based either on GPS location or State (I don't believe any current state/country souvenirs are therefore based on GPS location ). The discussion point about the process still remains feasible

Edited August 21, 2014 by thebruce0

[+thebruce0]

Thinking about it... I'm starting to think that here should not even be an automated removal of souvenirs.

 

Did you find a cache in VT? Look at your stats. No, yet you have a souvenir? Then one must have been moved out of VT.

 

Souvenirs and stats provide different views of your caching career. Souvenirs really are rewards for accomplishments as of the date you accomplish them. They're once-off rewards, not a live view of your data. Want to see if someone's lying or 'cheating'? Compare their souvenirs to their stats (if they're public).

 

At most, perhaps a 'revalidate' button to clean up and potentially remove a souvenir (as opposed to hiding it) if you don't want it there. Otherwise, what do souvenirs really represent? That you accomplished what was required to earn it, at least once, at some point.

The 'live' view is your stats.

 

So that leaves the problem of 'cheaters'. If you want to question whether a user actually found a cache on August 31st, well you can check their find stats. If not, then you know they fibbed their stats to get the souvenir. And then, does it really matter to you that they're showing it, if you know that they've cheated the system to get it?

 

All this chat - are we creating a reward system, or are we creating a live statistics view?

 

It's not like someone winning a medal after a race, then a judgement call voiding it so the medal is taken back -- there only one person can get the medal. Not so with souvenirs.

It's more like a teacher handing out valueless (not priceless =P) ribbons to everyone who was in attendance at an event, then someone who wasn't coming along after the fact and grabbing an extra. They could brag to other friends that they were there because they got the ribbon, which would be a lie, but everyone who was there knows that they weren't and could easily refute it.

 

Now if the ribbons/souvenirs had some inherent monetary/trade-in value at some point in the future, that would be different. But as it is, they are just images on your profile.

 

So yeah, if they really wanted to, they could create a Revalidate button in your profile. They could also potentially create a souvenir 'checker' that visitors to your profile could, say, click a souvenir and the system would confirm whether it's still valid. But that seems like it would be encouraging angst and profile policing. Unnecessary drama.

Certain souvenirs can be compared to a user's stats. I think that's all that would be needed.

 

I dunno, I think I'm moving now over to the side that we should just leave the stats as the 'live view', and souvenirs as once-off rewards for accomplishments. Set aside any angst and don't care about the cheaters. Their find stats will say if they're cheating. Unless they lie in their finds (like log dates), and that already happens all the time... *shrug*

[team tisri]

That's one of the issues we're discussing. If the coordinates move the the souvenirs would be processed differently based on whether the coordinates were updated because they were wrong (i.e. it was always in Texas but incorrectly listed as being in Oklahoma) or because the cache moved (i.e. it was in Oklahoma and when it was moved 100 feet to a better hiding spot it happened to cross into Texas).

 

In the first situation you shouldn't have an Oklahoma souvenir and should have Texas, in the second your Oklahoma souvenir should be preserved.

Do you realize that the cache's coordinates have nothing to do with what state it is in? It's all up to the cache owner to specify the state. For example, I can hide a cache in Arizona and set the state to Maryland.

 

If that's the case (I've never hidden a cache in the US) then it becomes easier still to process.

[team tisri]

Thinking about it... I'm starting to think that here should not even be an automated removal of souvenirs.

 

To be perfectly honest I think the best solution is to get rid of the souvenirs completely.

 

It seems to me that what Groundspeak need to do is encourage people to hide good caches, and go out looking for caches. Souvenirs might be interesting if you've found caches when travelling but if the only reason to go and find a cache in Istanbul is to get the souvenir then it doesn't say much for the caches in Istanbul.

 

If people are caching and enjoying it they don't need souvenirs. As it stands the souvenirs seem to do little more than seek to temporarily modify behaviour to get a gold star. Perhaps a souvenir will encourage people to try a puzzle cache even if they don't normally do puzzles, but they will also encourage people to put out a few easy puzzles so people can get the souvenir. So even ignoring those who brazenly cheat to get the souvenirs, they reward all sorts of behaviours that aren't necesarily what might be considered ideal. Last year when we had the "31 days of August" souvenirs I read of an area where people held a flashmob event every day so people could qualify for all the souvenirs. Is that really what they were designed to achieve?

 

Souvenirs and stats provide different views of your caching career. Souvenirs really are rewards for accomplishments as of the date you accomplish them. They're once-off rewards, not a live view of your data. Want to see if someone's lying or 'cheating'? Compare their souvenirs to their stats (if they're public).

 

The live stats make some sense for those inclined to look at them. The souvenirs seem to be little more than a bunch of icons related to the maps, and a few extras for caching on particular days. As you say, there's no way to know if people found a cache on the day they said they found it, it's pretty simple to log a cache on a specific day even if you found it on a different day, so they really serve no purpose. Is it really an accomplishment to find a cache on August 16, as opposed to finding the same cache on the 15th or 17th?

 

All this chat - are we creating a reward system, or are we creating a live statistics view?

 

This comes back to the question of what the souvenirs are intended to be. The more I look at what they do the more I think they're an idea that may have started out as an interesting idea but rapidly dropped into the quagmire of mediocrity of being associated with specific days, people cheating to "earn" them and little if any way to verify them.

 

I dunno, I think I'm moving now over to the side that we should just leave the stats as the 'live view', and souvenirs as once-off rewards for accomplishments. Set aside any angst and don't care about the cheaters. Their find stats will say if they're cheating. Unless they lie in their finds (like log dates), and that already happens all the time... *shrug*

 

Truth be told I never even look at souvenir pages, either my own or anyone else's. It seems they represent an "achievement" that is easy to cheat and impossible to verify, they serve no purpose and add no value, so I'd go a step further and do away with them completely.

[+thebruce0]

It seems to me that what Groundspeak need to do is encourage people to hide good caches, and go out looking for caches. Souvenirs might be interesting if you've found caches when travelling but if the only reason to go and find a cache in Istanbul is to get the souvenir then it doesn't say much for the caches in Istanbul.

Well, some people really like to get their passport stamped if possible when they travel to other countries. Doesn't mean they don't care about the country or what it has to offer; they just want that stamp

 

Last year when we had the "31 days of August" souvenirs I read of an area where people held a flashmob event every day so people could qualify for all the souvenirs. Is that really what they were designed to achieve?

But did that go against what they were trying to achieve? Or were they just trying to achieve that people go out and have fun doing geocaching-related things every day for a month? ...with the reward being a badge in their profile? If that's the case, what does it matter to anyone how the badge was received? *shrug*

 

This comes back to the question of what the souvenirs are intended to be. The more I look at what they do the more I think they're an idea that may have started out as an interesting idea but rapidly dropped into the quagmire of mediocrity of being associated with specific days, people cheating to "earn" them and little if any way to verify them.

Exactly. Are they "souvenirs" (implying visiting places), or achievements (accomplishing tasks or sets of tasks)?

 

Truth be told I never even look at souvenir pages, either my own or anyone else's. It seems they represent an "achievement" that is easy to cheat and impossible to verify, they serve no purpose and add no value, so I'd go a step further and do away with them completely.

Whereas to me, they don't harm anything; only cause angst to those who let them cause themselves angst. But they encourage people to get out and accomplish other types of goals. So really the net is positive, imo. They just need to do what they do best, and not try to be things they're not just because they can, muddying up the essence of what they are.

[jholly]

[+The A-Team]

This comes back to the question of what the souvenirs are intended to be. The more I look at what they do the more I think they're an idea that may have started out as an interesting idea but rapidly dropped into the quagmire of mediocrity of being associated with specific days, people cheating to "earn" them and little if any way to verify them.

Exactly. Are they "souvenirs" (implying visiting places), or achievements (accomplishing tasks or sets of tasks)?

I think they started out as souvenirs (e.g. for visiting countries, Mega events, specific notable caches), but now they're nothing more than a marketing tool (e.g. 2013/14 August campaigns, Maker Madness).

 

If this is all they're going to be used for going forward, it would probably be best if they just went away. Then the developers could spend their time making the website work...

[+NYPaddleCacher]

 

Truth be told I never even look at souvenir pages, either my own or anyone else's. It seems they represent an "achievement" that is easy to cheat and impossible to verify, they serve no purpose and add no value, so I'd go a step further and do away with them completely.

 

Although the trend has gone from the initial campaign of geocaching souvenirs mimicking real life souvenirs (as a token of remembrance for visiting some place or doing something unique) to more achievement based, but if you look in the "Bring back country based souvenirs" or the Country Collectors thread or many threads in the All Nations forum and elsewhere you'll see lots of people asking why they didn't get a souvenir for visiting a new country. Those that know why are asking for more country based souvenirs.

 

If you don't care about souvenirs, as you say, you never have to look at your souvenirs page. But a lot of people *do* care.

 

Who are you to state what has value to another person. Some people collect rocks. Some people collect shot glasses or fridge magnets. I don't collect any of those things so someone elses collection of whatever has no value to me but I'm not about to tell someone else that *their* collection has no value and serves no purpose. I'm not about do dump a handful of gravel from my driveway into someone elses rock collection because their collection of rocks has no value to me.

 

Does a photograph have value? Any pictures you have of your family have not value nor serve not purpose to me. You should delete any pictures you have our your family off your computer and put all paper photos in a recycling bin so that they can be recycled and turned into paper bags; something that would actually be useful.

 

[+frinklabs]

If you don't care about souvenirs, as you say, you never have to look at your souvenirs page. But a lot of people *do* care.

 

I care.

 

The souvenirs were incidental to any caching I was already doing. However, when I was looking at some of those I had collected, one stuck out over the others -- it actually reminded me of the caching I did that day.

 

This is the souvenir for 18 August:

 

 

And this is a picture from the gallery of one of the caches attended that day:

 

 

I didn't take that picture -- I haven't a waterproof camera and I was afraid to extract my iPhone from the nested series of baggies into which it was secured while we were in the canoe. But we did encounter a mother duck and ducklings, and a bunch of other waterfowl.

 

While any paddle cache is memorable, that day was in my top three for sure. My daughter actually volunteered that she was having a good time without being asked. My sister, who only recently became hooked on the caching, got her very first FTF, on a 5/5 cache whose puzzle she solved. It was neat to see how excited she was -- I didn't know that this was the first time she had ever paddled!

 

Best. Day. Ever.

 

A musician's paddle

A quiet paddle

[+NYPaddleCacher]

The souvenirs were incidental to any caching I was already doing. However, when I was looking at some of those I had collected, one stuck out over the others -- it actually reminded me of the caching I did that day.

 

 

And that, to me, *should* be the whole point of souvenirs.

 

A souvenir, by definition, is a token of remembrance. It's not the souvenir (whether physical or digital) that has value. The value comes from the memories they induce. Like others I've thought that the August souvenirs (especially last years) were more of a marketing promotion (for the benefit of GS) than anything else. Thanks for showing me that a bunch of pixels with "August 18" on it can still be meaningful to someone.

 

 

 

 

[+thebruce0]

A souvenir, by definition, is a token of remembrance. It's not the souvenir (whether physical or digital) that has value. The value comes from the memories they induce. Like others I've thought that the August souvenirs (especially last years) were more of a marketing promotion (for the benefit of GS) than anything else. Thanks for showing me that a bunch of pixels with "August 18" on it can still be meaningful to someone.

+1

[team tisri]

 

Truth be told I never even look at souvenir pages, either my own or anyone else's. It seems they represent an "achievement" that is easy to cheat and impossible to verify, they serve no purpose and add no value, so I'd go a step further and do away with them completely.

 

Although the trend has gone from the initial campaign of geocaching souvenirs mimicking real life souvenirs (as a token of remembrance for visiting some place or doing something unique) to more achievement based, but if you look in the "Bring back country based souvenirs" or the Country Collectors thread or many threads in the All Nations forum and elsewhere you'll see lots of people asking why they didn't get a souvenir for visiting a new country. Those that know why are asking for more country based souvenirs.

 

If you don't care about souvenirs, as you say, you never have to look at your souvenirs page. But a lot of people *do* care.

 

Who are you to state what has value to another person. Some people collect rocks. Some people collect shot glasses or fridge magnets. I don't collect any of those things so someone elses collection of whatever has no value to me but I'm not about to tell someone else that *their* collection has no value and serves no purpose. I'm not about do dump a handful of gravel from my driveway into someone elses rock collection because their collection of rocks has no value to me.

 

Does a photograph have value? Any pictures you have of your family have not value nor serve not purpose to me. You should delete any pictures you have our your family off your computer and put all paper photos in a recycling bin so that they can be recycled and turned into paper bags; something that would actually be useful.

 

The analogy breaks because the time spent fiddling with souvenirs is time that could be spent doing something more useful (as The A-Team said making the website work would be a far more useful activity).

 

If I collect shot glasses it makes no difference to you, but if Groundspeak spends more time fussing about with souvenirs and less time making things work and introducing new features that affects us all. To use your analogy it would be more akin to me collecting shot glasses if we shared a house, and you finding yourself with inadequate storage space because it was filled with my shot glasses.

 

I'm sure some people like their souvenirs. Someone already mentioned how a souvenir reminds them of the caching they did that day. I won't dispute that some people do think that way, but I don't think a single one of my souvenirs reminds me of anything in particular. Maybe the one that comes closest is my Kentucky souvenir, although I remember the Eagle Falls and the Cumberland Falls well and have only a vague memory of finding an ammo can somewhere on the trail.

[+frinklabs]

if Groundspeak spends more time fussing about with souvenirs and less time making things work and introducing new features that affects us all.

Someone already mentioned how a souvenir reminds them of the caching they did that day.

 

 

For the record, in this greater context, I would trade 100 of those souvenirs (whose memories they trigger I still have regardless) for implementation of the long-overdue Ghost Trackable feature.

[+thebruce0]

The analogy breaks because the time spent fiddling with souvenirs is time that could be spent doing something more useful (as The A-Team said making the website work would be a far more useful activity).

And of course we all know that every programmer on staff at Groundspeak is working on the exact same single thing at any one time...

[+ecanderson]

And of course we all know that every programmer on staff at Groundspeak is working on the exact same single thing at any one time...

It's a question of resource allocation. With the number of more pressing issues that could be addressed that impact a far greater number of their customers, one might question the entire souvenir plan.

 

It would be interesting to know how the team is constructed at Groundspeak, and what resources (and quality of resources in terms of experience and depth of knowledge about systems like this) are actually at their disposal.

[team tisri]

The analogy breaks because the time spent fiddling with souvenirs is time that could be spent doing something more useful (as The A-Team said making the website work would be a far more useful activity).

And of course we all know that every programmer on staff at Groundspeak is working on the exact same single thing at any one time...

 

I'm sure there are enough features in the suggestions list that are languishing in the black hole officially known as the "to do list" that a fair few developers could be doing useful stuff.

[+mike/kath]

Have a slightly weird souvenir issue. A souvenir showed up for Illinois on my souvenirs. Found out when a friend asked me about it. The day I supposedly received it, we were caching in Woodbridge Ontario and definitely did not log a cache in Illinois. Is it possible to remove it. If I "hide" it it just goes pale.

[Keystone]

You recently logged a find on a cache in Illinois. Therefore, you received the Illinois souvenir. Assuming this was a logging mistake, you can hide the souvenir so that a third party cannot see it displayed on your profile.

[+ecanderson]

They probably meant to log GC3CJZB instead of GC3CZJB, though that's still a bit away - closer to Hamilton.

[+EngPhil]

They probably meant to log GC3CJZB instead of GC3CZJB, though that's still a bit away - closer to Hamilton.

GC4M20C "Bond; Lake Bond." instead of GC3CZJB "Bond, Lake Bond".

[+mike/kath]

You recently logged a find on a cache in Illinois. Therefore, you received the Illinois souvenir. Assuming this was a logging mistake, you can hide the souvenir so that a third party cannot see it displayed on your profile.

[+mike/kath]

Thanks. Mystery solved. I had logged Bond,Lake Bond in Illinois instead of Bond;Lake Bond in Oak Ridges Ontario. Hmmm. Best to look at GC code. I was a bit mystified about a travel coin not showing on the cache page even though it was shown on tb page as being in the cache. First time I've created that kind of confusion.