Wikipedia talk:Flagged revisions/Consensus versions

What I like about this ... edit

After much discussion, and considering the problems with the previous proposals, I have come to realize that we have to be very careful not to damage the dynamic nature of Wikipedia that I'm sure we all value very highly. But I think we also need to have some way of measuring when a bunch of edits actually improve the article as a whole. I do think we need a more quality-oriented approach, and I think article flagging in some form would help us achieve this. I'm not at all sure, that any of the current proposals, are what we want... so let's hear the most critical opinions. And I'm not going to vehemently defend this proposal, in fact, I might even reject it myself. But right now it seems like a reasonable idea to discuss. --Merzul 13:53, 12 October 2007 (UTC)Reply

There's a definite tension between the goal of "perfecting" the encyclopedia and the goal of keeping it open to further improvement. It's hard to anticipate how any of the "flagged revision" specifications would change the dynamics of the wiki, so I can't tell if what you're proposing here would produce a better result for the encyclopedia or a worse result, long-term. Bad writing is undesirable, even if it's well-meant, but ownership is bad too, even if it's in the form of a "consensus" of a specific clique of editors. That does happen on Wikipedia, and I'm worried that it is becoming more commonplace the more Wikipedia matures. Is there more we can do to avoid it?--Father Goose 03:50, 13 October 2007 (UTC)Reply
Right! Ownership is something I had not thought about. Something like these consensus versions, or anything based on trying to flag something based on talk page discussions, makes is a very risky business. There is one thing one could do, and that is to inform the relevant WikiProjects whenever a consensus discussion is going to happen. I thought advertising these discussions widely would be a waste of resources, almost like spamming, but if a WikiProject place their banner on an article talk page, then they indicate will receive notices of consensus discussions. Something like this perhaps... --Merzul 16:45, 13 October 2007 (UTC)Reply
Perhaps any ideas here can be merged into /Quality versions. Voice-of-All 05:56, 14 October 2007 (UTC)Reply
Yes, you are right, in terms of software, this seems like a quality versions implementation. What one could do is have quality versions, and then in the subsection about how the quality reviews are picked, there are three different options:
  • Via specific reviewers, who are given the independent authority.
  • By FAC style processes.
  • Through talk page consensus style approaches.
And then we can remove this proposal, alternatively, we can group proposals into light-weight and heavy-weight, thus competing implementations of the software feature for "sighting" and "quality". I don't think it makes sense to have a third layer. --Merzul 10:23, 15 October 2007 (UTC)Reply
I'd prefer to have three levels than to have "quality versions" have very variable standards. Specifically, I see complete fact-checking as the absolute minimum standard for quality versions, whereas "consensus versions" might promote a lot of "we don't know if this is accurate or not, but we like it". There's an implicit guarantee that goes along with review and flagging -- with sighted versions, that there's no vandalism; with quality versions, that there's no inaccuracies (within reason). What guarantee would we be shooting for with a "consensus" level of review? Perhaps if we fold it into "quality", it should just be that in addition to fact-checking, a version should not be passed if it is substantially disputed.--Father Goose 17:11, 15 October 2007 (UTC)Reply
I think the integration into "quality versions" would be to also require well-defined standard, or standards (as I understand a version can be reviewed at different accuracy levels), when there is consensus that something might be of high quality, then the editors asks a reviewer to review it, this editor then checks if there is consensus and if it conforms to certain quality standard or some process as you have provided in the quality version page. I think we can mark this proposal as rejected and continue discussion in the quality versions. In retrospect, it only makes sense to fork the quality versions proposal, if we can't make progress through discussions! --Merzul 17:43, 15 October 2007 (UTC)Reply

Instruction creep edit

This seems to be a bit too much of a creep. I can't see this getting much use, and when it does, couldn't someone just discuss it on the talk page and agree on some rev ID? Do we really need more software and formal policy changes for this. Voice-of-All 05:31, 14 October 2007 (UTC)Reply

Well, I gather this is intended to be somewhere in between "sighted versions" and "quality versions" in terms of rigor. But I do think it's far too elaborately specified at present. It should be pared down to a very minimal spec, and if it does get adopted, let those actually using it in the field add "rules" to it.--Father Goose 05:56, 14 October 2007 (UTC)Reply
Actually, I don't know where it was intended. I don't think it can be used together with the other two, this would be a replacement, or one could think of it as one concrete implementation of quality revisions. It is terrible instruction creep, that I certainly agree to, but however one does this, some process is needed for the quality revisions.
  • The simplest option would be to trust certain reviewers, people we know are extremely fair and rigorous in their fact checking, and more importantly, are good at listening to other people's opinions. I know such editors do exist, and I would fully trust them to do the "quality" revision work, but I'm not sure everyone would accept giving a bunch of editors so much power.
  • The other option as suggested in the Quality proposal I believe is to sync it with FAC style processes. Perhaps that is the most promising, but even that requires additional process. Currently, an article gets promoted, but then editing continues, and so who decides which revision was the "quality" revision? Personally, I have no problems letting the FA driver or some group of "reviewers" do this, but again I'm not sure skeptics would like this.
  • Finally, the consensus version style thing, and again some rules are needed, for example, like the current proposal.
Having said that, perhaps it does make sense to just cut these down to the bare minimum of what they are intended to achieve, merge into the appropriate proposal according to the software feature they require. In this sense, this is a "quality" revision type proposal. --Merzul 10:32, 15 October 2007 (UTC)Reply
Regarding the "simplest option", I more or less suggested such an approach over at Wikipedia talk:Flagged revisions/Quality versions#Proposed process. I don't think we need to give fact-checkers any special powers or status -- if they have a reputation for good work, we will trust them when they vouch that they have fact-checked an article. We only need special status for those who do the final check-for-reputation and/or consensus before promoting the article -- and their role would be similar to that of a Bureacrat, as Voice of All pointed out.
I just added a line to the spec I proposed there which makes it explicit that Reviewers should not promote a version that is objected to. This is a less bureacratic approach than insisting there be a poll or discussion over every promotion -- in most cases, silence implies consent.--Father Goose 17:42, 15 October 2007 (UTC)Reply
We must be cross-posting :) this wasn't here a few seconds ago... I think we are converging on something here, so it is probably safe to reject this one and merge whatever of value to the QV proposal. --Merzul 17:47, 15 October 2007 (UTC)Reply