Likely upcoming tags in iD, review welcome: food= old_name= piercing= indoor_seating=yes/no

There are several new fields proposed to be added to iD presets which in almost all cases would add support for new tags. Feedback is welcome on all of them, but following are especially likely to be soon accepted:

If you think that some should not be supported (or should be), or specific way of supporting them being proposed can be improved: comments welcome.

If given tagging schema is bad and should not be used and should not be promoted by iD presets - please raise the problem by commenting and pointing out the problem.

You can also look at how new functionality will look in iD presets by following links above - if you think that it will encourage incorrect tagging, there are problems with language or see other trouble: please comment.

You can also test preview iD version with this preset included (saving itself is impossible but you can test how interface works).

Even if you are not using iD, GoMap!!, Rapid and any other software using iD presets, it may be still useful to take a look. Bad mapping induced by poorly designed iD presets affects also other mappers, so it is preferable to avoid it.

Comments will be taken into account and can really help! I am not promising that every suggestion will be followed (especially impossible if some are contradicting each other) but many were in past.

You do not need to review code, you do not need to look at code. Though if you would want, this is also welcome.

If you follow links you should be able to

  • see depictions how this will look if accepted
  • see some discussion
  • use preview link to see it in preview version of iD
  • (with github account) add comments
  • (with github account) add reactions, including thumbs up reaction (adding +1 to existing comment is better than repeating it)

If you need more info or preview link went stale: feel free to request it.

I am trying here format different than one in preset thread - hopefully it will be more successful (though big thanks for all reviews that appeared as result of it!).

I am hoping that interested people will look at it, and if changes being proposed are somehow problematic then it will be discovered before releasing it on osm.org and elsewhere. If no negative comments will appear then I expect that all mentioned changes will be merged.

BTW, if anyone want to monitor or review already merged changes: see Releases · openstreetmap/id-tagging-schema · GitHub - first release is not yet released one.

2 Likes

I appreciate the time and effort you invest in sharing your work/findings and keeping the community informed and really I hesitated to send this, but I would like to share some thoughts and questions to better understand your expectations toward the community.

What kind of feedback or contribution are you hoping for with your threads - especially in cases where there are no replies for several weeks? [1, 2, 3, 4, 5, 6, …]

Looking at last year, around 15% of your threads did not receive any replies, and another ~10% only included responses from yourself. This suggests that roughly a quarter of your posts currently generate little to no community engagement. It may be helpful to explore together what could improve interaction.

From my perspective, it is not always clear what kind of contribution is expected from readers. For example, I am unsure whether I should review code (which I am not familiar with, especially regarding iD presets), test functionality, or provide feedback in the form of comments on GitHub. I also wonder whether such input is useful even if I rarely use iD.

Additionally, the number and scope of threads can make it challenging to follow and engage. Many posts include extensive details and numerous links, but often without a clearly defined call to action. This can make it difficult to determine how the broader community is expected to respond or contribute.

As a possible approach, it might be worth considering consolidating updates into one or a few central threads - similar to the PTNA thread. For example, a “News about iD Presets” thread and an “ATP Import News” thread could help structure the information. Interested contributors could follow these threads, while others can more easily focus on topics relevant to them.

I appreciate your ongoing commitment to improving the project and engaging with the community.

2 Likes

At least myself commented in Github many times, where you are asked, and where it belongs, to be organized. Did you check there? Discourse isn’t the most suitable for multi-topic discussions, where the lack of nested threading has pros & cons.
I can agree it can be a single post similar to PTNA, and WeeklyOSM. But this depends on attention.

Yes, comments on Github are better. I have seen them, I have currently enabled notifications across entire iD tagging schema repository, so I see them all.

And thanks for review there!

I was trying to fix specifically this problem here. I edited post to improve it further. Is it still bad?

I tried to include just few selected cases rather than gigantic link pile and add more clearly how people can help.

Now I also added

is it helping, or is it still bad? (maybe both!)

For another idea:

It can be done this way if people would prefer it.

I am trying to balance

  • spamming forums by making too many threads is bad
  • it was requested that iD tagging schema changes should give community opportunity to give feedback
  • iD tagging schema is not finished and ceasing making any changes is bad

