Log Of The Reviewer Published

[ju66l3r]

Having the name of which reviewer is helpful also.  I have seen where a cache was placed on private property and the cachers were able to quickly let the reviewer know and get the situation under control.

That was already available. It is called an SBA log.

That does work most of the time. In this case I was filling in for a reviewer on vacation, so I would not get the SBA notification for her state. Also, folks do not always post SBA logs. In this case there were 3 notes posted, no SBA, and an e-mail to myself and the owner.

Yes, users do not always use the tools given to them appropriately. Of course, I could also reiterate comments I have made in the past about how things go from development to active here without much attention being brought as to how they work/what they are for/how to get best utility...even more so if you are one of the thousands of users who never enters the forums. (For example, how come this hasn't been announced on the front page "New Log Type!").

 

Beyond that, I'm also in agreement with some of the sentiments above that the "Approved by: XYZ" line that hiders see but users don't could have been uncovered any time in the past (with the XYZ linking to the approver's profile/e-mail) and the same utility of providing a second way of immediately alerting the reviewer to a problem without adding a lame visible one word "published" log. (Add the date of approval to satisfy Prime Suspect's point)

 

Of course, if we're looking to make sure approvers, reviewers, and owners are notified immediately when there's a BIG problem, it would seem like the better implementation would be some sorta "smash glass, pull lever" method for reporting an errant cache that sets off a spinning red light in every reviewer's house. Oh, wait, it's just tupperware in the woods...right.

[Jeremy]

So are you upset that the action of publishing a listing is in the form of a log entry? Or are you upset that it isn't pretty.

 

I don't think it was necessary to announce that there is a new "publish" log type. I did, however, announce far beforehand to the developers so they could implement it in their software.

 

We do receive feedback from a smaller audience before implementing a feature. We do not, however, announce all features to the forums for feedback.

[ju66l3r]

So are you upset that the action of publishing a listing is in the form of a log entry? Or are you upset that it isn't pretty.

 

I don't think it was necessary to announce that there is a new "publish" log type. I did, however, announce far beforehand to the developers so they could implement it in their software.

 

We do receive feedback from a smaller audience before implementing a feature. We do not, however, announce all features to the forums for feedback.

For me, the answer to your first question(s) is "Both". I'm not clear on the necessity of a "log type" for it and it doesn't seem like a "loggable" action. The online log has been for the most part a reflection (however incomplete for some reasons) of the in-cache log. From a user interface/perspective, it seems akin to expecting someone to count to 10 and hearing them go "0, 1, 2, 3...". The fact that I (not the hider and system) can see the cache page means "it's published".

 

It's something that's only in place as a technicality of function (as a log) because as has been pointed out, there are other ways already included in the site backend and frontend for knowing that something has been approved/published.

 

As for announcing it, I don't see why *not* to announce it. At best you've saved 10 minutes typing up the announcement...just to have a 50 reply forum topic on it and who knows how many non-forum users scratching their heads as to why the approver keeps using this new log icon and why they can't delete it to clean up their log pages (and a pile of questions that will arise that I can't even dream up).

 

Whether you announced it or not for feedback, it seems your going to get it anyways because that's the nature of this forum and the community who use it, know it. Simply announcing it on the main page will help keep users (primarily non-forum ones) apprised of new things they run into and help them keep track of what's going on with the website since last here. Psychologically, it helps foster a sense of "oh look at that, new!" which keeps users returning to see the next "new". I would guess that 3-5 times more people will browse/read a changelog than a terms of use.

 

If the user will never see it (backend development), then yes, it's probably not necessary to announce it (although developers still like to hear those sorts of things). If the users can see it, it's best if you introduce it rather than having it tripped over.

[+mini cacher]

Well said!

 

Current implimentation:

Reviewer marks cache as "approved" -> approval triggers "Published" log -> "Published" log triggers notification of new cache

 

Is there a technical issue that prevents cutting out the middle step like this:

Reviewer marks cache as "approved" -> approval triggers notification of new cache

 

Regardless of the announcment or not... the feature exists and that opens it up for comment. If you do not wish to receive user comment on the site and the features therein, then that should be stated clearly somewehre. If you do wish to receive user comments, then users should not be expecting a swift kick to the eggs for offering such comment. I think it is great that there is the new notification feature. It should prove to be quite useful. I only have a problem with the seemingly useless "Published" log when on the surface it looks like it could have been accomplished without the "wart" (as it has been refered to).

 

At the risk of boring some people, I would think a more technical answer is in order here. Obviously this need not reveal any super-secret voodoo that makes up the backbone of the system.

Edited August 2, 2005 by mini cacher

