Proposed work on iD triaging & improvement of iD tagging schema

General talk
1

Dear OSM Community,
@Mateusz_Konieczny has proposed to the OSMF EWG the possibility of funding work on issue triage for the iD editor and iD tagging schema repositories, and improvements to the iD tagging schema repository, which would fall under the EWG budget. The request can be found at proposing work on iD triage and work on improving iD tagging schema by matkoniecz · Pull Request #58 · osmfoundation/ewg_bidding · GitHub

Per EWG’s request, I am now opening a 2-week public consultation to ask whether the OSM community has any issues to raise regarding this topic. You can answer either in this thread or in the previously linked issue at the EWG Bidding repository.

Best,
Héctor
on behalf of the EWG

6 Likes
2

Well the very obvious issue is that you are asking the community to discuss this in a financial vacuum.

Not only is no price tag associated with the proposed activity, neither the EWG nor the OSMF have a published budget which could be used to actually fund it.

I’m sure there are lots of things that the community would find great to have in the abstract, but except if the EWG has invented an unlimited money making machine, spending more money in one place will take money away from another task. And you are not being transparent about what that would be.

8 Likes
3

proposal text (linked from proposing work on iD triage and work on improving iD tagging schema by matkoniecz · Pull Request #58 · osmfoundation/ewg_bidding · GitHub ) has costs section that seems to be covering this.

I added to the updated version of a proposal

192 hours at 14 GBP per hour would bring costs to 192*14 = 2688 GBP.

line for clarity. Maybe it also appear in summary at the beginning?

as mentioned in later section: I agree that if it can be spend for something better or it is better to keep funds as a reserve it would make sense to do so, and funding this one makes sense if it is better than alternatives. Including not spending funds at all.

6 Likes
4

Or funding more depending on the discussion !

5

The 2026 OSMF budget was approved at the public meeting last month (the minutes are still not finalized, but will be available here later this month: Board/Minutes/2026-01 - OpenStreetMap Foundation).
One of the lines approved for the EWG is “Various website work”, with £25k allocated for it. A similarly named budget line was approved in previous years, and the EWG has been putting in requests for bidding on this line at GitHub - osmfoundation/ewg_bidding.
However, in 2025, no bid was put in by the EWG, mostly because of the lack of time from its volunteers. That meant that the allocated 2025 budget for this line was unspent.
However, funding for website development has not stopped from the OSMF side, as our Core Software Development Facilitator and Core Software Engineering have been working to advance development of our website and core software, but this came from a different funding line, as it’s STF money. And, of course, for iD continuous development since 2021, again a different funding line.
As volunteers, time is limited, and the EWG has welcomed this proactive approach, which helps prevent this line from going unspent again during 2026. We still, however, need to decide how much of the line to spend in the proposal if it goes forward.

6

Thank you for raising this point here and for the proposal to tidy iD tagging’s repository.

At short term, it’s great to give some funding to a very time consuming work. I support it.

At medium and longer term, it would also be great to invest on a new process to save us not only funding but also time with shouldn’t-be-an-issue tasks.

It’s true some tagging require particular investigation to be implemented in editors. Other don’t.
Okay to fund the cleaning, but what will ensure us the issues list doesn’t become messy again?

7

what you think now, after being pointed to cost section and EWG providing some additional info?

8

It is all about financials (and staffing), you are not going to find somebody saying triaging issues and PRs is not a good thing including myself. Do I consider the situation with PRs and issues particularly dire for either project, not really, they are about what you would expect, but others might disagree.

But you would expect that the EWG has at least a rough idea of their own priorities and could use those to decide the issue assuming they have budget.

9

The EWG has just decided to approve @Mateusz_Konieczny’s proposal. The work will happen over the next 12 weeks, starting today.

1 Like
10

Just a reminder: the budget still hasn’t been published even though in the mean time there has been another public board meeting.

PS and off topic: wrt the last board meeting, organisations wanting to benefit from sticking official “OpenStreetMap” participation on their grant/project applications is nothing new. During my time and I believe later this has always been rejected as of literally no actual benefit to the OSMF and at odds with the structure of the project. Naturally if we now have under utilised employees that can be sent off to waste their time this might be viewed differently, but how would I know, see the missing budget.

11

So from February 21th to April 23th I spend 192 extra hours on iD and iD tagging schema, thanks to funding from OpenStreetMap Foundation.

Grant covered work on reviewing code changes proposed by others (pull requests), testing code and implementing changes as needed.

On topic of thanks - I want to thank k-yle[2][3][4][5][6][7][8][9], ak8abhinay[2][3][4][5][6][7][8][9], ashree2118[2][3][4][5][6], gy-mate[2][3], tyrasd[2][3], JaiswalShivang[2], tordans[2], Ambuj123554, codeinabox, cuatim, danieldegroot2, Geo-2695, hlfan, Hufkratzer, ivanfang-dev, Kaushik4141, Kayd-06, michaelblyons, olafkryus, petercooperjr, sanatsathaye, sbraz, sezerbozbiyik, tiptoptom, tjasz, Vectorial1024

Their proposed code changes (pull requests) were merged as result of this review. Thanks for your improvements and helping to make mapping easier! Some code that was waiting for years is now finally reviewed and merged. And is now in use helping to improve OpenStreetMap - or will be on the next release of iD.

Also thanks to people who created pull requests and issues that remain unprocessed - for now. I tried going over all pull requests and issues in iD, iD tagging schema, iD schema builder repositories. But there was no time to fully process all of them. Some were not processed at all.

Also thanks to all people who created useful issues - I also implemented some of them.

You can see full list of processed issues and pull requests if anyone is interested in extra detail. Some effort went into closing issues/PRs. This is sadly necessary in some cases. It is useful as it makes actionable cases easier to find.

Things have not went 100% perfect with no mistakes but overall things went really well.

For things that went poorly… I tried gathering more feedback about some considered changes.

Threads New presets entries proposed to be added to iD tagging schema - list, feedback request and Likely upcoming tags in iD, review welcome: food= old_name= piercing= indoor_seating=yes/no went not well. I am still thinking about a better way to gather feedback. I will likely create a diary entry listing some cases, maybe with attempted submission to OSM Weekly. For now I was focused on cases where it is less necessary to get feedback from wider OSM community.

Also, it appears that latest iD tagging schema release (that I asked for) was not sufficiently coordinated with iD release. So new icons are blank for now. So sorry for this bug, but it will go away when iD will release a new version. I will also try to prevent future occurrences of such problem.

Hopefully that completes list of problems.

I want to note that I spend also some time on related forum posting, editing OSM Wiki and fixing bad map data I spotted while doing all of that. But this map editing and forum activities (including preparing this post) and wiki time were not covered by grant, and were not paid for. Though, some - like this post - would definitely not happen without it.

I am interested in extension of the grant, also at rates discounted from commercial ones. Though less discounted than this already completed part. Partially because my rate was really discounted. Partially because low-hanging fruit in form of time-consuming but relatively easy and nice (for me) tasks is now mostly exhausted.

But if no grant will happen, I plan to continue helping there as I did before the grant. But it would not be viable for me to do as much as I did over this last two months.

25 Likes
Proposed work on iD triaging and id-tagging-schema improvements (redux)
12

Thank you for the work you did here and for finding a way to do it (AKA setting up the grant). From my perspective, the kind of communication, “gardening,” triage, problem solving, and fixing (smaller) things in the tagging schema and iD ecosystem is a huge help for many OSM projects.

As a contributor, I can say it is very motivating when someone like you is there to help get my ideas thought through and merged (or rejected). So much, in fact, that I think we saw an uptick in contributions because of this work. It also frees up time for other contributors and maintainers to work on more complex or long-running tasks, which again has a big impact on the projects.

For those reasons, I would very much welcome it if your funded work on those projects continued!

6 Likes
13

Though statistics on that will be quite confused by

  1. GSoC-related PRs arriving at the same time (though that in turn made triaging more useful)
  2. PRs made directly by me

As usual, statistics are hard if you are interested in actual underlying events happening and why they actually happen.

But at least in schema-builder it directly triggered some work toward release happening.

14

I’m excited to see this and that OSMF saw it fit to value it with a grant. Thanks for the thorough report-out.

And I agree with @tordans - iD doesn’t lack energy, ideas, or a user base, but it does lack governance and investment of someone with knowledge in the code base in doing deep triage goes such a long way in helping the many people who are writing code or documenting issues to feel like it matters that they spent the time!

If you were to extend the grant, I’d love to see a roadmap developed. I’d volunteered to do some triage quite a few years back, but quickly realized I had nothing to reference for what was in-scope or out of scope, and I couldn’t close a lot of issues that were likely out of scope because I just didn’t know. I feel like on the heels of your recent work, a roadmap that lets contributors know if their work would be likely to be accepted would be a huge deal.

Thank you again! I love seeing improvements to iD!

1 Like
15

For anyone reading here, a great contribution that could be made to iD tagging schema presets with a very low entry barrier is translation.

Even in languages that show as complete and near-complete in Transifex, there is something that can be done to improve discoverability of presets, and that is adding more synonyms and terms.

Synonyms are added below the primary name, separated by ↵ (newlines).

Terms are just terms with which the individual preset can be found, by typing, e.g. a term for a household goods store could be “pan”, “pot”, “tableware”, “cutlery” etc..

image
image1144×294 28.3 KB

An issue with at least the German translation is that

  1. people attempted to translate English terms, no more, no less, even though e.g. “Porta John” is not known in German, rather, the colloquial name for these kinds of toilets I know is “Dixi Klo”
  2. and/or used the terms field as synonyms. Synonyms however belong into the field where the primary name is given. This makes a difference, as when searching, matches with synonyms are shown first, terms come very much at the bottom of the results list. Also, software may use the synonymous name instead of the “primary” name

Edit: Example: If you search start typing “pot”, first “potter” (craft=pottery) should turn up, then very much further below, (shop=houseware) shuld turn up, because “pot” is just a term used to find shop=houseware, while “potter” is either the primary name or a synonym.

6 Likes
16

a roadmap that lets contributors know if their work would be likely to be accepted would be a huge deal.

Better guidelines including the definition of what is in scope or out of scope for iD would indeed be useful and could not only boost the confidence of new contributors regarding whether their ideas fit or don’t into the project.[1] The crux is only that defining such a roadmap is far from trivial: On the one side of the spectrum, such a guideline would be so abstract/vague that it is not even worth mentioning (e.g. that a contribution should improve the usability of the editor). On the other side of the spectrum one would essentially write down a textbook in user experience design and GIS design patterns. It’s generally very hard to come up with something in the middle of those two extremes that is concise, but also coherent and fully covers all important aspects of the software.

I did try to present my ideas about this in my State of the Map talk in 2024 ( Setting the Stage for the Future of Web Based Mapping - State of the Map 2024 – Nairobi, Kenya ), but even there I was not able to provide a full picture, but instead relied on a couple of hand-picked examples to illustrate the direction. I would like to repeat that what I said at the end of the talk: It is still early stage, and the details have to be fully figured out. And the way towards figuring this out is IMHO for more people to actually get involved. This can be something as simple as leaving constructive feedback on issues or pull requests, to participating and discussing ideas during the monthly Community Chats, or even something more involved like mocking-up novel UI prototypes, etc.

  1. That said, specifically for people interested in starting to contribute to iD, we do already have specialized issue labels, collecting feature requests that were already vetted as being suitable to immediately start working on: help wanted / new contributor opportunity. ↩︎

2 Likes
17

Hey Martin,

Thanks for your thoughts on this, I really appreciate them!

Here’s what I think would be helpful for me as a volunteer wanting to help with triage, that could cascade down to others who file bug reports, or that could support the active code contributors. I recognize that you’re familiar with this process already, but just to lay out my thinking more completely for everyone reading it.

  1. Start with defining what’s currently out of scope entirely. Things that, for the forseeable future (at least a few years out), will not be considered for iD. This might be a mix of closing existing big idea issues, or as general as “no major UI overhauls”, “no significant changes to the rendering stack”, etc. Or it might be as specific as “we have no plans to allow users to upload data directly to display on the map, or to consume ArcGIS services directly without an intermediary”.
  2. Define 2-3 time periods for the road map - “immediate”, “3-6 months”, “Within a year”. Anything outside of that is beyond the horizon. Immediate items might get to super specific issues, but then 3-6 months and a year could be things as simple as what areas you’d like to prioritize improvements to as the maintainer - are you interested in focused improvements to the tagging experience? Rendering speedups? Workflows for power users? etc.
  3. Once those are defined, we can adequately triage issues and raise the ones that fit into the roadmap to the attention of you or another person capable of commenting on or merging code quickly. Ones that are fully out of scope (step 1) can be closed. Ones that aren’t out of scope, but don’t fit into the priority area can be put on the backlog, so we can tell whoever contributed the issue not to expect a response in the nearterm. With the rest of the items on the roadmap, people can see where it fits into your prioritization. None of it is an obligation, and maintainers can naturally shift things around or pull things out of the backlog that they think were misclassified, etc. But if we can reduce the noise you all have to wade through and set better expectations for people filing issues, I think that’s a huge win.

I recognize it’s real work, as you said, and would be best done with some input from the community about what areas they would most like improvements in followed by discussions from the maintainers about their own priorities. I’d be happy to support that work, as well as then triaging issues onto the relevant parts of the roadmap.

I also want to recognize that things have improved recently and thank everyone who is doing that work - there are fewer open issues and more of them have tags or pull requests - it certainly makes me feel a bit more like contributing time to iD would be worthwhile. I still think a roadmap would improve the energy and investment of the community, but I also see the amazing work that you all are doing to keep iD as a great editor, so thank you.

2 Likes
18

seems in large part to be covered by closed issues and specifically labelled with say

doing it explicitly seems an endless task as space of all possible ideas is vast and only some tiny part of them is a good idea

19

Yes, those are great, but only when a maintainer comes along and can use those. A roadmap is probably the simplest way not just to delegate the ability to close an issue with one of those labels to someone like me whose time is less useful to the project than Martin’s, but to also tell people proactively that an idea won’t be accepted and that taking the time to submit it won’t be useful. That helps the community to invest energy in things that are helpful.

I know a roadmap isn’t the only way. You showed that here by taking some of these tasks on. But I’m advocating for something proactive to allow both more volunteer support and drive community confidence in contributions.

20

For those interested, new round has been proposed: Proposed work on iD triaging and id-tagging-schema improvements (redux)

3 Likes