osmcha-frontend icon indicating copy to clipboard operation
osmcha-frontend copied to clipboard

Change "bad" to "needs improvement"?

Open willemarcel opened this issue 7 years ago • 4 comments

On SOTM, a user suggested to change the changeset verification term from Bad to Needs improvement. I agree that "bad" is too much negative, but a long term will impact the frontend interface. So we should think about it... @batpad @rasagy

willemarcel avatar Jul 29 '18 10:07 willemarcel

I was that person that suggested dropping the bad to something like Needs Improvement. One option would be to drop the good/bad and just go with the checkbox tags already there. I'd also like to see if we can categorize the edit with items like didn't square bldg, wrong or omitted tags, used abbreviated street names, incorrect classification of streets, etc. By classifying errors we might be able to cause fixes to editors and see what we can do to improve instructions. I'm happy to assist.

cliffordsnow avatar Aug 04 '18 16:08 cliffordsnow

Sometimes a changeset has both good and bad changes (mostly accidentally bad changes) it would be good to be able to tag to reflect that.

:+1: to tracking the cause of issues, eg.

  • issues caused by https://github.com/openstreetmap/iD/issues/4776
  • People thinking they are adding private bookmarks in Maps.me, but instead updating OSM

I also agree that "Bad" from a social/community point of view may not be the best choice, it could easily load to contributors on the receiving end feeling insulted or attacked by their changesets being labelled Bad.

andrewharvey avatar Sep 06 '18 12:09 andrewharvey

I remember seeing somewhere that the "bad" changesets are used to train machines to learn to identify damaging changesets. I think it might reslt in interesting data if we can mark "bad", "needs improvement" and "good". Allowing tagging before needing to mark "bad" would also work.

joostschouppe avatar Mar 17 '22 09:03 joostschouppe

@joostschouppe thanks for bumping this!

I whole-heartedly agree with changing Bad. And also agree that giving the user more options to add specificity to "what was wrong" is going to be extremely useful to both humans and machines who might use this data-set in the future.

I can see with the current UI, there maybe hesitation to mark a changeset as "Bad" for say, a single minor error in 100 otherwise great changes. How about this as an idea for how the UI could work:

Currently, a user is asked to choose between Good and Bad, and after they select Bad they are presented another menu with tags they can add to the changeset to give more details about "why" it was bad. How about:

  • We have a single check-box for something like "Is Good", or "Verified" or "checked", which does the same thing as marking a changeset as "Good".
  • We surface the drop-down of tags immediately, so there is no explicit step of marking "Bad" before the user sees the dropdown with tags. We always show the drop-down of tags, and when a user selects a tag, we do the same thing we are doing in the backend for a user marking Bad + Adding a tag, so we don't need to change the schema on the backend. I think this can serve multiple purposes: remove this judgemental "Bad" word from the UI completely, remove an extra step for the user to add a more granular tag, and also force users to add a tag to describe the reason for flagging the changeset, as having these tags is likely going to be very useful to train our future machine overlords.

@willemarcel does this sound reasonable?

The only problem I see is that this would allow the user to mark something as "Good" as well as add a tag to it - would probably need to check what implications this might have on the backend, or how we could design the UI to actually disallow that - i.e. if you select a tag, it automatically unselects the "All is good" checkbox. That bit might need a bit of thought.

batpad avatar Mar 17 '22 10:03 batpad