---
tags: iD
---
# Gathering of the iD forks

## Attendees

* Dan Rademacher
* Rory McCann ([e-mail] or [e-mail] )
* Wille Marcel ([e-mail])
* Alex Ianncielli ([e-mail])
* Danil Kirsanov ([e-mail])
* Den Raskovalov ([e-mail])
* Jim McAndrew ([e-mail])
* Michal Migurski
* [e-mail]
* [e-mail]
*

### Apologies

* Quincy Morgan

## Agenda

* Intros and quick context set
* Rory -- OSMF board, has made small PRs to iD, but not a big iD dev
* Alex -- listening in from Kaart
* Andy -- one of two maintainers of OSM website core software, make sure iD is happening, so releases can be merged and deployed
* Den Raskovalov -- MS integration of OSM data into MS maps services
* Dan Rademacher -- GreenInfo, OHM
* Danil -- Facebook, RapiD public fork that we talk about a lot
* Michal Migurski, also FB
* Jim McAndrew -- US Dept of Interior, made a couple of iD forks, recently trying to do that only to presets and imagery
* Nikola - Microsoft, the part othat involves OSM and open data in general, keen interest in getting iD up and running again, no public forks yet
* Ninoslav - working with Nikola, to spin up the editorial crowdsourcing effort based on iD. We don't have public forks, and ideally keep it that way. They have an internal wrapper around iD, provide additional higher level editing on top of it
* Pedram Rezaei -- CTO for Maps and Geospatial, Microsoft
* Wille -- Work with HOT, responsible for iD integration; leaving HOT soon

* Immediate term concerns
* Quincy transitioning out, looking for near term and long term management of iD
* Knowledge transfers
* Deployment
* Andy: Deployment -- for main website, iD maintainer makes a PR to OSM main website, then basic check and merge the PR. Otherwise, OSM website maintainers are not involved in the intenrals of iD. Doesn't know the intenrals of iD release and deployment. There are tons of people on iD repo with admin and write access. Do any of them want to step in short-term? Dependencies are being updates, and iD hasn't kept up with those updates. It would be super useful if someone could just do point releases with those.
* Willie -- it is quite simple to build, we are publishing a package on NPM with each release, to pull into React app. that part of teh build prcoess is quite simple. It is not documented.
* Andy: this is the release process documentation https://github.com/openstreetmap/iD/blob/develop/RELEASING.md
* Milel: This looks recent and thorough. Is anyone willing to take on minor updates and releasing? Mainly the editor layer index. Most of the people who have admin access now have not been active lately
* Rory -- the board has reached out to a few people and no takers yet.
* Ninoslav -- from MS side of things, we can devote some dev time. there are even one or two PRs we have that got stuck,so we would like to help with the current maintenance. One of their devs would need write access, but we can take this offline
* Rory -- anyone could make a PR, since it is all open source
* Mikel - it would be a good idea to have someone at least document on the changelog that there's a version attached to it
* Michal -- I can imagine folks form FB doing something around these lines, but it's hard to answer without things not yet on the agenda. Like the engineering working group, introspection on the board's part of why recent iD maintainers have left. More direction form the board on what the vision is for iD. We're here to figure out what the situation and lay of the land before we waste engineer's time
* Mikel -- we're in a holding pattern on iD and we want minimal maintenance, and board focus is on recruiting new person or people. They would have seating in the EWG. The staff of EWG is not reformed. Propsoed new charter for that in process, hope to approve this month if we hear in time. Small group led by Paul Norman. We're not at the point of longer term vision. We could talk a bit about coordination into the core.
* Pedram -- I would love not be in a position to ever need to fork iD, and we no issues with helping.

