Regarding the USA Map Protection page, I’d like to suggest we add a section called “Manual Locks” to this page, probably right after “Traffic Locks”. The section would read as follows. Hope this sounds like a useful addition.
This is a great set of guidelines to follow when deciding to lock something in the map at a higher-than-normal level. One such example was Lombard St. in San Francisco. The 8-hairpin turns on this steep grade are not ideal for most drivers. Trucks are not allowed and most private citizens do not care to be routed through this difficult stretch of road. SFO has high tourism, especially at this site. There are many visitors who may be interested in “adjusting” the road (as it is set to private to prevent routing). It is not, however, a very important segment for routing as it is only one-way and covers only one city block. Currently it is locked at 4. Had this segment been more significant for routing higher volumes of traffic, it may very well qualify for a 5+ lock.
Using DLs logic could help an editor through some critical thinking before making a final decision.
Definitely agree with this, particularly in areas where some segments may still be locked to old standards and editors might assume that they are remnants that need to be set to the current standard while they have the segments DL’d for other work.
I think the best reason to publish this is to be able to send new editors there so they understand why something is uplocked. One place instead of repeating for each new editor.
Nice job.
Sent from my iPhone using Tapatalk
Love it.
Thanks for proposing this DL. I support your addition. I also think the wording should be adjusted in the first two paragraphs of the throttling section in order to better reflect American idioms (mass editing vs. massive edits, etc). Here is how I think this should be written.
I like the additions. My only feedback would be using the word “hack”. While we all know it happens and what is meant, I think the phrasing should be different. Maybe something like “…involving unusual segment mapping”.
I am sure someone can come up with a better way of phrasing it than me.
Hacks may also be covered under “difficult tradeoffs” and “depart from standard practice”
Nice work … a good summation of what causes experienced editors to deviate from standard locking. And use of MCs is, of course, important point to finish off the section.
Very nice. I would recommending adding the following couple of words highlighted in Blue:
I would like to suggest that the title of the sections in the Map Protection Wazeopedia be changed to reflect that we are talking about locks.
Change Rank Rules to Locking and Rank. Change Automatic lock rank to Automatic Lock. Change Manual rank to Manual Lock.
With regards to the comments about publishing for new editors, the only link I could find is in the locking segment section of the Best map editing practice Wazeopedia. We may want to put a link into the Welcome page. Maybe add the following to this sentence: “4. Not make changes to roads that are connected to locked roads.” so that it reads “4. Not make changes to roads that are connected to locked roads. For more information on locks, please see this article” and link this to the Map Protection Wazeopedia page.
I know that the last paragraph has nothing to do with this particular set of proposed changes, and will be more than happy for assistance to move it to the proper forum topic.
A big THANK YOU for all the supportive comments! As some of you know, in many of my past wiki efforts I hoped to clarify and resolve controversial topics. It’s an understatement to say I’m unused to strong positive consensus – and wow it is really delightful! 
So thanks again.
Normally I’d wait a bit longer, but the response has been so encouraging I’ve posted the addition, first exactly as proposed above, then with modifications suggested here plus a few of my own.
You can see the (extremely minor) difference between the initial proposal and the current release by viewing this diff: https://wazeopedia.waze.com/wiki/USA/index.php?title=Map_protection&diff=163246&oldid=163243
p.s. I support additional improvements to this article as some of the commenters proposed, and I wouldn’t mind seeing a sentence or two on the dangers of overlocking. But I wanted to get the proposed addition out before expanding the scope of the discussion.
Good work on this section.
Coming from a region where we have some higher locking standards when compared to other regions, this is a nice addition to clarify in writing why we have implemented them. There are a few key areas that are locked much higher than one would normally expect to encounter based on exactly what you have drafted. These locks have been effective stopping the undesirable changes that could damage the work done and forcing editors to reach out so we can work with them if there is something that needs adjusted.
Great job on this
This is a great page,
For the risk section I would include something on recent changes that are not reflected in aerial and/or street view photos or even recent GPS traces. So that well meaning editor does not come through and attempt to fix the road segments to match what is seen. This type of fix really unfixes an area. A junior editor can ask for a downlock and get a non-local senior editor who is not familiar with the changes.
Editors will usually drop a map comment but since not everyone has MCs visible the uplock is for the extra protection.
So add “recent changes not reflected in aerial/street view photos or GPS traces” before the current “or that depart from standard…”
Would consider changing “Risk may be mitigated somewhat with the use of a Map Comment.” to “Risk can be reduced, but not eliminated, by leaving a Map Comment explaining the situation.”
Agree with all of the above, although initially I was thinking that subs5’s addition – ongoing construction issues – could be addressed under the “stability” section. Just as long as the aerials-to-reality discrepancy thing is handled somewhere.
It’s excellent to have a place to send people when they ask “Why is this locked so high?” 
Sorry it wasn’t clear, but I am talking about an area that is complete. The new set up is not reflected in the photos or even the GPS traces. There should not be any subsequent changes. Prior to map comments just had a few people come behind and change things and undo the correct mapping. Well intentioned but incorrect. MCs help a lot, but sometimes overlocking can be used.
Well thought out. Thank you for compiling this information!
This is an excellent observation, and it got me thinking about some of my constructions that have been at risk over the years (sometimes far more at risk than I imagined). I’ve substantially modified the “risk” bullet point.
I would be interested to know if my new reference to automated tools is helpful or should be struck. I have had many dreadful experiences on the receiving end of scripts; in my view they substantially magnify the risk involved in all sorts of things, because the operating editor is often not looking carefully (or at least the experiences that stand out for me are ones in which the operator was not looking carefully). I added the sentence regarding even a red TR being at risk, because indeed, a very high-ranking editor recently cleared intentionally-set red TRs at a downtown intersection in a major city because, apparently, some script flagged the red TRs and said they should be green. Hilarity did not ensue.
But I realize automated tools are a complex topic. If it’s felt better I remove that reference, no problem.
Diff (production wiki): https://wazeopedia.waze.com/wiki/USA/index.php?title=Map_protection&diff=163367&oldid=163246
I like your new changes.
Understand the mass editing if very highly discouraged, but have run across some foreign editors using them here in the states and you can’t undo some of their automated changes. Ex accepting PUR for Gas Station to RPP…
I’m wary of this one. If a situation occurs where state management thinks that something needs to be locked above its “difficulty level” because of one editor, something other than segment lock levels probably needs to change.
Most of the time, the solution is education and connection to the editing community. In very rare cases, an RC might decide it is necessary to bring an editor’s editing “power” in line with their editing ability by requesting a reduction in rank for the editor.
That is solved by connection to the community and by appropriate updates to the state or regional wazeopedia page.
Connection to the community, updates to the wazeopedia.
An editor who repeatedly refuses to learn and to work together with the rest of the team might merit a reduction in rank.
This one is difficult to understand. It could mean anything from “difference of opinion” to “kind of a lone wolf” to “downright disrespectful and abusive”
Local guidance can be published in the state wiki page for everyone to learn.
Any editor who feels that some protion of local guidance is suboptimal can discuss it with active editors who drive on those roads, ask recognized experts for advice, even take the matter to the RC team if the issue cannot be resolved at the local or state level. It should be possible to resolve most disagreements about the best ways to map in courteous, respectful, friendly way.
If the community feels one editor is disrespectful and unwilling to work in a positive way and cannot resolve it one-to-one, they can bring the issue to the RC team. If an editor feels there is some issue with editing skill or appropriate behavior by an area or state manager, and if peer-to-peer communication doesn’t help, they can turn to their RC team for help.
I applaud and share the principles you articulated in your post. Unfortunately, over the years I’ve been editing, I’ve come to regard them as impractical.
It just seems to happen that, from time to time, a mid-level editor who has been using his or her rank to make unproductive or counterproductive changes is not sufficiently responsive to mentoring or guidance to gain the trust of local management. The person seems to engage, but the problematic edits continue.
When these cases have come up, my personal experience has been that demotion is effectively impossible. I am told that no less an authority than Waze HQ strongly discourages demotion as a means of managing such things.
So again, though I deeply wish things could reliably work out the way you suggest, I don’t believe the practicalities favor it. My experience has been that senior editors simply must, from time to time, lock certain things with one or more specific editors in mind.
And, even if I agree that this should never happen, the fact that it does happen means that people trying to understand why something might be locked should know that this is one potential explanation.
I agree that the wording on this one is difficult to write with a positive tone, and definitely welcome alternate wording suggestions!