ArtVictorP wrote:Before this feature, we didn't have to "keep an eye" on an UR, we just closed it as solved or unidentified at the moment. That's why it is said: "Ignorance is a bliss".

That depends more on your community than the comments feature, in México we already had a rule about not closing as "Not Identified" any reports for which the icon wow still yellow.

Good policy! May I know how good were its results? It would be a good idea to apply it in Ecuador too.

In the cities where I'm most active it works well since I try and train the local editors an the correct practices... The biggest problem are the users who don't read the wiki (same as every tool and rule) but I try and get in contact with the newbies I notice to point them in the right direction.

Don't know if it's possible, but some sort of restriction on closing a UR that has a conversation you're not involved in may be useful.

As it stands now: an error is reported. Editor A initiates a conversation for more information. Editor B comes along X period of time later, [doesn't read the conversation, can't figure out what's wrong,] marks it as not identified, and that's it unless the original reporter takes the time to report it again.

With the restriction enacted, Editor B can't close the report until Y period of time later unless certain conditions are met (they're AM/CM/staff, the report has been open for more than Z days, etc). Even if Editor B adds something to the conversation, there would still be a period of time before they can close it.

Just a rough idea that came to mind after having more than a couple URs closed out as not identified within a few hours of starting a conversation by some overly-enthusiastic and rambunctious editors

-Elle EmmeArea Manager, Portland (OR)/SW Washington Metro areaNow these points of data make a beautiful line/we're out of beta, we're releasing on time...

jasonh300 wrote:How do we handle users with driven area permissions that allow them to start conversations in URs but have no ability to edit anything on major roads in the area because their level is too low, and therefore no hope of being able to solve anything?

Perhaps it wasn't your intention, but what I got from that statement is "what good are these useless low-ranked editors? All they can do is ask questions and then not be able to fix anything!"

Which, as a low-ranked editor, is rather offensive

-Elle EmmeArea Manager, Portland (OR)/SW Washington Metro areaNow these points of data make a beautiful line/we're out of beta, we're releasing on time...

jasonh300 wrote:When you make the initial comment on a UR, you become responsible for that UR. Nobody else is going to get a notification that the reporter has replied.

Unless you follow the conversation as well.

So now, the lower level user has to ask for an unlock, or ask for someone else to fix the problem, creating additional complication.

As long as the lower-ranked editor does that, is it really such an issue? How is it any different than a low-ranked editor running across the same problem during their normal editing of the map and posting an unlock request in the forum?

We've worked on and tested this feature for 6 months now to make it a DIRECT communication between the editor and the reporter. Obviously this isn't how it's going to work now that everyone has access to it. This is quickly going to turn into an unmanageable mess.

If you worked on and tested it for six months, then how did this issue never come up? Did no one ever bring up the possibility of rank-locking conversations according to the rank lock of the road the UR was reported on?

edit: also, if it's such a big deal that plebeian editors are forbidden from initiating conversations on roads that are rank-locked and only patrician editors should do so, why isn't it addressed in the Wiki article about URs and conversations?

-Elle EmmeArea Manager, Portland (OR)/SW Washington Metro areaNow these points of data make a beautiful line/we're out of beta, we're releasing on time...

They can still try to locate the issue and report it in a corresponding subforum or thread. Being a local editor or driver, even with no privileges yet, they can have the necessary knowledge, which some CM might be well missing.

In our area it proceeds this way already for ages.

If the UR communications were rewarded with some e.g. 3 points per message, they would also be well stimulated to do so.

...with the good old crashing Symbian 2.1.99.114 (N-E52), whiletrying to get used to the good new social Android 3.9.xx.yyy (SG-A2 JealousBin).

pizuz wrote:When batch-selecting a couple of segments that don't bear the same street name or city name (no common street and no common city), editing one of those fields deletes the contents of the other one.

This has been like this in the editor for two years. This is why, and the interface is quite clear, the No Name checkbox is selected for those fields which will be set that way if you continue.

There have been proposals to Waze to make multiple-selections more user friendly, but none have been enacted yet. Waze doesn't consider this a serious enough issue (it is not a bug) to spend time changing it at this time.

Even if I should agree with this not being a bug, I'm considering it being at least a serious misbehavior

pizuz wrote:I guessed that this behavior was intended, but wouldn't it be possible to issue an explicit warning in that case? At least once?

I could not imagine one reason for such behavior to be intended. Except for simplifying the necessary code...

...with the good old crashing Symbian 2.1.99.114 (N-E52), whiletrying to get used to the good new social Android 3.9.xx.yyy (SG-A2 JealousBin).

The only bit I'd add to some UR etiquette: if someone believes he knows the correct solution for a problem, make it and write about it in the conversation, then just wait a bit more with its closure. If none has an objection against the solution, or the reporter or other communicating editors agree with it it, the UR is free to be closed.

...with the good old crashing Symbian 2.1.99.114 (N-E52), whiletrying to get used to the good new social Android 3.9.xx.yyy (SG-A2 JealousBin).

Now I know for sure. If I follow someone other's map problem, upon its closure the client's Inbox message lies me, that "The map problem YOU've reported has been closed". Even the message's header tells it correctly and mentions the followup. The notification email is correct as well.

It's going on like this for a few weeks long.

...with the good old crashing Symbian 2.1.99.114 (N-E52), whiletrying to get used to the good new social Android 3.9.xx.yyy (SG-A2 JealousBin).