I think the tagging in use prior to this changeset was probably more accurate (and the description at highway=track agrees). I guess that you made this change because the rendering looked funny with a track leading to a driveway, but the correct way to fix that is to change the tagging on the other part of the driveway to highway=service, service=driveway (with the existing foot=yes indicating public access on foot).

There are a couple of issues with this changeset. Firstly, you've removed connections between the path and the road at the roundabout. This means that routers will no longer be able to use the paths for routing, as it looks like it isn't possible to rejoin the road (or a pavement adjoining the road) at that point).
Secondly, I cycled past here a couple of weeks ago, and at the time there was no accessible footpath on the west side of Robinson Way because it was part of a construction site. Has that now changed? If not, then I don't think a currently non-existent path should be mapped through the construction site.

The house numbers were already present on the building ways, so this changeset has added duplicate numbers. It seems that separate nodes were only being used here where one building contains multiple addresses. I've reverted this change in 83081728.

The paths added in this changeset should have been marked as private. I've fixed this myself, but I haven't added any notes detailing these restrictions (such notes are currently present on other footways in the college).
It also adds a tree in the middle of the river. I don't recall there being a tree in the river here, so it seems likely that either the tree has been mapped in the wrong location, or (less likely) the river is inaccurately mapped. Can this be checked/fixed please?

Also, I think you've mistagged the patio area (or whatever it is). The access tag is on the outer way of the multipolygon, but should probably be on the multipolygon itself.

This changeset has been reverted by sladen in 82308605. If you haven't discussed this data with them, then I suggest you start that discussion.

I wouldn't describe smb1001's changeset (75018301) as "armchair mapping damage" - that implies to me that the changeset was incorrect for reasons that would be apparent on the ground. The actual disagreement here is over the relevance of the data to OpenStreetMap, including whether it's relevant to include the name a mapper gave to their own (or at least someone's - I don't know that it's yours) private back-garden BBQ.

Personally I wouldn't include the name tag, particularly as it currently prevents the house number appearing in some renderings. I'm also not sure that this is really the intended use of the 'amenity' tag. In any case, since you clearly disagree with smb1001 about what is appropriate to map, then you ought to have some sort of discussion with them, rather than just reverting their edit. (Perhaps you have had that discussion - if so, then it's worth mentioning so that other people know it's happened.)

You forgot to adjust the bus route relations; I've updated these to use the new road now.

In this changeset you enlarged the roundabout but forgot to adjust the layout of the service road or under-construction layout cycleway to match. I've changed these to match your road alignment (without realising at the time that the road realignment was a very recent edit).

I don't think this is a correct fix - you've just changed one incomplete mapping of the car park into a different less accurate mapping of the car park (the 'dead end' you removed was the exit from the bottom of the spiral ramp; you've redirected it to connect to an exit from the ground floor).

Can you confirm whether or not there is pedestrian or cycle access between these two roads? Your edit implies that there is no access at all, but it seems unlikely that there wouldn't even be a gap for pedestrians.

EN:
Should way/32062630 have been tagged highway=secondary (and not highway=motorway_link). Currently there is no through route for non-motorway traffic.

ES:
¿Debería haberse etiquetado el via 32062630 highway=secondary (y no highway=motorway_link)? Actualmente no existe una ruta directa para el tráfico que no sea de autopista.

I think you forgot to remove the access=no tag. I've removed that tag now.

It seems there have been complaints about this task on the GitHub for the site. SomeoneElse has just commented on the GitHub issue at https://github.com/Zverik/osmstreak/issues/38 and mentioned this changeset as an example.

You should try to avoid creating a changeset with a large bounding box, as it makes it harder for other people to review changes to the map. In particular, you are wasting the time of lots of people who are trying to look at changes affecting their local area, and are seeing this changeset in the list due to it's inappropriately large bounding box.

Your changeset comment suggests that you deliberately made this changeset's bounding box very large. Please don't do this (or anything similar) again.

If the node was intended to be moved, then there's probably nothing else to do right now. If it was in the right place before, and is now in the wrong place, then you should create another edit moving it back to the correct place (and if you do that, then it would be helpful to mention this in the comments here, and mention in the description of the new changeset that it fixes a mistake in this one).

Reverted in changeset/79314757.
Some advice for a future - if you think something has been incorrectly mapped for years, then it's usually worth having a look at the history of the object, to see if it's been changed recently. In this case you would have immediately discovered that it had been retagged as under construction only five months ago, with the changeset comment stating "Stourbridge Common - Ditton Meadows cycleway jetty closed for reconstruction".

Yes, but it is currently closed until summer 2020 for reconstruction, hence why it was tagged as under construction. I think this changeset needs to be reverted.

This changeset also moves a node in Germany by a small amount - presumably this wasn't intentional? How did this happen?

I don't think "disused" has the right meaning here. It's not disused; just temporarily closed for maintenance. The construction tag might be better, but I think the right way to do it (as referenced in the third paragraph on construction=*) is to use conditional restrictions.
E.g., retaining "amenity=fuel" and adding "amenity:conditional=no @ (2020 Jan 2-2020 Feb 12).