• Se-BusT-eL over 7 years ago

    Producer, Composed By, Synthesizer, Electronics [Rhythm Machines], Design [Cover Design] – John Foxx

    was splitted into:

    Design [Cover Design] – John Foxx
    Producer, Composed By – John Foxx
    Synthesizer, Electronics [Rhythm Machines] – John Foxx

    -> http://www.discogs.com/history?release=255569#latest

    other opinions, please

    thanks
  • mawiles over 7 years ago

    The guideline which demanded combination of roles seems to have been dropped some time. But I don't know what the convention is now.
  • hafler3o over 7 years ago

    10.1.7. Please don't edit releases to move about credits between sections because of personal preferences, as this can lead to errors being introduced.

    As the release was not edited specifically to 'move' information to preference I'd say it was OK. If it also matches the release formatting then it must make it easier to check too, personally I wouldn't bother updating credits like that unless there was an error in the original credits ;)
  • ccj over 7 years ago

    ccj edited over 7 years ago
    See my obvious comments: http://www.discogs.com/history?release=255569#latest

    The convention remains, and for good reason.
    He should NOT be splitting content up onto redundant lines, and AFAIR he's been told not to in the past too.
    This is as per the rules on Discogs, nevermind the guidance virtually all internet content providers follow: data and the display of the data are separate entities.

    In Discogs case, images are allowed here for this purpose if a user wants to see the precise layout on the release, NOT the text data. Otherwise you get into data starting to get indecipherable/unreadable/unusable. Which is bad bad bad.

    In future a strong likelyhood is that users will be able to see the credits in a variety of ways as per their choosing, so this type of splitting lines needlessly is a complete waste of time all round, and should be heavily frowned upon!

    (oh, and BTW, the old "parsing" issue for credits was fixed with the new credit display system; so that's no excuse for doing this. And even if the parsing issue was still active, that is something for Discogs coding team –or person ;-P– in Portland, USA to fix, *not* for users to work around by adding the data wrongly.)
  • Mr.Mystery over 7 years ago


    hafler3o
    As the release was not edited specifically to 'move' information to preference

    Err... it wasn't?

    Seems like a completely redundant edit to me if nothing else was changed.
  • marcelrecords over 7 years ago

    Se-BusT-eL
    Producer, Composed By, Synthesizer, Electronics [Rhythm Machines], Design [Cover Design] – John Foxx

    was splitted into:

    Design [Cover Design] – John Foxx
    Producer, Composed By – John Foxx
    Synthesizer, Electronics [Rhythm Machines] – John Foxx

    The guidelines are not in favour of such updates, see the quote above.
    Mr.Mystery
    Seems like a completely redundant edit to me if nothing else was changed.

    I am not so sure about that. It looks as if the reason behind the update was to let the credits sort under their correct heading on the artist page: visual, production and instruments.
  • hafler3o over 7 years ago

    Mr.Mystery
    Err... it wasn't?

    Look again.
    http://www.discogs.com/history?release=255569&diff=30
    Certainly not specifically to move credits, a credit was moved from notes, notes were updates and BAOI expanded (as well as the credits themselves being presented in a new way closer to the release).

    As I said before, I don't favour this approach but the guidelines as I quoted, and as are written do not expressly forbid this.
  • sebfact over 7 years ago

    Oh dear, undulations...

    ccj
    The convention remains, and for good reason.
    This is as per the rules on Discogs,

    Splitting up or combining credits are neither allowed nor forbidden - unless edited on their own, which clearly wasn't the case. I wonder why we have the revisions mode?

    ccj
    He should NOT be splitting content up onto redundant lines,

    As I said, it's not forbidden and I will do it again if it's like that on the release and if there are other edits to be undertaken.

    ccj
    and AFAIR he's been told not to in the past too.

    Ain't I a naughty boy....
    http://www.discogs.com/master/25268

    ccj
    nevermind the guidance virtually all internet content providers follow: data and the display of the data are separate entities.

    This is Discogs. As-is rules.

    ccj
    In Discogs case, images are allowed here for this purpose if a user wants to see the precise layout on the release, NOT the text data.

    What if there aren't images? Or they are blurry, too small, etc. Very clever...

    ccj
    In future a strong likelyhood is that users will be able to see the credits in a variety of ways as per their choosing, so this type of splitting lines needlessly is a complete waste of time all round, and should be heavily frowned upon!

    Oh dear, making generisations out of 1 case.
    But thank you for being so caring about me wasting my time.

    No frowning necessary. The credits are now as appearing on the release - following the acknowledged Discogs as-is approach but not by my choosing! If you consider that needless then you seem to follow a personal preference.

    Anyway, case closed.
  • loukash over 7 years ago

    loukash edited over 7 years ago
    sebfact
    The credits are now as appearing on the release

    Sort of, but rather coincidentally.
    "Turn" the release page layout the other way round (i.e. switch the columns, which is just a matter of quite simple web programming), and you'll end up with this:
    John Foxx – Design [Cover Design]
    John Foxx – Producer, Composed By
    John Foxx – Synthesizer, Electronics [Rhythm Machines]

    … which is then totally pointless.

    A database is primarily about data being entered in appropriate records and fields. Splitting fields to simulate a "layout" is pretty much useless in terms of a database, as the actual record display is completely independent from the data.

    As long as there's a syntax (and there is one) how to list all credit roles in one single field correctly (i.e. separated by a comma), any splitting is superfluous, because any splitting can be done automatically by the database software. The New Artist Page structure is a "living proof" of that concept in practice. (In spite of all the failures it bears as well… ;)

    That's why § 10.1.7. is a Very Good Thing™:
    Please don't edit releases to move about credits between sections because of personal preferences, as this can lead to errors being introduced.

    Display "as on release" or not, adding other credits or not: you've still split them because of personal preferences as far as I can see it.

    P.S. ^^
    I'm referring to http://www.discogs.com/history?release=255569&diff=30 - any subsequent "edit wars" are of course pretty much pointless as well, so I'm rather being the devil's advocate here.
  • Staff 3.1k

    nik over 7 years ago

    Doing other changes to the release data does not negate 10.1.7. "Please don't edit releases to move about credits between sections because of personal preferences" http://www.discogs.com/help/submission-guidelines-release-credits.html#Credit_Fields

    The credits should have been left as they were, not split. 'As on release' doesn't matter here, we are not trying to preserve the exact typographical layout of the release.

    So this is a warning - do not alter the credit layout for aesthetic reasons please, do not get into 'edit wars', and do not make personal remarks against other users when discussing problems.
  • sebfact over 7 years ago

    nik
    Doing other changes to the release data does not negate 10.1.7.
    and
    nik
    'As on release' doesn't matter here, we are not trying to preserve the exact typographical layout of the release.

    Well, then add that to the Guidelines to avoid future edits in that respect. However, the current setup has been voted correct, twice even. So, do you want me to combine the credits again then?

    nik
    do not alter the credit layout for aesthetic reasons please, do not get into 'edit wars'

    I didn't. And I didn't change anything because of personal preferences. I was credulously following an (obviously imaginary) as-is rule.
  • marcelrecords over 7 years ago

    nik
    do not alter the credit layout for aesthetic reasons please

    Certainly, but...
    all credits on one line gives a problem on the artist page.

    ''Vocals, Producer, Design - Xxx''
    renders a credit in one of the sections only, while

    ''Vocals - Xxx
    Producer - Xxx
    Design - Xxx''

    divides the credits on the artist page over three sections, like they should.
    How could that be considered ''aesthetic reasons''?
  • loukash over 7 years ago

    marcelrecords
    all credits on one line gives a problem on the artist page.

    That's only and nothing but a page display issue.
    That's a problem which must be solved at the headquarters in Portland, Oregon, by the website layout programmers. Not by users having to split credits over several fields.
  • Staff 3.1k

    nik over 7 years ago

    marcelrecords
    all credits on one line gives a problem on the artist page.


    That issue was sorted during the artists page reorg, the credits should parse out correctly now.

    sebfact
    I was credulously following an (obviously imaginary) as-is rule.


    "As on release" is not a guideline or rule as such, it is a concept that is reflected in some guidelines on the site. It should not be applied as a blanket rule.
  • Internaut over 7 years ago

    nik
    That issue was sorted during the artists page reorg, the credits should parse out correctly now.


    Confirmed.

    sebfact
    I was credulously following an (obviously imaginary) as-is rule.


    Confirmed.
  • marcelrecords over 7 years ago


    nik
    That issue was sorted during the artists page reorg, the credits should parse out correctly now.

    I am very happy to hear that!
  • ccj over 7 years ago

    ccj edited over 7 years ago
    Comment on Rev.44: http://www.discogs.com/history?release=255569&diff=44

    [sigh, here we go again...]
    - sebfact still doesn't get it, dunno why; when the rules (& the above explanations of said rules from various other users & Nik) clearly explain.
    - Coincidence_vs_Fate voted wrongly, explained below...

    I wasn't quoting §11.1.3 actually, but if you must:
    11.1.3. The "First Letter Of Each Word Must Be Uppercase" rule does not apply to the release notes field. Normal English grammatical rules apply.

    But the rule I was using applies the same standard: § 1.2.1., as no exceptions apply here.
    1.2.1. The standard Discogs rule for artist and label names, release and track titles, format free text field, and index track titles, is the First Letter Of Each Word Is Capitalized. Track Positions can usually be represented exactly as on the release. All other text (notes, comments etc) should follow standard English capitalization rules.


    ...So that's First word of sentence cap'd, Nouns cap'd, and fullstops then please.
  • Coincidence_vs_Fate over 7 years ago

    ccj
    But the rule I was using applies the same standard: § 1.2.1., as no exceptions apply here.

    1.2.1 generally instructs on how the capitalisation in certain fields has to be done - not including the release notes. Then it states "All other text _should_ follow..." - not _must_.

    This is specifically handled in 11.1.3, which explicitly allows "free text" regardless capitalisation and by thus enables to add the designer's graphical elements / presentation. Unless it's more complex and indeed grammatical rules are to be adhered to. Something I do not question. Generally.

    But show me the grammar in the release notes then.
    It's 5 lines. No punctuation marks. No sentences.
    So, no sentence - no standard English capitalisation rule - no first letter to be capitalised. No full stops. No grammatical rules to be applied.

    ccj
    ...So that's First word of sentence cap'd, Nouns cap'd, and fullstops then please.

    Wrong! Small caps are perfectly acceptable and help to reflect the way it is presented on the release. And your edit was wrong as you have added something that isn't on the release: Punctuation marks.

    If Virgin didn't object to be written in small caps, you shouldn't bother either.
    If the designer didn't add full stops you shouldn't force them into the release notes either to only then being able to define that as grammatically relevant.
  • loukash over 7 years ago

    Coincidence_vs_Fate
    Something I do not question. Generally.

    Agreed generally, with the exception of ALL-CAPS when used solely as EMPHASIS, which I usually ask to be changed to Title Caps.
  • mirva over 7 years ago

    Coincidence_vs_Fate
    And your edit was wrong as you have added something that isn't on the release: Punctuation marks.

    o_O

    In general, IMVHO, that's taking the "as on release" a bit too far. While it's a nice guideline to have in your head, it shouldn't be followed too rigorously. A little bit room should be left for exceptions, and common sense.

    The capitalization and grammatical choices on releases tend to be affected by such non-linguistic things such as the design, marketing, and/or legal matters, which is why I wouldn't copy them exactly as they are, whether it is all small letters or all caps, but rather try to present the information, which is the most important thing, in a clear and professional manner.

    And, just to point out, the general capitalization rules apply to more than just your basic English sentence, whether it is an complete or incomplete one. The fine print can be probably considered legal writing, which is usually full of short sentences and sentence fragments.

    But just my two cents.
  • psy-mark over 7 years ago

    Not just in relation to this specific example,

    mirva
    In general, IMVHO, that's taking the "as on release" a bit too far.


    seems to be a commom 'problem', which is why it's nice to see

    nik
    "As on release" is not a guideline or rule as such, it is a concept that is reflected in some guidelines on the site. It should not be applied as a blanket rule.

  • swagski over 7 years ago

    nik
    That issue was sorted during the artists page reorg, the credits should parse out correctly now.

    Yippee, I was still in the dark as to separating 'Producer' for example.
    Are the indexed roles up-to-date in the 2nd col of Credit List?
    loukash
    A database is primarily about data being entered in appropriate records and fields. Splitting fields to simulate a "layout" is pretty much useless in terms of a database, as the actual record display is completely independent from the data.

    As long as there's a syntax (and there is one) how to list all credit roles in one single field correctly (i.e. separated by a comma), any splitting is superfluous, because any splitting can be done automatically by the database software. The New Artist Page structure is a "living proof" of that concept in practice. (In spite of all the failures it bears as well… ;)

    Thanks for that well-worded clarity

    On a 'geeky note' one could argue that the credit string should read L-to-R as per the order it appears 'as on release' top-to-bottom, per respective artist. One would then not have to subjectively decide - shall I put Producer first, or Vocals in this Artist string?
    Although the sleeve may conflict with the label order.
    I suppose it doesn't matter, if all credit-strings lead to Rome
    (Which they doubtless will on Italian releases) ;)
  • loukash over 7 years ago

    swagski
    On a 'geeky note' one could argue that the credit string should read L-to-R as per the order it appears 'as on release' top-to-bottom, per respective artist. One would then not have to subjectively decide

    This is exactly the method I'm usually using when listing the credit roles. Perhaps it's just me, but it just always seemed the most logical one to me.
  • Mr.Mystery over 7 years ago


    nik
    "As on release" is not a guideline or rule as such, it is a concept that is reflected in some guidelines on the site. It should not be applied as a blanket rule.

    Oh hell yes! I'm going to quote the crap out of this statement.
  • Se-BusT-eL over 7 years ago

    I think sebfact still didn't get it?

    http://www.discogs.com/history?release=834104#latest

    10.1.7. Please don't edit releases to move about credits between sections because of personal preferences, as this can lead to errors being introduced.

Log In You must be logged in to post.