-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add requesting review #4223
Add requesting review #4223
Conversation
It'd be good to sort the tagging out with the community, not on the iD issue tracker. |
Why? My feeling has always been that:
I am really happy to change the tag, if anybody cares. It doesn't have to be |
(doesn't really add anything and not written for newbies)
uiCommit is getting kind of big as we add more to the commit pane. I'm going to split it up and put the field rendering code into a separate module, similar to how uiEntityEditor embeds uiPresetEditor for the fields. This allows us to add a few more fields that users can set on their changesets (like hashtags, source), and even hide them under a "Add field" dropdown.
I realize I could check this out and look, but what are y'all thinking about for prompting the user to ask for review? A popup? A checkbox near the changeset save button? |
This request review field is great and I could merge it right now, but instead I'm going to spend some time to refactor the commit pane a little bit - it is like 500 lines of code and getting difficult to manage as we add things to it. Managing a bunch of fields and the tags that they change is something that @iandees, here's a screenshot showing current placement of the checkbox, along with some dummy fields that I stuck at the top. The dummy fields are being rendered by the new |
Refactoring the commit pane by using the new
and some scope creep..
|
It would be great to think of a way to call out that "request review" checkbox, especially for new folks. Can it pulsate or be a different color or have an arrow with a friendly globe suggesting they give it a try? |
I have thoughts on this request review checkbox and how it might be perceived by different kinds of users. Not everybody wants feedback on their edits. For example, millennials may be more likely to want the feedback, and genx'ers may be more likely to not want the feedback. Majority users may be more comfortable with public edits, and minorities may not feel comfortable having their edits under additional scrutiny. I think this feature could be very helpful and welcome to a lot of people - especially new users - but I don't want to put assumptions into the software, and so that's why we ask the user whether they want the review or not. Also at this point we don't know how many people will check the box, or who will step up to do the reviews. The answer is some combination of - OSMCha, whodidit, bots, rss feeds, dedicated validators, paid mapping teams, and volunteers. I thought about just checking the box if it's a user's first edit, or having the preference be "sticky", but I don't want to promise something the OSM community can't deliver. So for now, let's leave the box unchecked, and "opt-in" to review. We can change this later and encourage more users to check the box, if after a few months we decide that the reviews are working well and helpful. |
Agree with @bhousel -- until we know how many requests will actually be honored it's probably better to not call it out too much. If people don't want to review or use discouraging words to do so it would just serve to turn more people off than the other way around. |
Also includes a bunch of css cleanups for the tag-reference section to fix style for readonly raw-tag-editor rows and adjust margin widths
Hey @talllguy, one benefit of the recent refactoring work is that it makes it super easy to just reuse fields like the ones that iD already has other places. We don't have a field that's an array-of-checkboxes, but we do have a multiselect field that turns the values into a semicolon separated list. What do you think of this?: |
@bhousel I like to see this fields reused this way. This implementation looks cool! I'd use this. Next steps would be using an algorithm to analyze the changeset comment and other metadata to suggest source tags. ;) |
FYI just pushed a working implementation of hashtags (see #2834). The idea here is to give mapathons, task managers, QA tools, a special field to store their hashtags, instead of (ab)using the comment field, which some people don't like. Hashtags will also be settable through the API just like comments currently are. |
(it will say "0" for someone making their first edit)
These tags all start with `ideditor:` (closes #3968) ``` ideditor:walkthrough_completed=yes ideditor:walkthrough_progress=welcome;navigation;point;area;line;building;startEditing ideditor:walkthrough_started=yes ```
Just merged this - thanks for your patience! |
…the `review_requested=yes` changeset tag. Inspired by: - openstreetmap/iD#4133 - openstreetmap/iD#4223 - http://neis-one.org/2017/09/review-requests-osm/ git-svn-id: http://josm.openstreetmap.de/svn/trunk@12719 0c6e7542-c601-0410-84e7-c038aed88b3b
…the `review_requested=yes` changeset tag. Inspired by: - openstreetmap/iD#4133 - openstreetmap/iD#4223 - http://neis-one.org/2017/09/review-requests-osm/ git-svn-id: https://josm.openstreetmap.de/svn/trunk@12719 0c6e7542-c601-0410-84e7-c038aed88b3b
…the `review_requested=yes` changeset tag. Inspired by: - openstreetmap/iD#4133 - openstreetmap/iD#4223 - http://neis-one.org/2017/09/review-requests-osm/ git-svn-id: https://josm.openstreetmap.de/svn/trunk@12719 0c6e7542-c601-0410-84e7-c038aed88b3b
This adds review request.