Try to upload your changes in smaller areas, like one for the changes in California, one for Alaska, etc. This changeset and some of your previous ones have covered massive areas and show up on QA tools for widespread areas when they don't need to.

Something you're doing keeps putting buildings way up in the Arctic Ocean. I would recommend figuring out what's happening to cause this before adding any more.

way/757045771 was created way up in the Arctic Ocean

Please stop doing this. Such a massive change needs to be widely discussed with the global OSM community. The community will not allow you to be the only one to decide on this major topic, so there's no point trying to impose your personal opinion. You're just wasting everyone's time.

Translation:
Bonvolu ĉesi fari tion. Tia amasa ŝanĝo devas esti vaste diskutata kun la tutmonda OSM-komunumo. La komunumo ne permesos al vi esti la sola decidi pri ĉi tiu ĉefa temo, do neniel penas trudi vian personan opinion. Vi nur malŝparas ĉiun tempon.

The hotel/motel has been mapped since 2012. I've merged the relevant address information into the existing object and removed the duplicate node.

The small flares where the road joins the cul-de-sac imply physical separation (ie. an island), but there isn't one visible on aerial imagery. If there isn't any physical separation, the road should just join the cul-de-sac directly. Likewise with the other nearby roads. If islands have been installed since the aerial imagery was taken, you can ignore this comment.

Ah, I understand. For cases like this, building:part is indeed what should work best. The two large pieces of the building would be building:part=yes and building:levels=4. Each balcony would be building:part=balcony. In addition, you would map a single way overlapping the outer limits of all of these, and this is what you would tag with building=apartment and all of the address and name tags (no building:levels, though, because that is already on the relevant parts). This way, you only have a single object with an address, and there's only one building=* object rather than a number of them. This would best represent reality, because it's really just one building. Unfortunately, this still doesn't allow us to tell data consumers that one of the parts is offset vertically compared to the other, but I honestly don't know of a way to indicate that. We may just have to accept that there currently isn't a good way to do that. You could add a note on the building object describing the layout so someone can update the tagging if a good solution is later found.

I passed by today and confirmed that these ways don't actually have a name in real life. I suspect these are considered interchange/exit roads as part of the highway. The fact that Google Maps calls this "Swartz Bay Road" is simply another of their countless road name errors. I've removed the name and tagged these ways with noname=yes.

These garden beds are tagged with letter names, which seems unlikely. Do these beds really have these names or were these mistakenly imported?

Are you sure there are two separate buildings here? They've both been tagged with exactly the same tags, so they should probably be joined together into one building.

I'm fairly certain the overpass and approaching ways don't actually have a name. I only now realize that they've always had a name in the database, but I think that's an error. I'll double-check the next time I'm out that way.

Hi mardil10, it looks like a copy of the roads and stops for the 81 got shifted and uploaded (see here: https://overpass-api.de/achavi/?changeset=76021561&relations=true). I've cleaned up the duplicated objects but kept the valid stops you added.

Some of these clearly don't fall under the category of craft=*. I've now reported you to the DWG due to your massive number of mechanical edits and your failure to communicate with other contributors.

This user is performing a massive number of mechanical edits all over the world. They need to be stopped immediately.

I'm sorry that you feel my edits are vandalism. I assure you they aren't, and I make it a point of monitoring the southern part of the island for true vandalism or damaging/misguided edits. To show you that I have the best intentions, I previously agreed to not fix the many duplicated addresses you've been adding in Esquimalt because you didn't like what I was doing, and I've stuck to that plan despite a strong desire to fix the issues.

As for these areas, they are definitely not administrative boundaries in the context of OSM. An OSM administrative boundary is one that defines a geo-political entity, such as a country, province, municipality, or neighbourhood. The areas changed in this changeset - watersheds and arbitrarily-named woodland areas - don't fall in this category. The way they were tagged with boundary=administrative and admin_level=10 indicated these were neighbourhood areas, which is obviously not true. There doesn't seem to be a good way to tag watershed areas documented in the wiki, so the best we can do for now is just leave them as boundary relations. If a good tagging scheme gets devised for watershed areas, by all means add it to these relations.

Feel free to comment on any changesets where you feel I may have made a mistake and we can have a discussion about it, but please try to keep things clean and don't just assume that anyone who makes changes to things you've edited is a vandal.

Google Earth isn't allowed for editing. Please revert this changeset immediately to remove any data that doesn't comply with the ODbL license

From what I understand of the proposal, the result when complete would best be mapped as highway=living_street, so highway=footway wouldn't be used anyway. We can give the original contributor a bit more time to explain, but then I agree that the footway should be removed, especially if there haven't actually been any changes on-the-ground yet.

This is a fairly major change, and one that should be discussed. The BC regional districts have been tagged as admin_level=6 since their creation. Why are these three now being changed to 5 (and none of the others)? That level seems to be generally used for groups of districts or counties, which doesn't fit here. On a lesser level, it breaks the smooth mapping of 2=country, 4=province, 6=regional district, 8=municipality, 10=neighbourhood, which allows for edge-cases to fit in between. There may be a good reason for this change, so I'd just like to know more so I can adjust my mapping if necessary.

The footway you created is overlapping Kings Road. Has this section of road been closed and changed to a footpath? If so, that section of Kings Road should be removed so cars don't still try to drive down it.

It also reuses node IDs from 13 years ago for no apparent reason. This seems like something that wasn't intended to be uploaded and should be reverted.