I replied to your comment in the Walking Trails thread.

bummerdude69 wrote:Should adding House Numbers be included in the Constructive Work section? With link to https://wiki.waze.com/wiki/House_Numbers.

Properly done HNs have rescued difficult situations a number of times in my experience. At the same time, improperly done HNs have caused horrible headaches.

Once, for example, an editor activated HNs along a divided road through an industrial park in Santa Clara. Well, for starters, all of the destinations involved are reached via parking lot roads, not directly off the street, so the newly-active HNs would not help routing that much even if done correctly. But to make matters worse, the editor activated them on the wrong side of the divided highway, and U-turns were sparse, so traffic to these destinations was being routed around so it could approach them the wrong way! What a mess. And because HNs are not visible to editors ranked below the lock of the road, the primary editor trying to understand the problem could not even see it! (Yes I know about Practice Mode -- now.)

In the back of my mind is also the worry that activating HNs will become something of a Cow Clicker if editors start adjusting them en masse without any investigation. I keep thinking that if Waze wanted all of them to be enabled without investigation, they would have done so when HNs were imported. So, if done properly, activating HNs can be slow. But still definitely a contribution.

Maybe the right approach is to create a new entry for "Improper House Number Activation". With that in the article, then it can be added to "constructive work" list. I'll think about that!

@dude463 you're right, WME behavior does seem to have improved to improve editors' chances of doing the right thing when mooving HNs. Now, if they'd make HNs visible to editors of any rank that would be even better

@tonestertm thanks, my concerns were extrapolated from theory and a handful of events. Good to know these concerns haven't turned out to be significant in your experience.

Does anyone think that an "improper HN activation" section could be appropriate as a common mistake for brief treatment in the article? Since WME is better about choosing the closest named segment, the new wiki section would just refer to enabling HNs for locations reached by side roads at some distance from the named road.

After much discussion, the Road Types (USA) wiki article has a completely new section on Walking Trails.

As a result, I have restored (and completely overhauled) the corresponding section in the Incorrect Edits article.

Like every single one of us, you have been caught in the Waze editing vortex.

The vortex starts out by encouraging you to edit with no training except an optional and counterproductively obsolete video.

Then it presents you with a user interface in which Highways are not necessarily highways, walking trails are not necessarily Walking Trails, Pedestrian Boardwalks are not necessarily pedestrian boardwalks, and parking lots are not necessarily Parking Lots. Where the display shows roads appearing to connect that don't necessarily connect. Where the interface offers U-turns that, while legal, should not necessarily be enabled. Where mapping a private alley can corrupt routing to adjacent destinations. Where an update requested by the system is not an Update Request and a problem with the map reported by a user is not a Map Problem.

What do you suppose happens next?

Mistakes. Lots of them, by every single one of us. Guaranteed.

Personally I agree with you that Waze could dramatically improve editor morale and map quality by requiring some kind of basic training before allowing people to edit. Or at least by overhauling the user interface so it is more intuitive. But, they have shown no interest in these things. This forces the community into the role of cop whether we want it or not. And folks who assumed they were helping find out that they weren't.

When you find things are not as you assumed they would be, please, step away for a bit, and think about what you can do that is fun for YOU right now. Do not require Waze or the community to change before you can start having fun. If you can't have fun under those circumstances, then you are right, it is time to find another hobby. We are just volunteers! Help out at a pet shelter, take meals to the elderly, show kindness to strangers. There are other rewarding things to do in life.

I have had lots of rough spots with Waze. But I keep finding things to do that I find fun, so I keep editing. Maybe there is something in Waze for you too.

I'm really honored, and thrilled, that you've found the page so useful. And it's wonderful that you expressed your experience, and so kindly. Thank you!

As you've seen from a few posts up, you're not the first to have this reaction towards the lead-in language. I agree it is time for this page to lose the "why this page exists" language. That may have been useful at one time -- I'm not sure -- but it's not now.

Let me see what I can do.

Let me know if this comes across as more helpful and understanding.

