Position in approval queue feature?

[+-=(GEO)=-]

While the approval of a cache is pending, I'd like to see the position of the entry in the queue next to the 'This cache has not been approved yet. Once it is approved, it will be listed on the site.' message.

 

[+Markwell]

It's not a linear thing like lining up to get in to the movies or getting a morning cup of coffee at $tarbuck$. They don't all fall in sequence. There are numerous cache approvers for different regions. There's no way of knowing which one is going to approve your cache. And what about caches that are in the process of being approved? They've been looked at by the cache approvers, but there's a dialog going on about caches.

 

Carrying the $tarbuck$ analogy: it would be like having a crowd of 100 people in line for their coffee.

• One counter only handles orders from people who live on the east side of town, another for the north, etc.
• Most people just order their coffee black - the server pours the cup out of the pot, slaps on a lid and takes your money.
• Someone orders a double mocha espresso with half-decaf and a lime twist in a coconut shell with a pink umbrella. That drink will be made, and other orders will be taken while they are making that one.
• Of course, someone will come in to the $tarbuck$ asking for a latte without a cup ("just pour it right into my hands") - which they would never do.

In an establishment like that, it would be impossible to know if you are the 42nd person in line.

 

Markwell

Chicago Geocaching

[+The Leprechauns]

When you go into Markwell's $tarbuck$, just be sure not to order your coffee "to go." They just recently banned travelling coffee cups.

 

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x

I was formerly employed by the Department of Redundancy Department, but I don't work there anymore.

[+-=(GEO)=-]

I understand what you're saying. Still, there -are- queues which are likely stored as database records. The number of queues (I don't see why more than one would be needed either) or the number of approvers should not matter. For instance 'select count(*) from CacheQ where State = 'NY' and Country = 'US';' will tell you how many records are in queue for NY state. It does not matter how many approvers work on that queue.

 

I realize that I'm making the assumption that the queue is unique for all regions and that it's stored in a SQL table. I can also think of another easy way using SQL to determine precisely -how many- caches are pending before mine too.

 

Your comparison with $tarbuck$ is like comparing apples to oranges. The 2 processes are completly different: the cache approval process is -highly- distributed and parallel while the coffee making process is -highly- sequential.

 

[+Mopar]

If I understand things correct, there is only one queue line.

Approvers check in when they have free time and work on ones in their region. Your NY cache is in the same line as the ones from CA, or the UK. Because of time zone differences, and when approvers are free to do their job, they don't get approved in order. UK caches submitted long after your NY one may be approved hours sooner, because your approver is sleeping while the UK guy is knocking some off before work. Some regions slow down when approvers are sick, or away, or get flooded with new submissions after a nice weekend. Your area might only have a few caches to approve because it was cold and rainy. So while yea, you could know your position in the queue, it wouldnt help you to determine how long before your cache was approved.

 

Tae-Kwon-Leap is not a path to a door, but a road leading forever towards the horizon.

[+9Key]

quote:

---

when approvers are sick, or away, or get flooded

---

 

Mopar and Markwell are both on the dot.

 

For instance, Erik has been traveling and I'm not sure where Davros is, the northeastern caches have been getting a bit stale.

I would grab them but I've never been further east than Ohio. I wouldn't be familiar with the rules and regulations out east.

 

[+-=(GEO)=-]

I maintain that it's achievable fairly simply strictly using SQL given the location info provided on the cache page by the hider.

 

[+Markwell]

If that's how you're looking at it, then the data is already available.

 

On the Geocaching.com main page, there's a list of the most recently approved caches. The top of the list as I type this is cache ID=60700. If I submit a cache into the queue, I would immediately be told the URL, including the ID number (e.g. ID=60751). I would then know that there are 51 caches in front of me using your thought process.

 

But what happens if you look at this data and the most recently approved cache is 60750? You cache 60751 may indeed be the next one sequentially entered into the database to be approved. You check back in three hours (since your cache is not approved yet), and you see that cache 60763 has already been approved, yet 60751 is not yet approved.

 

