-
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
Validation: Add "learn more" per validation issue #5900
Comments
I think I'm in favor of this. @bhousel is adding an info ( What do people think of creating pages about general QA principles/issues? Like "QA:Road Crossings" or "QA:License Compatibility". There could be subsections about how various tools detect and handle issues (like iD, JOSM, KeepRight, MapRoulette). That way there could be unified documentation on how to resolve common issues. Some pages that list types of QA errors:
Cc: @1ec5 and @nyurik, who may know more about how the wiki works. |
My thoughts where: There will be cases when the validator will not fit perfectly. Or even if it does, I will not always understand what it wants from me. In similar situations for tags, I am happy to have an easy way to get to the wiki. – And maybe this could be the first step here. Scribble: This has the advantage: No need to add new pages to the wiki. But the existing pages might still describe edge cases of validation, if helpful. |
For QA, we could introduce a new documentation section (after all, wiki is the central docs place). I would also suggest using a new type of a data item - "validation rule", which would:
This approach will give a permanent ID to the validation rule itself, so that many systems can re-implement it and just reference it for everyone to understand what it does. P.S. @tordans actually my approach could be merged with yours -- the validation rule data item can link to existing docs or even sections rather than a dedicated QA wiki page -- we could have both depending on the rule itself. |
I don't think I'm quite ready for the iD validation rules to be attached to permanent ids. We're still changing them! per #6218 I'd like to merge some of the rules together into the kinds of general categories that a human would be interested in ("some tags are old") rather than hyperspecific checks that a machine (or OSM pedant) would be interested in ("multipolygon tags should be on the relation and not the outer"). I don't want to burden our users with 100 checkboxes in the rule list (like osmose does for example). |
Agreed. This is why I suggested general-purpose QA pages where users could learn about handling issues in the abstract. |
I really like the fact that iD links to external sources to learn more. Like on the tag, there is the (i) that pulls from the wiki and links to the wiki. I use that a lot to learn more about how to properly use the tag.
This pattern could …
a. help to make the validation issues a learning moment, where the linked page explains more about OSM, the tags involved and the issue at had.
b. help clarify validation issues that have more than one solution, like #5891 for example.
The linked pages could be markdown files inside the iD Codebase. Or links to the OSM-Wiki in a separate namespace.
The text was updated successfully, but these errors were encountered: