User:Freso/Editing principles: Difference between revisions
(Initial draft of page) |
m (Minor tweaks) |
||
| Line 1: | Line 1: | ||
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. |
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. —[[User:Freso|Freso]] ([[User talk:Freso|talk]]) 10:26, 4 April 2018 (UTC) |
||
== Missing data is better than wrong data, or “if in doubt, leave it out” == |
== Missing data is better than wrong data, or “if in doubt, leave it out” == |
||
| Line 11: | Line 11: | ||
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. |
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) [[MBID]]s will all point 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. |
If it is later found out that the two are the same, they can be merged and the two (or more) [[MBID]]s 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. |
||
Revision as of 10:26, 4 April 2018
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.
