Update Requests: Difference between revisions Discussion View history

No edit summary
m (→‎Interface Elements: Minor correction)
 
(132 intermediate revisions by 26 users not shown)
Line 1: Line 1:
[[Map Editing (new Editor)#Editing Manual |Back to Map Editing]]
{{ReturnTo | Editing manual | the editing manual}}
{{NeedImage}}
[[Image:Request pin open-high.png|left]]  


=Update Requests=
''The information here is what is known at this time and subject to change.''
[[Image:Request_pin_open.png|left]]


''This information here is what is known at this time. Subject to change.''
This article covers Update Requests submitted by Wazers and they appear in the Waze Map Editor as a colored balloon with a white Waze icon. Balloons without a white Waze icon are automated Map Problem reports by the Waze system and are covered under [[Map_Problems_in_Waze_Map_Editor|Map problems]].




Update Requests are visible and contain useful information in the Waze Map Editor. Since the proposed two-way communication system with the end user is not built yet, the Update Requests layer in the Waze Map Editor currently does not inform the Wazer who submitted the Map Issue that their Update Request was closed.
==Overview==
An Update Request (UR) is what the Waze client app calls a "Map Issue." When a Wazer submits a map issue for wrong driving instructions, or a disallowed turn, etc., the icon with the small Waze icon is added to the editing map in the Update Requests layer. Due to the Waze terms of service and privacy policy, the username of the Wazer is not displayed. The new communication system added to the map editor enable a 2-way conversation between the Wazer reporting the error and the editor.


When an Update Request is marked "Solved" or "Not Identified," an email is sent to the reporting Wazer's registered email address showing the username (not email) of the editor who closed the issue. This secondary communication method enables the reporting Wazer to see the user name of the editor who closed their report, and to make contact in the forums or by private message if they wish.


==Overview==
In the Waze Map Editor, Update Requests contain information about the route the user drove as well as the route Waze had given them. This makes diagnosing the report much easier in many cases, especially for Incorrect Junction and Wrong Driving Directions reports.
In the Waze Map Editor, Update Requests contain information about the route the user drove as well as the route Waze had given them. This makes diagnosing the report much easier in many cases, especially for Incorrect Junction and Wrong Driving Directions reports.


When you first click on an Update Request pin, the map display will automatically center on the pin and zoom in to an appropriate level.
When you first click on an Update Request pin, the map will display a window of information at the top of the screen, overlaying part of the map. If you press the '''show''' button, the screen will recenter and zoom into that Update Request.


[[Image:Wme update request first click.png|600px]]
[[File:UR_View_2019.png|700px]]


This initial view tries to get you to a spot where you can see the most information. However, it is likely that you may need to zoom in or out and pan around to see all of the requested route and drive information.
This initial view tries to get you to a spot where you can see the most information. However, you may need to zoom in or out and pan around to see all of the requested route and drive information. In a few cases, the editor may zoom in to a spot somewhat distant from the actual Update Request information, in which case you may need to zoom out far enough so that you can recenter the map manually on the relevant spot.


Note that while this Update Request window is visible, other Update Request and Map Problem icons will appear as faint images until the Close button is pressed.


==Interface Elements==
==Interface Elements==
The color of the Update Request pin, just like Map Problems, are indicative of something. In the case of Update Requests, it is the age of the update request. See below for details on the several variations of the Update Request pin:
[[Image:Request pin open-low.png|left]] A yellow update request has been open for 0-5 days.{{clear}}
[[Image:Request pin open-med.png|left]] An orange update request has been open for 6-14 days.{{clear}}
[[Image:Request pin open-high.png|left]] A red update request has been open for 15 days or longer.{{clear}}
[[Image:Editor-assets-UR-markers-convo-mark.png|left]] A white balloon attached to any request balloon indicates a conversation in progress.{{clear}}
[[Image:Request_pin_open_conversation-low.png|left]] A yellow update request has been open for 0-5 days and has a conversation in progress.{{clear}}
[[Image:Request_pin_open_conversation-med.png|left]] An orange update request has been open for 6-14 days and has a conversation in progress.{{clear}}
[[Image:Request_pin_open_conversation-high.png|left]] A red update request has been open for 15 days or longer and has a conversation in progress.{{clear}}
[[Image:Request pin-notidentified.gif|left]] The Update Request changes to this icon when you mark an Update Request as "Not Identified" because you cannot locate a reason for the request or the request is unclear. Not identified update requests are visible on the map for up to seven (7) days after closure.{{clear}}
[[Image:Request_pin_solved_conversation.png|left]] This is a Solved Update Request which has a conversation. Solved update requests are visible on the map for up to seven (7) days after closure.{{clear}}
When you click on an Update Request pin, the top portion of the map display area is taken over by the information for the update request.
When you click on an Update Request pin, the top portion of the map display area is taken over by the information for the update request.


Line 26: Line 42:


===Meta Info===
===Meta Info===
[[Image:wme update request meta info.png]]
[[Image:wme update request meta info.jpg]]
 
In the top left of the screen you will see the problem description from the user (if entered) and when the user reported it.


To the left you will see the type of report, a description if the wazer entered any text information to explain the issue, the date of the report and the username of the wazer.
===Display related (show)===
[[File:UR_Show_Button_2019.png]]
The top right of the display will include this hyperlink that will recenter and zoom the display into the area covering the Update Request. The display can also be manually zoomed and panned to the area.


===Drive and Trace selection===
===Drive and Route===
[[Image:wme_update request route and trace.png]]
[[File:UR_Routes_2019.png]]


On the right will be zero, one or two checkboxes, depending on the data Waze was able to capture from the app. Each is to allow you to select whether to show the Waze requested route, or the users actual driven route, or both.
On the left will be zero, one, or two checkboxes, depending on the data Waze was able to capture from the app. Each one enables you to show the Route which Waze requested the user take, the user's actual drive, or both. Note that due to privacy concerns, the route driven will only be about 0.1 miles (probably longer) in length, and will not include the very beginning or end of the user's drive. This may make it difficult to truly understand where the user actually ended up driving if there are a number of intersections past the end of the route indicator.


===Report As===
===Report As===
[[Image:Wme update request reportas.png]]
[[File:UR Solved Not Identified 2019.png]]
 
While any editor can reply to and work on URs, the minimum editor rank to close an Update Request is 2. Rank 1 editors need to work with a higher ranking editor to complete the UR process.
 
At the bottom of the Update Request area is where you can take an action on the update request. You can leave it open, or mark it as '''Solved''' or '''Not Identified.''' This action, once you Save it, marks the Update Request as closed in the system, and neither you nor anyone else will be able to change the status again.
 
Closed Update Requests are visible on the map for up to seven (7) days after the closed date using the green icon.  Comments added after the closed date will reset the closed date and extend the visibility of the UR.
 
====Solved====
If you are able to identify a reason for the reported issue, and if you are able to fix the problem in the editor, fix the problem and save your changes. Then mark the update request as '''Solved'''.
 
====Not Identified====
For various reasons, such as lack of detail provided by the Wazer, or conflicting route vs. drive trace information, you may not be able to identify the source of the reported problem. In these cases, you should attempt to initiate a conversation with the reporter.
 
If a conversation has already been initiated by another editor and a reasonable time has passed since last hearing from the reporter, suggest that it be closed. Wait for that editor to contribute prior to taking further action.
 
If you do not receive a response within a reasonable period of time (minimum one week) after asking the question, you may consider marking the Update Request as '''Not Identified'''.
 
Also, users may sometimes report problems that are valid problems, but not problems that can be fixed in the editor – for example, problems with the app not loading map tiles properly. These should also be marked as '''Not Identified''', with an explanation to the reporter that the reported issue cannot be fixed in the editor.
 
====Before Saving====
Before Saving, enter a comment about why the request is being reported/closed in the manner you have chosen and Send that comment before clicking Save.


At the bottom of the Update Request area is where you can take an action on the update request. You can leave it open, or mark it as Solved or Not a Problem. Once you make once of these selections, you need to click the Save button.
Once you choose one of these selections, you need to click the Save button to save your changes. As soon as you click Save, any Update Requests and map edits you updated since the last save will be saved, and an email is sent to the Wazer who submitted the update request.


===Close===
===Close===
[[Image:Button close.png]]
[[Image:Button close.png]]


Way to the right of the Update Request information area is Close button. This closes the update request in the Waze Map Editor. Keep in mind that the Update Request database in the Waze Map Editor and Cartouche_old are two independent databases.  Prior to January 25, 2012, Update Requests will be duplicated and need to be dealt with in each editor.
Far to the right of the Update Request information area is a Close button. This button doesn't actually mark the Update Request as closed but simply dismisses the interface for reviewing the update request. It also hides the route information displaying on the map. This button is useful for clearing up the map display area while you work on solving the Update Request. Click on the Update Request again to bring up the details so you can mark the Update Request as Solved or Not Identified.
 


==Driven and Requested Routes==
==Driven and Requested Routes==
Line 51: Line 91:
If you cannot see the direction arrows or direction of the route, you may need to zoom in. Once zoomed in, the lines will show the direction of travel. Additionally, at each junction on the requested route (purple), a turn marker will be shown.
If you cannot see the direction arrows or direction of the route, you may need to zoom in. Once zoomed in, the lines will show the direction of travel. Additionally, at each junction on the requested route (purple), a turn marker will be shown.


[[Image:Wme_update request zoom detail.png]]
[[Image:Wme_update request zoom detail.jpg]]


One of the following turn instructions is placed at each junction on the purple request route line:
One of the following turn instructions is placed at each junction on the purple request route line:


* [[Image:Big direction forward.png]] - Continue straight/forward (client doesn't give this instruction by design)
*[[Image:Big direction forward.png]] - Continue straight/forward (client doesn't give this instruction by design)
* [[Image:Big direction right.png]] - Turn right
*[[Image:Big direction right.png]] - Turn right
* [[Image:Big direction left.png]] - Turn left
*[[Image:Big direction left.png]] - Turn left
* [[Image:Big direction exit right.png]] - Exit/Keep right
*[[Image:Big direction exit right.png]] - Exit/Keep right
* [[Image:Big direction exit left.png]] - Exit/Keep left
*[[Image:Big direction exit left.png]] - Exit/Keep left
* Blank Arrow - junction error ([[#Blank arrow|see below]])
*[[Image:Big_directions_roundabout.png]] - Roundabout numbered exit turn
*[[Image:Big_directions_roundabout_l.png]] - Roundabout left turn
*[[Image:Big_directions_roundabout_r.png]] - Roundabout right turn
*[[Image:Big_directions_roundabout_s.png]] - Roundabout straight through
*[[Image:Big_directions_roundabout_u.png]] - Roundabout "u-turn" (exit the way you came in)
*Blank Arrow - junction error ([[#Blank arrow|see below]])
 
Note that these turn instructions are relative to the direction of travel (the arrows inside the purple line).  For example, in the upper left corner of the screenshot above, the route was heading west and then turned south, so the icon for a left turn is shown, even though the arrow is pointing away from the direction of travel.  In other words, the icon indicates a turn to the left relative to the previous direction of travel, ''not'' a turn to the west.




Line 67: Line 114:
Using the information provided by any divergence of the requested route and user drive, you can look for turns which may need to be allowed at intersections.
Using the information provided by any divergence of the requested route and user drive, you can look for turns which may need to be allowed at intersections.


In beta testing of this feature, it was noticed that Waze often routed users either against turn restrictions, or in odd, non-optimal routes. Through communication with the drivers, it was determined that most of the ''Wrong Driving Directions'' reports were due to the "Prefer Goodie Munching" or "Prefer Cookie Munching" option being enabled in the app. This is the reason why it is now recommended that this option be turned off and that Waze is looking to remove this feature completely.
If you are able to determine a fix for the user's report, you may ''click'' the '''Solved''' action on the Report As section and then ''click'' '''Save'''.


If you are able to determine a fix for the user's report, you may ''click'' the '''Solved''' action on the Report As section and then ''click'' '''Save'''.
There will be times when the user description for the problem is provided, but does not seem to relate to the portion of their route you see on the map. This typically happens when the driver initially looks at their overall route and they see a problem at the end of the navigation turn list or on the map. They mark the problem there at the beginning of their trip, but don't realize an editor only sees about a mile of their route and nothing else about their trip. There is nothing you can do in these cases if they did not provide enough information to identify the problem area without the map route visual so mark these as "Not Identified". The original reporter of the problem may then reply directly to you or come to the forums to better explain what they saw.


===Turns Diagnosis===
===Turns Diagnosis===
====Orientation====
====Orientation====
When reviewing the route, it is easy to be confused by the turn direction arrows dispalyed at junctions. Remember that these will display the turn for the direction being traveled. Because the Waze Map Editor uses north-up orientation, for a route going south, these turn arrows will appear to be backwards. You need to put yourself in the orientation of the driver.
[[File:Big direction left.png|left|Example "turn left" instruction.]]
When reviewing the route, it is easy to be confused by the black turn direction arrows displayed at junctions along the Waze recommended route. Note that these will display the turn for the direction being traveled. Because the Waze Map Editor uses north-up orientation, for a route going south, these turn arrows will appear to be backwards. You need to put yourself in the orientation of the driver. Details are covered in the [[Update_Requests_in_Waze_Map_Editor#Driven_and_Requested_Routes|Driven and Requested Routes]] section above.


====Continue arrow====
====Continue arrow====
Remember that the "continue" arrow is merely informational. At this time, the routing server does not give the client any information about what to say for these. In the future, this feature may be enabled for specific circumstances.
Remember that the "continue" arrow is merely informational. At this time, the [[routing server]] does not give the client any information about what to say for these. In the future, this feature may be enabled for specific circumstances.


====Blank arrow====
====Blank arrow====
Line 85: Line 133:
The reasons for this are:
The reasons for this are:


# There is something invalid with the junction
#There is something invalid with the junction
#* It could have a short circular segment
#*It could have a short circular segment
#* Very distorted in some way  
#*Very distorted in some way
# There is a bug in the routing server when handling this node.
#There is a bug in the routing server when handling this node.


If the reason is #1, it should be quite obvious and fixable in the editor. If not, it may be #2, in which case you will need to open a support ticket.
If the reason is #1, it should be quite obvious and fixable in the editor. If not, it may be #2, in which case you will need to open a support ticket.




==Communication==
==Conversations==
Because communication with the end user is not possible at this time via the Waze Map Editor Interface, the Wazer who submitted the Map Issue will not be notified when their Update Request is closed in the Waze Map Editor.
[[File:wme_ur_conversation1.jpg]]
 
Two-way communication with the user who submitted a Map Issue (the Reporter) from the App is possible via a feature called Conversations. Newly submitted Update Requests will have no replies and so the Conversations button will show "0" until replies are added. The Conversation feature allows editors to ask for clarification of the Reporter, and allows the Reporter to respond back. This conversation can go on until the issue is clarified and resolved or determined to not be solvable.
 
 
'''{{Red|Note:}}''' You will need to have [[Map_Editor_Interface_and_Controls#Update_Requests|Update Requests]] checked in the [[Map_Editor_Interface_and_Controls#Layers|Map Layers]] to view open conversations.
 
===Interface===
[[File:wme_ur_conversation_replies.jpg|210px|right]]
To the right is an example of a conversation with several replies from both an Editor and the Reporter. The conversation button will show the total number of replies or comments which have been submitted by Editors and the Reporter for that Update Request.
 
The Reporter's comments are shown in blue bands and the Editors are shown in white/gray bands. The colors alternate between blues and white/gray if the Editor or Reporter enters more than one comment before the other person responds.
 
'''{{Red|Note:}}''' If you comment on your own Update Request (you opened it as a Map Issue in the app), you will show as the Reporter in the conversation thread.
 
===Usage===
To open an Update Request conversation, click the Conversation button. The Conversation button alternately opens and closes the Conversation panel. Collapsing the Conversation panel allows you to see more of the map.
 
Add a comment or question into the box marked '''Enter comment'''. To submit the new comment, click the Send button. You may enter as many comments as you like.
 
When you enter a comment, the system will automatically set you to Follow the Update Request conversation. You may click the Unfollow button if you do not wish to be notified of replies. See the [[#Notifications|Notifications section]] below for details.
 
Once a comment is entered, it cannot be removed from the Update Request Conversation. Your comments will be visible to all editors.
 
You may elect to receive notification of comments and replies on an Update Request by clicking the  '''Follow''' button. You can do this on any Update Request on the map. Click the '''Unfollow''' button to stop receiving reply notifications.
 
Any Editors who are Following an Update Request can also add comments from the Waze App Inbox message they receive after any reply is added to the Conversation.


It is likely that you will find the [[#Driven and Requested Routes|drive and route data]] to be very helpful in resolving Update Requests without needing to request additional information from the Wazer who submitted the Map Issue.
It is likely that you will find the [[#Driven and Requested Routes|drive and route data]] to be very helpful in resolving Update Requests without needing to request additional information from the Wazer who submitted the Map Issue.


If you find you cannot solve the Update Request without clarification from the Wazer, the best option is to send a PM via the Waze [http://www.waze.com/forum/ forums], using the username you see in the Editor. Keep in mind that there is no option to mark an Update Request with Missing Data or Pending Response as there was in Cartouche, so another map editor may work on and close out the Update Request.
===Notifications===
Here is a quick summary of notifications which the system sends:
 
*If you are the Reporter
 
#You will receive an email to your registered email address (if you have one) and a message in the Waze App Inbox when another Editor adds a comment to the UR Conversation
#You will receive an email and a message in the Waze App Inbox when an Editor (who is not you; see note below) closes (marks Solved or Not Identified) the Update Request
 
*If you are Following an Update Request Conversation (as an Editor)
 
#You will receive an email and a message in the Waze App Inbox when either another editor or the Reporter adds a comment to the Conversation
#You will receive an email and a message in the Waze App Inbox when an Editor other than you closes (marks Solved or Not Identified) the Update Request
 
==The resolution process / Etiquette==
 
When you respond to user reports, you are interacting with the original reporter, and you may also be interacting with other Waze editors who respond to the same request. The recommendations in this section are designed to:
 
*Promote harmony between editors and the reporter, and improve the good reputation of Waze and its user community
*Promote harmony among editors and prevent conflict or duplication of effort
*Engage the reporter productively, efficiently, and courteously in the problem resolution process
 
Below is a description of the issues that require finesse in your response etiquette to prevent or resolve.
 
===Missing information===
 
Many reporters do not describe the map issue well enough for an editor to find the root cause of the issue and resolve it. Editors must find a way to engage the reporter to get additional information. There is a balance between composing a request that gets the responding editor all needed information with the most exacting accuracy, and overwhelming the reporter. There are many ways to overwhelm the reporter! Requests for too much detail. Jargon or other overly technical descriptions of the information requested. Exacting specifications for the answer. Discourteous language or cultural issues. With the exception of the latter, each of these might be requested in good faith, and may even be somewhat necessary - but they may turn the reporter off and cause the reporter to disengage. As an editor requesting information, your job is to present the request in such a way that the reporter is willing to work with you, while getting the reporter to provide you with the right information to solve the problem reports where they initially lack enough information to properly analyze.
 
 
====Style/boilerplate====
Under most circumstances, use short response texts, as reporters are unlikely to read longer texts.
 
The New Jersey and Pennsylvania editors have developed two boilerplate text approaches that you should consider using. With experience, you will probably be able to find an approach based on their examples that works optimally. Note that "optimally" may mean that you still only get a low success rate in getting responses or getting workable responses. However, the alternative is an even lower response rate, or lower quality responses, or both.
 
The URComments-Enhanced (URC-E) script implements a similar boilerplate approach. However, be careful, as the text is not always an exact match for the situation. The automated boilerplate's ease of use may lull you into not tailoring the text for the situation.
 
You can find a list of boilerplate responses published by various editors in the [[:Category:Sample responses|Sample responses category]] list page.
 
===Non-responsive reporters===
 
A clean map, with few open reports and a low percentage of old reports, is a good goal. However, in practice, we often have "littered" maps, with many older reports (orange and red icons). This is partially due to manpower, and partially due to missing information, causing the report to stay open even after an editor starts working on it.
 
The best way to reduce this clutter is to speed up the cycle of report resolution. But this has to be done without prematurely closing reports that could still be worked on, with resulting map or routing improvements.
 
The guidance below will help you engage reporters initially, provide them opportunities to work with you, but not allow reports to remain open indefinitely. In particular, be sure to review the flow chart for responding.
 
===Multiple editors===
 
Our standards of etiquette call for allowing the first responding editor to take ownership of problem resolution as a general matter, although individual states or regions may have different approaches that should be followed. Other editors should not step in unless they think the owner needs help (whether the owner realizes it or not), or has abandoned/lost track of the report over time. If you see reports being mishandled by a particular editor -- whether in the language of interaction, analysis and problem-solving skills, the map edits taken toward resolution, or an abusive own/abandon cycle across many report -- you should still avoid direct confrontation. Consider that your responses may trigger a defiant response, especially in the public nature of the report conversation technology. Instead, you may want to use private messages to make constructive suggestions. If the other editor takes offense, disengage and ask the Regional Coordinator for assistance.
 
===Closing the Update Request===
 
Before marking an Update Request as Not Identified or Solved, enter a conversation message stating what you did to resolve the problem, or why the request is being marked as Not Identified.
 
===Flowchart===
[[File:Waze_Flowchart.png|731px|left]]
 
Once you add a comment or question to an Update Request that requires a response from the Reporter, it is recommended that you wait at least seven (7) days for a response. If there is no response, then you will need to decide how to handle the Update Request as best you can from the data available. (This situation is no different than before Conversations existed.)
 
This may mean you have to close the report as ''Not Identified''. In that case the Wazer who submitted the Map Issue will be notified via email when their Update Request is closed. They can still try to contact you through a private message if they do have more information.
 
When you come across an Update Request that has an on-going conversation, do not close that UR unless you were separately asked by either the Reporter or other Editors via email or private message that it is OK to do so.
 
If the Update Request conversation has no updates for at least seven (7) days, and the last message was from an Editor, you may try to solve the request and mark it appropriately. If the last message was from the Reporter, add a note so that the original Editor receives another message, which should "wake them up" and complete working on the UR. If another seven days goes by with no action, you are free to solve/close the UR as appropriate.
 
{{ReturnTo | Editing manual | the editing manual}}


[[Map Editing (new Editor)#Editing Manual |Back to Map Editing]]
[[Category:Waze Map Editor]]

Latest revision as of 02:05, 13 July 2022

Images are going to be added to clarify these instructions.

The information here is what is known at this time and subject to change.

This article covers Update Requests submitted by Wazers and they appear in the Waze Map Editor as a colored balloon with a white Waze icon. Balloons without a white Waze icon are automated Map Problem reports by the Waze system and are covered under Map problems.


Overview

An Update Request (UR) is what the Waze client app calls a "Map Issue." When a Wazer submits a map issue for wrong driving instructions, or a disallowed turn, etc., the icon with the small Waze icon is added to the editing map in the Update Requests layer. Due to the Waze terms of service and privacy policy, the username of the Wazer is not displayed. The new communication system added to the map editor enable a 2-way conversation between the Wazer reporting the error and the editor.

When an Update Request is marked "Solved" or "Not Identified," an email is sent to the reporting Wazer's registered email address showing the username (not email) of the editor who closed the issue. This secondary communication method enables the reporting Wazer to see the user name of the editor who closed their report, and to make contact in the forums or by private message if they wish.

In the Waze Map Editor, Update Requests contain information about the route the user drove as well as the route Waze had given them. This makes diagnosing the report much easier in many cases, especially for Incorrect Junction and Wrong Driving Directions reports.

When you first click on an Update Request pin, the map will display a window of information at the top of the screen, overlaying part of the map. If you press the show button, the screen will recenter and zoom into that Update Request.

This initial view tries to get you to a spot where you can see the most information. However, you may need to zoom in or out and pan around to see all of the requested route and drive information. In a few cases, the editor may zoom in to a spot somewhat distant from the actual Update Request information, in which case you may need to zoom out far enough so that you can recenter the map manually on the relevant spot.

Note that while this Update Request window is visible, other Update Request and Map Problem icons will appear as faint images until the Close button is pressed.

Interface Elements

The color of the Update Request pin, just like Map Problems, are indicative of something. In the case of Update Requests, it is the age of the update request. See below for details on the several variations of the Update Request pin:

A yellow update request has been open for 0-5 days.

An orange update request has been open for 6-14 days.

A red update request has been open for 15 days or longer.

A white balloon attached to any request balloon indicates a conversation in progress.

A yellow update request has been open for 0-5 days and has a conversation in progress.

An orange update request has been open for 6-14 days and has a conversation in progress.

A red update request has been open for 15 days or longer and has a conversation in progress.

The Update Request changes to this icon when you mark an Update Request as "Not Identified" because you cannot locate a reason for the request or the request is unclear. Not identified update requests are visible on the map for up to seven (7) days after closure.

This is a Solved Update Request which has a conversation. Solved update requests are visible on the map for up to seven (7) days after closure.

When you click on an Update Request pin, the top portion of the map display area is taken over by the information for the update request.

The top bar of the Update Request states that this is a User Reported Problem.

Meta Info

In the top left of the screen you will see the problem description from the user (if entered) and when the user reported it.

Display related (show)

The top right of the display will include this hyperlink that will recenter and zoom the display into the area covering the Update Request. The display can also be manually zoomed and panned to the area.

Drive and Route

On the left will be zero, one, or two checkboxes, depending on the data Waze was able to capture from the app. Each one enables you to show the Route which Waze requested the user take, the user's actual drive, or both. Note that due to privacy concerns, the route driven will only be about 0.1 miles (probably longer) in length, and will not include the very beginning or end of the user's drive. This may make it difficult to truly understand where the user actually ended up driving if there are a number of intersections past the end of the route indicator.

Report As

While any editor can reply to and work on URs, the minimum editor rank to close an Update Request is 2. Rank 1 editors need to work with a higher ranking editor to complete the UR process.

At the bottom of the Update Request area is where you can take an action on the update request. You can leave it open, or mark it as Solved or Not Identified. This action, once you Save it, marks the Update Request as closed in the system, and neither you nor anyone else will be able to change the status again.

Closed Update Requests are visible on the map for up to seven (7) days after the closed date using the green icon. Comments added after the closed date will reset the closed date and extend the visibility of the UR.

Solved

If you are able to identify a reason for the reported issue, and if you are able to fix the problem in the editor, fix the problem and save your changes. Then mark the update request as Solved.

Not Identified

For various reasons, such as lack of detail provided by the Wazer, or conflicting route vs. drive trace information, you may not be able to identify the source of the reported problem. In these cases, you should attempt to initiate a conversation with the reporter.

If a conversation has already been initiated by another editor and a reasonable time has passed since last hearing from the reporter, suggest that it be closed. Wait for that editor to contribute prior to taking further action.

If you do not receive a response within a reasonable period of time (minimum one week) after asking the question, you may consider marking the Update Request as Not Identified.

Also, users may sometimes report problems that are valid problems, but not problems that can be fixed in the editor – for example, problems with the app not loading map tiles properly. These should also be marked as Not Identified, with an explanation to the reporter that the reported issue cannot be fixed in the editor.

Before Saving

Before Saving, enter a comment about why the request is being reported/closed in the manner you have chosen and Send that comment before clicking Save.

Once you choose one of these selections, you need to click the Save button to save your changes. As soon as you click Save, any Update Requests and map edits you updated since the last save will be saved, and an email is sent to the Wazer who submitted the update request.

Close

Far to the right of the Update Request information area is a Close button. This button doesn't actually mark the Update Request as closed but simply dismisses the interface for reviewing the update request. It also hides the route information displaying on the map. This button is useful for clearing up the map display area while you work on solving the Update Request. Click on the Update Request again to bring up the details so you can mark the Update Request as Solved or Not Identified.

Driven and Requested Routes

The route that the user received from Waze will be shown in purple, just like in the app. The route that the user actually drove is in bright green.

If you cannot see the direction arrows or direction of the route, you may need to zoom in. Once zoomed in, the lines will show the direction of travel. Additionally, at each junction on the requested route (purple), a turn marker will be shown.

One of the following turn instructions is placed at each junction on the purple request route line:

  • - Continue straight/forward (client doesn't give this instruction by design)
  • - Turn right
  • - Turn left
  • - Exit/Keep right
  • - Exit/Keep left
  • - Roundabout numbered exit turn
  • - Roundabout left turn
  • - Roundabout right turn
  • - Roundabout straight through
  • - Roundabout "u-turn" (exit the way you came in)
  • Blank Arrow - junction error (see below)

Note that these turn instructions are relative to the direction of travel (the arrows inside the purple line). For example, in the upper left corner of the screenshot above, the route was heading west and then turned south, so the icon for a left turn is shown, even though the arrow is pointing away from the direction of travel. In other words, the icon indicates a turn to the left relative to the previous direction of travel, not a turn to the west.


Diagnosis

Route Diagnosis

Using the information provided by any divergence of the requested route and user drive, you can look for turns which may need to be allowed at intersections.

If you are able to determine a fix for the user's report, you may click the Solved action on the Report As section and then click Save.

There will be times when the user description for the problem is provided, but does not seem to relate to the portion of their route you see on the map. This typically happens when the driver initially looks at their overall route and they see a problem at the end of the navigation turn list or on the map. They mark the problem there at the beginning of their trip, but don't realize an editor only sees about a mile of their route and nothing else about their trip. There is nothing you can do in these cases if they did not provide enough information to identify the problem area without the map route visual so mark these as "Not Identified". The original reporter of the problem may then reply directly to you or come to the forums to better explain what they saw.

Turns Diagnosis

Orientation

Example "turn left" instruction.
Example "turn left" instruction.

When reviewing the route, it is easy to be confused by the black turn direction arrows displayed at junctions along the Waze recommended route. Note that these will display the turn for the direction being traveled. Because the Waze Map Editor uses north-up orientation, for a route going south, these turn arrows will appear to be backwards. You need to put yourself in the orientation of the driver. Details are covered in the Driven and Requested Routes section above.

Continue arrow

Remember that the "continue" arrow is merely informational. At this time, the routing server does not give the client any information about what to say for these. In the future, this feature may be enabled for specific circumstances.

Blank arrow

There are circumstances which will cause Waze Map Editor to show a blank turn arrow tile at a junction.

The blank instruction means the routing server failed to provide an instruction in this node. The client treats this as a non-audible continue straight instruction, which usually means the instruction the user hears and refers to is the next instruction after the blank one.

The reasons for this are:

  1. There is something invalid with the junction
    • It could have a short circular segment
    • Very distorted in some way
  2. There is a bug in the routing server when handling this node.

If the reason is #1, it should be quite obvious and fixable in the editor. If not, it may be #2, in which case you will need to open a support ticket.


Conversations

Two-way communication with the user who submitted a Map Issue (the Reporter) from the App is possible via a feature called Conversations. Newly submitted Update Requests will have no replies and so the Conversations button will show "0" until replies are added. The Conversation feature allows editors to ask for clarification of the Reporter, and allows the Reporter to respond back. This conversation can go on until the issue is clarified and resolved or determined to not be solvable.


Note: You will need to have Update Requests checked in the Map Layers to view open conversations.

Interface

To the right is an example of a conversation with several replies from both an Editor and the Reporter. The conversation button will show the total number of replies or comments which have been submitted by Editors and the Reporter for that Update Request.

The Reporter's comments are shown in blue bands and the Editors are shown in white/gray bands. The colors alternate between blues and white/gray if the Editor or Reporter enters more than one comment before the other person responds.

Note: If you comment on your own Update Request (you opened it as a Map Issue in the app), you will show as the Reporter in the conversation thread.

Usage

To open an Update Request conversation, click the Conversation button. The Conversation button alternately opens and closes the Conversation panel. Collapsing the Conversation panel allows you to see more of the map.

Add a comment or question into the box marked Enter comment. To submit the new comment, click the Send button. You may enter as many comments as you like.

When you enter a comment, the system will automatically set you to Follow the Update Request conversation. You may click the Unfollow button if you do not wish to be notified of replies. See the Notifications section below for details.

Once a comment is entered, it cannot be removed from the Update Request Conversation. Your comments will be visible to all editors.

You may elect to receive notification of comments and replies on an Update Request by clicking the Follow button. You can do this on any Update Request on the map. Click the Unfollow button to stop receiving reply notifications.

Any Editors who are Following an Update Request can also add comments from the Waze App Inbox message they receive after any reply is added to the Conversation.

It is likely that you will find the drive and route data to be very helpful in resolving Update Requests without needing to request additional information from the Wazer who submitted the Map Issue.

Notifications

Here is a quick summary of notifications which the system sends:

  • If you are the Reporter
  1. You will receive an email to your registered email address (if you have one) and a message in the Waze App Inbox when another Editor adds a comment to the UR Conversation
  2. You will receive an email and a message in the Waze App Inbox when an Editor (who is not you; see note below) closes (marks Solved or Not Identified) the Update Request
  • If you are Following an Update Request Conversation (as an Editor)
  1. You will receive an email and a message in the Waze App Inbox when either another editor or the Reporter adds a comment to the Conversation
  2. You will receive an email and a message in the Waze App Inbox when an Editor other than you closes (marks Solved or Not Identified) the Update Request

The resolution process / Etiquette

When you respond to user reports, you are interacting with the original reporter, and you may also be interacting with other Waze editors who respond to the same request. The recommendations in this section are designed to:

  • Promote harmony between editors and the reporter, and improve the good reputation of Waze and its user community
  • Promote harmony among editors and prevent conflict or duplication of effort
  • Engage the reporter productively, efficiently, and courteously in the problem resolution process

Below is a description of the issues that require finesse in your response etiquette to prevent or resolve.

Missing information

Many reporters do not describe the map issue well enough for an editor to find the root cause of the issue and resolve it. Editors must find a way to engage the reporter to get additional information. There is a balance between composing a request that gets the responding editor all needed information with the most exacting accuracy, and overwhelming the reporter. There are many ways to overwhelm the reporter! Requests for too much detail. Jargon or other overly technical descriptions of the information requested. Exacting specifications for the answer. Discourteous language or cultural issues. With the exception of the latter, each of these might be requested in good faith, and may even be somewhat necessary - but they may turn the reporter off and cause the reporter to disengage. As an editor requesting information, your job is to present the request in such a way that the reporter is willing to work with you, while getting the reporter to provide you with the right information to solve the problem reports where they initially lack enough information to properly analyze.


Style/boilerplate

Under most circumstances, use short response texts, as reporters are unlikely to read longer texts.

The New Jersey and Pennsylvania editors have developed two boilerplate text approaches that you should consider using. With experience, you will probably be able to find an approach based on their examples that works optimally. Note that "optimally" may mean that you still only get a low success rate in getting responses or getting workable responses. However, the alternative is an even lower response rate, or lower quality responses, or both.

The URComments-Enhanced (URC-E) script implements a similar boilerplate approach. However, be careful, as the text is not always an exact match for the situation. The automated boilerplate's ease of use may lull you into not tailoring the text for the situation.

You can find a list of boilerplate responses published by various editors in the Sample responses category list page.

Non-responsive reporters

A clean map, with few open reports and a low percentage of old reports, is a good goal. However, in practice, we often have "littered" maps, with many older reports (orange and red icons). This is partially due to manpower, and partially due to missing information, causing the report to stay open even after an editor starts working on it.

The best way to reduce this clutter is to speed up the cycle of report resolution. But this has to be done without prematurely closing reports that could still be worked on, with resulting map or routing improvements.

The guidance below will help you engage reporters initially, provide them opportunities to work with you, but not allow reports to remain open indefinitely. In particular, be sure to review the flow chart for responding.

Multiple editors

Our standards of etiquette call for allowing the first responding editor to take ownership of problem resolution as a general matter, although individual states or regions may have different approaches that should be followed. Other editors should not step in unless they think the owner needs help (whether the owner realizes it or not), or has abandoned/lost track of the report over time. If you see reports being mishandled by a particular editor -- whether in the language of interaction, analysis and problem-solving skills, the map edits taken toward resolution, or an abusive own/abandon cycle across many report -- you should still avoid direct confrontation. Consider that your responses may trigger a defiant response, especially in the public nature of the report conversation technology. Instead, you may want to use private messages to make constructive suggestions. If the other editor takes offense, disengage and ask the Regional Coordinator for assistance.

Closing the Update Request

Before marking an Update Request as Not Identified or Solved, enter a conversation message stating what you did to resolve the problem, or why the request is being marked as Not Identified.

Flowchart

Once you add a comment or question to an Update Request that requires a response from the Reporter, it is recommended that you wait at least seven (7) days for a response. If there is no response, then you will need to decide how to handle the Update Request as best you can from the data available. (This situation is no different than before Conversations existed.)

This may mean you have to close the report as Not Identified. In that case the Wazer who submitted the Map Issue will be notified via email when their Update Request is closed. They can still try to contact you through a private message if they do have more information.

When you come across an Update Request that has an on-going conversation, do not close that UR unless you were separately asked by either the Reporter or other Editors via email or private message that it is OK to do so.

If the Update Request conversation has no updates for at least seven (7) days, and the last message was from an Editor, you may try to solve the request and mark it appropriately. If the last message was from the Reporter, add a note so that the original Editor receives another message, which should "wake them up" and complete working on the UR. If another seven days goes by with no action, you are free to solve/close the UR as appropriate.