* Longer term
* Coordination into core
* forks eventually a matter of configuration and deployment params
* Mikel -- everyone would like to see common code base and lots of instances of iD that do different things, but where everyone can benefit from all the code in one place and individual devs don't have to worry about having to merge thigns back in when you've taken things in a different direction. Why is this not happening yet?
* Start with RapiD? For there to be less divergence, what do you need to see in iD?
* Danil - We try to stay as close to iD as possible, and then adding specific functionality. iD v3 simplifies the workflow for users to make new objects, making it work better for areas with low bandwidth. Some conversation about using it on mobile, sounds interesting from my perspective. Not sure if there are serious plans for that
* Migurski -- we have discussed the rendering performance, like pushing into webGL to get more stuff onto the screen, but all of these are lower in priority than a strong central iD that prevents us from forking off in different direcitons.
* Mikel: iD v3 was such a departure it was going to be hard to keep momentum on something that was almost a complete rewrite. Why do people fork?
* the presets
* add filters
* RapiD has different UI, but also different functionality, different bakcend, etc
* A complete rebuild is not in the cards, is there a way to separate concerns more?
* Ninoslav -- integrating some backend servies is an important thing to think about, esp additional data validation. We experimented with OSMCha and importing other validation signals. Some tech details with current iD implementation makes it hard to put a wrapper around it. Maybe we could start talking about how we could make additional signals pluggable.
* Wille: OSMCHa works mostly on the changeset level and it can be a bit hard to make that relation between the feature and the changeset, to check if that feature was flagged.
* Mikel: Collectively gather the features that have driven forked versions, and how that was implemented and what it would take to implement it more akin to configuration or still a fork but not as far away. Seems like that would align with Microsoft idea, and for RapiD feature by feature, what would need to change. Whcih partys of the code base does that touch? What would make that less of entanglement
* Rory: Looking at the history, there wasn't a lot of people actually making changes. It would be cool to figure out, even though it's a lot of work. From a board perspective, it would be nice to see more forkers submit PRs back. Let's get more people contributing to the project
* Mikel: Can we identify the needs of the forks?
* Ninoslav: How can we drive the PR acceptance/rejection process? A steering committee or something?
* Mikel: Get some people in a position to keep the lights on, and then see if muscles pick up?
* Rory: Some challenges around PRs where the maintainer of software can get blamed for what new users submit in the form of messy data.
* Mikel: We did have some discussion of whether there could be a steering committee of some kind, but the thinking was we want some recruited and in place before imposing a governance structure should look like. I am personally of the mind that it might be helpful if that was in place. But we wanted to focus on recruitment before we commit to a governance structure
* Migurski: I think it's correct to think about a person before a structure. That person doesn't necessarily need to be chosen because of their JS skills. More that someone is granted immediate authority to manage some of the social challenges. The Dispute Panel is a very post hoc panel. Ideally what you want is some sort of directionality of what the board wants from iD, and then find the peson who would fulfill that desire. Allan Mustard recent document about core mapping -- maybe an open path all the way through?
* Rory: The maybe in there, is we have a thing saying there has to be at least one open source editor. There have not been high level, generic discussions like that.
* Mikel: It's a very rough outline at best. We have invested into iD, but in no way is there a specific way of mapping that's more important than another
* Rory: The board is aware that the main issue is going to be lack of applicants. It can be nice to think about generic principles, but we probably won't be swamped with people wanting to work as developers, so I don't know how useful it is to think that way.
* Mikel: Would it make sense to create some documentation about the what and the why of the forks. What would it take to bring these back into the fold? Make it more of contributing back to core.
* Pedram: We could certianly write down our needs.
* Rory: It's just one PR. Move fast and break things!
* Andy: Two most common reason for forks is a divergance of vision, but more often it's a lack of capacity to merge back into the core. I don't think planning will solve this or by PRs. I think most important is development capacity. that's why I was looking for at least a minimum capacity to tag releases and get them out the door. The biggest challenge is when the final maintainer moves on without a successor. But outsiders anointing a maintainer is very dangerous. I would personally prefer Quincy picking the successors rather than OSMF or OWG picking someone. Ideally it would be Quincy
* Migurski: right now sending PRs to iD looks like a low value effort, since there's no one there to accept them. Since it sounds like there's enthusiasm at MS to take that role, for the board and Quincy to designate a PR acceptor/reviewer. We really want someone to act as a shepherd or guide who is able to take some sort of PR, no matter how small, all the way through to the OSM domain.
* Rory: Board asked Quincy about successors, and he didn't have any names at that time. For PRs, it's a lot easier for the board to get behind cosponsoring someone if they demonstrated that they've done a lot of stuff in the past.
* Mikel: I have taken an action to set up a time for MS team to talk to Quicny. Work around their schedules, but if anyone else wants to join they are welcome.
* Pedram: From the MS side, we are happy to help in any way you folks see. No issues from our end
* Ninoslav: One more perspective to the overall fork story, with all this documentation we gather around current status, current forks, we may end up concluding it would be really difficult to merge all this back. Another perspective could we create common ground? that iD and these other things emerge from the same source, a build frmo a common code base.
* Mikel: There will always be forks, but they maybe don't need to be so far away or can contribute back
* Dail: Maybe making iD modular, which could make life a lot easier for people on the call.
* Rory: Next steps, MS people can contact the board and say you are the people who are interested in iD. Fire it off to the board.
* Mikel: I'll take the next step to email everyone.

## Actions

* Mikel: Schedule discussion with Quincy, Microsoft and Board about passing baton for interim maintainance
* Mikel: Start doc to gather requirements for more modular iD core https://hackmd.io/jZdaQf-gT_2SPkkp0ZjUNA