Voting Guidelines

Starting off with some of my thoughts.

Voting

RSG §20.2.1. The primary function of voting is to tag the current correctness of the information.

RSG §20.2.2. All votes should be based on the current Submission Guidelines. Please follow and keep up with changes in the Submission Guidelines. Guideline changes will be posted in the Guideline Changelog forum thread, please check there before voting. Follow the guidelines as closely as possible.

RSG §20.2.3. The voting system is based on the understanding that the adding or updating the information is at least trying to make an honest attempt to improve the Database.

• First: Fix it if you can. Comment if you can't.
• : the vote will be received by the last editor.
• Familiarize yourself with the “minimum requirements” for a correct submission RSG §1.3.1.a and vote or comment accordingly.
• s that vandalize, remove, obfuscate, and otherwise make malicious and damaging updates, should be marked 'Entirely Incorrect' and an abuse report should be made to the Database team.
• If the last edit attempted to address a previous incorrect issue, votes applied for previous issues should not exceed Needs Minor Changes.
* Bear in mind RSG §20.3.1 "Go easy on new s"
* Do not vote your own submissions "correct" until and unless other s have made subsequent edits.

RSG §20.2.4. Votes are NOT counted on images, please do not vote on image additions / adjustments, please update the images yourself if you think there is a problem.

====================

RSG §20.2.5. Votes for releases should follow the table below.

Complete And Correct +5
This vote can be used when the entry contains enough information to be considered complete; above and beyond the minimum requirements for a 'Correct' vote. A release that qualifies for this vote should include all of the following:
• Good quality scans of the printed areas of the item;
• Full credits, all company and label information;
• Any run out etching information;
• All identifying numbers printed on the release;
• Any distinguishing features noted in the Release Notes;
• Explanation of data submitted in Submission Notes.

Correct +4
For release data that contains correct information, with at least the minimum standard RSG §1.3.1.a set in the guidelines. An entry can be correct but still need more information to make it complete. No explanation is needed for this vote, but comments can still be left.

Needs Minor Changes +3
This is used to mark an entry where only small changes are required: Things like capitalization, spelling in track names and notes, track numbering, catalog number formatting, general title and track title formatting. The voter must point out the items that need changes. If possible - how to do so, and why to do so (especially for new s).

Needs Major Changes +2
Major changes would be considered to be incorrect artist(s), incorrect label, incomplete tracklist, and/or many minor errors that add up to a lot of errors in the data. The voter must point out the items that need changes. If possible - how to do so, and why to do so (especially for new s).

Entirely Incorrect Edit +1
For updates to the release; that are totally incorrect, incomplete or vandalism. You believe there is nothing that can be 'rescued' from the edit. This vote will revert the last edit! If the edit contains correct information and can be improved and made more correct by editing, do not use this vote, use 'Needs Major or Minor Changes' instead. This vote should be used sparingly. You must give a good justification in the submission comments for using this vote.

Entirely Incorrect Submission +1
For release, artist or label data that is totally incorrect, incomplete or so badly entered that it is impossible to judge whether it is a valid addition to the Database. For s that vandalize, obfuscate, and otherwise make malicious submissions. If the release is attempting to describe a unique release and can be improved and made more correct by editing, do not use this vote. This vote should be used sparingly. You must give a good justification in the submission comments for using this vote.

And general comments:
Stop asking s to link all credits. ̶A̶s̶ ̶t̶h̶e̶ ̶f̶r̶e̶e̶ ̶t̶e̶x̶ ̶F̶i̶x̶ ̶i̶n̶ ̶g̶u̶i̶d̶e̶l̶i̶n̶e̶s̶ ̶m̶a̶y̶b̶e̶?̶ ̶U̶n̶l̶i̶n̶k̶e̶d̶ ̶o̶k̶a̶y̶ ̶i̶f̶ ̶y̶o̶u̶’̶r̶e̶ ̶n̶o̶t̶ ̶s̶u̶r̶e̶ ̶o̶f̶ ̶P̶A̶N̶?̶
LOL, I either mised or you've changed. It already says "add unlinked writer credit(s) where the full name is not known"
Stop asking s to add runouts unless absolutely needed - often wrong. I f’d up at first myself – missed about 100 “p”s.
Basically stop asking s to add more than the required minimum!
It’s just not right that s asking for votes get negative votes instead of help.
Send welcome letter to new s: Link guidelines, link to forum for new questions, explain CIP.
Send welcome letter to new voters: Link voting guidelines, explain CIP, caution on harsh votes.
Check/fix algorithm for voting rights.
Fix or clarify the current voting guidelines.

Great stuff! Much to dig into here, so I am going to reply to random bits in no particular order as I process things. Yee haw.

TopCats45s
Fix it if you can. Comment if you can't.

There's a lot of parallels to wikipedia's approach that I strongly agree with: https://en.wikipedia.org/wiki/Wikipedia:Be_bold

TopCats45s
I think you did too Brent.

I don't think I added any for the first few years until I realized it was a plant id and not some kind of weird pressing machine artifact. Transcribing matrix data can be extremely difficult. We've entered into an era where sometimes properly identifying the right copy requires a level of knowledge of detail that was not required when the guidelines were written & the voting system was implemented.

For certain types of releases (largely, mainstream physical media releases from roughly the 50's through the 00's), the learning curve for proper identification has grown significantly. It's also very unfortunately an extremely common entry point into learning about physical music.

As a result, some of the most difficult releases to work with are also those more likely to be handled by novice contributors than others. It's extremely important to this when working with those submissions. Which segues into..

TopCats45s
Stop asking s to add runouts unless absolutely needed

& if you do need to ask for additional information, be clear & precise in why the information is needed, where they are able to find it, and if the symbol is abstract, anything to help with it's identification. Keep some template fill-in-the-blank questions in a document to speed up the process if it helps.