Alternative Incorrect Edits lead-in wrote:
This article reviews the most common editing mistakes in Waze. For those new to the [[Waze Map Editor]] (WME) it describes these mistakes and how easy it is for anyone starting out to make them. For advancing editors and Area Managers, it describes how best to respond to the mistakes when they are discovered. Finally, it discusses productive ways for new editors to contribute with minimal risk.

Incorrect edits are a natural part of Waze

Waze created the WME with the desire to attract as many editors as possible. To this end, the WME allows anyone to change the map quickly and easily without reading, training, practice, or tests.

Beneath the WME's attractive and welcoming exterior, however, lies cutting-edge technology. The WME provides expert tools that behave differently depending on minute and often invisible details. Under some conditions the WME behaves counterintuitively and trips up experts and beginners alike.

This situation guarantees that no editor will escape the WME unscathed. We all make mistakes, and lots of them.

This article discusses three categories of typical confusion: misunderstood principles, functional mistakes, and misunderstood conventions. Before discussing those, however, it's critical to bring up one kind of incorrect "edit" that is worse than all the others put together.

Some additional concerns regarding tone have come my way, and it seems a good time to say again why I wrote this article and who I wrote it for.

As discussed above, I definitely do see an issue with the tone of the lead-in paragraphs and am changing those! But overall, I think the "common mistakes" tone of the article serves three critical goals.

First, I am concerned that the tone of any wiki article, certainly this one, not make light of damaged maps. I believe damaged maps are a serious affair. A new editor can ruin the commute for thousands of people, and I think an article like this needs somehow to convey the weight of this responsibility. I may not have done the best job of that, and will look again. But I believe it's critical new editors understand that real people are affected by what they do and that the community takes this seriously.

Second, I feel that recasting the article in a positive tone would lose its target audience: editors who don't read the wiki. These folks get a PM out of the blue and are annoyed because they are sure they did it right. Their question is never "well, how do I do this correctly?" It is always "tell me what I did wrong, explain to me why it was wrong, and make it quick!" I can say this because I have had this attitude myself

To this end, I wanted Incorrect Edits to be compact, communicating as much through images as through text. For depth, Incorrect Edits would go no further than the absolute basics associated with the mistake, but would provide links. I wanted the article to answer only the immediate question "what did I do wrong" while at the same time providing a tantalizing gateway to the wiki.

A third goal that is somewhat hidden but, I think, absolutely critical: Incorrect Edits provides a community-approved response path for editors who discover problems. This gives the responding editor crucial moral support for changing another editor's work. This was in fact the original driving intent for this page, and that's why the first name was "Responding to incorrect edits" -- it was initially aimed at responders!

I hope this clarifies the goals for this article: take map damage seriously, answer the question "what did I do wrong" as quickly and clearly as possible, and provide support for responding editors. To the extent the tone supports these goals then I take that as a positive.

It's not so much another way of looking at it, but rather optimizing for different goals.

It sounds like your primary goal is the enthusiasm and retention of novice editors. That is a fantastic goal! Nobody will argue with that. Certainly not I.

But that's only one of our goals. There are others. The three I stated were: convey the seriousness of what we are doing, answer the question "what did I do wrong" as quickly and clearly as possible, and provide wiki and moral support for advancing/responding editors.

The question is not which of these goals is correct. I am sure you don't disagree with my goals any more than I disagree with yours.

The question is how we prioritize goals. But to prioritize properly, we need good metrics for map quality, driver satisfaction, and retention rates of both new and (!!!) advancing editors.

As far as I know we don't have those metrics. Without them, I don't know how we can prioritize among the different goals. Each one of us has to do what feels right.

(p.s. I want to emphasize the importance of supporting advancing editors as well as new editors. In my case, every senior and advancing editor I worked with in my immediate area when I started editing -- nearly two years ago -- has apparently quit. Supporting advancing editors can be a very different goal from supporting new editors.)

The lead-in paragraphs of the article have been changed, with additional adjustments. Unless wiki functionality has changed recently, one will need to be logged into the wiki to see the changes, at least for some number of weeks.

Thanks very much indeed to those who pointed out the shortcomings in the previous language. You've helped improve the article for everybody who comes across it.