OSM Notes eco system - ID editor improvements

[EwenH]

According to Pascal Neis , since 2013 or so, OSM users have logged 4.76m OSM notes, of which 452,000 remain open, close to 9.5%. Is it time to look at the Notes system and look for short and long term gains...

Quick(ish) implementation
Read mode...

1. When in OSM view mode, use the same Iconography as in the edit mode. This hopefully allows users to see more notes that are clustered with the reduced size.
2. When looking at a changeset, allow users to easily access the note from the changeset noteId or within the item edited.

In Edit mode...

1. When moving into edit, by default, open the notes layer so that local editors can see and rectify issues. Editors can always toggle the layer but expose the issues at hand.
2. Provide a check box to toggle closed notes visibility. It is difficult to sometimes view what needs to be altered with open notes impacting on the closed notes and not all notes being rendered if too many for an area. Get rid o
3. Like the Mapillary id insert into values button, allow users to capture the Notes ID to their clipboard, for pasting into their changeset comments or into the notes key of the entry they are fixing. There is a disconnect that is difficult to trace back to a note once the update has been made. A changeset noteID=12345 would be ideal for this.
4. For open notes < 31 days, add a little asterisk to identify new notes
5. For open notes > 365 days, identify these in a different manner.

Not so quickish implementation
This relies on OSM Notes system but I think additional key/values of Local_Knowledge_Required=yn , expert_Knowledge_Required=yn and perhaps a gamification system where more points are awarded for more complex, older (or brand new) notes where the note is not reopened.

Any thoughts OSM hive mind?

[1ec5]

This has been crossposted to the forum as well.

[DeeKaart]

Hello.

In that discussion on the forum, I suggested that one useful way to reduce the number of open Notes would be to send a notification to the previous mapper:
“[user] has just put a Note on an item you touched on [date]”

My reasoning is that, as I had just done, the previous mapper might well be able to resolve and close the Note immediately IF s/he is aware of it. In my case, I saw the note by chance, because I returned to the area.

Another contributor liked the idea, but stated that "right now notes are not linked to individual objects. Some UI changes would be needed in order to make this possible".

Hence, my question: how difficult would the change(s) be?

I can see that we might need to retain the ability to place a Note on an object which exists but isn't yet on the Map, but I suggest that Key:fixme looks after that requirement.

[Vectorial1024]

The concept is good. However, so far I have observed and dealt with many notes being placed on items that I have never touched before. The in-practice probability of having a "returning note" is just way too low.

There's also this classic question of item detection. Sometimes notes are placed to indicate a problem with the general neighbourhood (e.g. poorly drawn street grids), and then the note would need to link up with many items near itself, and we can't be sure the exact scope. Or, the note may be referring to a missing item that was previously deleted by mistake. It leans a bit into the "undecidability" principle.

However, having said the above, this could work if we may adjust the target to "has just put a note near a (resolved) note that you were interested in". Now that would likely indicate a new development, and the previous mappers will likely have some idea what should happen with respect to the new note.

---

My (probably biased) take is "notes should be triaged, and be triage-able". Kick the unimportant notes to the backlog and pretend nothing happened.

[Vectorial1024]

We have to consider the case of "uncloseable notes": notes that carry very little information, are very difficult to survey/armchair (e.g. remote location, lack of usable maps), yet seemingly contains just the right amount of info that justifies their existence. If these pile up, the notes system simply becomes unusable, no matter what kind of work is done to "improve it", or even no matter the incentive to close it, because these are almost in practice "uncloseable".

The forum post does outline a strong conflict between these two style factions:

• The OSM purists
• The OSM pragmatists

OSM purists definitely want to keep the notes active until a satisfying resolution, while OSM pragmatists view these as distractions and noises when they cannot be effectively resolved.

I find myself being a pragmatist. So far I have seen multiple notes created by anons or by low-activity accounts in rural areas that are this kind of "uncloseable". Attempts to close them as unimportant has met with fierce pushback from the purists.

I view the notes system as a way that OSM members may "escalate" a problem from themselves to the wider OSM community. Examples include the existing gamified mapping apps raising unexpected issues because e.g. we can't know the opening hours of a shop when it was bulldozed entirely. If the problem is not significant, then it shouldn't have a note for it.

Also consider cases where OSM members genuinely want to add something to OSM, but for some reason did not edit it directly and just left notes at the locations, and we would be stuck with a lot of low-value "there is something here" notes that are "uncloseable". Users have to learn to stop misusing opening notes, but on the system level, there has to be a mechanism to harmlessly deal with "friendly misuses".

---

I believe the key is "triage". Not all notes are of equal importance. This should mean:

• ability to classify notes importance (mappers may self-assign importance levels?)
• ability to filter notes by importance

Conceptually this is like GitHub's "issue tags".

This should satisfy the purists by keeping the notes active, while ensuring pragmatists can effectively work with the list of open notes.

Though, this would need additional views e.g. recently-reclassified notes, lest some anon/griefer mass-allocates inappropriate importance levels to notes, and then some mappers will never know of new notes of their interested categories.

---

Pinging @Kovoschiz for some additional perspectives.

[Kovoschiz]

This is an iD repo, not OSM. iD can only style the icons differently, eg date, and number of comments.
You are misrepresenting what you did. Eg you closed a Note mentioning landslide warning sign despite knowing hazard=landslide for your standard of "unimportant". It isn't. It's not "distractions and noises when they cannot be effectively resolved". If you don't want to do it, ignore it. Don't close it for your own personal use.

[Kovoschiz]

However for your purposes, the idea of hiding or fading personally seen, unworkable, or uninterested Note has been suggested. This might be doable in iD. https://community.openstreetmap.org/t/the-osm-notes-ecosystem-possible-changes/145324/29
It may need to be unhidden/unfaded when there are new comments. But this can still be in different styling, less prominent than others.

[Vectorial1024]

The OSM stack can be confusing at times. I typed the above under the impression that this was the website repo. Nonetheless, changing rendering method in iD without changing rendering method on the website would be a huge design/planning blunder. This should then also be forwarded to the website repo.

Besides, iD just cannot effectively offer at-a-glance view of available notes in the larger neighbourhood. Any zoom closer, and then iD instantly becomes sluggish by trying to load everything immediately.

I maintain that there is a systemic/managerial interest to prevent the list of "uncloseable notes" from going out of control. Either we allow it but develop effective management tools, or we conceptually permit closing "uncloseable notes" / "low-value notes".

[Vectorial1024]

But other than that, (I view) it is good practice to do some housekeeping on the list of open notes once in a while.