[+Renegade Knight]

...We do not, however, announce all features to the forums for feedback.

But you get it soon enough just the same.

[Jeremy]

Regardless of the announcment or not... the feature exists and that opens it up for comment. If you do not wish to receive user comment on the site and the features therein, then that should be stated clearly somewehre.

Umm... I never said anything about not wanting comments. In fact I thanked folks for making comments in another thread (which makes more sense than the OP in this one). To clarify I was responding to the claim that we release functionality without a peer review. We just don't have the forum participants in the initial peer review. If anything you guys are testing it now... right?

 

Like the enabled/disabled log types and the archived/unarchived log types, the published/retracted log types are actions, much like "found it" on so and so date or "Dropped" or "picked up" for travel bugs. They're part of the history of the listing and is an important part of the history for that listing.

 

As for publish/retract being a log type, I still haven't really seen a true justification as to why this isn't the "right way" (whatever that magic spot is). It seems to work quite well actually. However, the true issue is that the current way that logs are shown on cache listings need a major overhaul and should mimic how travel bug logs look. That way we can remove the "Published" text since the log entry itself (as shown in notify emails) is descriptive enough.

 

As I stated before I have been implementing it as part of a "soft" release and as of yet have not announced it to anyone. I'm currently just responding to folks who have happened to find it. Thanks to the feedback I am making adjustments and fixes before announcing it to the rest of the community.

 

I occasionally forget that ju66l3r is not a Premium member, so a lot of this won't make much sense anyway since the feature is not available to regular members. Thanks for the non-PM perspective.

[+The Leprechauns]

I will try again.

 

The notification service is based on log types. Right now, everyone's focused on the "Published" log type, because in the initial beta testing rollout, that's what users can sign up to receive notifications about. But there are many other log types. Wouldn't it be cool if you received notifications of "will attend" logs on an event cache in your area, so that you'll know that your friends from 50 miles away will be driving in for the event? If yes, select a notification for "event caches" and a log type of "will attend."

 

That functionality is not available now, but if you read this post in the main thread about Insta-Notify, you'll see that there are future plans to expand the feature. This is why you are asked to select just one cache type for each notification, because the available log types will vary from one cache type to the next. (Will attend, attended, webcam photo taken, etc.)

 

So, if you have a feature that is triggered off of log types, a way to make that feature work for brand new listings is to have a log type associated with a brand new listing. It's called "Published." So, you could have a notification set up for "Traditional" caches with log types of "Published," "Disabled," "Enabled" and "Archived," for example.

 

Anyways, that is how I understand it from reading the other thread.

[+Prime Suspect]

I'm not clear on the necessity of a "log type" for it and it doesn't seem like a "loggable" action. The online log has been for the most part a reflection (however incomplete for some reasons) of the in-cache log.

Quite a while ago, Jeremy stated he was moving towards the "permalink" model that many blogs use. If you think of it as an "activity record" rather than a "log", it makes more sense. Like a permalink, every log has a globally unique identifier attached to it, that never changes. Every action that happens to the cache is reflected with an activity record (i.e., log), such as user-submitted logs, cache disabling, enabling, archiving, unarchiving, etc. The one major event that hasn't been reflected in a log up to this point, was the publishing of the cache.

 

Why should this event should be handled differently than the others?

[Jeremy]

That's a good explanation. For clarification anything that changes the "state" of the listing should have an action assigned to it. Publishing a listing makes it go from a queued listing to a viewable one. We're just one step closer to that goal.

[+mini cacher]

my appologies for misreading your comment "We do receive feedback from a smaller audience before implementing a feature. We do not, however, announce all features to the forums for feedback."

 

Its just that we already had the info on the status of a cache already available. From my point of view, this new log type adds absolutely no more info that wasn't already (or couldn't have been) made available some other way.

 

Let's take it one step further and add a "Hidden" log that gets automatically inserted at the time the cache enters the system. It's no more or less redundant than the "Published" log

[Jeremy]

my appologies for misreading your comment "We do receive feedback from a smaller audience before implementing a feature. We do not, however, announce all features to the forums for feedback."

Sorry. I meant "pre-announce" - which is sort of this topic and the last one anyway

 

Its just that we already had the info on the status of a cache already available.  From my point of view, this new log type adds absolutely no more info that wasn't already (or couldn't have been) made available some other way.

 

No. Prior to the new log type there was no timestamp when the listing was published or by whom. Sometimes listings are re-published by new reviewers as well, so the usernames may or may not match.

 

Let's take it one step further and add a "Hidden" log that gets automatically inserted at the time the cache enters the system.  It's no more or less redundant than the "Published" log

 

