This page is to list a number of principles that are not, to my knowledge, written elsewhere, but which I apply to my own editing, as well as when giving advice and feedback to other editors. This could maybe also be the starting point for a discussion to get these principles written into the MusicBrainz style guidelines or other such official documentation. —Freso (talk) 10:26, 4 April 2018 (UTC)
Missing data is better than wrong data, or “if in doubt, leave it out”
If you're not sure about a given piece of data, it is generally better to omit it rather than entering a guess and potentially be wrong. E.g., if you know that a CD exists, but you're not completely sure where it was released, it's better to leave the Release Country blank rather than guessing. The missing data can always get added at a later point by yourself or another editor once more information is available.
This also makes it easier for other editors to positively verify whether their copy of a Release, for example, is the same as the one you entered. If they have a digipak packaged CD release, but you used "Jewel Case" for the Release Packaging on a guess, the new editor will think they have a different version of the release and enter they Digipak-version. If the original Release's packaging was left blank, it could have promoted the 2nd editor to research the release already existing in MusicBrainz to see whether it is actually the same digipak packaged release.
Duplicating is better than wrongly reusing
In the same vein of Merge Rather Than Delete, it is also better to create a new entity rather than reusing an existing one if you're not positively certain the two are actually the same.
If it is later found out that the two are the same, they can be merged and the two (or more) MBIDs will all point to whichever entity was merged into, meaning that all references that people using MusicBrainz has for those entities will continue to work. If, on the other hand, you reuse an existing entity and later has to split it out, there may be references for Releases, relationships, etc. in external copies of the database, in file tags, in databases referencing MBIDs otherwise (e.g., Wikidata) that may continue to point to the wrong entity indefinitely.
Specific is better than generalised
If someone applies to all Recordings on a given Release, it is better to apply this data to all the Recordings, rather than the Release as a whole. If you have an exact date, it's better to use that than to use just the year.
Edit for MusicBrainz, not downstream users of MusicBrainz
If certain data structures in MusicBrainz are handled in a problematic way by downstream users, still make the edits adhering to MusicBrainz guidelines and best practices. Downstream users need to make their software handle these issues in their software.
Music metadata is complicated and MusicBrainz as such must mirror this complexity. Downstream users can ingest this complication and simplify it, but it should not be simplified on MusicBrainz’ end as different downstream users may want to simplify different things or in different ways and the only way to accommodate everyone is for MusicBrainz to retain its complexity.
MusicBrainz is MusicBrainz, not Site X
Similar to how MusicBrainz shouldn’t be edited to fit into downstream users’ usage of MusicBrainz data, it is also important to recognise that MusicBrainz should not be edited to "blindly" mirror others sites or databases or systems.
MusicBrainz is not Wikipedia, Wikidata, Discogs, a national library database, or any other database, site, or system that is not MusicBrainz. MusicBranz has its own set of guidelines and best practices that may or may not be inspired by or even adapted from other systems. But it is not the same. That means that sometimes you will have one artist entry in MusicBrainz but multiple in some other one, or multiple entries in MusicBrainz but only one in an external database. Which can be fine, depending on how that other site defines their data policies.