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.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".
Edson Jiménez
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.ArtVictorP wrote:Good policy! May I know how good were its results?edsonajj wrote: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.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".
It would be a good idea to apply it in Ecuador too.
Edson Jiménez
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
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 Emme
Area Manager, Portland (OR)/SW Washington Metro area
Now these points of data make a beautiful line/we're out of beta, we're releasing on time...
Area Manager, Portland (OR)/SW Washington Metro area
Now these points of data make a beautiful line/we're out of beta, we're releasing on time...
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!"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?
Which, as a low-ranked editor, is rather offensive
-Elle Emme
Area Manager, Portland (OR)/SW Washington Metro area
Now these points of data make a beautiful line/we're out of beta, we're releasing on time...
Area Manager, Portland (OR)/SW Washington Metro area
Now 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.
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?So now, the lower level user has to ask for an unlock, or ask for someone else to fix the problem, creating additional complication.
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?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.
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 Emme
Area Manager, Portland (OR)/SW Washington Metro area
Now these points of data make a beautiful line/we're out of beta, we're releasing on time...
Area Manager, Portland (OR)/SW Washington Metro area
Now 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.
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 (on N-E52), while
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
Even if I should agree with this not being a bug, I'm considering it being at least a serious misbehaviorAlanOfTheBerg wrote: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.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.
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.
I could not imagine one reason for such behavior to be intended. Except for simplifying the necessary code...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?
...with the good old crashing Symbian 2.1.99.114 (on N-E52), while
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
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 (on N-E52), while
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
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.
It's going on like this for a few weeks long.
...with the good old crashing Symbian 2.1.99.114 (on N-E52), while
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
trying to get used to the good new asocial Android 4.xx.0.yyy (on OP-X March-me-Low).
Re: Official feedback thread - v1.3 - Schedules & Conversati