Quoting Scooter1836:

Quote:
Quoting mediadogg:

Quote:
@Scooter1836, I'm loving all those thoughts.

So we would have at least these three tasks going?

(1) Priority set of rules updates
(2) Contribution Wizard
(3) Definition of Consensus process to be used for Rules Change submissions to Invelos (I like all those ideas you have on this)

Only question is, how do we get some folks working on them? Anything you can do to get stuff organized, please go for it ...

I think the first thing to do is define a process for concensus building.  In the past that has been a big part of the Ken's process that has been missing.  For smaller things that has not been as much of an issue.  What I can do is come up with a proposal for that process in the "Contribution Rules Committee forum.  But I would not be able to do it until later next week.  However that may work out since some key people are staill awaiting access.

After a consesus process is agreed upon we should then formulate the list of rules/issues we want to tackle.

A process for building consensus is absolutely needed.  If you ask, "How do I apply this rule?", even if it takes a lot of arguing, people will usually eventually settle on a single answer.  If you ask, "What should this rule be?", all bets are off; everyone will have their own pet idea on how things should work, and agreement is a rare commodity.

In any given poll where the options are A, B, C, D, or "I don't know", you'll be lucky to get more than 1/3 of all respondents voting for any single choice.  The main problem is, nobody who votes has to justify their choice with actual, verifiable argumentative details.  They can just say, "I don't like the choices" or "I don't like you" or whatever, and nothing ever gets accomplished.  The anonymity of the poll also means that you can't ask specific people about why they chose choice X over choice Y.

I had, back in the day, a specific mathematical pattern that I used for determining the validity of consensus for a poll result.  I don't think I saw more than one poll that passed muster as a valid consensus.  In the end, the mathematics don't matter very much (though I can still provide some mathematical validation if that's desired) because they don't address the underlying issue: the people usually vote for their gut instinct on any given issue, but gut instinct doesn't provide a convincing argument, and there's no real way to tell whether it's 'right' or 'wrong'.


If I were to write up rules for a process of how to go about things, I'd probably go with the following (quick and dirty overview):

1) One thread per discussion topic, and that thread must be defined as narrowly as possible.  If it's related to other issues, it can reference them (eg: in other threads), but it should maintain its focus on the single issue that can be defined by a single answer.  If the topic finds itself dependent on the results of an unanswered question or undefined/poorly defined term or similar, it can be put on hiatus until the underlying question is resolved.

2) There should not be a poll for the basic discussion.  This helps avoid the issue of the poll setting limits on what people are allowed to answer.

3) The OP needs to lay out the details of the issue in the starting post, and should maintain a full list of arguments, objections, and resolutions (with justifications) within the post so that everyone can see the full summary of the activity on this question.  In other words, whoever starts the question has to remain an active participant.

4) Arguments that are logically flawed (as in, break down due to logical fallacies) should be tossed out.  If you can't form a coherent argument to support your point, there is no reason to consider your point valid.  "I don't like it" is not a valid argument for an objection, though it might be used as a starting point for trying to define what the actual objection is.

4a) In order to support this, a fair number of truly fundamental principals and terms must be defined.  There are a great many things in the current rules that are simply assumed, where their clarification and definition would make answering other questions easier.  A reluctance to complicate the rules with this information does not mean that they should be ignored altogether, though they do not necessarily have to be directly integrated into the general rules document.

5) In order to consider an objection 'resolved', there must be a logically complete and coherent argument that addresses the issue that the objection brought up.  An objection to the resolution should be handled the same way as for the principal topic itself.  A single person refusing to accept the resolution does not mean an objection has not been resolved.

A resolution that defers the issue (eg: it requires a change to the program, and thus can't be resolved until Ken implements it) can be considered resolved for the purposes of argument, but not for the purposes of the consensus (ie: moving to point 6) unless there is full commitment that the deferred action is absolutely going to take place (eg: Ken posting that he will definitely implement the change).

6) Only if -all- objections to the original point are resolved to the satisfaction of most participants can you consider it to have reached the first tier of consensus.

