'ref:FR:FFT' is already used quite a lot on sport-related POIs, so this looked like a trivial typo. I change it back.

Thanks - I don't remember what happened here so long ago.

Hi & welcome to OSM!
In your edits you used many tags that are not used in any other place.

In OSM we have to use a well-defined set of tags to allow all the software tools to understand the data and e.g. show it on maps.

Please make sure that you only use tags that are documented in the Wiki or are available as presets in your editor.

Hi,
please check your edits, there are many ways with a strange "NAME10" tag.

Hier stimmt so einiges nicht. Alle nodes haben viele falsche Tags, wichtige Tags fehlen.
Wo findet sich die notwendige Dokumentation dieses Imports?

Diese Änderungen sollten komplett revertiert werden, und dann nach unseren Import-Richtlinien komplett neu angefangen werden.
osm.wiki/Import/Guidelines

Hi,
please check the defibrillators you added. The proper tag is "emergency=defibrillator", not "emergency:defibrillator=yes"

emergency=defibrillator

Please don't just dump new data into OSM. This import should have given you more than 11000 warnings and errors from the validator. These should be fixed before uploading!

Hi,
what does 'risk:natech' and 'risk: natech' mean? These tags are not used in any other place.

Hi, and welcome to OSM!
You have to make sure that you only use data from sources that are licensed to be used for OSM. google does not allow to use its data for OSM, so I had to revert these edits.

Hi,
you used many 'addr:...' keys here that are not used in any other place. Please use only those tags that are described in the wiki or are present as presets in the editor - everything else can not be found by any search function.

Where did you find an approval of 'source:url'? It's just a specific form of 'source', i.e. the source of the 'url' tag - although it has been misused by several large imports. It isn't even explicitly mentioned in the wiki.

'source_ref' is the tag for external source links that is used millions of times since the beginning of OSM.

Hi, please check the presets / auto-completion in your editor. It shouldn't be 'eaf_cycle', but 'leaf_cycle'.
I fixed a few dozens of them.

Hi,
these power poles got some uncommon tags:

BSK= Derby 33kV
GSP= Willington
Primary Substaion= Mackworth 33 11kV

Please check the wiki how those reference codes are typically tagged.

Hi,
what does 'through_traffic=no' mean? That's usually excluded by using vehicle=destination.

Also, are even pedestrians not allowed to walk here? Otherwise 'access=destination' is wrong and should be 'vehicle=destination'.

Hi,
what does 'recycling:bundles' mean? This tag is not used in any other place.

Hier ist noch einer übrig geblieben:
node/1976962915

Right, destination:distance is better in this context. Essentially using the options we have for destination signs also for milestones.

In the case of a milestone with arrows we could also use
direction_north and direction_north:distance

distance:City seems to be a quite local phenomenon:
https://overpass-turbo.eu/s/2if8

Hi,
hier fehlen die Tags an der Relation:
relation/20044848

Hi Robert,
wouldn't it be better to replace those "old school" "distance:Nelson Monument" tags with a more modern tagging that doesn't use free text in the key? This would do the job - and at the same time also keep the order of entries on the milestone:

destination = A City; B Village; C Place
distance = 10 mi;2 mi;234 mi

Using 'destination' on a milestone seems appropriate to me, even though it's not a guidepost pointing in the right direction...

In einem Value ist das auch weniger ein Problem, aber für Keys nicht geeignet.

Meiner persönlichen Meinung nach gehört das ohnehin gar nicht in den Key. Lieber in einer sauberen, nummerierten, maschinenlesbaren Form inklusive eindeutigem Link zu wikidata:

railway:name:1
railway:ref:1
railway:operator:1
railway:operator:1:wikidata

Wenn aber ein Name im Key erwünscht ist, dann so kurz wie (eindeutig) möglich, aber mit Leerzeichen durch Unterstriche ersetzt und ohne Semikolons.

Und als letztes Argument möchte ich erwähnen, dass diese Tags am Knoten eigentlich gar nicht nötig sind: Ich brauche nur auf die beiden anschließenden ways zu sehen um diese Information zu bekommen.