Keep the history
When things change in the real world, be bold, and edit the map to reflect the current situation. But be aware that OpenStreetMap can store the editing history of an element. It can be worth taking a few extra steps to help preserve this history.
Instead of deleting elements such as buildings or landuse and redrawing them anew, it is generally better to update the geometry of the existing objects, retaining their editing history. Similarly, make sure to preserve the identity of an element even when its tags become different (but don't overdo it, see #Don't mix the history). Example: If a café closes down, don't delete the node. Just remove the cafe related tags and leave other tags (like the address) in place. If a real-world object is physically moved (e.g. 
Structure relocation) then it is preferable that the history of corresponding OSM element would reflect that.
Editing techniques
For JOSM there is a tool "replace geometry" in the plugin utilsplugin2. With this you can draw a new outline of an object and then move the history of the old outline to the new outline: simply select both objects, then press Ctrl+⇧ Shift+G.
When you find a single node for an object, and want to draw the outline of the building or the campus, it is good practice to keep the node (without its tags) prominently in the outline (e.g. as a corner of the building or the campus entrance). This preserves the history of the information in the "old" node, which is easy to find when somebody inspect such an object.
Example: node to area
(school node to campus area outline):
- Move the school node to a corner of the aerial image.
- Draw the campus area with this node as one of the corners.
- Copy the tags from the node and delete all its tags.
- iD users can select the area and the node and press C to merge the node data with the area.
- JOSM users with the utilsplugin2 plugin can use Ctrl+⇧ Shift+G to do the same.
- Paste the tags on the campus area outline.
- Remove old source=* tags.
- When uploading, add your source to the changeset (not to the school object).
Keep changesets manageable
Try to keep changesets to a manageable size, both in number of changes and geographical scope.
- If a changeset includes too many different objects, it will be difficult for later mappers to understand what was changed.
- A changeset that covers too large of an area can be hard to find and difficult to edit. More details are here.
- Good changeset comments are only possible for simple, smaller changesets.
Good changeset comments
- Main article: Good changeset comments
A good changeset comment should concisely and adequately describe an edit. You should do this out of courtesy to your fellow mappers, to avoid misunderstandings, and get mistakes fixed quickly. It makes your edits more valuable. It may even help you when you look back at your edits in the future.
Check the history
Before making significant changes to major features based on aerial imagery or past knowledge, check their history, changeset comments and source tags. A feature may have been mapped based on recent survey in person or more recent aerial imagery. Previous editors may have valuable insights to offer on why things are currently tagged the way they are.
This is especially important for large or complex objects that may be difficult to restore, for example administrative boundaries, buildings with complex footprints, and long route relations.
Previous changeset comments and source tags could be viewed in multiple ways:
- JOSM users may press Ctrl+H to bring up the JOSM history window (example).
- Website OSM History Viewer (by PeWu)
- Mapki's Deep Diff is a diff tool for single nodes/ways/relations that showing all versions in a table.
- openstreetmap.org website View History link
Don't mix the history
Don't convert relations, ways, or nodes that would otherwise be deleted into completely different types in an effort to prevent deletion. Deletion is not erasing the history of an object in the database. Generally, only keep the history if at least one tag of the OSM element applies to the current real-world object and they are in the same place.
For example, turning a turn restriction relation into a multipolygon is not helpful (example
example); it is better to delete one relation and create new one.
For example reuse of node number 1 is not resulting in a clear history.
If there is forest and one is improving geometry, then it is better to move existing nodes and keep existing way.
But if forest was cut down and replaced by shopping mall - then reusing nodes is not helpful at all, it is OK to just delete it.