Give editors the ability to enter Notes onto User Reports without these going to the reporters themselves.

This will allow us to leave messages for other map editors without the reporter being notified, for example, Please leave open - due to a Waze developer investigation, Please leave open for a pending site survey, etc.

It may also give us the ability to for to use for an internal conversation about the report that the reporter doesn't need to know about.

Yes, I know we have Map Comments, but having the ability to do this directly on the report would make it easier.

This is slightly outside the scope of WME Beta, but in general about our ability to provide a better service for end users.

Allow users to reply to URs via email. Many support systems allow this, and in most cases, the process is fairly simple. The process might be as follows:

• User submits a request/issue from the app while they drive


• We (editors) get a pin on the map with submitted details as before


• User gets an email with a unique response email address (something like 8766123133@requests.waze.com)


• User gets instructions on how to view the map issue they submitted


• User gets instructions on how to provide more details (ie, from the app, or reply via email)


• If user replies via email, the email goes to a processing application and the details are added to the UR


• If user replies via app, they get an option to approve the full details of the journey to volunteers (start/end, exact details entered, route taken, etc)


• Editors now have a higher chance of getting details to support drivers because of email support, and the check box allows drivers to approve exposing extra details to volunteers.

Obviously the exposing extra details to volunteers will probably have to go through some legal process, but as we (as editors) often ask for details about the driver's routes anyway, I'm not sure there really is a difference.

The really important bit here is the reply via email. With it pinned to a sub-domain of waze.com (such as requests.waze.com) a processing application can append the replies to existing requests (based on the part in front of the @). This is a pretty common practice on many support ticketing systems, and I'm sure we'd get a much higher response rate on user request follow-ups.

Cheers
Jonathan

By: jangliss
Link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=306988

User Reports (URs) come in by the truckload. Despite a message from an investigating editor, only 10% of URs will receive a reply. This represents a significant amount of time by editors, particularly senior editors managing large areas, to the manual handling of individual URs. Since 90% of the URs result in the same process, help us streamline and automated it so we can focus our valuable time on productive investigations and edits that will value add to Waze.

I propose an additional tick box under "Follow conversation" that says along the lines "Auto reminder and mark as not identified."

When ticked:

• and a user replies, the auto remind and close is disactivated


• and a user does not reply, the user is automatically sent a reminder message after 4 days of the last editor reply, and after 7 days, the UR is automatically marked "not identified" and the last editor to reply is credited with the UR closure.

The "Auto reminder and mark as not identified" flag can only be toggled on if a message is sent. The flag can be toggled off however without a message being sent.

Possible visual presentation: https://imgur.com/VMIGTEW

Access to this feature can be controlled by a country level permission, ideally level 3 and above as default.

July 2020, Waze has three camera types: speed, red light, dummy. It is clear talking to different community leaders that the requirements for specific cameras vary from country to country. Thus, we are asking for the ability to add new camera types per country, with the ability to input into text to speech (TTS), and on/off toggle alert in the app. These could be provided by form, similar to new gas station brands, etc. by a country's leadership.

Alternatively, collect a list of camera types from the communities to create a long list, and allow countries to turn them on/off by country.

Obviously there's a wide range of cameras, and in each jurisdiction some are more important to others. There are also new and emerging camera types, such as dual red light AND speed cameras, and even newly released mobile phone detection cameras which fine users for driving while holding their phone.

When adding or editing RPP, if there is a conflict with the HN layer (i.e. too far), then the WME issues an error that prevents you from saving your edit. Thus, you cannot add or update this RPP.

To resolve the issue you need to perform the following steps:
1. Update/Remove the address in HN layer
2. Wait for next (successful) map build
3. Add the RPP

This is an annoying procedure that should and can be avoided.

The issue can be handled in one of the following ways:
1. Verify the RPP against the most updated data either in the edited or production HN layer databases.
2. Allow conflicts. Issue a warning but allow to save (rank depended). The same as forced HNs are allowed. Especially that for navigation, exiting RPPs are used before HNs.

The above suggestions or any other solution that will allow immediate RPP editing would be very welcomed.

I prefer option 1, as it also solve the conflict.

Currently, Junction Boxes do not have a controllable lock level. From the look of it, the lock level displayed is the minimum level for the country that can edit a JB. For example, in the UK only L5+ editors can edit JBs, so all JBs show auto(5) in WME.

With various changes that HQ are making into WME and the app, it seems to me that they expect a massive increase in JBs over time. U-turn prevention, junction modification for Falcon are just some of the things for which the answer often seems to be "use a JB".

I'm not disagreeing with the increased use of JBs. But some of them in the UK are attached to very complex motorway junctions (https://www.waze.com/editor/?env=row&lon=0.19921&lat=51.87156&zoom=5) which we would definitely want to stay out of reach of junior editors.

On the other hand, we don't want to prevent junior editors being able to use JBs sensibly in situations where they're needed.

Without individual lock levels on JBs we don't have much choice. In order to protect complex, important JBs we have to lock junior editors out of JB use entirely.

By: iainhouse
link to original suggestion: https://www.waze.com/forum/viewtopic.php?f=1525&t=307738