Would it be better to state that an expiration date should be set for map comments vs explaining about removing them for temporary conditions?
I am leary on using an expiration date. If you put a MC for a disconnected ramp that needs to be connected after a certain date, if the MC expires then you might not be able to find the ramp again.
I have no issue with discussing expiration dates but I don’t think it should be encouraged.
Edited and added the following
If MC would send me an email when it expires then I may change my view on it.
I agree with your comments. I reckon I would not replace comments about removing them. I think there are situations that require manual removal for temporary conditions (such as a disconnected ramp) but I also think there are conditions for an expiration date (and an associated explanation of when they are appropriate). For example, I will sometimes use a map comment that contains a link to the closure source for nightly closures (more than one night). I will put an expiration date on the MC that coincides with the last date of the closure. There is no reason for the MC after the closure ends. That way, I wont forget to go back and remove the MC. The MC for closures becomes important when another editor finds a UR that states the road was not closed. As you know, this often happens when it rains and the construction crew does not close the road that night because they wont be doing any work. With a link available, other editors will be able to easily verify the closure data and respond to the UR.
That is a great example of utilizing a MC properly. I would probably suggest you have the MC expire a few days or so after the construction has completed that way anyone working URs shortly after the closure will have the information available to them.
I actually set most of mine to expire at least a couple of days after the construction, depending on the construction. If it is just a week project, then a few days is usually fine. In addition, if the construction is several months long, then I might add a month to it in case of delays (which seems pretty common around here). For example, projects starting now that “end in September”, I’ll expire my MC at the end of October. If I check on it mid-Summer and it is really behind schedule, I might even extend that.
A feature that I would like is the ability to set a reminder, so the MC sends me an E-mail on a date I set it for to check on it. Right now, I just put reminders in my calendar (for certain things, not all of them). But, an E-mail when it is about to expire or (especially) when someone else deletes it would be really nice.
ETA: If there is an action I need to take at the end of the construction (like the example earlier about needed to reconnect a ramp), I certainly wouldn’t set that MC to expire. Even if I forgot, at least someone else might stumble on it eventually (or when the URs stack up there).
So I have tried to incorporate recommendations here on the text of the “When to use map comments” section, as well as editing some of the style:
[code]Map comments should be used for conveying out-of-the-ordinary information about specific areas of the Waze map to editors in order to properly maintain the map. In the past, editors have used road segments or Update Requests put in from Live Map to make such notations. These notations should be replaced by map comments.
Possible uses of map comments may include:
unusual configuration (intersection configuration, naming, turn instruction overrides, and other hacks that are not otherwise obvious)
insightful forum discussions regarding the area in question
flagging temporary or missing information, such as
locations where the aerial or StreetView imagery is out of date, due to removal of places or roads (e.g., permanent closure of roads and places) or new places or roads (e.g., new subdivisions)
construction information, temporary or future traffic changes
missing information that you cannot gather (e.g., missing house numbers or road names in a new subdivision) or requires confirmation (updated SV and/or satellite imagery)
The use of map comments should be carefully considered to avoid overuse. Therefore, map comments used for flagging temporary or missing information should be deleted or set to expire when they are no longer necessary (e.g. missing information has been added, or construction has completed and StreetView has been updated to show the change). Removal of map comments should be done either in consultation with original author of the map comment or with the SM/RC.[/code]
Are we good with this?
Looks good to me
Looks good. Thanks!
Content is good.
May I recommend we format the examples as bullets or entries in a multi-column table? It is very hard to follow that section. I can help with the wiki coding if needed.
I have made the changes to the section, since it looks like we had agreement on the content. I organized the possible uses into a table and linked them where I could. I changed the wording to be a little more organized and clear, and I added a couple more examples, such as realignment and controlling U-turns.
Great job on this.
I updated the WME editor control page to link back here for details.
Reviewing it one more time I noticed a few items I’d like to propose (which then cascaded into this 
):
- Should the page title be “Map comment” singular per our style guide discussion thread?
- The MCPanel.png image is being resized down. Unless it is a close multiple it causes somewhat blurry text when the font is so small. Since the original image size is not much larger than 250px wide, I recommend just removing the resize. I tested it and it looks fine still in the layout, but removes the blurry effect that personally annoys me when the original image is so close in size. You will need a {{clear}} before the next section.
- The section titles should be updated to remove the repetition of the page name per our style guide (still under construction ). You could use 1) “Creating” or “Creation”, and 2) “When to use”.
- In the creation section, I think it would be good to more clearly point out each of the parts of that screen. In more complex examples we actually create subsections, which is overkill for this. Instead I think you can just use a bullet list with bolded field descriptions followed by the text you have now. (Example - Scroll down to the Settings tab.) Be sure to order them as they appear on the screen.
- We don’t have anything covering when to select area vs place. It should be added and included in the list above.
- I’m thinking the last sentence should be a separate section “Removal”. Maybe repeat the comment that if they are set to expire, there is no need to remove them.
- Maybe wikilink the SM/RC comment at the end.