Re: NY Protocol for Handling UR's

Post by beachbumli247
Also, I personally feel that once a user reports then to help in the process of doing UR's - a UR is free game for anyone to tackle until after the reporter responds or if there was sufficient information to being taking action in the initial report.
I agree 100%, and I know most of those editing in my area at least feel the same way. A lot of times an editor will comment on a handful of UR's, then may get busy for a week or 2, and I don't feel the user should suffer as a result of an editors busy schedule. If anyone has any argument to the contrary I'd be interested in hearing it just to hear both sides of the argument.

Seems most people agree we should also have a longer lead time between responses to allow for more users to have time in responding. Any downsides to doing so, other than more UR's staying on map longer, which is not necessarily a bad thing once we get the backlog under control.
beachbumli247
Area Manager
Area Manager
Posts: 65
Has thanked: 15 times
Been thanked: 3 times
Send a message

Re: NY Protocol for Handling UR's

Post by beachbumli247
Ok so I just read back through these posts, and aside from NYC editors (which largely boils down to a density issue), it seems the general consensus is that a time period of comment, 7 days reminder, 7 days close, for a total 14+ days from initial comment (assuming no response from the user). I like the idea of using 2 cases of low (normal) vs high density as was previously pointed out.

I do agree with JDesola in his point that UR's will help in justifying an ongoing issue to senior editors, but feel that these are the exception rather than the rule. I've come across a couple similar cases in which may close a few UR's initially, but as you start to notice a trend we can either leave a few open to show that trend, or start to point it out to senior editors as you notice 1 or 2 UR's popping up complaining about it so they are aware of it. These are the type of issues that could be handled on case by case basis, and you could even add a comment stating something along the lines of "We believe this may be an ongoing issue, so we are leaving this report open as we look into it" so that other editors are aware not to close it immediately.

One main thing that still seems to be up for debate is how UR's by another editor are handled. I think most editors in the metro area (JDesola, JSNinja, Rfrsw, etc) have come to an agreement that with the large backup of URs, any UR that we come across that is ready for response or closing is fair game. I definitely see the benefit of allowing the original editor to continue dialog with the user though, both from the users perspective, and from a new editors perceptive. I know that as a new editor it would've been a little intimidating to have more experienced editors jumping onto my UR's before I could spend the time to look into them.

I have modified my original draft with these comments in mind.
Update Requests (UR) are our only direct line of communication with the end user. As such, it is important that we not only make every attempt respond to reports as they pop up in a timely fashion, but also provide them with enough time to respond since many users are what are affectionately referred to "weekend warriors".