7) After that, the wording that describes the full consensus must be written.  I would recommend two forms: one that is complete, and can be used as an absolute reference to cover normal and edge cases (any new edge cases that it can't answer would prompt a new adjustment round); and one that is simplified to the most minimal level that can answer all non-edge cases for general use.

8) After that, you can form a poll to codify the resolution of the topic.  The poll should be a simple agree/disagree split.  Any votes for 'Disagree' must post with the details of the objection.  This stage does not require fully formulated objections, and may reference objections that were considered 'resolved' in the main thread (eg: if someone explicitly does not agree with a given resolution), or issues with the process itself.  Only negative votes that are accompanied by the point of objection will be considered valid.  Other 'Disagree' votes will be discarded.

9) If, after that culling, you can reach a 2/3 majority of agreement, then it can be considered a valid consensus for submission.

9a) Optional: If there is no explicit rejection of the consensus, it can be considered tentatively valid for use within some time period after the consensus is reached (I won't attempt to define what that time period might be).  I'd only include this in order to get around the issue of stagnation/unresponsiveness on Invelos' part.  IE: they must be part of the process if they want to maintain the relationship with the community.



The agree-upon simplified rule form would provide guidance for all standard use cases, which is all that most people need most of the time.  Ambiguity regarding edge cases should be referred to the more complete form of the rules.


The above is somewhat similar to the basic idea of how to get a rule changed in the Rules Committee forum, though obviously far more verbose and detailed.  And, being a set of rules itself, I'm sure there will be those who object to what I've written here.

There are aspects that could make it easy to push things through over objections, and there are aspects that could make it easy to completely stonewall a given topic.  I deliberately went for a construct that would allow for both.  In the current environment, it's far easier to deadlock than it is to make progress, which leads to people just giving up in frustration, so I tried to ensure there were levers for moving forward on things that are well justified while still having walls to keep changes from progressing too fast.  In a cooperative setting I would expect things to be easily resolved, but given past history here, that's most likely wishful thinking.

I have a question. Should all of this be done here?

Not to "take things away from the forum" as it could look if we did so, but I'm wondering how we can have discussions on amendments, rebuilding, and so many other issues without it clogging up the Contribution Discussion forum (or even the Rules Committee forum) in a way that makes it impossible to tell which topics/questions are related to how things are being down now and which are related only to propositions in the new business model.

@Kinematics
Thank you by those reflexions, which could work. But I think that we are in front of a huge work seeing how the rules are made. And I fear we'll never see the end of this process.

Rules are made on this general (and caricatural) model:

For this field, take the information from that place and copy it exactly.

Note that rules have very rarely a definition of what we want in the field (ex: what is a "DVD title" ??)

It works in 99% of cases, until there is, in the indicated place, an error or something that can't be copied exactly, or something that is beyond that should be in the field. Those remaining 1% cases are at the origin of most of animated and controversial threads, since most users accept to bend rules when they are interested by what is in the field, and refuse that other users bend rules for fields they do not care (this is particularly evident for crew roles).

We never speak of the 99% of cases that work fine (even if there may still be errors in profiles, this is just human unvoluntary errors from the contributor), and discuss during endless threads whether we want stupid data which follow blindly rules (rules that had just not anticipated the case), or satisfying data that bend the rule (in some rare cases, Ken posts "yes, use the correct data", and everybody is happy with that, since it's Ken, not a user, that gave the intelligent evident solution).

Once again, and it is probably the last time I propose that, wouldn't be simplier to just add to the introduction of rules a general sentence saying that we want correct data in the database, and each time a contributor has to bend the letter of the rule to keep to spirit of it, he just has to document his contribution and let screeners decide.

Quoting marcelb7:

Quote:
To all users who are working on this project: For an additional point of view, you might want to take a look at the contribution rules of discogs.com.

Really very interesting. In particular, they have a "Errors, Missing, and Conflicting Information" chapter

The general principle of entering information into Discogs is to reflect what is written on the release as much as possible. When the information printed on the release does not match the audio on the release, we enter the actual audio content, and outline the error in the release notes. It is important at all times to communicate the errors and nature of the correction with other users, using the release notes and the submission notes..."

This seems full of common sense. How can we live without accepting there are exceptions ?

Quoting surfeur51:

Quote:
Quoting marcelb7:

Quote:
To all users who are working on this project: For an additional point of view, you might want to take a look at the contribution rules of discogs.com.

Really very interesting. In particular, they have a "Errors, Missing, and Conflicting Information" chapter

The general principle of entering information into Discogs is to reflect what is written on the release as much as possible. When the information printed on the release does not match the audio on the release, we enter the actual audio content, and outline the error in the release notes. It is important at all times to communicate the errors and nature of the correction with other users, using the release notes and the submission notes..."

This seems full of common sense. How can we live without accepting there are exceptions ?

Underlining by me. We do the same thing here for the audio and video. If the information on the cover is incorrect compared to the actual disc we use the information from the disc and note this in the contribution notes.

Quoting TheDarkKnight:

Quote:
I am just saying that the use of the words "correct data" and "incorrect data" isn't black and white.

Well, I would say that "Nude Nuns with Big Guns" (incorrect per Invelos rules before Ken's clarification) is correct data, and both solutions ("Nude Nun with Big Guns" , "Nude Nuns with Big Gun" ) allowed by Invelos rules (before Ken's clarification) are incorrect. An overview which does not match with the movie on the disc is incorrect data (correct per Invelos rules). When a movie is made by two directors working together, they are called co-réalisateurs in French. Direct translation is co-directors, and is not allowed by rules. I think a database with a movie without director has not correct information...
A database that uses four non linking names for the same actor who never used any variant in credits is also incorrect information. I could give many other examples... and for all of them, can document my reasons so that screeners may decide if I'm right or not.

Quoting surfeur51:

Quote:
Quoting TheDarkKnight:

Quote:
I am just saying that the use of the words "correct data" and "incorrect data" isn't black and white.

Well, I would say that "Nude Nuns with Big Guns" (incorrect per Invelos rules before Ken's clarification) is correct data, and both solutions ("Nude Nun with Big Guns" , "Nude Nuns with Big Gun" ) allowed by Invelos rules (before Ken's clarification) are incorrect. An overview which does not match with the movie on the disc is incorrect data (correct per Invelos rules). When a movie is made by two directors working together, they are called co-réalisateurs in French. Direct translation is co-directors, and is not allowed by rules. I think a database with a movie without director has not correct information...
A database that uses four non linking names for the same actor who never used any variant in credits is also incorrect information. I could give many other examples... and for all of them, can document my reasons so that screeners may decide if I'm right or not.

I understand that but you have to draw a line between what is incorrect in your opinion or what's incorrect according to the rules. You can't mix these two together unless there are rule changes.

Quoting surfeur51:

Quote:


- correct data match the reality, incorrect data do not reflect the reality.

Examples of incorrect data : 1.78/1 when movie is 1.33/1
                            1h40 when movie duration is 140'
                            overview that describes a movie which is not the one on disc
                            wrong spelling for names : Brice Willis
                            wrong spelling for titles : L'Insoutenable Legerete de l'etre
                            cover scan that do not match with what you have in your hand
                            spelling or grammatical errors
                            ...

I hate when you you the word reality.  What is real, is what is in front of me.

Let's take your examples

1- Aspect ratio.  If the cover says 1.78, and you  can verify on the discthat it is 1.33, then you are allowed to change it, per the rules

2.  If the runtime says 1h 40 minutes on the cover, and verification on the disc says 140 minutes (2h 20m) then you are allowed to correct it per the rules.

3. Wrong overview (that is something that probably needs to be discussed by itself)

4.  Name misspellings - in cast crew list, that is what we have "credited as" for. In overview, we copy what is there (that is reality, it is what I see).

5. Misspellings of titles - For release titles, that is what original title can take care of, in overview it goes in

6. Scans - limitation of program, as long as you are referring to a valid original in the db.

7 Spelling grammatical errors.  In overview, you leave them.  We really do not want to get into arguments over grammatical errors.  THE ONLY VALID SOURCE FOR THE OVERVIEW IS THE COVER.  We catalogue what we see.  That is the reality of the rules and program.

Quoting The Rules:

Quote:
If you wish to save different information in your local profiles, you are free to do so in your local database, but do not contribute your information. The main database is standardized so that all profiles follow these rules. DVD Profiler allows you to lock your data so that it is not overwritten by updates from the main database.

I know that you feel you are trying to do justice for the Online and therefore the users, but if we get into correcting things into data that is not in front of us, then arguments and endless discussions will ensue.  Can you imagine an argument over whether it grammatically should be an en dash or em dash, or maybe just a hyphen.

We type in what we see (with the disc being the ultimate source), and make alterations to our local.  In my opinion this is what is necessary.

Charlie