TopCats45s
the required minimum

I think it might be good to think about the "optional information trap" that new s often fall into by trying to be helpful, adding as much data as possible, and getting into the deep end of the pool accidentally, say by putting a bunch of credits/companies in notes, which then can't be removed because valid information and we force a new to perform an advanced difficulty submission, only to receive additional NMi/aC votes upon each unsuccessful attempt to rectify the issue.

MORE TO COME.

You have a different perspective than me jazz_spirits

"Just giving negative votes" - In my field of vision, many of the s ask questions or make statements first especially with the new s. It's just (I think) the new doesn't respond or isn't on Discogs as often as us nuts.

"2 and 3 these two can go away" and then "EI vote could suffice for anything that is wrong" That would involve getting tekkies involved and rewriting the whole program. Right now, the last thing you want is only keeping EI because that carries the highest penalty. Should be reserved for vandalism or total incompetence.

"requesting an OS recheck their releases" No problem with that. But it's not required (and newbies shouldn't be made to feel that) unless that is what distinguishes it. And if a knows THAT, then they know to add the runouts.

"that doesn't always work with everyone" I gave out my very first EI the other day to deliberately get a on CIP. I felt bad about it, but messages, light votes, comments, nothing worked. Every single one of his submissions was an extremely poor dupe that had to be merged.

I do agree with everyone that the voting system needs a complete overhaul. That's long term though. So, short term - what do you think needs to be added or adjusted in either the guidelines or in the description of the votes?

I think too that a voter reminder link to the minimum requirements would be useful in the voting guidelines. RSG §1.3.1.a

TopCats45s, I've just reread your first post and I think it's all excellent. I like that you've included Brent's "Fix it if you can. Comment if you can't... etc." quote. It's a good one.

I added that line we discussed. Reading the whole thing, I think it rambles and repeats too much.

There. Fixed. Well, I think so. Anyone?

Should "* Do not vote your own submissions "correct" until and unless other s have made subsequent edits." be in a separate section with the complete Nik/Brent "rules"?

TopCats45s
• : the vote will be received by the last editor.
• Familiarize yourself with the “minimum requirements” for a correct submission RSG §1.3.1.a and vote or comment accordingly.
• First: Fix it if you can. Comment if you can't.
• s that vandalize, remove, obfuscate, and otherwise make malicious and damaging updates, should be marked 'Entirely Incorrect' and an abuse report should be made to the Database team.
* Bear in mind RSG §20.3.1 "Go easy on new s"

Can we put the "First: Fix it if you can. Comment if you can't." with bold letters? :-)

But in general, all of the above sounds good, and is a step to the right direction. While it may take a while to improve voter behavior, it is important to try to encourage voters to be more comionate when reviewing/voting if the system stays the same. Like many others, I would like to see the system changed but can also understand if it's not possible.

• If the last edit attempted to address a previous incorrect issue, votes applied for previous issues should not exceed Needs Minor Changes.

Kinda torn about this, because it suggests giving a negative vote to an editor who was trying to improve things. If someone improves things, even if a little bit, it is a good thing.

* Do not vote your own submissions "correct" until and unless other s have made subsequent edits.

Isn't this redundant? You can't vote on a release if you're the last editor, so it's technically impossible to vote on your own submission until someone else has edited it. Or is the point that there needs to be multiple edits by several s?

I also thought that there had to be a correct vote in-between, in addition to someone else editing it?

TopCats45s
I gave out my very first EI the other day to deliberately get a on CIP. I felt bad about it, but messages, light votes, comments, nothing worked. Every single one of his submissions was an extremely poor dupe that had to be merged.

I think most voters do feel bad about EIs, even NMCs (at least I do). EI is the non-fun last resort tool, and I think there should be an easier way to deal with vandals and other problematic s.

auboisdormant
Can we put the "First: Fix it if you can. Comment if you can't." with bold letters? :-)

I think everyone agrees on that 😊

auboisdormant
it suggests giving a negative vote to an editor who was trying to improve things

True. Maybe better wording - Diognes_The_Fox that's your line. What do you think?

auboisdormant
You can't vote on a release if you're the last editor

That a big huge LOL. I never noticed. However, I have asked if there should be a separate section with the complete Nik/Brent "rules" based on https://www.discogs.sie.com/forum/thread/180661 It's rather detailed though.

auboisdormant
see the system changed

Yeah, it was a bummer finding out it couldn't be done anytime soon.

auboisdormant
last resort tool

That's what is being emphasized, I hope it helps.

Okay - how bout this (chuckle here):
• If the last edit attempted to address a previous incorrect issue, votes applied for previous issues should not exceed Needs Minor Changes. Re-read the first 2 bullets above.

TopCats45s
• If the last edit attempted to address a previous incorrect issue, votes applied for previous issues should not exceed Needs Minor Changes. Re-read the first 2 bullets above.

It's better. ;-)

I mean in the end it's not a huge deal, I doubt it happens that often. Most of the time, voters try to communicate with the previous editor. (This again reminds me how great it would be if all owners would get notifications of comments and votes.)

I just would like to get rid of the habit of "punishing" s who do good updates. Could also talk about how much benefit there is in flagging something NMC... I've seen decade+ old NMC votes that no one has addressed. I think they sometimes prevent s from fixing other issues.

TopCats45s
However, I have asked if there should be a separate section with the complete Nik/Brent "rules" based on https://www.discogs.sie.com/forum/thread/180661

IMO yes. Important forum decisions/discussions amend the guidelines, and often help with the details and some of the more complicated cases. The old Discogs wiki (RIP) had some of them listed, so including a section in the guidelines or even a pinned thread in the database forum would be helpful.