Are you then -12th in line?

 

Markwell

Chicago Geocaching

[+Mopar]

quote:

---

Originally posted by -=(GEO)=-:

I maintain that it's achievable fairly simply strictly using SQL given the location info provided on the cache page by the hider.

 

http://img.Groundspeak.com/user/82972_1100.jpg

---

A few weeks ago I was waiting in line at the airport to checkin for a flight. There were probably 100 people in line ahead of me. Since my flight was leaving in 90 minutes, I was a bit concerned. Not to worry, 5 minutes later, a woman walked down the line asking if anyone was going to Phili. I was. Everyone going to Phili was sent direct to the counter. I was position #100 in the queue, Phili was "approved" long before the person in position #10 heading to Chicago.

Now, what it almost sounds like what you are proposing is really an overhaul of the entire approval process just so you can see how many are in front of you?

If I'm getting you right, you want a different queue for each approver, based on the area the approver covers and the area of the submission. If approver C does the NY caches, then your submission goes into a C queue, and you are told how many are in front of you. If CA cachers are approved by G, then those subbmisions go into the G queue. Do I have it right?

Sounds like an aweful lot of work just so you can see how many caches are in front of you. Also since approvers often overlap regions when there is a backlog in another region, it still wouldnt give you a realistic wait time.

 

Tae-Kwon-Leap is not a path to a door, but a road leading forever towards the horizon.

[+-=(GEO)=-]

No overhaul required to do this. I guess that to understand this feature some understanding of server-side development and SQL is required.

 

[+Mopar]

quote:

---

Originally posted by -=(GEO)=-:

No overhaul required to do this. I guess that to understand this feature some understanding of server-side development and SQL is required.

---

That's very possible, but I'm willing to try to learn enough to understand.

 

Tae-Kwon-Leap is not a path to a door, but a road leading forever towards the horizon.

[+nittany dave]

I think Markwell's point is valid, even understanding SQL.

 

If you select all NY caches, what would you use to order them? If you used the cache id, then using Markwell's example,

 

quote:

---

On the Geocaching.com main page, there's a list of the most recently approved caches. The top of the list as I type this is cache ID=60700. If I submit a cache into the queue, I would immediately be told the URL, including the ID number (e.g. ID=60751). I would then know that there are 51 caches in front of me using your thought process.

 

But what happens if you look at this data and the most recently approved cache is 60750? You cache 60751 may indeed be the next one sequentially entered into the database to be approved. You check back in three hours (since your cache is not approved yet), and you see that cache 60763 has already been approved, yet 60751 is not yet approved.

---

you would show next, but others could still be approved in front of you that had higher id numbers. If there were others remaining with lower id numbers than yours, it would only show an order entered, not an order of "to be approved".

Without an ' expected approval sequence' number field, I don't see how you could run a query that would give you anything besides order entered. In other words, your "position in a queue" can only be ordered by entry since there is no guaranteed approval order.

 

EDIT: But it would be a cool thing to have!

 

woody: how would a beer feel, mr. peterson?

norm: pretty nervous if i was in the room.

[kablooey]

The unapproved caches don't sit in a separate queue. They're all in the same list as the other caches. I know of at least one case where a cache just got forgotten for a week because there were so many caches submitted in California that weekend that the approvers just missed it when looking for unapproved caches.

 

I'm sure the site could run something like

select count(cacheId) from geocaches where cacheStatus='unapproved'

but that information really wouldn't be any more useful than the info already available to you. Check for most recently approved caches in your state. Compare the ID numbers against the ID number of the cache you've submitted. That will give you a general idea of how far behind your local approver is. Just keep in mind that approvers don't go through them at a constant rate. The 25 outstanding caches in your area could all be approved rapidly in succession after nothing's been approved for a day and a half.

[+-=(GEO)=-]

Given what we know about the structure of the table, that would be straight forward and a good enough indicator for me at least