Good point. We'll consider that.

[+Hemlock]

Let's take it one step further and add a "Hidden" log that gets automatically inserted at the time the cache enters the system. It's no more or less redundant than the "Published" log

If the hider enters anything in the "note to reviewer" field on the submission form, a new log *does* get created.

 

I'm baffled as to why a few people are so vocally against this new "published" log. I would think there are more important things to worry about.

[+mini cacher]

Let's take it one step further and add a "Hidden" log that gets automatically inserted at the time the cache enters the system.  It's no more or less redundant than the "Published" log

If the hider enters anything in the "note to reviewer" field on the submission form, a new log *does* get created.

 

I'm baffled as to why a few people are so vocally against this new "published" log. I would think there are more important things to worry about.

hmmm but that note is never seen by the viewer... it gets deleted (hidden) when it is no longer needed. So that is a great example of what *could* be done.

 

And, yes, there are more important things to worry about... where should we be making that list? Until then, this thread is about this topic. And I think we have a few people with opinions (one way or the other) about this topic. While I still see it as "not pretty" I can see from the technical aspect that eventually this type of log will be the standard way of doing things. And, while we might not like it, we ought to get used to it because the TPTB have additional plans not yet comunicated to us. I can accept that.

 

I've said my piece and can live with the answers handed down from high... but I still don't like it.

[ju66l3r]

That's a good explanation. For clarification anything that changes the "state" of the listing should have an action assigned to it. Publishing a listing makes it go from a queued listing to a viewable one. We're just one step closer to that goal.

This and the other two responses talking about the notification system seem to help clarify the backend voodoo for why this log type is being added (as an action).

 

I don't read every thread in the forums and the "notification" system wasn't something I worried about reading about.

 

So, after reading through both threads now, I still have two questions then:

 

Can you do a better timestamping job on the logs so that they render on the page in the order they were entered? This doesn't help put FTF at the bottom of the page (since the FTFer doesn't always get FTLO (first to log online)) but it would probably be a really good bug-like fix now-a-days since "Published" should be the first "action" on any newly activated cache not "Found It" (like in the example Welch (I think) linked to).

 

The other question, I'll pose in the Notification thread, since it's more pertinent to that.

[Jeremy]

Can you do a better timestamping job on the logs so that they render on the page in the order they were entered?

The short answer is yes. I'll be doing exactly that.

 

The long answer involves the fact that the cache listing page hasn't been updated in ages and needs a major overhaul. I'll be working on that as I add the bookmark list functionality there.

[+ChileHead]

People will see it's listed on their own, and the thought of first to find addicts getting an extra advantage doesn't sit well with me.

Yeah, those FTF addicts are real jerks.

[+Deliveryguy428]

I might have missed the answer but a simple question is this:

 

Can the owner not just remove the log once it has been approved?

[+Maingray]

I might have missed the answer but a simple question is this:

 

Can the owner not just remove the log once it has been approved?

No, cannot delete it.

[+JanniCash]

The "published" log triggers the notification.  That is a fact, not a claim.  The fact that you keep repeating yourself does not change anything about that fact.

 

Whether the feature was "hastily implemented" is an opinion.

I take back the "kludge" - sorry.

 

What we (most probably) have here is a system that already had a log based email notification module. In order to reuse that (rather than reinventing the wheel), the new "published" log entry was used as a vehicle. I would agree that this is an acceptable solution that keeps the amount of code stirrup low enough to allow an on the fly application change without going through a full QA cycle. It produces something that is visible at the surface ... a wart. But doing it without that would probably cost a lot more effort now AND more code maintenance effort in the future.

 

However, I would not agree that it is acceptable if there is a window where a cache owner can remove the log (as someone already proposed to do) before it has served its trigger purpose.

 

But then again ... does anybody care if I agree or not? I don't think so.

 

Jan

[+Hoppingcrow]

I had mixed feelings about the "published" log when it was added to my newest cache. My first reaction was "Why me?", but then I realized it was probably a new feature. Okay, I accepted that. Then I began weighing pros and cons.

 

(dons flameproof suit) I have been known to report a cache that was placed outside the guidelines (specifically, one that was placed in a spot specifically designated as a "potential terrorist target"). I had to go through several steps to find out who the approver had been in order to have the cache archived. If some of you were previously able to see who had approved a certain cache in the text at the lower left bottom of the screen, I was not. The only approver listings visible to me were those on my own hides. In this, I considered the new "green dot" to be beneficial.

 