I see few options, some of them quite silly:

  • declare that iD tagging schema repository including issue tracker and proposed changes is public and anyone interested should and can monitor it, and people not doing this should not complain, do not post on forums
  • post about upcoming major changes on forum, somehow (I am currently trying to find way that would work well)
    • maybe single consolidated thread would be a good idea?
    • maybe this thread is improvement over previous one, and iterating like this is helpful? And next one (not happening for at least two weeks) will likely go better?
    • maybe entirely different way is needed?
  • post about upcoming major changes on OSM Weekly only, no direct forum posts
  • maybe post OSM diaries, not on forum?
  • ban on adding to iD presets any tags that have not went through successful proposal on Wiki or require other very high barrier like this
  • declare iD presets to be completed and that no new tags will be ever supported
  • post on forum only in truly exceptional cases (no more than 6 threads per year? no more than one thread per year?)
  • ignore waiting proposed changes to iD presets if they try to add new tags

what else I have missed (especially if it would be a good option, working well?)

Besides, 2 examples are ATP imports, which should be announced individually based on a strict interpretation. Otherwise, you need to propose an ATP import in general, which may be too broad.

Your update is definitely an improvement, but it is still (seen in total over all threads) a lot of text to read.

From my perspective, the main remaining issue is not so much the wording anymore, but still the overall volume and fragmentation across multiple threads. Even with improved structure, it is difficult to keep up when many separate topics appear in parallel.

Good point and I agree that ATP imports likely need individual threads due to the import guidelines and their scope.

My suggestion regarding consolidation was mainly aimed at iD preset changes and smaller, non-critical topics, not imports which clearly benefit from separate discussion.

Likely it was mistake to post this thread so soon after another, but I plan to wait for longer before posting next one. Till May? Or is waiting say week or two enough? Or should I wait till June or longer?

Either I will need suspend reviewing any pull requests that add new presets or new fields.
Or recommend merging some without posting about new tags on forums?

(note: I am not an iD tagging schema maintainer, and I have no rights to accept changes there, and changes may be merged without any my input. this applies only to my reviews)

I don’t think you need to wait that long but more important than the exact timing is to be selective about what gets its own thread. Not every PR needs a forum discussion. It might be dangerous, but I attribute the low level of community participation to a sense of weariness with this topic.
If anyone here is really interested in these things, they can simply subscribe to the notifications on GitHub. I’m actually questioning, in general, how useful it is - regardless of the time interval - to invite people here to “discuss” matters on GitHub at all.

I would focus on posting only when:

  • a change is potentially controversial because of the tagging
  • it introduces or promotes a new tagging
  • or community input can realistically influence the outcome

For smaller, non-controversial additions, it’s probably fine to skip forum posts and rely on GitHub review only.

Oh it is a good idea. Though I do that already! Going with everything through forums would be absurd. I can list processed cases somewhere if anyone is interested in a list, currently it has 200+ entries.

The problem is that posts “hey, maybe review this iD tagging schema stuff” were only about cases where it introduces or promotes a new tagging.

And even with limiting what was listed it was clearly too much.

That is too much to post about all such cases, posting about say icon changes alone would be far too much.

Basically, you’re duplicating information from one platform to another. Your goal is clear and fine - you want to attract more attention - but (in my honest opinion) that just doesn’t work. That’s why I’m actually wondering whether it really makes sense to keep asking for feedback here in the forum while linking to GitHub anyway and expecting the discussion to take place there.
The goal should actually be for the relevant people to read along and comment directly on GitHub. But since this obviously isn’t working, my only question is: Is all this noise worth it?

1 Like

I don’t subscribe to repo in Github, nor use third-party RSS. That’s too much, too annoying, for a non-maintainer. Outside of posts from here, I otherwise simply keep and open a window of tabs from browser session management extensions, when I want to look at them.
A megathread can be started immediately. Whether it should daily, weekly, or irregularly when needed (cf official frontend) is up for deciding. What’s new on the OpenStreetMap website?

2 Likes

Thank you for bringing proposed changes to the attention;

have neither time nor inclination to subscribe to, and follow, all sorts of bulletin-boards, mailing-lists, matrix-channels, forum-posts - whatever;

this way I’m at least aware that something is afoot, and can if I feel a contribution, pitch in.

2 Likes