After the great LA Raid it was noticed that some sort of official management is needed for UR responses. Unofficially much of Virginia has loosely been following a ASAP/7/14 guideline. Meaning we comment as soon as possible after reported, 7 days later we provide a stale message “if no further information is provided this report will be closed soon” if we have received no response and 7 more days (total of 14 since initial response) we provide a dead message, “this report is being closed due to lack of information, please submit another report if the issue continues. Happy Wazing!” And close NI.
Myself and a few other AMs are proposing a 1/4/8 system. We have read a few forum posts ( https://www.waze.com/forum/viewtopic.php?f=943&t=107411 ) and it seems that quick initial responses lead to more reporter responses. There has also been mention of reporters not getting our responses until after a second message is sent. This shorter timeframe ensures reporters feel loved. Finally in urban areas there are many new URs appearing daily. A short cycle helps lessen the total number on URs in those areas.
I want to play drivers advocate here. 3 messages could be annoying for some drivers. I am all for VA making a UR closure warning standard. That said rural (leaving URs open longer and being nicer ) and urban UR standards could be used but why complicate things more? URs answering is a whole lot easier now with scripts but I don’t see a need to beat a dead UR as the warning could be worded to double as an impending closure notice. An optional closure statement could be sent but I don’t think we need to deviate too far away from the national standard 2 messages minimum for no response. Again, it’s not any more difficult to add a response when closing so I’m open to doing that if others deem it necessary.
Not that we editors need advocates, but you only get 3 messages when you drop a UR then ignore us. [emoji16]
That being said I can see both sides of the coin. A final message IS somewhat redundant however I believe both main scripts have been created around a 3 response system. On the other hand letting the reporter know that if we closed prematurely they can re-report the issue does have merit.
It great that we have editors that that review concurrent areas frequently enough that we need this coordination. I have no objections to a 1/4/8 system. All I’d want to make clear is 4 should mean three days after the first request for information is sent and 8 should mean 4 days after the warning of closure is sent. Note that not everywhere is covered adequately (yes we do need to expand some areas) so I’m currently on a 128/160 system in areas where there are URs over 128 days old. So where URs fall through the cracks there will need to be some flexibility.
I believe this deserves a separate thread. Request fearless leader snip off discussion starting with SuperMedic’s awesome suggestion (full disclosure: I am on of the “few other AMs” that SuperMedic referred to) and restart as separate conversation.
If we’re to codify this into the wiki, I strongly suggest we plagiarize heavily from TerryPurdue’s comments in https://www.waze.com/forum/viewtopic.php?f=943&t=107411. BIG Thankyou to Terry for bringing this to Virginia. Of particular interest (IMHO)…
This one explains the system pretty well and it makes a lot of sense to me.
and…
…I particularly like the emphasis on the team approach. Supermedic, TwoEightZero, Pfantom, AngryCheesehead when he was around, ct13 until he lost EA around HR, and I have pretty much been taking this approach around Hampton Roads already and I think it has worked out pretty well for us and the drivers.
I think the Waze Virginia Google Hangout has helped a LOT inasmuch as it has improved communication amongst the active editors and made this type of collaboration a reality even without codifying it as “policy”.
There were plenty of other GREAT comments in that lengthy discussion in the Great Lakes Region forum, but this already too long and I still have to respond to the issues brought up…
As Supermedic suggested, they only get 3 responses if they drop UR and then ignore us. IMHO, might be a GOOD thing if that driver is a little annoyed. Maybe s/he’ll get annoyed enough to either respond to our requests or stop wasting our time with URs we can’t fix. That being said, I don’t see any reason why we couldn’t just write up the strategy as close (NI) at 8 with no mention of comment or not, thereby leaving it up to each editor.
The 4/8 is only applicable based on the 1/. The system is designed around maintenance of an area after it is under control. Clearly it doesn’t work with old UR’s. That is spelled out in Terry’s posts and will be for Virginia plan, too (1/4/8 is just the short title, expect to explain it much better on the Wiki). Also, none of this would apply in under-covered areas…by default. If nobody working the area then nobody to implement the strategy.
That is already more than enough for one post so I’ll shut up, now. Have a great night and thanks for skimming (I KNOW you skimmed, NOBODY reads something THAT long online).
I’m always glad to see a group discussing UR response methods – thanks for the “invite”!
The only things I know that editors can do to create a long-term sustainable state where the local team can always stay on top of the velocity of incoming URs:
Editor outreach: leverage any/all methods possible to identify new editors as soon after they start working the area, then encourage them to join the area’s editing community (like Virginia, our area has found a very active Google Hangout to be a huge help in helping “hook” new editors)
Mentoring: a sustainable editing team is one that has a nice distribution curve of editors over all ranks. If all editors in the area – at all ranks! – are always actively working to distribute their knowledge with anyone/everyone else in the group, you’ll be always be making sure you’ve got a solid range of experience levels in the area
Diligent UR response efforts by ALL members of the team
On that last point, I personally (speaking only for myself) feel UR response is an area where it’s crucial to “lead from the front.”
Even though it’s so very tempting to feel like at a certain point you’ve “put in your time” doing your part of UR response and try to transition/delegate UR response down to newer editors, I feel that reaction has a chilling effect. In my experience, when senior editors delegate UR response to more junior editors it sends a clear message that UR work is some form of punishment/hazing. The junior editor might accept that role – but I assure you he’s heard the message, so he’ll already be looking forward to the time when he can pawn it off on someone else and earn the right to play with his pet projects full time.
Our leadership team has worked to establish a powerful and positive tone for newer editors by making sure as they begin to work URs across the area that they regularly see an even distribution of names from every editor in the area, especially those at R3 and above. That serves as living proof that the area’s leadership strongly believes that UR response is a base requirement for everyone who works the area, from brand new editors up to and including Global Champs.
Here is a different viewpoint. In urban areas, such as Northern Virginia, a newbie junior editor basically has nothing to do, other than drive in the boonies on purpose or waste life on updating house numbers. So, letting such an editor take care of URs and get experience, feel useful, get points, map edits or whatever – that’s all excellent and keeps them interested.
For instance, I am only level 3, but I am not touching fresh URs. Not because I think it’s a dirty job that is below me, but for the reason above, to give newbs a chance. There are plenty of stale URs to take care of.
To be honest, in general, I find this whole talk about “leadership”, UR response plans and “base requirements” kind of laughable, no offense. It’s a typical attempt to institute rules and regulations for the sake of creating rules and regulations in a system that works fine on its own. Existing editing limitations that are based on editor experience are enough to handle pretty much everything. Not to mention, the editors are not employees, they are random folks that are doing what they think is right.
Were you able to participate in either the NYC or LA MapRaids?
In LA, it took a team of over 200 editors two full weeks to close out over 25,000 open URs.
We found some URs that had been created ten months earlier … which had never been worked yet.
The list of upcoming MapRaids seems to strongly suggest, to me at least, that there are many places where the system is not “working fine on its own.”
While I don’t have many data points to draw on, from my personal experience, the densely-populated metro areas where editors are experimenting with some sort of organized response are proving better able to stay on top of the non-stop flow of incoming URs over longer timeframes (6+ months sustained).
That is the reason for too many URs, not the lack of organized response or standards and procedures, in my opinion. Waze needs to fundamentally change how things are submitted, not just let users hit “oh there is some error” button and have 200 editors scramble for 2 weeks with the resulting mess.
It’s been discussed many times, but I think a UR should not be allowed in unless it has all the information about the problem and the circumstances. Then it’s easier to handle with the limited number of volunteers.
Otherwise, it doesn’t matter, there will still be more frustrated drivers hitting “report error” than the editors to figure out what is wrong. Add strict procedures and base requirements where none are needed and you will also alienate many folks that are nice enough to spend some time on Waze, but don’t want to, or can’t be, dedicated to the point of promising certain hours per week or what have you.
How do you manage the lifecycle of a UR? Do you ever prompt the user a second time for more information? If so, how long do you wait after the first editor message is sent before you prompt the user a second time for more info? How long do you wait before you decide to close a UR when the reporter refuses to answer?
I agree with your first point about new editors working URs because, its that or parking lots. By leaving some URs floating around, it gives a new editor a chance to get engaged, and as red roads give us a visual indication of a new editor to contact, so to do improperly handled URs. It’s like a neon sign that says “PM me, I might want to learn.” Though, I’m not exactly sure how we balance this (the UR scripts are way too good ), while still properly working and solving URs.
There is currently already a “leadership” and a set of community prescribed rules that all editors are adhering to. These are not new rules that are being foisted upon everyone; there is already a standard UR response method prescribed in the wiki. This thread is about altering those rules to deal with the lack of reporter responses now that we have new tools at our disposal.
I will concede that the low UR response rate, around 15% according to UR-MP, is very demoralizing and can lead us to view URs with disdain. I myself was apprehensive about adopting this method because, I didn’t want to spend more time on URs. However, I think that adding the 4 day follow up, increasing the number of messages to 3, will bring in more responses and/or make people think twice about submitting a UR (we shall see if the latter is a good thing).
*edit I think the driver really gets 4 messages. Initial, follow up, closure response, and a Not Identified or Solved notice.
I am for not overwhelming the users and editors with messages they don’t need. So, if left alone – and keep in mind, most of the URs I deal with are already red – I would comment once, wait 5-7 days and close as not identified if there is no response. No need for a warning and no need for “closed due to lack of response” in my opinion, that’s already implied by the “not identified” message the user will get.
If it’s a missed communication, but the issue is burning and the user does want it solved, they will open another UR or do something else. Case in point: the location of LA Fitness in Manassas on Liberia Ave. There were like 5 URs there for a month, and the user really wanted that sorted out.
My point was, though, everyone’s common sense and very loose guidance is enough. There is no need, in my opinion, for strict rules on the number of days or anything else. It’s a lot more important to have quality URs that contain useful data from the beginning.
MisterYu has a good point about how it’s too easy for user’s to submit pretty bogus URs that take time to deal with. It was discussed at the NY meetup with Waze staff so I’m confident they’ll have something to help cut it down at some point.
I can appreciate rules being a bit of a hassle at times, but without a structure, chaos can rain down on any system. A new editor could come in and start “cleaning” up an area just by making rash decisions on closing anything more than a week old without any action and then say “Well, there are no rules against it” for example.
Encouraging new editors to work on URs is a good thing. But they aren’t going to be able to handle them all. We all need to pitch in and do some work on them here and there.
I personally like this idea, I don’t get very many UR’s in my general Eastern Shore area but I do make time to help my fellow editors over the bridge a few times a week. I believe the ratio is 90/10 of UR’s 14 days later being closed with no responses from the OP. The new system shouldn’t affect this very much.
Editors who don’t use tools map can be pretty scattered with UR’s and MP’s and they could be quite the annoyance on the map when skimming around. The 1/4/8 will also keep the map cleaner and free of Stale UR’s.
I’m a fan of the 1/4/8 approach. As Carl pointed out, it would be important to note the actual time between messages, rather than just day counts, especially in some areas that aren’t covered well. I, for example, will address URs that I may come across having been waiting, sometimes for weeks or months, after I drive through an area where I haven’t been before or that I rarely drive through. Most of the time, I don’t get a response, probably because so much time has lapsed that the OR doesn’t remember the UR or the issue to begin with.
Hate to bring up this old post. I have been unable to work on Waze things for a few months due to work, so I missed out on this discussion.
I just want to point out that I once did a UR to remind myself to fixed an issue (was last month too). I forgot about the report and someone asked for more info. Unfortunately I never got the editors request for more info until after 10 days it was sent to the app, and I got the second request at the same time. I just want to let you know I have been seeing some delays and hope this new policy does cause some problems. I like the idea of 1/4/8, but, just remember that sometimes there are delays on the Waze apps end.
That’s disturbing. I’ve been getting a lot of UR updates via email and not noticed any delays. It might be possible the delay was introduced elsewhere, like at an email gateway.
The one good thing about 1/4/8 over the wiki standard of wait 7 days and close is that it inserts that reminder in the middle of the responses at least. So the user at least gets two notifications to respond during that 7 day window instead of just the 1 and then close 7 days later.
Now that we have been following this practice for a while, does anyone have any additional concerns that need to be addressed before we can remove the “in progress” warning at the top of the UR section of the wiki?
Lentz, that sucks, I wish I had a better answer for you than “that’s a waze issue that editors can’t fix.” I have had a message I responded to I the app not post to a UR. The 3 messages gives reporters an abundance of indicators that someone is looking for more info or that their message might not have made it through.
Finally in urban areas there are many new URs appearing daily. A short cycle helps lessen the total number on URs in those areas.
), while still properly working and solving URs.