On the other side of the coin (if you're still reading, and not composing a scathing retort), I can see a lot more work being generated for the approvers who will now be receiving many more thought-of-the-moment complaints from newbies and others about coords not being accurate and other common whines. The Powers That Be may be re-thinking this move after it's had a trial run of a couple of weeks.

 

In any event, it's new, and new things always generate a certain amount of rebellion among the masses. If you'd just placed your first hide today, you wouldn't know the difference. We old folks tend to get a bit set in our ways, and when something new comes along, we're inclined to reject it without giving it a fair run. Let's don't be hasty to condemn something before we've seen how well it works.

[+CO Admin]

I had mixed feelings about the "published" log when it was added to my newest cache. My first reaction was "Why me?", but then I realized it was probably a new feature. Okay, I accepted that. Then I began weighing pros and cons.

 

(dons flameproof suit) I have been known to report a cache that was placed outside the guidelines (specifically, one that was placed in a spot specifically designated as a "potential terrorist target"). I had to go through several steps to find out who the approver had been in order to have the cache archived. If some of you were previously able to see who had approved a certain cache in the text at the lower left bottom of the screen, I was not. The only approver listings visible to me were those on my own hides. In this, I considered the new "green dot" to be beneficial.

 

On the other side of the coin (if you're still reading, and not composing a scathing retort), I can see a lot more work being generated for the approvers who will now be receiving many more thought-of-the-moment complaints from newbies and others about coords not being accurate and other common whines. The Powers That Be may be re-thinking this move after it's had a trial run of a couple of weeks.

 

In any event, it's new, and new things always generate a certain amount of rebellion among the masses. If you'd just placed your first hide today, you wouldn't know the difference. We old folks tend to get a bit set in our ways, and when something new comes along, we're inclined to reject it without giving it a fair run. Let's don't be hasty to condemn something before we've seen how well it works.

who will now be receiving many more thought-of-the-moment complaints from newbies and others about coords not being accurate and other common whines.

 

this also means more communication with the reviewer and thats always a good thing.

[+Robespierre]

I think it's time to say, "That's the way we do it around here, and it's not that bad." Deal with it.

[Yankees Win!]

I think it's time to say, "That's the way we do it around here, and it's not that bad."  Deal with it.

You're speaking for other people again. What if, at this very moment, they are fervently working on a different solution? Of course, if you are "in the know" and know otherwise, I apologize profusely.

Edited August 6, 2005 by Yankees Win!

[+Prime Suspect]

You're speaking for other people again. What if, at this very moment, they are fervently working on a different solution? Of course, if you are "in the know" and know otherwise, I apologize profusely.

There may be a few more tweaks in store, but I doubt they're working on scrapping something they've just implemented, and is working as intended.

[+Miragee]

This cache listing was the first time I saw the "Published" note.

 

I sure thought it was curious that all of us found, and logged, the cache before the "Published" note appeared.

[+WascoZooKeeper]

This cache listing was the first time I saw the "Published" note.

 

I sure thought it was curious that all of us found, and logged, the cache  before the "Published" note appeared.

I think it's simply a matter of the order that the different log types are sorted when the cache page is presented.

 

I haven't checked it out with a cache page, but I know that when I do the "quick view" of my account, on any given date all my TB entries display together, all my found logs display together, all my notes display together, regardless of the order I originally created them. Within each log type, they are in the order I created them.

 

So I suspect it's the same for the cache page -- for all logs entered on the same date, "publish" notes will display above "found" logs, which display above notes.

Edited August 7, 2005 by WascoZooKeeper

[ju66l3r]

As far as my years here have been able to tell, the database of logs is queried for the date (not an actual timestamp) for pulling out the logs for a specific cache. This means that whatever order they come out of the database (or are asked for as Wasco commented on) is how they get written to the page when it's rendered for viewing.

 

All things on the same date will always remain together right now, but some things that happened earlier in the day may be above other things happening later, depending on how they came out of the DB on query.

 

I asked Jeremy about finally getting around to fixing this by using a bona fide timestamp earlier in this thread and he said that it's in the works as part of the cache listing page revamp coming soon.

[+kayak-cowboy]

I for one am glad to see the reviewer publisher icon. If for some reason you have a problem with a cache hide: ex: private property where there is a no trespassing sign is posted. Then you have someone to contact after you go through the normal process of contacting the cache owner. For istance today I had gone to a cache which was 200 ft beyond a 'NO TRESPASSING' sign. I log a note to owner, and a little while latter I received an e-mail saying my log was deleted by owner. The owner did however post a note to come at cache from a different direction. This I don't understand No Trespassing means No trespassing regardless of what direction you come from. I will check this alternate directions before complaining to a reviewer of situation.