Anyway, welcome to OpenStreetMap, and thank you for your initial contribution. Unfortunately on this occasion you happened to find one of the ways it is possibly to get the details subtly wrong.

I think this is technically wrong - the presence of "no entry" signs does not mean that any part of the road is actually one way. The "no entry" restriction is already modelled using a tun restriction, and since there are no "one way" signs on this stretch of road I think it shouldn't be tagged as oneway.

Have a look also at changeset/46602497, in which "Restrictions are implemented as turn restrictions as signed, rather than faked with short one-way ways."

I'm a bit confused about your intentions here. The no-right-turn restriction doesn't seem to make sense, and effectively duplicates the constraint of the no_u_turn restriction on Long Road. The other two no_u_turn restrictions are probably not necessary for correct routing, and shouldn't both be there - if there is a signposted restriction here, then it's probably best to map only the restriction turning back at the first traffic light.

You also seem to have added a redundant node to the boundary of the residential area.

I've noticed that you've tagged several roads as "oneway=no" in this changeset. This tag is redundant and should almost always be removed.
I came across this changeset having noticed some inconsistent tagging around VInery Way. Your edit suggests that this is no longer oneway, which seems surprising, and the description seems to suggest both that these are armchair edits and edits based on local knowledge, which seems a little contradictory and gives no clear indication as to what your source is.

Is Vinery Road actually a oneway street? If so, then it should be tagged as such, and this relation is then redundant. If not, then the oneway:bicycle tag on Vinery Road is redundant, and it would seem strange for there to be a restriction on the left-turn in but not the right-turn in.

This appears to be the extent of the variable speed limits proposed in the withdrawn application to make the A14 a motorway in 2019. However, the Cambridge Northern Bypass has new signs that appear to support a variable speed limit there as well.

Do you know if this is still proposed (and likely)? If so, could you amend the tags to a valid combination. If not, then you should probably delete it.

Oops, I forgot the variable speed limits weren't approved yet (they were originally part of the now-withdrawn application for conversion to motorway status). I'll fix the stuff I changed between Swavesey and Milton using lifecycle prefixes.

So the bridge is officially open now? At the moment it's not linked to anything open at the north end of the bridge - should the link to the roundabout be open now?

That's odd, but it matches the data I can find online (which shows the NB Fendon Road stop not being served by Citi 1). I wonder why they're still doing that.

Unhelpfully, I can't find a description online - Stagecoach's promos and offers page still describes the original diversions, and the service updates no longer mention the roundabout. I think there was an update to the service update article when the roundabout partly reopend, but that's gone now.

I've just noticed that this changeset uses the tag "maxspeed=variable". This is incorrect use of the maxspeed tag - in this instance you should instead use "maxspeed=70 mph" (if the normal limit is 70mph) and "maxspeed:variable=peak_traffic".

Should there be an apostrophe in the name?

This changeset edits a way around the tennis court so that court is now duplicated and the boundary fence is unmapped. I've reverted this (and added your capacity tag to the other way instead).

Did you look at the surrounding map data before making this change? I'm pretty sure this is basically a flat toll plaza with no bridges; it looks like the original mapper decided to link all border post exits with all toll booths (on this side). While the original mapping is incorrect, your edit here just makes it worse.

This change looks like a mechanical edit (in that you are changing lots of things systematically without necessarily properly reviewing each change). There is now a page on the wiki about these (osm.wiki/Automated_edits). Unfortunately I can't easily check whether you've made other errors like this, or whether this was just a rare mistake.

I don't know, I've never used iD. JOSM explicitly asks which portion of the way should retain the history when splitting an existing way. If iD doesn't allow that, then it might be better to change the way you use iD to avoid this issue, or use a different editor.

Perhaps there's no explicit restriction, but the only thing they lead to is a road on which pedestrians aren't allowed. I think there are lots of similar maintenance access steps on motorway/trunk road embankments and cuttings, and I couldn't spot any others that were explicitly mapped. (One example is some existing steps next to the bridge over the A14 in Girton.)

You've manage to complicate the way history here by reallocating the way originally representing to the cycleway over the bridge to instead represent the cycleway adjacent to the bridge, and creating a new way for the bridge. Can you try to avoid this in future? I presume you did this by extending the existing way and the splitting it, with the history being retained on the wrong segment after the split; you should check that history goes to the correct section when splitting ways to avoid this sort of issue.

I don't think these are for normal public use, so should presumably be tagged "access=no". I tried to find existing examples to compare to, but it looks like this sort of access stairs haven't generally been mapped anyway.

This changeset doesn't actually contain the changes it claims to, because the intended changes almost entirely replicate those in 83547340, which was uploaded 5 minutes earlier (sorry, I beat you to it :) ).
The changes that actually remain are modifications to a stream (marking part of it as in a culvert and realigning it). I'd recommend in future that when you split ways, you try to ensure the main part of the way retains the old id. In this changeset I was left wondering for a bit why you had created a new stream to Longstanton, until I realised that the new way replaced an existing one which you had shortened and almost entirely realigned.

If you're changing the "highway=construction" tags because it's open, then you should also remove the "construction=cycleway" tags. Also, the "oneway=no" tag you added to one of the ways is redundant.