I am often one to request that the guidelines be clarified where they could be clearer. They are often fairly clear for most cases, but create confusion by neglecting to mention edge cases. Take for example the issue of misc information on tracklists. I think that because this issue isn’t mentioned specifically in the guidelines, but the related issue of extra title information is, it’s easy to confuse one for the other. But that is a separate discussion.
The way I think this should work is that when an editor comes up with a question that isn’t clearly answered in the guidelines, the editor should consult the community and have it clarified in the guidelines, even if the editor could have simply guessed the reasonable thing to do and probably have been right. The purpose of the guidelines should be taken into account when interpreting them, but if they can be clarified, that’s even better.
I get the feeling that there are many de facto standards for small things like this that aren’t clearly codified in the style guidelines. For a case like this, I would like to add a few clarifying sentences or a subsection to the guidelines. But since I rarely see others vouching for changing the guidelines, I would like to hear if there’s any principal opposition to guideline changes like them. Will it clutter up their guidelines? Should editors just use their common sense? Is the issue simply that no one bothers to open a ticket?
2 Likes
Short answer is “no”.
Long answer is “no, but they should cover stuff that happens often enough to have (or need) a general consensus behind it”.
There’s definitely a point where a set of guidelines becomes too complex and people do not read it (or can’t find answers in it) anymore. For some of our guidelines, I’d argue they’re past that point already. That’s why most of my guidelines changes have gone the other way, attempting to simplify them, condense them and get rid of over-specific things that were likely just added because whoever wrote the specific guideline thought they were important, but haven’t been an issue in practice. In some cases, having over-specific guidelines goes against the main tool we editors have to know what to do: the use of common sense.
That said, I’m not planning to get rid of all our guidelines! 
One (relatively) recent addition to our guideline set is Style/Work. That’s IMO a decent example of how we should aspire for our guidelines to look like (although I’m obviously biased!). Most stuff with works is either straightforward, or nowhere near consensus. But sometimes, that consensus is also not really needed: the most important thing with works is that they’re easily recognisable and useable, not what exact name variation should be used if a work is known by two similar titles.
So the guideline contains two things that we saw people were doing relatively often, yet seemed incorrect to us: the specific usage for work types, and the request not to add disambiguations that aren’t really useful (since all the data to separate them is basically available everywhere you see them). It doesn’t go into any other topics, and it doesn’t look at works field by field, because most other things haven’t seemed necessary to clarify just yet (I’m sure I’ll get at least two new style tickets about works now I said this, of course).
IMO this really depends on two things: “how specific is this standard” (for example, something that applies mostly to a couple artists or labels might make more sense in their annotations!) and “how much of an issue it is if something deviates from it”. Do you have any examples in mind?
3 Likes
I think cutting the guidelines down even more, but linking to more examples (a lot of well tagged edge cases are definitely missing, I’ve found that too!) would be the way to move forward.
That way we can keep the guidelines concise and clear, but demonstrate the complexities by example.
Of course we’re all a bit OCD if we’re heavy editors of MB so we naturally lean towards wanting to write every single possible detail down in stone, but I actually think that causes issues (eg maintenance, inflexibility, managing expectation)
That might seem a bit reductionist, but it’s my personal preference!
ps though I do have experience from creating and maintaining a very large helpsite for quite a few years
4 Likes
I agree with @reosarevok and @aerozol. I think the guidelines have two purposes. The first is to lay down rules to make sure that the data we have is consistent and useful. These should be as short and clear as possible. The other purpose is to give inexperienced users (or experienced users who lack experience in a certain area!) a helping hand to show what would be a good way to enter certain data. So that’s mostly examples, and it would be ok to deviate from them.
Let’s not forget that the longer the guideline, the smaller the chance anyone is ever going to read it. I imagine that it’s very disheartening for a novice editor to have the style guideline “rulebook” thrown at them the first time they edit or add something, especially if it’s that heavy.
3 Likes
I also agree that the guidelines should be trimmed like a bonsai tree. A good film editor cuts frames mostly than adds them… but a lot or more examples please.
Once an editor finds something in guideline that isn’t all that clear — let’s call it a loophole — he/she will use it as an argument and it’s enough to ensue long and heated debates over edits…
Here’s a concrete example of wording in guideline that, to be frank (which I’m not, I’m Paulo 
) still gets my brain running in loops, and here respective heated debate over this cancelled edit
Parts of titles inside parentheses section from Style / Language / English Guideline
1] Firstly, it gives 3 examples which are called exceptions (to rule). Then, right below the exceptions another set of (4 examples) titled exceptions!! Shouldn’t the latter set be called Examples or Rules?
2] “”(Don’t Fear) The Reaper". “(Don’t Fear)” could be considered optional (…)" <- How does one figure that out? How does one know if part of a phrase is optional? I was interpreting “optional” in a different sense… 
3] Those are mostly capitalized as if the parentheses do not exist, with a few exceptions as shown below.
I left this part for last. This phrase as a whole strikes me as a rule. The part italicized leads to confusion, for me that is.
Taking that into account, to apply “the rule” and using the “technique” as if the parentheses do not exist (or as fmera put it in supra referred edit: "lowercase is used, to comply with the rule to ignore the presence of the parentheses), titles like
Have You Ever Been (To Electric Ladyland) example from RYM become
Have You Ever Been (to Electric Ladyland). Correct, understandable, but… then again, the following examples aren’t actually exceptions anymore, are they? They comply with the rule.
I may be wrong here in this section’s interpretation, as if the parentheses do not exist still bewilders me sometimes, but all this just to show how this section is confusing and misleading (for us dummies).
Thanks for the feedback! There’s obviously a discussion to be had here. I can see your concern for the guidelines getting unwieldy, but I don’t think it by itself is a reason not to have definite guidelines. If that were the only problem, I’m sure it could be solved (partially) by separating the important things from the specifics somehow.
This looks like a bigger issue to me. It isn’t something that occurred to me earlier, but I can see the problem, and of course it goes hand in hand with the other problem.
I’m not against @reosarevok’s aspirations for the guidelines, but it certainly isn’t the idea I have gotten of them during my years on MusicBrainz. If their purpose is already different from what I had thought, I would like for it to be clarified, especially if we are aiming to condense the guidelines to move closer to that intended purpose in the future. Right now, the style principle only says that they should be followed, but not to what extent and what to do when they don’t cover an issue.
I agree with @aerozol’s points about the advantages of examples.
Well, consider the misc info case I used as an example. It’s not such a minor issue, there appears to be some sort of consensus and I think it’s more confusing not to have a guideline in this case. The editor has let a discussion take place. When the discussion has settled I think it would be better if the community doesn’t remain the only point of reference for such a general issue. Thoughts on this?
For minor questions that you deem unfit for the guidelines, I think the community is an excellent place to store them for future searches. I will keep asking questions that could otherwise have been answered with my own best judgment, if you don’t mind!
I should add that I’m aware that an overhaul of the guidelines doesn’t lie in the immediate future