<div dir="ltr">** UPDATE: **<div><br></div><div>The service now supports "reject" button.  To use it, your query must contain "  #queryId:...  "  comment.  By default, when a user rejects something, a tag "_autoreject=id" is created. An object can have multiple rejected IDs. If the current query was previously rejected, user will no longer be able to edit the object with the same query.</div><div><br></div><div>Optionally, query may specify a different rejection tag with   "  #rejectTag:...  ", instead of using the default "_autoreject".  I am still hoping for a better default name.</div><div><br></div><div>Both #rejectTag and #queryId values must consist of only the Latin characters, digits, and underscores.<br></div><div><br></div><div>Additionally, the tool no longer allows editing above zoom 16.</div><div><br></div><div>Thanks!</div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 14, 2017 at 12:34 AM Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com">yuriastrakhan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Simon, thanks for the constructive criticism, as it allows improvements rather than aggravation. I propose that "rejections" are saved as a new tag, for example "_autoreject".  In a way, this is very similar to the "nobot" proposal - users reject a specific bot by hand.<div><br></div><div>_autoreject will store a semicolon-separated multivalue tag.  A query will contain some "ID", e.g. "amenity-sanatorium", and that ID will be added to the _autoreject whenever user clicks "reject suggestion" button.</div><div><br></div><div><div>Benefits:</div><div>* use existing tools to analyse, search, and edit this tag, without creating anything new<br></div><div>* we can use it inside the queries themselves to say "only suggest to fix X if the users have rejected Y", or if someone creates a bad query and most values are rejected, we can easily find them and clean them up</div><div>* very easy to implement, few chances for bugs, no chances to loose rejection data by accident</div><div>* other tools can also use this field to store rejections, e.g. mapRoulette or Omose.</div><div>* Query authors can easily search for it to see why they showed up in the query result, and fix the original query</div><div><br></div></div><div>The biggest problem is the tag name, any suggestions?</div></div></blockquote></div></div></div>