consider consolidating into id-tagging-schema repo

[tyrasd]

Let's discuss the suggestion from d9c23fa#commitcomment-64100888:

[This repository could just be] some build scripts in the id-tagging-schema repo.

Right out of the box, I would agree.
I thought that there was a perhaps a reason for the repositories being structured like this. Perhaps some forks are using it to maintain their own set of presets?! Maybe @quincylvania could explain the original reasoning?

[1ec5]

The idea probably was in pursuit of a schema-agnostic iD. I don’t know if any forks are maintaining their own tagging schemas, but in principle a tasking manager could be set up to tailor the presets to a task-specific set or something. JOSM has this capability with swappable preset packs, but I’m not sure about the level of demand for iD to support something similar. I personally find this separate repository limiting, because we haven’t fully built out the meta-schema for id-tagging-schema yet – there are plenty of field types worth adding, for example.

[westnordost]

(FWIW as an irregular contributor, I (also) have found it confusing which to find in in which repo)

[matkoniecz]

iD does not have custom presets right now but ideally at some points it will have them

How we can setup it so that testing PR like #174 + openstreetmap/id-tagging-schema#1538 is not a confusing nightmare that requires custom hacks?

But at the same time makes easier for OpenHistoricalMap/Geofiction to maintain or create custom presets?

Also, should openstreetmap/iD#6483 be abandoned/closed first in such case? Or would it not be a blocker for still doing this. I admit that I am still not sure what benefit of making iD to be no longer an OSM editor was supposed to be.

[matkoniecz]

In other words: I support merging schema builder and iD tagging schema into one repo, but what kind of negatives it would bring us and to others?

How we can avoid this negatives?

Maybe we can put announcement of this plan into changelog, so people with potential interest can comment on? Before we potentially break something?

Or maybe there is noone who relies on this two-repo split and it will bring no negative consequences to the current users?

[matkoniecz]

Main thing to consider that I can spot: lets see that aliens arrive tomorrow and post high quality PR for #5049 and we get it up in the next iD version.

And lets say that we have someone (or bunch of someones) interested in maintaining separate preset, as a separate project.

Will it be possible for them to follow schema builder improvements with bunch of nasty hacks? how we should setup it so that despite this repo merge it will remain possible?

(obvious solution of "merge in upstream" would be terrible as it would merge in also all iD preset changes conflicting with whatever this other preset project is maintaining)

[matkoniecz]

also, we should contact projects/people listed at https://github.com/openstreetmap/id-tagging-schema/wiki/Projects-that-are-using-this-tagging-schema

[1ec5]

But at the same time makes easier for OpenHistoricalMap/Geofiction to maintain or create custom presets?

OpenHistoricalMap’s iD fork is currently using the same id-tagging-schema and name-suggestion-index as OSM, monkeypatching the JSONs to have the presets/fields/categories we need. It should migrate to forks of the helper repos: OpenHistoricalMap/issues#777 OpenHistoricalMap/issues#446. It’s unclear whether these forks should be almost identical to upstream with a few modifications, or whether they should be overlays that iD needs to combine with upstream. I also don’t know if making name-suggestion-index time-aware would require any changes to either schema-builder or nsi-collector.