hi,
cld you have a look to the opening hours tags on these bridges and change them to the common syntax according to the Wiki?
Thanks!

Hi,
it looks like something went wrong with import of boundaries (?) All the ways only have foreign tags that shouldn't appear in the OSM database. There are no common tags necessary for boundaries on them.
Could you check that?

Hi,
here's another node with those foreign tags:
node/9047165526

Hi,
please check the 'DANE' tags on the objects you added recently. There are several different spellings like 'DANE' and 'Dane'. There should only be one spelling - OSM is case sensitive.

Please check your edits, there are many tags with spelling mistakes.

Hi,
please have a look to these edits. There are 27 nodes with several strange tags that should be corrected to usual OSM keys, e.g.

document number
organization type
principal
related URL
service object

Hi,
something went wrong with this import.
All the objects have only foreign tags that shouldn't be in OSM.

In the process you also deleted many already existing trees with more valid tags than the new ones.

Where can we find the mandatory discussion and documentation of this import?

osm.wiki/Import/Guidelines

Something went very wrong here. There are hundreds of objects with only foreign tags like this way:
way/978448938

Before importing any foreign data, please make sure to follow the OSM import guidelines!
osm.wiki/Import/Guidelines

Hi,
could you check your recent edits? There are more than 5000 objects with a "xd=xd" tag.

Hi,
could you check these bus stops? There is a misspelled tag:
passanger_information_display
->
passenger_information_display

Hi,
please check your edits. There are many tags with spelling mistakes, e.g.
heath_level instead of health_level

Hi,
could you explain the meaning of these tags? They are not used in any other place:
railway_site
railway_site_passable

Hi,
could you check these edits? There are many nodes on top of other POIs. They have several strange tags which look like they don't belong to OSM, e.g. this one:
node/9037131752

feature_type=man_made
landmark_gps=-1.3519399 29.6616646 2285.3 4.56
village=Buzeyi

Ist das "zuständig" im Sinne von "nach dem Rechten schauen"? Das könnte dann in das häufige "operator" oder in das eher seltene und bisher nicht dokumentierte "maintainer".

Hi,
could you name the source of all this? There's a ring-like river and several zig-zagging roads I can't find on any aerial image.
This question also includes several of the other changesets you added in this region.

Hi,
could you check this?
Should it be 'step_count = 19'?
way/974799635

Hi,
you added four nodes here with many foreign tags, could you check that?
node/9037004044 (and more close by)

Hi,
you added the tag "bicycle:lts=0" to many different roads. What does it mean? Is there some documentation?

Sure, there should be a documentation in the Wiki for each tag. But, a generic scheme helps:
If I see a tag starting 'ref:US....' I immediately know that it's a local reference number. Then I can decide if I want to know the details (and search the Wiki) or not.

If I see your tag, I have no idea what it might be. I see '911' and 'address' - so is it some kind of emergency contact? So the value might be a phone number? Oh, it says 'id' at the very end, so it might be some reference number.

You also have to take into account that these tags will be seen by everybody using OSM. Say, someone creating a map of power infrastructure needs to decide which information to include and which to drop. They might decide to take every 'ref:...' tag and show this in a separate section but they would need a dedicated look-up table whether to include your custom tag or not.

Please, use a 'ref' prefix for any reference number. It makes the life of every data consumer so much easier.

Yeah, we're missing some handy documentation on how to create new tags. The scheme I propose would be inline with e.g. ref:linz:building_id
This is also mentioned on the Key:ref page in the Wiki. 'linz' is the dataset and 'building_id' the field name.

There's also the approach to add a country code into the tag, to be able to disentangle local ref numbers from each other in case somewhere else a similar abbreviation is used, like in ref:GB:uprn.
In your case that could be ref:US-VT:vcgi

I think it's very helpful to have all kind of reference numbers in one common namespace, prefixed with 'ref:' and a region code.
This allows others, not from the same region or not aware of the sources you use (like me) to easily see what this tag represents