Protocol for handling UR's in NY is to send an initial response to the user, regardless of the age of the UR. The length of time to wait on reminder responses and closing a UR are dependent on the density of UR's in an area. In high density UR areas (i.e. areas that have more than <5> UR's on screen at zoom level <7>), reminder responses may be sent after a minimum of 4 days, with the UR closed after an additional 4 days for a total of 8 days minimum from initial comment. In "normal density UR areas" (i.e. all other cases), a reminder response is to be sent a minimum of 7 days from initial contact, and the UR is to be closed out no sooner than 14 days from initial attempt at contact. If there is ongoing dialog between the editor and user, the UR may remain open longer at the editors discretion until a resolution is reached. If at any time the user stops responding for 7+ days, the editor is to send out reminder response to the editor, and the report may be closed out no less than 7 days from last contact by the editor.

If you come across a UR that is already being handled by another editor, priority should be given to the initial editor to continue the conversation with the user. If more than 7 days have gone by from the last response from the initial editor, then it may be handled by any editor that

In all cases, the editor should give their best effort to determine a solution to the users report. In some cases, a deviation from the users route and the Waze provided route is enough to solve the problem. Other cases following along the route in street view could show signs for a turn restriction that may not be immediately obvious. The point is that it is our responsibility as editors to make out best efforts to clean up issues that would cause a user to report map errors.
beachbumli247
Area Manager
Area Manager
Posts: 65
Has thanked: 15 times
Been thanked: 3 times
Send a message

Re: NY Protocol for Handling UR's

Post by clubjuggle
My practice has been 7/7. I'm okay with a shorter minimum standard but will probably continue to use 7/7 if it goes shorter as I also edit in NJ and PA.
clubjuggle
Posts: 193
Has thanked: 38 times
Been thanked: 30 times
Send a message

Re: NY Protocol for Handling UR's

Post by CNY_STi
I've been processing on the 7/7 standard but I do like the idea of expediting SLUR's as they are relatively simple to resolve (normally). Most that I encounter are simply that it is missing however I have run into them being reported as 25MPH vs 30 MPH as from my testing it today, is not a pre-selectable option (I saw 25/35/55 and other the 4 times I tried)

The issue with that is most SLs are being generated off of WSV. Using WSLM is nice as it posts the editors name and direction where as the SLUR just spits out "25 MPH" anonymously.

Other suggestion for speed of clearing SLURs would be that they show as a different color than all the other URs so that they stick out as SLURs and not another issue.

Kyle
CNY_STi
Map Editor - level 3
Map Editor - level 3
Posts: 9
Has thanked: 2 times
Been thanked: 1 time
Send a message
SAT- Editor from North Carolina.
North Carolina Southeast Area Manager
Join our Discord server to receive faster responses.

https://s.waze.tools/c3.pnghttps://s.waze.tools/am.pnghttps://s.waze.tools/s0050.pnghttps://s.waze.tools/mapr.png

Re: NY Protocol for Handling UR's

Post by jdelosa
I like the idea of this discussion... And I agree with your assessment of what my understanding on the general timeline is currently .
I feel the Reporting Wazer has no idea of what happens then they press the button. I get a lot of responses with very little info because they think we already have enough info to answer the UR. I have also noticed I don't get a response until after the reminder has been sent. So in my humble opinion a slight longer time line is warranted. I am in favor of a minimum of 7 days before the reminder can be sent and an additional 7 days before the close for no further communication.

If I can suggest we keep in the timeline topic until we get some consensus before we tackle other UR related subjects....thanks all John (JD)

Sent from my XT1080 using Tapatalk
jdelosa
PartnerCoordinator
PartnerCoordinator
Posts: 487
Has thanked: 448 times
Been thanked: 161 times
Send a message

Re: NY Protocol for Handling UR's

Post by jdelosa
I want to thank everyone who added to this thread so far. My only reservation to closing to quickly is my personal conversations with friends on how they as wazers use the app.
They do not have email notifications on and they only get them in the app. Which is why we get such poor resopnces. The user has to look at the notification to see our reply and if they only use the app for longer destinations they might not turn on the app for over a week.

Sent from my XT1080 using Tapatalk
jdelosa
PartnerCoordinator
PartnerCoordinator
Posts: 487
Has thanked: 448 times
Been thanked: 161 times
Send a message

Re: NY Protocol for Handling UR's

Post by jdelosa
All of these suggestions are great.... And given that this morning's total NYC scan has over 10,000 Total URs we have a long way to go.....

My idea for leaving a UR around for awhile comes from a few experiences where after seeing a UR and following time protocol removed it. Then working the area starting to notice a pattern at that location. But by the time I realized the pattern I had timed out and deleted the others.

So when presenting a map change I got push back due to the fact that there was not supporting URs to say there was an ongoing problem.

It seems to me that as NYC goes a lot of the big black and white problems have been solved, now more of the little tweaking is happening.

So URs play a role in proving that a problem exist. Most of this is really only for local Editors. Local as in working a area all the time.

I see that some of our helping SR Editors are starting to see patterns just because of being around.

But as I started with until we start clean with only a manageable amount of URs and a team of dedicated Editors to work on them we are shoveling URs against the tide.....

Sent from my XT1080 using Tapatalk
jdelosa
PartnerCoordinator
PartnerCoordinator
Posts: 487
Has thanked: 448 times
Been thanked: 161 times
Send a message

Re: NY Protocol for Handling UR's

Post by jdelosa
I stand corrected 8,700 URs

Sent from my XT1080 using Tapatalk
jdelosa
PartnerCoordinator
PartnerCoordinator
Posts: 487
Has thanked: 448 times
Been thanked: 161 times
Send a message

Re: NY Protocol for Handling UR's

Post by jdelosa
Hi All,
Thanks Warren for trying to spearhead this subject.  

After a lot of reading and I think Great Meaningful replys I have come to the conclusion that our intention has been set off track.

There might be some reasons for a change to the policy as a whole but what I think we were looking for was a general guideline that the NY Editors could refer to on the NY Wiki Page that would be a suggested way we should handle URs...
Understanding that a traveling editor might not know what we do as a normal way but as new Editors join our efforts we could refer them to our consensus ...... What we as a team think works best for us....

So I believe Warren put forth what I think we have been discussing in the GHO as a group.... And what I was hoping was we could get some help on wording it in a way that it could be put up one our NY state wiki page as such.....

And if you guys think some more discussion is needed then lets have it.....

I do agree with Dovid's last post that I would not want it to be misinterpreted the wrong way so maybe the wording in the final draft needs to be a little more clearer....

Thanks again all for helping with this project, as you know URs are the life line of Waze and we need to get this right.... John (JD) Brooklyn NY
jdelosa
PartnerCoordinator
PartnerCoordinator
Posts: 487
Has thanked: 448 times
Been thanked: 161 times
Send a message

Re: NY Protocol for Handling UR's

Post by jdelosa
User request, user report all of which are map issues ...... who cam up with that correlation......

Sent from my XT1080 using Tapatalk
jdelosa
PartnerCoordinator
PartnerCoordinator
Posts: 487
Has thanked: 448 times
Been thanked: 161 times
Send a message
Post Reply