Wikipedia talk:Mediation Cabal/Cases/27 February 2012/Wikipedia:Verifiability/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Closing the RfC

All of this preparation and work will be ruined if the closing of the RfC has problems like the previous large RfC regarding the lead of Verifiability. I don't see any reason why that wouldn't happen again if this issue isn't properly addressed. Before the RfC is begun, there should be policy in place to mitigate the type of closing problems that previously occurred. --Bob K31416 (talk) 19:05, 12 May 2012 (UTC)

That should be easy to do... announce that the RFC will run for a full 30 days, and don't close it until those full 30 days have run (even if it seems clear that a consensus has formed before then). And then... Advertize, Advertize and Advertize some more... so no one can say they "didn't know the RFC was taking place" (at least not with a strait face).

I assume that Mr. Strad will be the "proposer" of the RFC... if so, he should not also be the closer... as we get to the 30 days mark, Mr. Strad will seek a completely uninvolved Admin (or group of admins) who neither took part in this mediation nor left a comment (in any way) at the RFC, to act as closer(s) and summarize the results. Blueboar (talk) 19:46, 12 May 2012 (UTC)

It's established custom and practice that we can unilaterally revert any closes we don't like, as well. (Still furious about that.)—S Marshall T/C 20:00, 12 May 2012 (UTC)

Plus one to what S Marshall is still furious about. It's really important that we set everything up in advance to preclude that from happening again, and we should take our time now to make sure that we've got all those kinds of issues covered. And I'll throw in a pitch for having three uninvolved administrators doing the close (even inviting the same three as last time, if they consent, because it would make it very difficult for anti-change people to fight about any pro-change decision then). --Tryptofish (talk) 20:41, 12 May 2012 (UTC)

Plus another on the furious. North8000 (talk) 22:26, 12 May 2012 (UTC)

Me, too. Pesky (talk) 05:37, 13 May 2012 (UTC)

Of course, this is immensely and closely related to what the "question" is, the closer(s) must conform to that, whatever is decided. I had my "aha" moment on this in the bathroom today. If we don't have an "either or" situation (i.e. voting) then we don't have the pitfalls that require instant runoff to avoid them. So if the question is "which of the 4 proposals shall go in?" and if the instructions are (roughly speaking) "give your thoughts on EVERY version" and that you can "strong support" more than one, then that might work. Finally, I trust Mr. Stradivarius more than any random admin. They should be the closer or one of the three closers. Or I can think of a couple of controversey-shunning experienced admins who would want absolutely nothing to do with this who would have to get dragged in at gunpoint to handle it which would also be a good criteria for someone to handle North8000 (talk) 22:39, 12 May 2012 (UTC)

• It's not fair on Mr Stradivarius to ask him to close as well as mediate. It's also not okay: he !voted in the first poll and counts as involved.—S Marshall T/C 01:07, 13 May 2012 (UTC)

Thanks for pointing that out. You're right. But if you're involved, that still means that you can revert the close if you don't like it, right?  :-) North8000 (talk) 01:54, 13 May 2012 (UTC)

• Don't worry, everyone, I won't be closing the RfC. I thought that was obvious. :-) As well as not being an admin, I have also spent a lot of time in the current esteemed company, which is probably enough to make me seem involved to editors outside the mediation. I also !voted in the last RfC, as S Marshall pointed out. The three uninvolved admins idea is probably the best one, though it may be hard to find three admins who have been completely uninvolved with these issues! I suggest posting on WP:AN a week before the RfC is due to close to solicit closers. Leaving it closer than that might be too much of a rush, but doing it earlier might mean that the closers who we find are not sure of their schedules yet. — Mr. Stradivarius ^♫ 04:43, 13 May 2012 (UTC)

Did Ironholds !vote last time? If not, he might be a good closing-team-member, if he can be dragged to it ;P Foxj might be another good team member. Both have their heads well screwed on. Pesky (talk) 05:49, 13 May 2012 (UTC)

• We shouldn't be choosing the closers. That's another procedural thing that people could object to. Perhaps we should refocus on the exact questions to ask?—S Marshall T/C 10:10, 13 May 2012 (UTC)

Agreed. We should focus on the question at hand. Let's decide what combination of drafts and general questions we should have first - we can worry about other details later. To this end, I'm archiving this thread. — Mr. Stradivarius ^♫ 11:07, 13 May 2012 (UTC)

Step 7

Strad, will you be setting up a separate page (with accompanying talk page) for us to work on Step 7... or will we draft and discuss it here on this talk page? Blueboar (talk) 17:43, 6 May 2012 (UTC)

I thought I'd set up some kind of a separate page, yes. I'm not exactly sure how it will work yet, but I had a vague idea that we would draft it on a separate page and discuss it here. If you have any ideas, then please let me know! — Mr. Stradivarius ^♫ 21:13, 6 May 2012 (UTC)

Nah... that works for me... I was just curious. Blueboar (talk) 01:01, 7 May 2012 (UTC)

Blueboar, I notice that you put a "reply" to one of the bullet points in the brainstorming section. Mr. Strad can correct me if I'm wrong, but I am under the impression that we are not supposed to be doing that. --Tryptofish (talk) 20:10, 7 May 2012 (UTC)

I've removed the reply. Feel free to insert it as a new idea at the bottom though. — Mr. Stradivarius ^♫ 21:16, 7 May 2012 (UTC)

No problem... I had neglected to read the instructions. My bad. Blueboar (talk) 21:23, 7 May 2012 (UTC)

It will be immensely difficult and important to pick the structure and instructions for the next step. Some easily-made mistakes could sink this whole effort. A thorough discussion/decision is needed on that. Sincerely, North8000 (talk) 02:23, 8 May 2012 (UTC)

Lead of present version of WP:V

How does the lead of the present version of WP:V fit into the plans for the RfC? --Bob K31416 (talk) 01:20, 7 May 2012 (UTC)

I'm not sure yet. We'll discuss all this after we finish the brainstorm. — Mr. Stradivarius ^♫ 21:21, 7 May 2012 (UTC)

From the department of herding cats...

Please note that, today, the lead sentence at WP:V was changed from "the reader's ability" to "a reader's ability". I think that this change may, perhaps, need to be reflected in one or more of our drafts. --Tryptofish (talk) 21:45, 8 May 2012 (UTC)

If people think there's a need, then that's fine by me. — Mr. Stradivarius on tour ^♫ 22:26, 8 May 2012 (UTC)

I do think we should do that for Group 2 (assuming it stays that way at WP:V). --Tryptofish (talk) 22:46, 8 May 2012 (UTC)

Herding cats.....don't let anybody tell you it's easy.[1] --Bob K31416 (talk) 04:05, 9 May 2012 (UTC)

Meow! --Tryptofish (talk) 21:38, 9 May 2012 (UTC)

So somebody just cruises in and edits a locked article? North8000 (talk) 10:33, 9 May 2012 (UTC)

From my (somewhat hazy) recollection, there was some discussion (and agreement) on the talk page about it. Pesky (talk) 11:08, 9 May 2012 (UTC)

Yes, that's what I saw too (although one needs a scorecard to keep track of that talk page!). Personally, I'm not really convinced that there was enough discussion, but I would have complained loudly had there not been any. At least it's a pretty minor change, as far as I can tell. As I understand it, the reason is that "the" can be misunderstood by readers for whom English is a second language. Go figure. --Tryptofish (talk) 21:38, 9 May 2012 (UTC)

Hmmm... a grammar question... does saying "the reader's ability" indicate that we think Wikipedia has only one individual reader? Just a thought. Blueboar (talk) 12:10, 10 May 2012 (UTC)

I think "the reader" can refer to a generalised reader, not necessarily one specific person, but I'm not sure if this would be clear to our autism-spectrum editors. It might be better to pluralise to "readers' ability", with no "the". You might want to check with someone who actually knows their grammar, though. — Mr. Stradivarius ^♫ 12:33, 10 May 2012 (UTC)

Drafts and general questions

Thank you to everyone who took part in the brainstorm! I think that some of those ideas are very good, and I also spotted a few ones that haven't cropped up in our discussions yet. Rather than trying to discuss all of the ideas at once, I want to have a discussion about the group of ideas which I think are the most important. We seem to be divided over whether to have an RfC just about drafts, just about principles, or including a mixture of the two. Among the different ideas in the brainstorm I noticed these (listed in no particular order):

• Just have an RfC for drafts about the lead; don't poll anything else.
• Run the drafts RFC separately and subsequently to the general principles one. Before running the drafts RFC, modify the drafts according to the general principles.
• Have two RfCs, one for general principles, and one for drafts.
• Do not delay the RfC for drafts about the lead while waiting for an RfC about anything else.
• Whatever we include with respect to questions/general principles, first decide here what the planned action would be for whatever the community says. Don't just ask out of academic curiosity.

I would like to remind the participants here that the drafting process of steps 4-6 does not preclude merely using the drafts as examples of a question on general principles of the verifiability policy (yes, despite the fact that they have taken more than a month to finalise). Neither do we have to include any questions on the general principles of the policy at all. We do have to choose something to put in the RfC(s), though, and we will decide that as a result of this discussion. (And possibly further discussions if necessary.)

So, let's try and find the most sensible solution. For the purposes of this discussion, I would like you all to pretend that you don't care what the final result of the RfC will be. Instead, I want you to pretend that you care very much about the RfC gaining consensus. Our job here should not be to try and find some kind of preferred result; it should be to create a discussion format which will represent the community's wishes as clearly and as accurately as possible. Bearing this in mind, I would like you to discuss the following question: what combination of questions on drafts and principles in the RfC(s) that we are devising will most likely lead to those RfC(s) gaining consensus - and why? Let's see if we can't find a solution that will satisfy everyone. — Mr. Stradivarius ^♫ 14:19, 10 May 2012 (UTC)

Suggest having just the following RfC.

RfC regarding the lead of Wikipedia:Verifiability.

Please list the following options in order of your preference (most preferred first), and comment.

A. Keep the present version.

B. [...]

C. [...]

D. [...]

E. [...]

[Please note that the comments and the Instant-runoff voting method would be used to help evaluate the RfC.]

There is a possible problem in the above format, that editors will get tired of reading the options and not get to the last ones. --Bob K31416 (talk) 15:19, 10 May 2012 (UTC)

I would like to include a statement in the RfC that all the editors here agree that the drafts do not change the meaning of the policy, after first determining that is the case. --Bob K31416 (talk) 20:41, 10 May 2012 (UTC)

Two things:

• Agh! I just remembered something today that I wanted to suggest in the brainstorm, but logged in and found the brainstorm closed, so I will say it here. I think we need to have some "anti-highjacking rules" (of course, we shouldn't call them that!) stated from the beginning, that prevent premature closure or unilateral reopening, etc.
• I really don't like the RfC format just above, but think that "Strong support", "Weak support", and "Oppose" options for each proposed draft would work better. We need to let people oppose if they want to. We need to allow for "second choices" and the like, because that's very important to the goal of maximizing the likelihood of consensus. And, finally, we should look at our own experience with numerical ranking of choices, from when we tried it during this mediation. It was too complicated, and didn't really work. Many, perhaps most, of the editors in this mediation didn't really go along with the instructions, and that was just a small group of us who had all agreed to abide by the mediation rules! --Tryptofish (talk) 21:12, 10 May 2012 (UTC)

Sorry, I should have mentioned that the above RfC format would use an idea mentioned at the beginning of the brainstorm, "Use instant runoff voting to help decide which draft to use." I just added an explanation up there. Is that any better? --Bob K31416 (talk) 21:38, 10 May 2012 (UTC)

In a word, no. Actually, I had already assumed instant runoff when I made that comment. Instant runoff, as I understand it, requires everyone to rank all the choices numerically. I like the way it takes into account second choices and the like, but I don't like what I said just above. --Tryptofish (talk) 22:05, 10 May 2012 (UTC)

Well, maybe you could explain more how your system would work. For example, if one draft got 8 strong supports, 4 weak supports, and 4 opposes, and another got 6 strong supports, 8 weak supports, and 2 opposes, what is the method that you would use to rank these relative to each other? --Bob K31416 (talk) 17:40, 11 May 2012 (UTC)

Re "We need to let people oppose if they want to." — Another possibility is to have each respondent to the RfC oppose the drafts they wouldn't want and rank the rest in order of preference. BTW, this is similar to part of the Instant-runoff voting system where respondents would only rank the ones that they are interested in. --Bob K31416 (talk) 18:03, 11 May 2012 (UTC)

Tryptofish - I've added your brainstorm suggestion into the brainstorm list. — Mr. Stradivarius ^♫ 10:58, 13 May 2012 (UTC)

Thanks! --Tryptofish (talk) 20:12, 13 May 2012 (UTC)

I see that Mr. Strad was largely asking about that bullet list of points about drafts versus questions in the RfC, etc., so I better reply to that (talk about herding cats!). Personally, I don't see the need for anything more than an RfC about possible drafts – but, of course, I recognize that other participants here feel strongly about asking questions. So let me answer the question with another question. I'd like to hear from those who favor some form of "question" RfC, if you would specifically comment in terms of that last point in the bullet list: what do you envision as the "action plan"? --Tryptofish (talk) 21:18, 10 May 2012 (UTC)

Ping: I'm still very interested in hearing those kinds of plans about any non-drafts RfC. Implicitly, I'm also expressing skepticism of the need to have any non-drafts RfC if such plans are not forthcoming. --Tryptofish (talk) 20:44, 12 May 2012 (UTC)

Strongly support instant runoff. Numerous things make this very different from the usual. That requires person to voice an opinion on EVERY choice. And we should say that everyone who votes should tell us some of their reasoning in order for their vote to be included. North8000 (talk) 17:53, 11 May 2012 (UTC)

• Maybe it could be simplified by having the respondents choose the draft that they liked the best and add 2nd and 3rd choices if desired. Note that the Instant-runoff voting method could still be applied to these kind of responses. --Bob K31416 (talk) 18:37, 11 May 2012 (UTC)
• I've got a few points to make here. In my opinion:-

1. We have no right to impose the voting system of our choice on the community. A request for comment is a request for users to, well, comment. It shouldn't be a request for a poll that supports our predetermined options.
2. It follows that users should be able to reject our drafts and come up with their own.
3. An open discussion process for the whole community should precede any binding poll.
4. After the discussion, there should be a binding poll. We need a decision, not a compromise: a definite outcome.
5. We should trust the closer(s) to weigh comments and votes as appropriate. We certainly have no authority at all to impose a particular counting method.
6. The outcome should be binding for a reasonable period (minimum six months).

• Thanks for reading—S Marshall T/C 20:22, 11 May 2012 (UTC)

Hello S Marshall

On your point #1, everybody already has a system imposed on them. It's 1 or 3 people (the closers) decides the result. They are free to go against immense support to the contrary, as we have seen. That is the default. We are talking about a group deciding to use a better system. Also, presenting 3 or more alternatives would randomize the results unless there are special arrangements. Basically any proposal that has others similar to it would be defeated. North8000 (talk) 20:43, 11 May 2012 (UTC)

On your point #3, isn't that what has already been happening intensively for 18 months? And in a very organized fashion here for the last few months?

Sincerely, North8000 (talk) 20:36, 11 May 2012 (UTC)

There are those who feel disenfranchised by the process, North—driven away by the seemingly-unending discussion—who might wish to participate in a RFC with a known duration that aims for a definite outcome. And we have to trust closers. If we can't, Wikipedia can't possibly function.—S Marshall T/C 20:47, 11 May 2012 (UTC)

Good points of course. I also think that the points I raised are good points. Sincerely, North8000 (talk) 20:56, 11 May 2012 (UTC)

Discussion about possible voting systems

I have collapsed these comments about possible voting systems to use in the RfC, because it is not yet clear that we will need to use any such systems. Let's decide what combination of drafts and questions on general principles we want first, and then we can decide on the voting system if it is necessary. Best — Mr. Stradivarius ♫ 10:50, 13 May 2012 (UTC) I'm going to try to reply to multiple comments in one comment here. My answer to BobK's first question to me is that I wouldn't count votes, but ask someone neutral to determine consensus (and I don't expect the results to come out anything like that anyway). And I'll answer that question with another question: would instant runoff really make it any easier to determine the consensus of that hypothetical result, or would it simply impose an artificial arithmetic interpretation on something where the conclusion might really be to develop a combination of those two drafts? As for BobK's other possible options, I think those are things we might be able to work with. To North, please let me suggest that the important thing isn't instant runoff as some sort of end in itself, but rather, that we have a thoughtful way of evaluating how the community feels about all of the drafts, rather than pushing people into saying that they want their preferred version and nothing else would do. If, as may be likely, no one option gets overwhelming support, we will need to have a way to assess whether second choices indicate a path to a revised or combined version that will get broader acceptance. There are multiple ways we can accomplish that, without forcing everyone to generate a numerical ranking. That "forcing" problem is why I agree with S Marshall's points 1, 2, 5, and 6. I'll say it again: we couldn't even get the participants in this mediation to really go along with a numerical ranking system, so there will be even bigger problems if we try to make the broader community do that. --Tryptofish (talk) 20:57, 11 May 2012 (UTC) My concern is that with 3 or more proposals, the ones that are more similar will tend to kill each other, even if the a large majority prefer the concept embodied in both of them. North8000 (talk) 21:29, 11 May 2012 (UTC) And your concern is a good one. I agree with it. I'm just trying to make the case that we can accomplish that by means other than instant runoff per se, and I want to avoid any format that will make people respond by saying that they don't think the RfC procedure is valid, which I'm pretty sure will happen (based on our own experience when we tried it during this mediation) if we ask everyone to give a numerical ranking. One alternative (amongst many) that I like is "Strong support", "Weak support", and "Oppose". --Tryptofish (talk) 21:49, 11 May 2012 (UTC) While I am not sure about "instant run off" (voting off the island?)... The thing I really like about the "rank by preference" concept is that it helps people to think about alternatives - to focus on what is acceptable rather than what is perfect. If we simply ask everyone to Support/oppose, everyone is going to support their first choice and oppose the others... and it would not surprise me to find that the RFC resulted in yet another unsatisfactory "no consensus". BUT ... if we ask them to consider what their second and third choices are, we may find that there is actually more agreement than is apparent from a strait support/oppose type vote. For example, if almost everyone is in agreement as to their second choice... that indicates a consensus... even if they all disagree over what their first choice is. Blueboar (talk) 02:52, 12 May 2012 (UTC) Perhaps the RFC could be presented in two parts (simultaneously)... Part I would be a POLL - rank by preference. Part II would be COMMENTARY - explain your ranking and make further comments and suggestions. The closer(s) would be asked to consider both parts in determining consensus. Blueboar (talk) 03:04, 12 May 2012 (UTC) My promotion of "instant runoff" is solely to keep similarly-minded proposals from cannibalizing each other. Any other method which accomplishes that would be fine with me. Another method might be to ask/encourage people to weigh in separately on each of the 4 proposals. Could include suggesting starting with a choice between the following: Strong Support Support Weak Support Neutral Weak Oppose Oppose Strong Oppose And clarify / reinforce that there is no restriction as to how many they could say what on. E.G. they could "strong support" 3 proposals. North8000 (talk) 11:37, 12 May 2012 (UTC) Won't most people simply "Support" or "Strong Support" the one version they like and then "Oppose" or "Strong Oppose" all the others (perhaps without bothering to consider the subtle differences between them)? Blueboar (talk) 19:58, 12 May 2012 (UTC) Actually, I'd strongly oppose giving a "Strong Oppose" option for just that reason. A simple "Oppose" option will be quite enough, along with "Support" (and, come to think of it, maybe not "Strong Support") and "Weak Support" (or something like weak support). We do indeed need more than one flavor of support to prevent the cannibalizing that North draws attention to, I agree. I think we just have to accept, to some extent, that people are going to do what they are wont to do, and we cannot make them do what they don't want to do. Some people, but not necessarily most, will endorse one and oppose everything else (and some, indeed, will oppose everything and anything). But if we get enough people to articulate good faith support for a second choice or two, that will be enough for our purposes. I just think that the closers are going to actually have to read what people say, instead of us trying to make people do rankings that most of them will resist doing. --Tryptofish (talk) 20:54, 12 May 2012 (UTC) Hmmm... it might be possible to combine a "rank by preference" poll and indicate "support/oppose" The ideal response would be something like: Ranking: A,C,B,E,D - I strongly support A, but would accept C as an alternative, and am totally opposed to D. The reason I so strongly support A is that it says "blah blah blah" which is the heart of the policy (and I oppose D because it omits that). Blueboar (talk) 21:40, 12 May 2012 (UTC) Is it possible to have the drafts on a separate page from the comments (as outlined above) with multiple-choice radio-buttons ("Oppose" = -2, "Neutral" =0, "Weak support"= +1, "Strong support" = +2) for each draft? Lots of users find something like that much easier to deal with than working out numbers, and understand better how such results are easily analysed. It may give them more faith in the process as a whole; instant-runoff voting is hard for many people to get a grip on, whereas drafts "totting up numbers" is much easier to understand. Pesky (talk) 05:34, 13 May 2012 (UTC)

Proposal for a set of questions

I've copied the following comment by Tryptofish from the thread above. My own suggestion follows... Kalidasa 777 (talk) 08:28, 13 May 2012 (UTC)

Ping: I'm still very interested in hearing those kinds of plans about any non-drafts RfC. Implicitly, I'm also expressing skepticism of the need to have any non-drafts RfC if such plans are not forthcoming. --Tryptofish (talk) 20:44, 12 May 2012 (UTC)

Kalidasa, thanks! I'm also going to copy the latter part of the comment I made before that one, because I'm also very interested in hearing what we think about this. --Tryptofish (talk) 20:21, 13 May 2012 (UTC)

I'd like to hear from those who favor some form of "question" RfC, if you would specifically comment in terms of that last point in the bullet list: what do you envision as the "action plan"? --Tryptofish (talk) 21:18, 10 May 2012 (UTC)

I do still think it would be much better to ask people to consider a set of questions of principle before asking them to rate a number of drafts.

The questions I have in mind are basically those that distinguished between the drafts of the 4 work groups, plus the question of whether "verifiable but inaccurate" should be mentioned.

Recent discussion on the Verifiability Talk page has shown that there are still people with serious misgivings about words like "inaccurate". Whether or not you or I share those misgivings doesn't matter. If we don't provide scope for the misgivings to be expressed and worked through within any RfC, I doubt very much that consensus will be reached.

I suggest the questions should be as follows:

1. Would you like the intro to be as it has been, including the words "verifiability, not truth" and "threshold", without more explanation?
2. Would you like an intro that retains the words "verifiability, not truth", plus something more to clarify the meaning and/or implications of "verifiability, not truth"?
3. Would you like an intro that mentions "verifiable but inaccurate" material, in order to clarify "verifiability, not truth"?
4. Would you like an intro that distinguishes between perceived truth and verifiability in new words, and puts the words "verifiability, not truth" into a historical footnote?
5. Would you like an intro that simply speaks of verifiability, and does not mention the word "truth" at all?

I think the four drafts we've come up with should be presented along with the above questions, but the drafts should be presented (at this stage) as examples to comment on, rather than proposals to say yes or no to. Kalidasa 777 (talk) 08:28, 13 May 2012 (UTC)

Thanks for posting this, Kalidasa! I think we need to discuss this before worrying about whether we will use instant runoff or how it will be implemented. If the drafts are just used as examples, then there will not be any need to rank them, after all. Because of this, I think the discussion about instant runoff above is jumping the gun a little. Let's discuss one thing at a time - we can always come back to the instant runoff discussion if and when it becomes necessary. I'm collapsing some of the comments above to keep us focused on the issue at hand - what combination of drafts and general questions should we include in the RfC. — Mr. Stradivarius ^♫ 10:40, 13 May 2012 (UTC)

• • I'd prefer it if, instead of introducing drafts from the get-go, we began by asking editors to group themselves into broad categories. Something like:-

    Group 1: Editors opposed to any substantial change to WP:V.

    Group 2: Editors who want to keep "verifiability, not truth" as-is but support some other change to the policy.

    Group 3: Editors who want to keep "verifiability, not truth" but add some explanation and clarification.

    Group 4: Editors who would prefer to replace "verifiability, not truth" with fresh wording.

    Group 5: Editors who would prefer a large-scale restructuring/rationalisation/simplification of Wikipedia's policies such as WP:ATT.

    Then we add a free-text discussion area beneath, where we can mention our various rationales for changes, and allow a fixed time, I don't really know how long—3 weeks? Community patience is limited—and get that closed.

    Once we have this broad steer we can go back to the drawing board and refocus our drafts based on what the community tells us, and run a poll for the best draft thereafter.—S Marshall T/C 11:20, 13 May 2012 (UTC)

If the "broad steer" is the predominance between the groups, this would tend to have the issue I was concerned about. Similarly minded ideas will kill each other off. North8000 (talk) 11:57, 13 May 2012 (UTC)

• On a strict numerical vote count, that's true. The method relies on trusting experienced closers to be able to see groups of similarly-minded ideas together. Is this a concern to you?—S Marshall T/C 12:07, 13 May 2012 (UTC)

Yes, even a sincere closer can easily / is likely to miss that. It takes both familiarity with the issues involved (including their relative importance) spotting those attributes in the various proposals, looking for common themes across proposal regarding those attributes, and then mentally combining them. Sincerely, North8000 (talk) 12:35, 13 May 2012 (UTC)

Thanks everyone here, and I am finding this discussion very helpful (at least to me). A big part of where I'm coming from is a desire on my part (a feature? a bug?) to be very practical. Thus, I want to come to some understanding as to what we would do, depending on the outcome of the proposed questions.

• One thing that stands out to me is that we seem to be seriously considering scrapping all that we have just done in preparing drafts, subject to further feedback from a question-based RfC. Am I correct about that? Is that what we really want to do? And could we not get that same information by actually running the "drafts" RfC?
• In the event that we run any of the question-formatted RfCs, what would be the possible results from the community? In the event of each possible result, what would we then do, in terms of the subsequent RfC about drafts? How will we allow for the unpredictability of human behavior, in terms of things like editors who say one thing in the first RfC (or do not participate), but then come to the second and say "that's not what I meant at all"?

I realize that these are difficult questions, but I would feel more comfortable if we do the hard work now of thinking them through, instead of running into unanticipated problems later. --Tryptofish (talk) 20:34, 13 May 2012 (UTC)

My answers to Tryptofish's two questions...

• No, we shouldn't be scrapping the drafts or setting them aside. As I've said above, I think the RfC should have a list of questions, plus drafts as examples. I agree with S.Marshall that the focus should be on broad principles. However, if we only ask questions of principle, like "should VnT be clarified?", I think lots of people will find such a question too vague. They will want to ask us back "clarified how?" On the other hand, if we only present drafts to support or oppose, where will that leave someone who does agree that VnT should be kept and clarified, yet who disagrees with the wording of the Group 2 draft that does so?
• The terms of a subsequent RfC will flow logically from the results of the first. E.g. if there is a strong consensus for clarifying VnT, a subsequent RfC would hardly need to contain drafts that do not clarify VnT. And yes, people may change their minds in the course of the discussion. If the discussion is not too polarized, they may even change their minds in a way that leads to consensus! Kalidasa 777 (talk) 23:54, 13 May 2012 (UTC)

The amount of time that hundreds of responding editors are each willing to spend on evaluating the RfC should be considered. --Bob K31416 (talk) 00:36, 14 May 2012 (UTC)

Yes, it should indeed, which would argue for WP:KISS. Kalidasa's comments made me think of something. At first, this will look like I'm reopening the hatted discussion about format, but please bear with me. We could perhaps present an RfC with just the four drafts, but instead of the kinds of formats we discussed before, we could offer respondents a choice of "Support", "Support only with revisions", and "Oppose". For that middle option, we would ask that everyone explain what revisions (or, at least, what kinds of revisions) they have in mind. I think that would give us all of the same information that a question-based RfC would give us: am I missing anything? If something gets clear consensus as is, then that would be very nice. But if not, we would be much better pointed towards what to bring back the next time. --Tryptofish (talk) 20:42, 14 May 2012 (UTC)

What is the goal of the RFC?

The goal will determine how we set up the RFC... but I have a feeling that we are not in complete agreement as to what the goal actually is.

Is the goal to determine specific language or broad direction? Is the goal to determine whether VNT should remain or be removed from the policy? Is the goal to pick a "winner" from among our various drafts? Or is the goal something else? Blueboar (talk) 13:27, 13 May 2012 (UTC)

To stay on task, I think that we need to deal with the core issues(s) of the 18 month debate, which is VNT, staying, going, clarified etc. And that all of the other process questions basically are just trying to find the best ways to do that. North8000 (talk) 14:43, 13 May 2012 (UTC)

For me (in other words, your mileage may differ), the goal is to arrive at an improved lead for WP:V, specifically in terms of resolving the longstanding problems with VnT (but secondarily fixing whatever else we can, in the process). --Tryptofish (talk) 20:37, 13 May 2012 (UTC)

I think that that is an accurate description of the de-facto process. If the secondary stuff doesn't ties us up in knots, that's great. If it does, then I think we'd need to focus on VNT related items. Sincerely, North8000 (talk) 23:11, 13 May 2012 (UTC)

I'm going to be overseas where web access is a question mark May 15th -23rd. If I'm MIA, I'd like to give my "proxy" to Tryptofish.  :-) North8000 (talk) 23:17, 13 May 2012 (UTC)

Party at North's house! --Tryptofish (talk) 20:44, 14 May 2012 (UTC)

I would say that the goal of the process is consensus about the lead -- either consensus for an improvement, or consensus that WP can live with the lead as it has been. I'm not sure we will reach consensus in one RfC, though it would be great if we could. I agree with North that there needs to be a focus on key issues, like staying, going, clarified? If we can get consensus in an RfC for key issues like that, the next step will be looking for consensus on specific wording. Kalidasa 777 (talk) 23:25, 13 May 2012 (UTC)

Very brief draft descriptions

I think that very brief draft descriptions will help the respondents. A starting point for what the descriptions would be are the descriptions given by Mr. Stradivarius when he formed working groups to write the drafts.

• Group 1 - the "status quo" draft.
• Group 2 - the VnT compromise draft.
• Group 3 - the non-VnT compromise draft.
• Group 4 - the all-new draft.

--Bob K31416 (talk) 00:35, 15 May 2012 (UTC)

I'd argue, instead, against trying to characterize them at all. Just imagine the arguments over what is or isn't a compromise, or what constitutes the status quo. I'd suggest (in fact, I think I did suggest in the brainstorm) that we identify the Group 1 option by a diff or a permalink to WP:V at the corresponding time. The others should just have neutral identifiers, such as "Option 2", "Option 3", etc. On the other hand, it would make very good sense for mediation participants who like particular drafts to comment individually along the lines of those identifiers, such as "I support this version because it is an all-new draft, correcting the problems of...". Or "I support this version because it retains VnT but is a compromise that corrects the problems of...". --Tryptofish (talk) 00:57, 15 May 2012 (UTC)

I understand your points but it's too much effort to expect from respondents to come in cold and try to figure out what's going on without some easy hint. Also, I think that the comments that respondents read are the last comments that are posted and the shorter ones, so expecting them to read the descriptions that some of us might give them at the beginning is unrealistic. And names like Option 2, Option 3, ... are easy to get mixed up.

Let's try to agree on some descriptive titles for the drafts. Maybe you could come up with some that might work! No harm in trying. : ) --Bob K31416 (talk) 02:30, 15 May 2012 (UTC)

I like idea of brief descriptions, as long as they are clear as well as brief. I agree with Trytofish that words "status quo" and "compromise" are problematic. What about this?

• Option 1 - Recent past version, with VnT.
• Option 2 - VnT with added clarification.
• Option 3 - New wording about perceived truth, verifiability.
• Option 4 - New wording about verifiability.

Kalidasa 777 (talk) 03:26, 15 May 2012 (UTC)

Kudos; very clear :D Pesky (talk) 06:38, 15 May 2012 (UTC)

Suggest the following for Option 4.

• Option 4 — No mention of "truth".

Also, we might include the present version.

• Option 0 — Present version.

--Bob K31416 (talk) 17:45, 15 May 2012 (UTC)

Yes, we keep forgetting about the the present version. Again, I might be gone or sparrodic for the next 9 days, going overseas. Give my "proxy" to Tryptofish. North8000 (talk) 17:51, 15 May 2012 (UTC)

I'm afraid that I'm still not happy with any of that. What's the difference between "present" and "recent past"? Why say "present" when it actually isn't, as of now? How is "No mention of "truth"" a neutral descriptor – or even one that really describes the draft accurately? Does "New" imply "new and improved"? What constitutes "clarification"?

Actually, are we supposed to be discussing this issue at this stage of the mediation? --Tryptofish (talk) 19:44, 15 May 2012 (UTC)

Tryptofish, you've asked whether we are supposed to be discussing this right now.

Well, looking back to what Strad wrote, under the heading "Drafts and general questions", Strad asked us all: "what combination of questions on drafts and principles in the RfC(s) that we are devising will most likely lead to those RfC(s) gaining consensus - and why?"

It seems to me that Bob's suggestion of accompanying each draft with a brief description is one possible answer to Strad's question. It may or may not be the best answer. But yes, we are supposed to be discussing ideas like this now. Kalidasa 777 (talk) 04:47, 16 May 2012 (UTC)

OK, thanks. I just wasn't sure. --Tryptofish (talk) 20:26, 16 May 2012 (UTC)

Please note that Kalidasa's suggested title for option 4, "New wording about verifiability", describes most of the options. The titles should differentiate between the options. The descriptive title for Option 4 that I suggested was influenced by Kalidasa's descriptive titles for the other options. The other options' titles essentially had in them "verifiability, not truth", "verifiability, not truth" clarified, and "perceived truth, verifiability" respectively. So I suggested "No mention of 'truth' " to be consistent with the form of the other titles and to differentiate from them.

Another possibility for the Option 4 descriptive title is "No mention of verifiability, not truth or truth. --Bob K31416 (talk) 00:14, 17 May 2012 (UTC)

I agree with you that my suggested title for option 4 "New wording about verifiability" fails to differentiate it from the other options. In this respect, your suggestion "No mention of 'truth' " is better. Your other suggestion "No mention of verifiability, not truth or truth "... a little too convoluted, I think... The only problem I see with "No mention of 'truth' " -- I think the title should indicate what the option does mention, as well as what it doesn't. How's this: "About verifiability, no mention of 'truth' ". Kalidasa 777 (talk) 02:12, 17 May 2012 (UTC)

That's OK with me. --Bob K31416 (talk) 00:43, 18 May 2012 (UTC)

What shall we use for the present version? One possibility is "Present version, with 'verifiability, not truth'." --Bob K31416 (talk) 21:43, 18 May 2012 (UTC)

Not bad... but suggest "Current" rather than "Present". Blueboar (talk) 22:41, 18 May 2012 (UTC)

Fine. --Bob K31416 (talk) 13:28, 19 May 2012 (UTC)

To summarize what we have so far, with the change of VnT to "verifiability, not truth" if that's OK,

• Option 0 — Current version, with "verifiability, not truth".
• Option 1 — Recent past version, with "verifiability, not truth".
• Option 2 — "Verifiability, not truth" with added clarification.
• Option 3 — New wording about perceived truth, verifiability.
• Option 4 — About verifiability, no mention of "truth".

--Bob K31416 (talk) 13:28, 19 May 2012 (UTC)

works for me. Blueboar (talk) 13:34, 19 May 2012 (UTC)

Does that mean that we would go from four options to five, with what is on the page as of the present time as the fifth option (number 0)? If so, I'd be inclined to number them 1–5, rather than 0–4. I would also identify the first and second (current, and recent past) with permalinks/diffs, to show users where they came from. And, while I still have some lack of comfort with using these identifiers, I have to admit that these versions do seem to me to be neutral and without problems, so my congratulations on that. --Tryptofish (talk) 15:44, 19 May 2012 (UTC)

Another possibility is A, B, C, D, E instead of ... Option 2, Option 3, ... . Letter designations might work better in rankings and discussions. --Bob K31416 (talk) 23:15, 19 May 2012 (UTC)

I agree that the current version should be there. Strictly speaking, its wording is "verifiability, and not truth" -- may not make much difference, but no harm in getting it exact. Putting in diffs to the source texts of the first two options is a good idea. I think "option" is a good word to use, not sure how much difference it makes whether we use letters or numbers. How is this?

• Option A — Current version, with "verifiability, and not truth". [2]
• Option B — Recent past version, with "verifiability, not truth". Diff to be added
• Option C — "Verifiability, not truth" with added clarification.
• Option D — New wording about perceived truth, verifiability.
• Option E — About verifiability, no mention of "truth".

Kalidasa 777 (talk) 00:40, 20 May 2012 (UTC)

Yes, I think that is looking good. At this point, I'm getting comfortable with the descriptors (after my previous concerns, now satisfied), and I like using letters and the five (rather than four) options.

About the diffs, I'd suggest using permalinks instead, because they are easier for users to view and understand quickly.

• For Option A, that would be: [3].
• And for Option B, it is: [4]. --Tryptofish (talk) 13:42, 20 May 2012 (UTC)

Format for presenting versions in the RfC

Here is a possible format for presenting the versions in the RfC.

---

RfC regarding the lead of the Verifiability policy page

Please choose which one of the following versions you prefer for the lead of the Verifiability policy page and comment. Also, you are encouraged to give additional alternate choices from the list and rank them in order of preference.

A. Current version, with "verifiability, and not truth".

Verifiability on Wikipedia is a reader's ability to check cited sources that directly support the information in an article. All information in Wikipedia must be verifiable, but because other policies and guidelines also influence content, verifiability does not guarantee inclusion. Verifiability, and not truth, is one of the fundamental requirements for inclusion in Wikipedia; truth, of itself, is not a substitute for meeting the verifiability requirement. No matter how convinced you are that something is true, do not add it to an article unless it is verifiable.

It must be possible to attribute all information in Wikipedia to reliable, published sources that are appropriate for the content in question. However, in practice it is only necessary to provide inline citations for quotations and for any information that has been challenged or that is likely to be challenged. Appropriate citations guarantee that the information is not original research, and allow readers and editors to check the source material for themselves. Any material that requires a citation but does not have one may be removed. Unsourced contentious material about living people must be removed immediately. For help on adding citations, see Citing sources. This policy applies to all material in the mainspace.

Verifiability, No original research and Neutral point of view are Wikipedia's core content policies. They work together to determine content, so editors should understand the key points of all three. Articles must also comply with the copyright policy.

Notes

B. Recent past version, with "verifiability, not truth".

The threshold for inclusion in Wikipedia is verifiability, not truth—whether readers can check that material in Wikipedia has already been published by a reliable source, not whether editors think it is true.

To show that it is not original research, all material added to articles must be attributable to a reliable, published source appropriate for the content in question. In practice you do not need to attribute everything. This policy requires that all quotations and anything challenged or likely to be challenged be attributed in the form of an inline citation that directly supports the material. For how to write citations, see WP:Citing sources.

This policy applies to all material in the mainspace—articles, lists, sections of articles, and captions—without exception, and in particular to material about living persons. Anything that requires but lacks a source may be removed, and unsourced contentious material about living persons must be removed immediately.

Verifiability is one of Wikipedia's core content policies, along with No original research and Neutral point of view. These policies jointly determine the type and quality of material that is acceptable in articles. They should not be interpreted in isolation from one another, and editors should familiarize themselves with the key points of all three. Articles must also comply with the copyright policy.

References

C. "Verifiability, not truth" with added clarification.

Verifiability on Wikipedia is the reader's ability to check reliable sources that directly support the information in an article. All information in Wikipedia must be verifiable, but because other policies, guidelines, and considerations also influence content, and particularly influence when verifiable but inaccurate material should not be included, verifiability by itself does not guarantee inclusion. Verifiability, not truth, is one of the key requirements for inclusion in Wikipedia—nothing, such as your personal experience or what you know to be true, can be a substitute for meeting the verifiability requirement. No matter how convinced you are that something is true, do not add it to an article unless it is also verifiable.

It must be possible to attribute all information in Wikipedia to reliable, published sources that are appropriate for the content in question. However, in practice it is only necessary to provide inline citations for quotations and for any information that has been challenged or that is likely to be challenged. Appropriate citations guarantee that the information is not original research, and allow readers and editors to check the source material for themselves. Any material that requires a citation but does not have one may be removed. Unsourced contentious material about living people must be removed immediately. For help on adding citations, see Citing sources. This policy applies to all material in the mainspace.

Verifiability, No original research and Neutral point of view are Wikipedia's core content policies. They work together to determine content, so editors should understand the key points of all three. Articles must also comply with the copyright policy.

References

D. New wording about perceived truth, verifiability.

In Wikipedia, verifiability means that people reading and editing the encyclopedia can check that information comes from a reliable source.

Wikipedia does not publish original research. Its content is determined by previously published information rather than by the personal beliefs or experiences of its editors. Even if you're sure something is true, it must be verifiable before you can add it. When reliable sources disagree, their conflict should be presented from a neutral point of view, giving each side its due weight.

All the material in Wikipedia mainspace, including everything in articles, lists and captions, must be verifiable. All quotations and any material whose verifiability has been challenged or is likely to be challenged must include an inline citation that directly supports the material. Any material that requires a source but does not have one may be removed, and unsourced contentious material about living people must be removed immediately. For how to write citations, see Citing sources.

Verifiability, No original research and Neutral point of view are Wikipedia's core content policies. They work together to determine content, so editors should understand the key points of all three. Articles must also comply with the copyright policy.

Footnotes

E. About verifiability, no mention of "truth".

Verifiability is one of the most essential requirements in Wikipedia. Information added to articles must be verifiable using only reliable sources that have been published.

An appropriate inline citation is evidence that information is verifiable. Inline citations are required for any information that has been challenged or is likely to be challenged, and for all quotations. Suitable inline citations should refer to published reliable sources that explicitly support the information being presented. For help on adding citations, see Citing sources.

Any material that requires an inline citation but does not have a suitable one may be removed. Unsourced contentious material about living people must be removed immediately.

Compliance with the Verifiability policy does not guarantee that material will be accepted. For example, it must also comply with other policies and guidelines, most notably No Original Research, Neutral Point of View, and Copyright.

Notes

---

This format has several advantages over showing the text of all of the versions at once. 1) Uses less space. 2) Some versions won't get lost among the text of all the other versions. 3) Versions can be compared more easily, for example by showing two versions at a time. 4) Improves the equality of presentation of the versions. For example, we don't have the situation where some are viewed through links and others aren't. Also, the versions farther down the list have a better chance of being viewed, than with showing the text of all the versions. --Bob K31416 (talk) 04:16, 20 May 2012 (UTC)

Question... should we mention this mediation somewhere in the RFC. I could see editors who were not aware that this mediation took place saying "Oh no... not again... how many RFCs are we going to get on this issue?" It may help if they know that the mediation took place. Blueboar (talk) 11:14, 20 May 2012 (UTC)

To Blueboar's question about indicating the mediation, I say a resounding "Yes!". That's very important. About Bob's format, two things. First, we've discussed updating some of the drafts to reflect recent changes at the main page, so let's not forget to do that. Second, I don't think we've arrived at consensus yet about ranking choices or whatever, so let's please not get ahead of ourselves. I suspect that Mr. Strad will provide some guidance on discussing that. --Tryptofish (talk) 13:46, 20 May 2012 (UTC)

One possibility is to have the RfC signed as "Mr. Stradivarius, mediator for the Mediation Cabal Working Group on Verifiability", if that is OK with everyone involved. --Bob K31416 (talk) 14:39, 20 May 2012 (UTC)

No objection, but I'd go further, by having a brief preamble that links back to the main mediation page. --Tryptofish (talk) 14:44, 20 May 2012 (UTC)

Blueboar wrote, "It may help if they know that the mediation took place." — The info in the signature accomplishes that. Keep it simple. Respondents have a lot to read and think about as it is. --Bob K31416 (talk) 15:30, 20 May 2012 (UTC)

I agree with you that it should be simple and short. I'm only thinking in terms of a brief explanation, maybe a sentence each on: a link to the last RfC, mention of the current full protection, and a link to the main mediation page. Just enough for editors to be able to figure out where this new RfC is coming from, and certainly not a long read. I think that the new draft RfC page would allow for that quite readily. --Tryptofish (talk) 21:36, 20 May 2012 (UTC)

Worth a quick look

By way of a non-scientific view of what some members of the community, outside of the mediation process, are thinking, it would be a good idea to take a quick look at WT:V#Remove "under discussion" tag. --Tryptofish (talk) 15:11, 18 May 2012 (UTC)

• One member of the community. History2007 has always been very vocal and quite sarcastic in his opposition to change in this policy. He's not exactly a representative sample.—S Marshall T/C 07:59, 19 May 2012 (UTC)

That's why I said "non-scientific". But one need only look at the last RfC to observe that we ignore such points of view at our peril. --Tryptofish (talk) 15:45, 19 May 2012 (UTC)

First draft of the RfC

Hello again everyone, and thank you for your continued discussion of possible RfC formats. We have had a wide range of comments on a number of issues relating to the RfC, and the level of the debate has been very high, in my opinion. However, I don't see that we have reached any agreement on the central question I asked regarding whether to have the RfC on drafts, or on general questions. Because of this, I have been wondering if we can't create a combined RfC that would have the good points of both of these approaches. To this end, I have created a draft RfC page with a rough draft of what the RfC could look like.

• Permanent link to my initial draft

None of this is finalised at all - it is just a suggestion to spur on the conversation. Please feel free to jump in and edit it, and to rewrite it completely if you want. We can have a discussion about people's ideas here using permanent links to our respective versions of the page, so there's no need to preserve features of anyone else's version if you don't want to.

Now let me explain a little bit about why I have chosen to draft the RfC the way I have. First, I think there is no harm in having both general questions and questions on specific drafts in the RfC, as long as the questions do not repeat themselves too much. (I haven't chosen any of the text of the questions myself, by the way; I just just copied Kalidasa's suggested questions. Whether these questions are suitable to ask when we have questions about drafts as well is something that we can work out through further discussion.) The general questions are the most likely to lead to consensus - they invite opinions, rather than give predetermined choices. Editors may wish to oppose all the drafts we make, but if we ask them what they want using a more general question, then we may well get an honest and reasoned opinion. Because we are more likely to get thoughtful responses with these type of questions, I have put them at the top of the RfC.

It will be harder to get consensus about individual drafts, because of the problem of editors opposing over small details that we have noted before. However, I don't think we should automatically assume beforehand that we won't get consensus about an individual draft, or that we necessarily need to delay such questions for a future RfC. There is a (small? medium?) chance that a particular draft could gain consensus for inclusion, making further discussion unnecessary. Even if no one draft gains consensus, including questions about individual drafts may give us good hints about editors' preferred wording. And if no one draft gains consensus, then we will still have the results from the general questions, which we can use to craft drafts for a future RfC should that prove necessary. The main downside to having both general questions and questions on drafts is that it could be possible that the two sets of questions come up with different results. For example, one possible result scenario from this structure would be that the general questions point clearly towards a desire to clarify VnT, but that the draft questions show a clear consensus to use the historical draft B (the group 1 draft) with no clarification of VnT.

I have tried to incorporate as many other things that we have agreed about in the step 7 discussion as I could, so the descriptions of the drafts, and Bob's suggestion of collapsing the drafts for comparison, are all as they have been discussed on the talk page. I chose Tryptofish's suggestion for the voting system for the drafts, of "support", "support with revisions", and "oppose" sections for each draft. I like the way this allows editors to express different levels of support while still retaining the "oppose" sections. (People love opposing things, after all. ;) This is very much open to further discussion and debate, however, especially seeing as I closed off the discussion we were having on this point early.

Before we discuss the details of questions and voting systems, though, I would like to hear what you think about the general structure that I have drafted. Is this a viable solution to all of our concerns about questions on drafts versus more general questions? Is there anything you would like to change in that regard? Does the problem scenario that I described have a realistic chance of occurring, and is there anything we could do to mitigate this? Let's talk this through and try and find an agreement. Best — Mr. Stradivarius ^♫ 16:26, 20 May 2012 (UTC)

As broad structure (ie without getting into quibbles on wording and petty details), I think this would be excellent. Well done. Blueboar (talk) 17:35, 20 May 2012 (UTC)

The drafts farther down the list have less chance of being considered when the uncollapsed drafts are shown, and this is exacerbated by having 5 separate polls increasing the amount of text before the later drafts. The last large RfC had hundreds of editors responding. As an old joke goes, "Other than that Mrs. Lincoln, how did you like the play?" --Bob K31416 (talk) 17:56, 20 May 2012 (UTC)

• I'm sorry to say this, because I can see how much work's gone into it, but I'm afraid the draft is far too long.—S Marshall T/C 18:40, 20 May 2012 (UTC)

  It wasn't all that much work really - I just cobbled together all the things that we have been discussing anyway. I'll reply to your comment about the length further down. — Mr. Stradivarius on tour ^♫ 01:43, 21 May 2012 (UTC)

• My preference would be to omit all the questions at the beginning, and just have the poll on the "options". During the previous stage of the discussions, I asked if anyone could suggest what "action plan" we would follow in response to how the community answers those questions, and no one really gave an answer to that. Honestly, I don't see a good rationale for asking – except as an academic exercise, as opposed to something that would help the community come to consensus about what WP:V should say. On the other hand, if we suggest that those users who !vote "support with revisions" provide comments about what revisions they want, I think that we will get the same information that the questions try to elicit. And that's a good way to make the RfC shorter and simpler!

• I could also suggest, as a format for the options, to make use of however Beeblebrox set up the current RfC about pending changes, so that users editing the comments page of our RfC cannot edit where the options are listed. --Tryptofish (talk) 21:31, 20 May 2012 (UTC)
• P.S. Another thought I have when looking at the draft page is that I notice a "discussion" section for each of the proposed options/drafts, in addition to the support/support-revise/oppose options. We should encourage discussion within each of those !voting areas, as opposed to simple votes, so maybe those separate discussion sections could be moved, instead, to the RfC page talk page. --Tryptofish (talk) 21:41, 20 May 2012 (UTC)

• I totally disagree with Tryptofish about removing the questions at the beginning, which I see as the important part of the RFC.—S Marshall T/C 22:32, 20 May 2012 (UTC)

• It looks like we have a stalemate. Both of you seem to agree about the RfC draft being too long, but (I assume) you want to cut different sections in order to make it shorter. We obviously can't cut both the drafts section and the general questions section, and if we just wanted to cut one, I honestly couldn't say which one it should be. This looks like a situation where we might just have to compromise. (Note that I don't necessarily mean the compromise solution that I've drawn up - it could look much different to mine.) But before we agree on any solution, we should discuss things until we are sure we are on the same page. I think a good place to start would be Tryptofish's concerns about the practical use of asking general questions, which I agree were never really given a satisfactory answer.

  It is my understanding that S Marshall wants to have a second RfC that would be informed by the results of the first one on general questions, and he has said that those results would be directly used in developing drafts for the second RfC. Tryptofish, however, has argued that we could get the same information by getting people to comment on possible changes to the wording of the drafts that we have worked out in steps 4-6. So I have a question for S Marshall and others who are in favour of general questions - is it indeed not possible to get the kind of information you want through editors suggesting possible changes to the drafts we have worked out? And if not, why not? (And what is the information we should be looking for, anyway? Are the questions in the current RfC draft on the right track?) — Mr. Stradivarius ^♫ 11:36, 21 May 2012 (UTC)

My answer to Tryptofish's argument is this... If (for instance) someone thinks that it's a very good idea for the intro to distinguish between verifiability and perceived truth and to put VnT into a footnote, but is not convinced that Draft D has the right wording... Which is the simpler way of expressing that in-principle position?

• Being able to say "yes" to a question like Question 4?
• or having to tick "support draft D with revisions", and then being expected to spell the revisions out? Kalidasa 777 (talk) 12:24, 21 May 2012 (UTC)

And my response, in turn, is that someone saying "yes" to Question 4 is still likely to turn around and find something else to complain about when they eventually see specific draft wording that they didn't see when they answered Question 4. Don't make the mistake of assuming that answers to general questions will have enduring currency. In contrast, people who choose "support draft D with revisions" will say as much or as little as they want to say about what they would want to change, and, once we have all the responses at the end of the RfC, it will be possible to take all those responses in aggregate, and determine what would have to be revised in a given draft in order to bring it to a large margin of support over oppose. --Tryptofish (talk) 14:29, 21 May 2012 (UTC)

• Isn't it better to proceed from the general to the specific than to try to work from the specific to the general?—S Marshall T/C 16:24, 21 May 2012 (UTC)

No, not always, I think. In this case, the problem with starting with the general is, in effect, the Rorschach test effect: people seeing what they want to see, and one person seeing one thing while another person sees something else. --Tryptofish (talk) 17:26, 21 May 2012 (UTC)

Doesn't that also apply in reverse? We've seen clear evidence that editors will oppose a draft for a particular phrase even if they approve of its general thrust. Personally, I foresee that the specific drafts route goes to another "no consensus" outcome.—S Marshall T/C 17:37, 21 May 2012 (UTC)

That's a good question, but I think what can happen here is to go, not from the specific to the general, but from the specific to the specific. Maybe you will prove overly pessimistic, and a draft will gain consensus, or consensus pending an easy and obvious revision. But if not, we will be much closer to knowing what (if anything!) to propose next, when we have reactions to specific language, than reactions to general questions. If people say that they like a particular draft in general, but have opposed it because of a specific small phrase within it, that's very specific information, upon which it will be clear how to act. --Tryptofish (talk) 18:12, 21 May 2012 (UTC)

I think S.Marshall is right -- an RfC with specific drafts, but no general questions, would risk another "no consensus". On the hand, as Tryptofish says, it is also possible that if draft intros are presented, one of them will gain consensus... So why not include both the general questions and the draft intros? ... On a topic of this much interest, is a questionnaire with 5 general questions and 5 draft intros really too long? Respondents presumably don't have to attempt all questions, after all... Kalidasa 777 (talk) 23:31, 21 May 2012 (UTC)

1) From practical considerations, the questions before the main RfC will take up quite a lot of space if hundreds of editors respond to each one. Also, respondents will read some of the other respondents answers. And all this comes before the five drafts, which are the main part. Please consider how that would work in practice.

2) Regarding consensus, what would that be when there are five drafts? Last time, 62% support of the only draft proposed wasn't enough. So what would be consensus when there are five drafts to choose from? --Bob K31416 (talk) 00:22, 22 May 2012 (UTC)

A couple of things. First, I still haven't really heard an answer to my question of how, specifically, we would use the answers to questions to come up with specific insights into how to better prepare drafts that would be able to get consensus. Second, nor have I heard an explanation of what we would learn from the answers to questions, that we wouldn't learn from what users would revise in the drafts. Third, one possibility would be to rearrange the RfC page, so the draft options are at the top, and the questions are at the bottom. Fourth, the last RfC actually came closer to producing consensus than the end result would appear to suggest, so now we are working with a lot more useful information than we did last time. It's not unrealistic to suggest that we might get consensus this time. And fifth, the sky will not fall if the result of the new RfC is no consensus about the current drafts, but clear guidance about what revised draft will get consensus the next time. Indeed, that would be merely a best-case scenario if we were to go only with a general question RfC. --Tryptofish (talk) 13:53, 22 May 2012 (UTC)

The information obtained from general questions may not be "specific", but it will hopefully give a valuable sense of the general direction people want to go in. I also think that having general questions in the RfC will encourage people to focus on the principles involved in the various drafts, instead of getting lost in details. For this reason, I think consensus for one of the drafts in this RfC is more likely to happen if the general questions are there also. I am not too worried about whether the questions are at the top or the bottom of the RfC page. Perhaps another possible way to address the space problem would be to have two linked RfC pages? Kalidasa 777 (talk) 01:24, 23 May 2012 (UTC)

My apologies to all participants. I grew rather weary as this process went on and allowed my attention to drift. From what I see, though, you've made good progress. With refreshed eyes, it occurs to me that even if the RFC finds one clearly preferred version, there will still be issues with the details of that version. There will be a need to lay out a path between choosing a listed option, tweaking it, applying it, and revising it once in use. Should that path not be described prior to the RfC in order to preclude process disputes? LeadSongDog come howl! 19:47, 23 May 2012 (UTC)

One possibility that occurs to me would be to associate the questions with the drafts, so that there would only be one part to the RfC. Thus, each draft would have "Support", "Support with revisions", "Oppose", and (instead of a general "Discussion" section) one or more questions about that draft. For example: "Would you prefer that this option include a mention of "verifiable but inaccurate material?" --Tryptofish (talk) 21:54, 23 May 2012 (UTC)

This might be a good way to compromise. For the questions that pertain directly to a particular draft, we can put them in the section with that draft. If there are other questions that apply to all the drafts, then we can include it in its own section. (I don't mind at all whether this section is at the top or the bottom - I'll leave that decision up to the rest of you.) Would anyone have any objections to doing something like this? — Mr. Stradivarius ^{(have a chat)} 11:06, 24 May 2012 (UTC)

• Have I somehow missed a decision step? Editors appear to be talking as if we have decided that drafts must be included in the first phase of the RFC, and I'm not sure that's been decided at all.—S Marshall T/C 11:18, 24 May 2012 (UTC)

  No, it's not decided yet. My comment immediately above yours was a suggestion of how we might find a compromise that everyone can live with. If it comes to it, though, we might have to make the decision the old-fashioned way, by having a mini-RfC and asking all the mediation participants to join the discussion. I take it that my specific suggestion above is not one that you're willing to go ahead with? — Mr. Stradivarius ^{(have a chat)} 11:44, 24 May 2012 (UTC)

  I didn't say that; I'm still angling for a two-stage RFC proceeding from the general to the specific, but of course if there's consensus for going the way you suggest then that's what we should do.—S Marshall T/C 16:40, 24 May 2012 (UTC)

  I guess my rather large lack of enthusiasm for two stages is that, partly because a second stage with drafts may still require a third stage with a revised draft, is that it would prolong the time until we actually accomplish a revision of the policy. The way I see it, no matter how many general question RfCs we have (even 100), once we have a drafts RfC, we will probably be one more revised-draft RfC away from having consensus. --Tryptofish (talk) 23:02, 24 May 2012 (UTC)

I think the simplest way of presenting the RFC is to have a distinct section of general questions, before the drafts. Though the questions themselves can probably be simplified. I've just added a simplified list of questions to the thread below "About whether or not we need general questions". Kalidasa 777 (talk) 10:57, 25 May 2012 (UTC)

First draft of the RfC — Break 1

Tryptofish made a small change to Draft C[5] because that draft is so similar to the current version of the lead of WP:V, which was changed since the mediation began. Although that change of Draft C is OK with me, I would suggest not making any more changes of Draft C or A until just before the RfC is proposed. At that time, we can do a "Compare selected revisions" on the history page of WP:V to determine what needs to be changed for Draft C, and simply copy the then current version of the WP:V lead for Draft A. --Bob K31416 (talk) 01:46, 21 May 2012 (UTC)

I just want to make it clear that I did it after having discussed it somewhere here in talk. But I agree that we should, in any case, update the "current" option. --Tryptofish (talk) 14:19, 21 May 2012 (UTC)

• Agree with the overall approach. It would be great if we could get consensus on a draft, but I think Strad is right -- it is more likely that consensus will be found on general questions. At least if this happens, the RfC will have accomplished one step forward. It is true that a lot of work did go into this -- not only Strad's work, but the work of everyone who has taken part in drafting the draft intros. I think part of the reason the draft RfC looks long is that the five draft intros appear twice, first in collapsable format and then in full format. The perm link for the source of draft B is not quite right -- the words don't quite match, although they almost do. Perhaps Blueboar could fix that, as he was the one who researched that version, IIRC? Kalidasa 777 (talk) 04:30, 21 May 2012 (UTC)

• I made an edit of the RfC that removes uncollapsed versions of the drafts, which may address previous comments of various editors including myself.[6] --Bob K31416 (talk) 11:13, 21 May 2012 (UTC)

  I like this, actually. I put the uncollapsed drafts in so that editors would be reminded what they are !voting on as they scroll past all the comments, but now that I see the page with just the collapsed drafts I think that you are probably right. By only showing collapsed drafts we are actually forcing editors to consider them all at once. How about adding some anchor links as well, so that people can navigate quickly between the comment sections and the different drafts? — Mr. Stradivarius ^♫ 11:46, 21 May 2012 (UTC)

  Something that I think will be very important is using full protection in order to prevent anyone from trying to modify the drafts while the RfC is in progress. --Tryptofish (talk) 14:21, 21 May 2012 (UTC)

• By the way, if anyone wants to take a shot at writing the introduction section, it would be a big help. — Mr. Stradivarius ^♫ 11:50, 21 May 2012 (UTC)

Bang! Bang! ...That is the sound of me taking a shot... Please have a look, and see whether you think I'm on target... Kalidasa 777 (talk) 01:57, 23 May 2012 (UTC)

Overall, I think it looks good. The first two sentences might give a bad impression.

"This is a new Request for Comment about the introduction to WP:Verifiability, and the much-discussed phrase "verifiability, not truth" (VnT). This time, we are not presenting just one proposal for comment, we are asking you to consider a range of possibilities. "

1) Why do we need to say "new"?

2) Re "This time..." — The reader might think that considering a range of possibilities is worse than what was done before. In fact, it might be worse because it could be very difficult to come to a consensus on any one of them. For example, the working group wasn't able to come to a consensus on any one of them, for if we did, we would be offering only one. --Bob K31416 (talk) 15:18, 23 May 2012 (UTC)

I also would avoid "new", too likely to elicit a response of "what, another one?". I'd also leave out the rationale for wanting to change the lead. Instead, I'd put the history part first, keeping it brief and linking to the previous RfC and the mediation pages, and let that provide the rationale. --Tryptofish (talk) 22:33, 23 May 2012 (UTC)

Can we get this detail right?

The source stated for Draft B, the recent past version, doesn't quite match the text of Draft B. The stated source -- 00:47, 15 December 2011.[7] --has "but in practice you do not need to attribute everything." Draft B has a separate sentence: "In practice you do not need to attribute everything." I think this came about because Blueboar found the version, but didn't say exactly where he got it from, then when someone asked the source, someone else suggested a source which actually wasn't the one one used by Blueboar in the first place... I had a look back through the WP:V history pages, and found that the version of 22:54, 1 July 2011 [8] does seem to be identical with Draft B except that the words "reliable, published source" are a link in 22:54, 1 July 2011, while in Draft B they are not a link... This is hair-splitting, I know, but we might as well get the details right if we can. Kalidasa 777 (talk) 03:11, 23 May 2012 (UTC)

Here's a comparison of the three versions.

• In the following diff, the Dec 2011 version is on the left and draft B is on the right.[9]
• In the following diff, the Jul 2011 version is on the left and draft B is on the right.[10]
• In the following diff, the Jul 2011 version is on the left and the Dec 2011 version is on the right.[11]

They all look about the same. Perhaps we should copy the Dec 2011 version to Draft B because it is more recent, and using the Jul 2011 version would be pushing the description of it as a recent past version. Also, the Jul 2011 version has a problem with the link [[Wikipedia:No_original_research#Sources|WP:NOR]] because there no longer is a section #Sources at WP:NOR. --Bob K31416 (talk) 05:58, 23 May 2012 (UTC)

When I proposed the text for Draft B, my intent was to have it reflect the text of the policy as it was on a date before we started to discuss VNT ... I don't remember which date I chose... but do remember looking for one where the text had been stable for a while (several months).

In other words... we don't necessarily want Draft B to represent a most recent previous version ... we want it to reflect a previous version that was stable and "long lasting". Blueboar (talk) 13:38, 23 May 2012 (UTC)

Regarding stability,

• In the following diff, the 15 Feb 2011 version is on the left and the previously mentioned 11 Jul 2011 version is on the right.[12]
• In the following diff, the previously mentioned 11 Jul 2011 version is on the left and the previously mentioned 15 Dec 2011 version is on the right.[13]

Comparing the two diffs, the change in the 5 months from Feb to Jul is greater than the change in the 5 months from Jul to Dec. This suggests that there was greater stability in the 5 months before the Dec 2011 version than in the 5 months before the Jul 2011 version. In other words, if you wanted "one where the text had been stable for a while (several months)", then the Dec one would be preferable to the Jul one. --Bob K31416 (talk) 14:41, 23 May 2012 (UTC)

I'm at least partially at fault for this confusion, sorry, because I think I was the person who originally provided the diff in the group page talk, and then repeated it here. I didn't realize at the time that it didn't exactly match what Blueboar had posted; indeed I've believed that it did. So, kudos to Kalidasa for catching what I missed.

My feeling about it isn't so much that it's important to go by "stability" as measured by edits during a time period, because a lot of edits end up being things that just reflected one editor's edit, not accepted by anyone else – there was a flurry of that after closing the last RfC. Instead, I would want to avoid going too far back in history, so, as noted by Bob, we don't stretch the meaning of "recent" past. Instead, I think that the previous "stable" version was what we had at the time the previous RfC was closed. That makes sense to me: Option A is what the page is at the time the new RfC will open, while Option B is what the page was when the last RfC was closed.

Therefore, I'd be inclined to keep the same permalink that we have now, from December 15, but correcting the Option B text to match what the permalink shows. --Tryptofish (talk) 22:28, 23 May 2012 (UTC)

That would be fine by me. Would anyone object to doing this? — Mr. Stradivarius ^{(have a chat)} 11:28, 24 May 2012 (UTC)

As noone has objected to Tryptofish's suggestion, I've just corrected the Option B text to match exactly what the permalink shows.Kalidasa 777 (talk) 22:51, 3 June 2012 (UTC)

About whether or not we need general questions

I've been asking what, specifically, we could find out from the general RfC questions, and I feel like we are kind of at an impasse, without really convincing one another in either direction. So, I'm going to pose some questions about the questions:

1. Question 1 asks, in effect, whether respondents like the wording of Option B, with respect to VnT. I realize that someone might say that they like this wording, while objecting to the draft over something else that it contains. But: is there any other way that the responses to this question would tell us anything that the responses to Option B would not tell us?
2. Question 2 asks, in effect, whether respondents like the wording of Option C, with respect to VnT and its explanation. I realize that someone might say that they like this wording, while objecting to the draft over something else that it contains. But: is there any other way that the responses to this question would tell us anything that the responses to Option C would not tell us?
3. Question 3 asks, in effect, whether respondents would like the policy to address "inaccurate material". Would it be better, instead, to have a question following Options D and/or E, to ask whether or not respondents would prefer that the specific draft contain language along that line?
4. Question 4 asks, in effect, whether respondents would like a footnote about the historical VnT. Would it be better, instead, to have a question following Options D and/or E, to ask whether or not respondents would prefer that the specific draft contain such a footnote?
5. Question 5 asks, in effect, whether respondents like the wording of Option E, with respect to never mentioning truth. I realize that someone might say that they like this wording, while objecting to the draft over something else that it contains. But: is there any other way that the responses to this question would tell us anything that the responses to Option E would not tell us?

I'd appreciate answers that respond specifically to what I've asked here, number-by-number. I believe that such answers will be useful in figuring out how best to organize the RfC. Thanks. --Tryptofish (talk) 22:13, 23 May 2012 (UTC)

A response and a suggestion

Responding to the 5 questions raised above...

1. Question 1 in the draft RFC contains 56 words, including example text. Option B contains 243 words, and will contain more if one or more questions are going to be tacked on the end. Which is easier to read, consider, and respond to?

2. Question 2 contains 84 words, including example text. Option C contains 483 words, and will contain more if one or more questions are going to be tacked on the end. Which is easier to read, consider, and respond to?

3. Question 3 (whether intro should mention "inaccurate material") is relevant not only to Option D and Option E, but to Option C as well. Would it be better to have an essentially similar question following Option C and Option D and Option E? Or simpler to ask that question just once?

4. Question 4 doesn't only ask whether respondents would like a footnote about VnT. It asks whether they would like the intro to distinguish between verifiability versus perceived truth, plus have a footnote about VnT. It contains 74 words, including example text. Option D contains 226 words. Which is easier to read, consider, and respond to?

5. Question 5 contains 45 words, including example text. Option E contains 219 words, more if questions are going to be tacked on the end. Which is easier to read, consider, and respond to?

Bottom line -- the general questions are comparatively simple and user-friendly. They will help to identify areas of agreement over key issues, which might otherwise get lost in disputes over commas and things.

What is the argument against including general questions, as well as the Options? I know it has been suggested that they will take up space, especially as answers get added in, and so there is a risk the specific Options may get lost at the bottom of the page. And I agree that this is a valid point.

To avoid anything getting lost at the bottom of the page, I suggest that the section "Questions about the general wording of the lede" be presented in a collapsable/expandable format -- the same sort of format used in the current draft RFC for Options A to E. Possibly respondents' answers, as well as questions, could be hidden in the collapsed form, revealed in the expanded form? Kalidasa 777 (talk) 09:29, 24 May 2012 (UTC)

PS As an experiment, I have just edited the RFC draft page so the General Questions section is collapsable/expandable like the Options...Kalidasa 777 (talk) 09:59, 24 May 2012 (UTC)

I don't think we need to worry too much about the length of the questions or how easy they are to understand. To get a good idea of the debate editors will have to read each other's comments anyway, so whatever we do the RfC will be hard to understand to a certain degree. Indeed, making the questions longer could make commenting on them easier, as we could give editors context that they might only otherwise get from reading through the disparate comments or from searching around on other pages. It's just a fact of life in RfCs that editors will need to read and make sense of a lot of text, whether that is dispute background, other editors' comments, or whatever. As for collapsing people's RfC comments, that's a definite no-no. That's what usually happens to comments that are off-topic (or worse) at pages like WP:ANI, and we don't want to imply anything bad about the comments editors leave at the RfC. Much better to leave comments un-collapsed, even if it does pose problems for how we structure the discussion. About your interlinked pages idea - how about doing it on a single page with anchor links? We already have the table of contents to show editors the main sections and to allow them to navigate there straight away, so to me it seems that half of the solution to this is already in place by default. But then again, maybe I'm missing something? — Mr. Stradivarius ^{(have a chat)} 11:25, 24 May 2012 (UTC)

Well, you may be missing something, in terms of my suggestion about collapsing comments. What I was trying to say, was that the RFC could contain a series of collapsable/expandable sections, each section containing both questions/options and comments. For instance, if options are collapsible/expandable, why shouldn't comments about the options collapse and expand along with the options themselves? Will people want to read answers without questions? Will people want to read comments without reading the stuff commented on? You tell me...

I take your point that the RFC will inevitably be hard to understand to a certain degree, but isn't that all the more reason to reduce the difficulty as far as we can?

Kalidasa 777 (talk) 12:01, 24 May 2012 (UTC)

Re Mr. Stradivarius's comment, "About your interlinked pages idea - how about doing it on a single page with anchor links?" and Kalidasa's comment, "I take your point that the RFC will inevitably be hard to understand to a certain degree, but isn't that all the more reason to reduce the difficulty as far as we can?" — If the questions are presented, perhaps it would be better to put them on a separate page so as not to overpopulate and complicate the main RfC page. Also, I suggest putting one link to them at the bottom of the RfC page, rather than various anchor links in the drafts, if it is decided that the questions should be presented. --Bob K31416 (talk) 12:54, 24 May 2012 (UTC)

It seems to me that it's a bad idea to collapse sections of the RFC because that suggests it's optional to read the collapsed sections before opining. I think that if something can be collapsed then it can be omitted from the RFC. I also think that if something can't be omitted from the RFC then it shouldn't be collapsed.—S Marshall T/C 16:43, 24 May 2012 (UTC)

I guess I don't care too much about those format issues, except to the extent that I want something that prevents people from changing the RfC while it's in progress. --Tryptofish (talk) 23:29, 24 May 2012 (UTC)

Thank you Kalidasa for responding to my questions (remember those?). Your answers are very helpful, and I appreciate them. (I'm also making a mental note that no one else answered.) Here is what I think, based on what you said. I don't think that I need to number it this time.

With respect to questions 1, 2, and 5, it seems to me that what they offer is two advantages. First, as Kalidasa says, they are short and sweet, and potentially easier for respondents to navigate than would be questions appended to the draft options. Second, as I noted based on earlier talk, there is the likelihood that some respondents will oppose specific drafts over separate issues about wording choices, so general questions will avoid that noise. It appears that, per lack of an answer to what I asked, there is not any other information we will get from them, beyond what we will get from responses to the various drafts.

My response to those two advantages is that the short-term advantage of easy and clear answers from the community will turn out to be a will-o-the-wisp, for exactly the same reason that people will object to specific drafts even if they were happy as clams about a general concept. Never underestimate the propensity of the Wikipedia community to say "no!" to change after we thought that they previously said "yes"! Where Kalidasa argues that questions at the beginning or end are an easier option than questions stuck on to each draft option, I agree, but I can offer an even easier format: skip the questions completely, and rely on the "Support with revisions" responses that we will get anyway.

As for questions 3 and 4, I think Kalidasa makes good points, and I pretty much agree. (By the way, I wavered over including Option C, so that makes sense to me too.) Could we, perhaps, then ask general questions 3 and 4 (maybe at the bottom of the RfC page), but blow off questions 1, 2, and 5?

--Tryptofish (talk) 23:29, 24 May 2012 (UTC)

I'm back from overseas and back on wiki. It will take me a while to read the substantial stuff involved in order to contribute intelligently. Possibly at the moment I'm a mineshaft canary regarding avoiding reductions of persons involved with this. Sincerely, North8000 (talk) 23:44, 24 May 2012 (UTC)

Thank you Tryptofish for your thoughtful and thought-provoking posting.

You've suggested that consensus from general questions will be a will-o-the-wisp. Are you saying that there is no point doing something which may bring wikipedians a step or two closer to consensus, because even if they take one step forward, they will very likely take two steps back afterwards? Well, I agree that might happen. But I still think bringing wikipedians a step or two closer to consensus would be a positive thing...

Tryptofish, you've said an easier format would leave out questions 1,2 and 5 and instead rely on the option of "support with revisions". My question is "easier for who?"

A newcomer to the RFC will get the point of question 2 by reading 84 words. To see what is meant by giving "support with revisions" to Option C, they must first read the 483 words of Option C, and even then they may be left wondering what "support with revisions" really means. Does it mean Option C is to get a major overhaul, followed by another RFC, or does it mean Option C will be incorporated into policy, and then tweaked a little down the track? If your phrase "support with revisions" is going to be used, won't this phrase itself need clarification, i.e. more verbiage?

You've suggested fewer general questions. I think you might be right about this, actually, although I do not think two questions are enough. But I do think the number of questions could probably be reduced, and the questions themselves made simpler.

Here is a new list of four questions

1. Do you think the lede should contain the words "verifiability, not truth"?

2. Do you think the lede should say more about the distinction between perceived truth and verifiability?

3. Do you think the lede should talk about verifiability without mentioning "truth" at all?

4. Do you think the lede should mention "verifiable but inaccurate" material?

I've presented these questions without example texts, although I do think example texts should probably be included with them, except in the case of Question 1.Kalidasa 777 (talk) 09:35, 25 May 2012 (UTC)

I like your new questions better than the existing ones (but question 2 needs to make clear "say more than it currently does"). As for easier for whom, I think that, no matter how else we go about it, we are going to have to rely upon uninvolved closer(s) to read through every response and determine consensus. But you are right that we would have to give some guidance about "Support with revisions", although I think it boils down to saying that this response means that you wouldn't support "as is", and saying that all respondents should provide informative comments rather than just me-too votes. Let's say, just for example, that one of the draft options gets a lot of support, plus a lot of support-with-revisions. And of those wanting revisions, 80% say that it needs to discuss "verifiable but inaccurate" material, and the other 20% are scattered over a wide variety of idiosyncratic complaints. It could then be pretty clear that revising it that way will lead to consensus.

You say to me that bringing us a step or two closer to consensus would be good. We agree, and are both saying that, but arguing for different ways to achieve that step or two. Given that you seem to agree with me that there is a risk of steps backward, let me ask you this: Why do you think that answers to general questions will be harder to step back from, than would be answers to specific draft proposals? It seems to me that the opposite is true. It's too easy for someone to agree with a general principle, but then turn tail when they see specific wording, but once they take a position on specific wording, they've taken a specific position. Why do you disagree with that? --Tryptofish (talk) 00:57, 26 May 2012 (UTC)

I don't disagree, Tryptofish... To put it more positively, I agree with you that consensus on a draft lede would be a bigger step forward than consensus on a more general question. I agree with you that inviting people to comment on drafts might lead to consensus, and I agree with what you've said about the two-RFC idea in the thread below -- if we are going to offer people both drafts and general questions, then we should do both simultaneously. My concern has been that an RFC process without general questions might end without consensus on anything... Kalidasa 777 (talk) 03:54, 27 May 2012 (UTC)

• Scuse me? The fact that I haven't answered Tryptofish's questions yet doesn't mean I'm not going to!—S Marshall T/C 11:00, 25 May 2012 (UTC)

Good! I'll be listening. --Tryptofish (talk) 00:57, 26 May 2012 (UTC)

S Marshall's answers to Tryptofish's questions

1. — Depends how we phrase the RFC;
2. — Depends how we phrase the RFC;
3. — Depends how we phrase the RFC;
4. — Depends how we phrase the RFC;
5. — Depends how we phrase the RFC.

• I'm sorry if this reads like a cop-out, and I assure you that it's not meant to be. It's intended as a different approach to the questions because we're having trouble reaching a consensus with the current route. A problem we have with the RFCs as drafted at the moment is the use of closed questions with binary, yes/no or support/oppose answers. I do not think this will lead to a productive or enlightening RFC, and it will probably not lead to a consensus. I believe we will do better by beginning with open questions and asking editors to group themselves into categories. An example may help.

S Marshall's ideal RFC, stage 1

Question 1: Please group yourself into one of the following categories. Group 1: Editors opposed to any substantial change to WP:V. Group 2: Editors who want to keep the wording "verifiability, not truth" as-is but would support other changes to the policy. Group 3: Editors who want to keep the wording "verifiability, not truth" but add explanation or clarification. Group 4: Editors who would prefer to replace "verifiability, not truth" with fresh wording. Group 5: Editors who would prefer a large-scale restructuring/rationalisation/simplification of Wikipedia's policies such as WP:ATT. Question 2: Please use this free text area to discuss the reasons for your choice of group or make any other comments you may have.

• The reason I like this is that it groups editors, but not in a binary way; we put them in a continuum line between pro-change and anti-change. We're then looking for the fulcrum point on that line as the route to the solution that the most editors can live with.

S Marshall's with-drafts RFC, stage 1

Please read the following four drafts: (Insert the four drafts agreed.) Question 1: Please add as many or as few comments as you wish to the following headings:- Things I like about draft #1 Things I don't like about draft #1 Things I like about draft #2 Things I don't like about draft #2 Things I like about draft #3 Things I don't like about draft #3 Things I like about draft #4 Things I don't like about draft #4 Question 2: Please group yourself into one of the following categories. Group 1: Editors completely opposed to any substantial change to WP:V. Group 2: Editors who want to keep the wording "verifiability, not truth" as-is but would support other changes to the policy. Group 3: Editors who want to keep the wording "verifiability, not truth" but add explanation or clarification. Group 4: Editors who would prefer to replace "verifiability, not truth" with fresh wording. Group 5: Editors who would prefer a large-scale restructuring/rationalisation/simplification of Wikipedia's policies such as WP:ATT. Question 3: If you wish, please use this free text area to discuss the reasons for your choice of group or make any other comments you may have.

• It would be my hope that with the steer from this Stage 1 RFC, we could agree a new phrasing for the policy without further recourse to the community. Realistically our views are very diverse and we may not achieve that, in which case the Stage 2 RFC would be to present revised drafts based on the feedback received in Stage 1.—S Marshall T/C 13:28, 26 May 2012 (UTC)

No problem: once I spent a second or two getting past the first list, I realized that your answer is actually a thoughtful one. Actually, I see quite a bit of wisdom to approaching it, at least in part, in these ways. I'd actually have high enthusiasm for an RfC in which part 1 is the draft options pretty much the way they are on the draft RfC page, and part 2 is your question 2 from the second collapsed example (or question 1 from the first). I would really like everyone in this mediation to give serious thought to using questions of this sort, asking respondents to put themselves into groups, instead of the kinds of questions we have been considering until now. I think this approach to questions pins people down in a way that solves the problems that concerned me in my previous objections to the questions. I actually think that S Marshall has answered the questions I asked, by explaining how the existing questions do not really get us anywhere closer to where we want to be, which is what I think too. But this alternative approach makes much better sense to me. --Tryptofish (talk) 00:25, 27 May 2012 (UTC)

Some more things I forgot at first. I didn't really respond to what you proposed about asking people to say what they like and what they dislike about the draft options. My reasoning is that we will be able to get the same information from "Support", "Support with revisions", and "Oppose", because most people will say "why". But, there is a chance that there actually will be consensus for one of the options, and we really ought to go into it keeping that possibility open. And that's why I don't want to do the first version you proposed, as a step before an RfC about the draft options. I don't want it to take any longer than it has to, before getting an actual improvement to the policy page, and I also don't want to trash the work we've already done in this mediation. And one more thought: I'd prefer to have those questions on the same page as the draft options, but at the bottom rather than at the top, because I'd like people to try to evaluate the drafts before they adopt what could be a line-in-the-sand self-identification. --Tryptofish (talk) 00:36, 27 May 2012 (UTC)

There are a couple of things I like about S.Marshall's suggested RFCs. In the with-drafts RFC, I like how the first part invites comments on the drafts: e.g. "Things I like about draft 1, Things I don't like about draft 1". And I agree it would be a good to include a question about large-scale restructuring, like WP:ATT. I'd also agree that we want to avoid polarization into two groups.

But I have to question the idea that questions should try to establish "a continuum line between pro-change and anti-change". Does such a continuum really exist? For instance, Fred Smith might be very happy to see VnT removed from the intro (putting him on the pro-change end of the continuum). The same Fred Smith might strongly oppose any use of language like "verifiable but inaccurate" (putting him on the anti-change end). Which of S.Marshall's five groups is Fred Smith supposed to choose?

So, should the questions aim to find out how much/how little change editors would like or can live with? Or should they aim to find out what sort of change editors would like or can live with? Kalidasa 777 (talk) 04:58, 27 May 2012 (UTC)

• Of course, what we should find out is what sort of change editors would like or can live with. But if we do that in Stage 1 of the RFC, then we will need to do some re-drafting before Stage 2, which is apparently unacceptable to Tryptofish. It's a conundrum...—S Marshall T/C 07:44, 27 May 2012 (UTC)

I'm thinking about what Kalidasa and S Marshall have said since my last comments, and about how we might resolve that conundrum. I'm inclined to accept that Kalidasa is correct in the comment in the thread above, that in the event that there isn't consensus about one of the draft options, we actually need to have some questions, in order to improve the odds that we will, at least, come closer to having consensus about something. It kind of comes down to figuring out how to "optimize the likelihood of consensus", as it were. I don't have all the answers, but it seems to me that we should try to ask about both draft options and general questions at the same time. If we do that, and there isn't consensus about a draft option, we'll be closer to an understanding of consensus than we would have been if the RfC had been questions only, or drafts only. Beyond that, I guess it's a matter of figuring out the general questions in such a way that they will be designed to maximize our understanding of what to do, in order to create a better draft option. One option would be to ask both of the following: support and oppose on the drafts, and, also, what we like and dislike about the drafts. (Could we accomplish that by explicitly instructing respondents to say what they like or dislike in their support or oppose !votes?) Alternatively, we could ask people to characterize themselves into (informative) groups in the way S Marshall described, but give them some more options to choose from, and also allow them to put themselves into more than one group, per what Kalidasa pointed out here. (At the moment, I'm leaning towards the second of those options, while also seeking like/dislike specifics in the !votes.) --Tryptofish (talk) 21:15, 27 May 2012 (UTC)

• Tryptofish, would you have time to put together a draft of your preferred RFC?—S Marshall T/C 21:46, 27 May 2012 (UTC)

No.(?) Sorry, I couldn't resist saying that. I don't have time today, but I'll at least think about it and maybe do some combination of spelling things out better here in talk, and/or doing something at the RfC draft page, within a few days. --Tryptofish (talk) 22:17, 27 May 2012 (UTC)

Format issue

Re: Bob's concern of Options getting lost at the bottom of the page, especially as people add answers and the page gets longer... I agree with Bob that linked pages may be a good idea, but I'd suggest a different arrangement... Why not have three linked pages:

• Page 1. Introduction, questions and options.
• Page 2. For answering the questions. (This page would have the questions, without example texts, plus fields for answers to the questions.)
• Page 3. For commenting on the options. (This page would have the brief descriptions of the options, not the full texts, plus fields for comments on the options.) Kalidasa 777 (talk) 11:28, 25 May 2012 (UTC)

Feasibility

Just a cautionary reminder that we need to consider whether there is a significant difference between what we want to put in the RfC and what is feasible. Try looking at the form of the RfC through the eyes of the typical editor who sees the RfC for the first time. Also, consider that the longer and more complicated the RfC, the more likely an editor will decide how to comment by only looking at the comments of others, and who made the comments. --Bob K31416 (talk) 12:55, 25 May 2012 (UTC)

What I would suggest is two separate RFCs... the first would ask the general questions.

1. Do you think the lede should contain the words "verifiability, not truth"?

2. Do you think the lede should say more about the distinction between perceived truth and verifiability?

3. Do you think the lede should talk about verifiability without mentioning "truth" at all?

4. Do you think the lede should mention "verifiable but inaccurate" material?

The second would ask about our drafts. Perhaps something like:

As a follow up to the above RFC... a team of editors has spent the last few months in discussions over these questions at WP:Mediation Cabal/Cases/27 February 2012/Wikipedia:Verifiability, and created the following drafts to show what the lede of the policy might look like, depending on what the consensus is on the questions asked above.

Please refer to the drafts and comment upon them. Let us know which one you like best, which ones you would be willing to accept as an alternative, and which one you like least (consider ranking them from "most like" to "least like"), and tell us why you either like or dislike them.

A. Current version, with "verifiability, and not truth".

Verifiability on Wikipedia is a reader's ability to check cited sources that directly support the information in an article. All information in Wikipedia must be verifiable, but because other policies and guidelines also influence content, verifiability does not guarantee inclusion. Verifiability, and not truth, is one of the fundamental requirements for inclusion in Wikipedia; truth, of itself, is not a substitute for meeting the verifiability requirement. No matter how convinced you are that something is true, do not add it to an article unless it is verifiable.

It must be possible to attribute all information in Wikipedia to reliable, published sources that are appropriate for the content in question. However, in practice it is only necessary to provide inline citations for quotations and for any information that has been challenged or that is likely to be challenged. Appropriate citations guarantee that the information is not original research, and allow readers and editors to check the source material for themselves. Any material that requires a citation but does not have one may be removed. Unsourced contentious material about living people must be removed immediately. For help on adding citations, see Citing sources. This policy applies to all material in the mainspace.

Verifiability, No original research and Neutral point of view are Wikipedia's core content policies. They work together to determine content, so editors should understand the key points of all three. Articles must also comply with the copyright policy.

Notes

B. Recent past version, with "verifiability, not truth".

The threshold for inclusion in Wikipedia is verifiability, not truth—whether readers can check that material in Wikipedia has already been published by a reliable source, not whether editors think it is true.

To show that it is not original research, all material added to articles must be attributable to a reliable, published source appropriate for the content in question. In practice you do not need to attribute everything. This policy requires that all quotations and anything challenged or likely to be challenged be attributed in the form of an inline citation that directly supports the material. For how to write citations, see WP:Citing sources.

This policy applies to all material in the mainspace—articles, lists, sections of articles, and captions—without exception, and in particular to material about living persons. Anything that requires but lacks a source may be removed, and unsourced contentious material about living persons must be removed immediately.

Verifiability is one of Wikipedia's core content policies, along with No original research and Neutral point of view. These policies jointly determine the type and quality of material that is acceptable in articles. They should not be interpreted in isolation from one another, and editors should familiarize themselves with the key points of all three. Articles must also comply with the copyright policy.

References

C. "Verifiability, not truth" with added clarification.

Verifiability on Wikipedia is the reader's ability to check reliable sources that directly support the information in an article. All information in Wikipedia must be verifiable, but because other policies, guidelines, and considerations also influence content, and particularly influence when verifiable but inaccurate material should not be included, verifiability by itself does not guarantee inclusion. Verifiability, not truth, is one of the key requirements for inclusion in Wikipedia—nothing, such as your personal experience or what you know to be true, can be a substitute for meeting the verifiability requirement. No matter how convinced you are that something is true, do not add it to an article unless it is also verifiable.

It must be possible to attribute all information in Wikipedia to reliable, published sources that are appropriate for the content in question. However, in practice it is only necessary to provide inline citations for quotations and for any information that has been challenged or that is likely to be challenged. Appropriate citations guarantee that the information is not original research, and allow readers and editors to check the source material for themselves. Any material that requires a citation but does not have one may be removed. Unsourced contentious material about living people must be removed immediately. For help on adding citations, see Citing sources. This policy applies to all material in the mainspace.

Verifiability, No original research and Neutral point of view are Wikipedia's core content policies. They work together to determine content, so editors should understand the key points of all three. Articles must also comply with the copyright policy.

References

D. New wording about perceived truth, verifiability.

In Wikipedia, verifiability means that people reading and editing the encyclopedia can check that information comes from a reliable source.

Wikipedia does not publish original research. Its content is determined by previously published information rather than by the personal beliefs or experiences of its editors. Even if you're sure something is true, it must be verifiable before you can add it. When reliable sources disagree, their conflict should be presented from a neutral point of view, giving each side its due weight.

All the material in Wikipedia mainspace, including everything in articles, lists and captions, must be verifiable. All quotations and any material whose verifiability has been challenged or is likely to be challenged must include an inline citation that directly supports the material. Any material that requires a source but does not have one may be removed, and unsourced contentious material about living people must be removed immediately. For how to write citations, see Citing sources.

Verifiability, No original research and Neutral point of view are Wikipedia's core content policies. They work together to determine content, so editors should understand the key points of all three. Articles must also comply with the copyright policy.

Footnotes

E. About verifiability, no mention of "truth".

Verifiability is one of the most essential requirements in Wikipedia. Information added to articles must be verifiable using only reliable sources that have been published.

An appropriate inline citation is evidence that information is verifiable. Inline citations are required for any information that has been challenged or is likely to be challenged, and for all quotations. Suitable inline citations should refer to published reliable sources that explicitly support the information being presented. For help on adding citations, see Citing sources.

Any material that requires an inline citation but does not have a suitable one may be removed. Unsourced contentious material about living people must be removed immediately.

Compliance with the Verifiability policy does not guarantee that material will be accepted. For example, it must also comply with other policies and guidelines, most notably No Original Research, Neutral Point of View, and Copyright.

Notes

---

Blueboar (talk) 13:52, 25 May 2012 (UTC)

• Except in certain unimportant details, I concur with Blueboar.—S Marshall T/C 16:41, 25 May 2012 (UTC)

• I think Blueboar's idea is a good one. Two shorter RFCs would be easier for people to navigate that one longer one. Kalidasa 777 (talk) 20:55, 25 May 2012 (UTC)

• I'm still not back up to speed yet. But IMHO the most important one is missing, something along the lines of: "Do you think that clarification should be added that the meaning of VNT is (only) to reinforce that verifiabiity is a requirement for inclusion? North8000 (talk) 21:33, 25 May 2012 (UTC)

• That's a good point. I also think that for completeness, the "general principles" one should mention the possibility of a complete revamp of the policy pages along the lines of WP:ATT (a proposal that I don't personally espouse but very nearly gained consensus at one stage). What I wanted to support was the principle of a two-stage RFC.—S Marshall T/C 21:36, 25 May 2012 (UTC)

• I have no objection to doing two in this way, but only if they are done simultaneously. I'd object to a questions-only RfC done first, as a waste of time. --Tryptofish (talk) 01:00, 26 May 2012 (UTC)

• I can see advantages in doing them simultaneously, and linked. As within this mediation, in the broader WP community there will be people who can relate more easily to a list of in-principle questions, and others who want to see specific drafts. Why not cater for both groups? Hopefully the two RFC pages can complement each other. Kalidasa 777 (talk) 23:03, 26 May 2012 (UTC)

• Stop the presses! I'm really intrigued by S Marshall's ideas about a different approach to questions, see just above. And I think it would be entirely feasible to have a single RfC page, with the draft options as we currently plan them at the top, and questions in S Marshall's format below it. --Tryptofish (talk) 00:28, 27 May 2012 (UTC)

• Well, I never. :) It looks like we're actually getting close to a compromise - I have to confess I was a bit worried that we wouldn't make it. Let's continue the debate on these lines and iron out the details. I think the next step should be for everyone to have a go at editing the RfC page to a version they think could find consensus here. Bold edits to the RfC page are totally ok, by the way - just make sure that you report back here, linking to your version with a permanent link. And also, feel free to start a new section on this page, as this one is getting quite convoluted. — Mr. Stradivarius ^{(have a chat)} 13:34, 28 May 2012 (UTC)

The first sentence in the above intro for the drafts is not true.

"As a follow up to the above RFC... a team of editors has spent the last few months in discussions over these questions at WP:Mediation Cabal/Cases/27 February 2012/Wikipedia:Verifiability, and created the following drafts to show what the lede of the policy might look like, depending on what the consensus is on the questions asked above."

It says that the drafts came out of the responses to the questions, which is not true. That can be corrected, but then the question would be, why didn't the drafts take into account the responses to the questions. --Bob K31416 (talk) 23:15, 25 May 2012 (UTC)

Too late to join?

I was involved in the discussion about the tag at the end of last year, but I quit (and unwatched it) because it seemed that it was set to go on indefinitely with no prospect of agreement. I only became aware of the mediation a few days ago when I raised a new (but related) issue on the policy talk page. Am I allowed to jump in and contribute to the discussion? Alternatively, can I get my name added to the list of participants? Scolaire (talk) 08:51, 28 May 2012 (UTC)

Hi Scolaire! I'll add you on if you want, but you should be aware that you're getting into this very late, and that you'll have to do a lot of reading to get up to speed. We will probably be ready to submit something to the community in a week or two, though, so it might just be easier to wait until then. I'll leave the final decision up to you. Best — Mr. Stradivarius ^{(have a chat)} 13:22, 28 May 2012 (UTC)

I have done quite a bit of reading. Basically there is one proposed draft that's likely to be presented (and IMO likely to be approved in an RfC) that I have a specific issue with. All I want to do is to start a discussion on the talk page of the relavant group. And that's why I don't want to wait until the proposals are submitted to the community. So yes, please add me. Scolaire (talk) 16:36, 28 May 2012 (UTC)

Hmm, I see. The immediate issue that I see with this is that we finalised the contents of the drafts a few weeks ago, with the majority of participants feeling that the current drafts were "good enough" and that we should move on to drafting the RfC proper. I'm not so sure that the participants will be keen to revisit the drafts, especially with the talk of adding sections to the RfC that ask if editors would like to see revised wording for the individual drafts. That said, I'm not going to say that we definitely can't revise any of them - why don't you post your suggestion here and let everyone have a look at it? If there's something obvious that we have missed then we may well choose to incorporate it. — Mr. Stradivarius ^{(have a chat)} 09:12, 29 May 2012 (UTC)

Since you have invited me to post on this page, I am going to start a new section below. Thanks. Scolaire (talk) 13:06, 29 May 2012 (UTC)

Suggestions for a revised format of the RfC

Yesterday, S Marshall asked me to suggest a revised version of the draft RfC page, and more recently Mr. Stradivarius has encouraged everyone to boldly edit that page. Right now, I don't feel ready to do that, because I'd like to think about it some more and also get feedback from the rest of you to what I've thought of so far – so here is what I've thought of so far.

I think we could do this as a single RfC on a single RfC page, with two main sections. Part 1: Options would be about the draft options that we have. Part 2: Endorsements would be what we have, up until now, been thinking of as general questions. By "endorsements", I really just mean what we have been calling "general questions", but S Marshall's insight made me realize that we could simply frame these questions as asking respondents to endorse those positions with which they agree, and that seems to me to be a much more concrete thing to ask, than asking what one thinks in general about an issue. It's more likely that people will "endorse" only what they really think, only what they really will stick with and not waver about later.

Important: I think the RfC page needs to be set up like the recent RfC on pending changes, such that no one can go around changing the drafts or the questions mid-process. That means the main RfC page is full protected, but each area where people can respond has a "click here to edit" link, that opens (I don't know how) a sub-page where the responses are entered, and that gets automatically transcluded onto the main RfC page. Maybe Mr. Stradivarius could ask User:Beeblebrox how they did that for the other RfC.

• The introduction at the top (I'll make some bold edits there in another day or two) should tell people to not just "vote", but provide informative comments, and should encourage discussion using the "#:" notation.

• Part 1: Options would be the draft options. There would be three editable fields for each draft option: Support, Support with revisions, and Oppose (no need for a further discussion field, I think). The instructions would say that if you support or oppose, please indicate in your comment what you like or dislike about the option. If you support with revisions, that means that you would not support as is, and please indicate clearly what revisions you would require in order to support.

• Part 2: Endorsements would, in effect, be our general questions. For each position, there would be only one editable field: endorse. You can endorse as many or few positions as you wish.
  • Based on S Marshall's list above, plus whatever else I could think of from our discussions so far, these are the positions that I'm aware of, worded as positions that one could endorse:

1. "I oppose any substantial change to WP:V."
2. "I want to keep the wording "verifiability, not truth" as is, but I would support other changes in the policy."
3. "I want to keep the wording "verifiability, not truth", but I support explanation or clarification of that wording."
4. "I want to move the wording "verifiability, not truth" to a section below the lead, with explanation or clarification of that wording."
5. "I want to move the wording "verifiability, not truth" to a footnote, with explanation or clarification of that wording."
6. "I support including a discussion of "verifiable but inaccurate" material in the policy."
7. "I support replacing "verifiability, not truth" with new wording."
8. "I support a large-scale restructuring/rationalisation/simplification of Wikipedia's policies, such as WP:ATT."

I think that it's important that we all give careful thought to whether anything else should be added to that list of endorseable positions. Is there anything else?

How does this sound? --Tryptofish (talk) 21:00, 28 May 2012 (UTC)

• I'll wait for others to comment about the content of this proposal, but before that I just wanted to explain how Beeblebrox set up the other RfC. (There's no need for me to ask him, as I've done a little work with templates and I know how this works already.) It works by transclusion, the same way as a {{cite book}} or {{infobox person}} template is displayed in an article. It's just that this time, the "template" we are displaying is very large and consists of a lot of comments. You can actually transclude any page onto any other - to demonstrate I made this version of the RfC draft, which displays the entire contents of this talk page right in the middle of the draft. all I had to do was add the text {{Wikipedia talk:Mediation Cabal/Cases/27 February 2012/Wikipedia:Verifiability}} to the middle of that page. You can't tell if you look at it now because it's not the latest version, but usually the "edit" links for each section will be displayed, and if you click on one of them you will be taken to the edit screen of whatever page that content belongs to. So if you clicked on the link for this section, "Suggestions for a revised format of the RfC", then you would actually be editing this page, and not the RfC draft page. This is the same principle as clicking on an "edit" link from the daily AfD log - it takes you straight to the individual AfD page. When the comment pages are transcluded on the RfC page like this, all you would need to do is get an admin to protect the main RfC page, and make sure the comment pages were left unprotected; the result would be RfC text that is not able to be tampered with. Does that explain things well enough? — Mr. Stradivarius ^{(have a chat)} 08:54, 29 May 2012 (UTC)

That's fine! I didn't know that you were already on top of it. And clearly, you understand the process much better than I do!--Tryptofish (talk) 21:41, 29 May 2012 (UTC)

• I certainly wouldn't want this RFC to resemble that horrible pending changes RFC in any way whatsoever. This RFC should be a discussion, not a vote. It should not have a team of pre-appointed closers who reach their decisions off-wiki. There should not be a debate manager who closes down and hats discussion that goes outside the pre-defined railroad tracks. And it should not consist of a protected page with transcluded subpages. This is Wikipedia where we're open and transparent and we trust our users.—S Marshall T/C 09:59, 29 May 2012 (UTC)

I'm sorry, I think I said something unclearly, so please let me clear that up. I never meant that we should approach this RfC, conceptually, the way that they did that other one. I totally agree with you about it being a discussion, not a vote. But my point – and I feel strongly about it! – is that we will have chaos, not a usable discussion, if we don't use the protection-transclusion format. If we have 100 editors supporting a draft option, and then someone comes along and changes its wording in a manner that 60 of them dislike, it will be a mess. And all you have to do is look at the "highjacking" of the last RfC to see that we shouldn't trust individual users to be able to mess with things mid-process.

But there's something else where you and I absolutely disagree. Who is going to close the RfC? You? Yeah, it will go over real well with the people who "highjacked" it last time if anyone fitting the definition of "involved" tries to determine the results. It has to be one or more persons who are uninvolved, or one segment or another of the community will reject the result. You may find this hard to believe, but I'm actually trying to rig the process so that change will take place! Yup, I confess to that! And the best way to get that to happen will be if we use a panel of three uninvolved administrators. And better yet, the same three as last time, if they agree. Because, if the consensus is for change, no one will be able to find fault with that. And if there isn't such a consensus, it won't be possible to convince the community otherwise by closing it the way we "want". --Tryptofish (talk) 21:54, 29 May 2012 (UTC)

Yes, now you come to mention it, I think it would be best if I personally closed the RFC.  :-)

I wish to point out that the problems you mention are caused by this insistence on having drafts in the RFC. It really would be so much simpler and better in every way to omit them.—S Marshall T/C 22:09, 29 May 2012 (UTC)

Except for two things. First, see below what North and I both say about "give us your thoughts". Second, it should of course be me closing the RfC. --Tryptofish (talk) 22:35, 29 May 2012 (UTC)

I'm ok with the idea of having a part 1 with the options and a part 2 with general questions. However, there are a number of things about wording of your endorsements section which I don't think will be helpful.

For instance, Number 1 "oppose any substantial change". If someone endorses that, logically speaking they are committing themselves to shoot on sight any suggestion for an improvement to the policy. It amounts to saying: "My mind is completely closed on the topic of changes to WP:V."

Number 2 "would support other changes". If someone endorses that, what in heaven's name does it mean? What sort of changes?

Number 8 Yes, the proposition of large-scale restructuring should be mentioned. But the wording should enable people to say "no" to this particular idea, as well as to say "yes" by endorsing it.

Tryptofish, you've said you are trying to rig the process so that change will take place. Perhaps you were joking, but I really think we should be try to set up the process to get consensus either for or against changes. The wording needs make it as easy as possible for opponents of changes, as well as supporters of changes, to express their particular views. Kalidasa 777 (talk) 00:21, 30 May 2012 (UTC)

Oh, please, I'm not really trying to rig anything! That was a (perhaps too) colorful way of saying that, although I'm advocating a method of closure that might appear unpopular amongst those editors here who are the most eager to change the wording of the policy page, what I'm advocating is actually what will make it most likely to make whatever consensus emerges from the RfC stand, and not get gamed out of existence. Again: "Because, if the consensus is for change, no one will be able to find fault with that. And if there isn't such a consensus, it won't be possible to convince the community otherwise by closing it the way we "want"."

Now back to the substance. Yes, I'm fine with all the points you raised about the wording of those positions/views. What I wrote was a draft, in talk. Let's revise it. Please suggest revised wording, along those lines.

And about people being able to say "no" to those positions/views, that's a good point, for all of them, actually. Maybe instead of just having "Endorse" for each of them, we should have "Endorse", "Oppose", and "Neutral". (I'm talking about the questions, not the draft options, remember.) Thoughts? --Tryptofish (talk) 19:07, 30 May 2012 (UTC)

Sorry I doubted you, Tryptofish... I like the idea that each of the questions/positions/views should have "Endorse", "Oppose", and "Neutral"... Here is a revised draft list of eight propositions...

1. "I think the words 'verifiability, not truth' need to be part of the lede."

2. "I don't think the words 'verifiability, not truth' need to be in the lede itself, but they should be mentioned elsewhere on the policy page."

3. "I don't see any need for the words 'verifiability, not truth' to be mentioned on the policy page."

4. "I would like the lede to say more than it currently does about the distinction between perceived truth and verifiability."

5. "If the lede includes the words 'verifiability, not truth', then I would like it to clarify that these words mean only that verifiability is a requirement for inclusion."

6. "I would like the lede to mention 'verifiable but inaccurate' material."

7. "I would like the lede to be just about verifiability, I don't think it needs to mention 'truth' at all."

8. "I support a large-scale restructuring/rationalisation/simplification of Wikipedia's policies, such as WP:ATT." Kalidasa 777 (talk) 11:03, 31 May 2012 (UTC)

No problem! And I agree that we should have Endorse/Oppose/Neutral for all. And I also agree with all of those revisions, with nothing that I can think of to add or change. --Tryptofish (talk) 00:26, 1 June 2012 (UTC)

Good that we agree, Tryptofish! I've just done a few edits to the draft RFC page, so that it has the Part 1, Part 2 structure as you suggested, and with the 8 statements above, so we can see how it actually looks. (Also got rid of some words in the draft RfC's own intro which people didn't like.) Kalidasa 777 (talk) 09:02, 3 June 2012 (UTC)

Format proposed by North8000

I'll describe it followed by arguments in key areas. Have the RFC consist of the 5 drafts plus the one currently in the policy. The sequence should be random. For clarity each should get a dispassionate neutral 1-sentence explanation regarding what it is/does structurally in relation to VNT. Make these things emphatically clear in the RFC:

• Each proposal is taken only with respect to it's treatment of VNT (including "threshold") Other items not directly related to this can and will be tweaked afterwards. So, don't rate a draft based on secondary wording not related to treatment of VNT/threshold.
• Respondents should rate EVERY draft with one of the following 5 exact choices: Strong Support, Support, Neutral, Oppose, Strong Oppose. Emphasize that it is very important to the process that they rate EVERY draft. Each choice can and should be used as many times as they wish.
• The RFC is just for editors who are at least slightly active. To participate, one must have had 5 edits total to Wikipedia in January-April 2012.

When closing, assign numerical values of 4,3,2,1,0 to the choices respectively. Tally them up. The one with the highest number goes in.

Now to address arguments against the above:

• In the big picture, S Marshall's point (and Tryptofish's idea above) is sound, as long as the questions are specific. An unstructured "give us your thoughts" RFC as S Marshall advocated months ago IMHO would not produce usable results, that's what we already did for a year and we got a 1/2 million words of opinions with no doable way to derive action from them. A structured polling on concepts as the discussion seems to be converging to would probably be the best place to start if we could turn the clocks back. But I think that it's too late now. If we put them both out side by side and results conflict, what would we do? If we start with just principles, then we're delaying resolution by another 6 months (but maybe that would be OK). Plus, if the drafts are taken (only) as I proposed, then they sort of are an RFC on general principles.
• Yes, it is sort of a vote. This is in the 1% of cases in Wikipedia where such is a good idea. This is because in this case, the flaws with voting are much reduced, and the flaws where 1 or 3 people subjectively "decide what people decided" are vastly increased.
• One might say that it is "complex" to get multiple choice ratings for each one, and asking everyone to rate every one. First, this really isn't complexity, it's actually simple and clear cut. But something like this is absolutely essential for any inquiry with 3 or more choices. Otherwise similarly minded proposals will certainly kill each other off, even if their concept has the most overall support.
• Is the "5 edits January-April 2012" criteria exclusionary? 99% of exclusions would probably be just SPA's created for the RFC, dormant sock accounts, and canvassed people who are no longer editing.

- - End of addressing arguments - -

Sincerely, North8000 (talk) 11:12, 29 May 2012 (UTC)

I think that your point about SPAs is a good one, that I hadn't thought of. Do we all think that the "5 edits" criterion is the best way to achieve that? Should we tweak it?

I also agree with you that we need to steer clear of anything like "give us your thoughts". Absolutely!

As I've said exactly a gazillion times before, I oppose anything like five numerical degrees of support. We won't be able to get people to cooperate, because we didn't even get us to cooperate when Mr. Strad tried it in this mediation. And, no, it's a discussion, not a vote. The thought of an algorithm that yields one with the highest number that will automatically go in (what if that highest number is nonetheless very low?) is about as appetizing to me as "give us your thoughts".

I don't like random order either. It's much more user-friendly if we start with two options that are identified by permalinks, followed by three that this mediation proposes. --Tryptofish (talk) 22:06, 29 May 2012 (UTC)

Could we please just trust the closer to identify SPAs and give them weight according to their merit.—S Marshall T/C 22:57, 29 May 2012 (UTC)

On second thought, maybe that is the right way to go. There's also Template:Spa, that can be used. (And I certainly agree with giving comments weight, as opposed to counting votes.) --Tryptofish (talk) 23:07, 29 May 2012 (UTC)

North, I can understand that you would like rapid closure. But the RfC needs to give people space to say what they want to say. If seriously held views are left unexpressed, then it won't resolve anything.

For instance, what if someone strongly agrees that RfC should be kept in the lede and clarified, but strongly opposes mention of "verifiable but inaccurate" material in any clarification?

As far as I can see, the voting-type format you're proposing would give such a person no way at all of expressing such a view. Kalidasa 777 (talk) 23:38, 29 May 2012 (UTC)

Just to clarify (or, actually, explain what I failed to note) I was thinking that folks would also give comments. But the main purposes would be to sway other respondents / have a discussion, and also to see that the respondents are real, involved people.

Another "just to clarify" my proposal was just to try to help the process, not an expression of deep-rooted opinions. I'll pretty much go along with anything that looks viable. Sincerely, North8000 (talk) 23:53, 29 May 2012 (UTC)

Issue with the opening sentence of drafts A and C

The first sentence of Drafts A and C is identical to the current first sentence of the article. I will re-post here what I said at Wikipedia talk:Verifiability#Opening sentence is a nonsense: The current opening sentence is a nonsense. Verifiability is a property of the article text; it is not and cannot be a property of the reader. "Verifiability on Wikipedia is a reader's ability to check cited sources..." means that it is different for every reader, depending on his or her degree of literacy, computer/internet skills, proximity to or membership of a library etc. It is clear to me (as a reasonably literate reader) what the sentence is trying to say. That does not alter the fact that it is wrong.

Prior to this edit on 2 March 2012 the opening sentence read "Verifiability on Wikipedia is the ability to cite reliable sources that directly support the information in an article." This explained the "ability" part of "verifiability" without attributing it to the reader. In the dicussion I linked to, only Trytofish has defended the current wording, while two or three others took my point that the sentence is factually incorrect. I don't think it should be too difficult to get agreement on a small tweak to make the sentence accurate. On the other hand, if it is presented in an RfC as is, and wins the !vote, it will be extremely difficult to get discussion on it further down the line, because the response will always be, "It took the best part of a year to agree this text, we can't tinker with it now." Scolaire (talk) 13:06, 29 May 2012 (UTC)

• I agree with Scolaire's logic and endorse his request.—S Marshall T/C 17:25, 29 May 2012 (UTC)
• I agree as well. I've argued this in the past. Verifiability doesn't have abilities, people do. The sentence is grammatically incorrect and so also inaccurate in that it personifies verifiability.(olive (talk) 17:37, 29 May 2012 (UTC))

Re "Verifiability doesn't have abilities, people do." — Does this mean you don't like either of the versions mentioned above? Perhaps the proposed change should be clarified in the form: In C, change from [...] to [...] . --Bob K31416 (talk) 18:32, 29 May 2012 (UTC)

A suggestion: "Verifiability on Wikipedia means that information in an article can be verified by reference to reliable sources that directly support the information." Scolaire (talk) 20:34, May 29, 2012 (UTC)

• I agree with your comments on the wording and on the proposed change. I'd even like to change it in the drafts as well as the current policy. As an aside, I am promoting the idea that the drafts are to be taken as showing the approach to VNT, not the other wording, and the other wording can be considered outside of the decision and changed if needed. North8000 (talk) 21:12, 29 May 2012 (UTC)

(edit conflict) I think the first issue is that we cannot make this change to Option A, for the simple reason that this option is, by definition, whatever WP:V says on the day the new RfC will open. If the change is made at the policy page, then of course we will make the change in Option A as well.

Whether we do it or not for Option C rests on the merits. But let's look carefully at the logic here. Scolaire argues that Verifiability is a property of text and not of persons, and S Marshall agrees. Insofar as that goes, I agree too. Of course it's a property of text, similar to clarity, comprehensiveness, and accuracy. And it clearly isn't a personal property, such as intelligence, literacy, or good faith. But it's interesting what Olive said: that verifiability doesn't have abilities, whereas people do have them. The wording of Option C is that it is "a reader's ability" – the ability of a person to do something, not of text to do something. So the "ability" is a personal property, not a text property. So, changing from "verifiability is a reader's ability" to "verifiability is the ability" is actually going from bad to worse! That was my objection at WT:V.

Logically, verifiability is actually the property of text that confers on the reader the ability to check sources and so forth. Can we say that succinctly? I'm not wild about the subsequent suggestion, because it follows the form "verifiability means... can be verified". How about changing Option C from

"Verifiability on Wikipedia is a reader's ability to check..."

to

"Verifiability on Wikipedia means that readers can check..."?

I actually like that, because it gets rid of that kludge about whether it's "the" reader or "a" reader! Thoughts? --Tryptofish (talk) 21:38, 29 May 2012 (UTC)

Actually, option A is what wp:ver said last fall. I advocate the addition of a sixth choice which is the current (as of opening) version of wp:ver. North8000 (talk) 11:00, 30 May 2012 (UTC)

• ...or combine the two: "Verifiability on Wikipedia means that readers can check the information in an article by referring to cited sources that directly support the information." That would bring together the keywords "information", "reader" and "check" before getting into the details of reliable sources and NOR. Scolaire (talk) 07:50, 30 May 2012 (UTC)

If you subject this to rigorous logical analysis, you still end up with a quandary, but it's still worth doing. The universal requirement established by wp:ver is that material be sourcABLE, NOT that it be sourcED. So the question is, which of these two shall "verifiability" in the first sentence define?:

1. That which this policy requires of all material? In this case the must include material that sourcable but not sourced. In that case, a typical reader is not able to verify anything, so anything about the reader should be removed
2. That which the policy requires only in certain cases? (sourcED)

I think that #1 is more appropriate on several levels. If you agree with that, then any reference to "the reader" should be removed. Sincerely, North8000 (talk) 11:16, 30 May 2012 (UTC)

If you agree with that, then you must remove not only any reference to "the reader", but any reference to "cited sources"! By that criterion, verifiabilty means that information can in principle be checked by referring to some hypothetical or actual "reliable source". That's a huge leap from any definition I have seen before. Scolaire (talk) 12:40, 30 May 2012 (UTC)

Actually, even if it did relate to the theoretical checking of information from a hypothetical source, it would still be "the reader" that was doing the checking. Scolaire (talk) 12:53, 30 May 2012 (UTC)

I think it is important that we not tinker with Option A... that option represents the "old" text of the policy prior to any questioning of VNT, and represents the view point of those who said "The policy is fine... don't change it" during the last large RFC (about a third of those who responded). Option C can be tinkered with if we wish (but please, let's not get hung up debating narrow wording changes ... The goal at this point is to determine macro "broad direction" consensus, not micro "specific wording" consensus). Blueboar (talk) 12:37, 30 May 2012 (UTC)

Surely Draft B represents the "old" text? Draft A represents the text after a good deal of tinkering and before full page protection. Scolaire (talk) 12:42, 30 May 2012 (UTC)

D'OH... Yeah, I got my versions mixed up... I thought that Option A was the "old" text, that Option B was the "current" text... Sorry... my bad.

That said... My point may still be valid... I would present both the "old" and the "current" text as "un-tinkered with" options (ie without any changes)... suggestions on how to change them to make them better can be made in your comments at the upcoming RFC. Blueboar (talk) 13:01, 30 May 2012 (UTC)

I think that if even WE (the few still heavily involved with this) are mixed up about current version, vs. fall 2011 version etc. the we have a pretty big-time-confusing situation that we need to clarify. North8000 (talk) 13:34, 30 May 2012 (UTC)

This is getting off-topic, but perhaps it would be an idea to rename Draft B as "Original" version (including the scare quotes, because of course it's not the original original), to remove the confusion. It might also help - though it might be a step too far - to swap A and B around so that there is a chronological order: past, present and potential future.

BTW, you might want to strike this comment. Scolaire (talk) 14:41, 30 May 2012 (UTC)

First, according to the current draft RfC page, Option A is what WP:V says at the start of the RfC, and Option B is what it said last fall after the previous RfC was closed. Not the other way around. I think we already had consensus to do it that way, and I feel quite negatively about reopening that discussion yet again.

As for the wording of the first sentence of Option C, I'm open to other ways of wording it – as well as just leaving it as is! – but I think it is very important to do two things. First, keep the wording as succinct as is practical. Second, minimize the "novelty" of the language, relative to what has been on WP:V in recent months. Both of those things grow out of the same consideration: that what's important here is VnT, and how Options C, D, and E approach it in different ways. The more that we add other, unrelated, unfamiliar wording to Option C (whose "purpose", in a sense, is to change VnT less than Options D and E do), the more reasons the community will find to oppose Option C for reasons other than its main point. For that reason, I don't think that we gain any traction by changing "check cited sources that directly support the information in an article" (what we have now) to "check the information in an article by referring to cited sources that directly support the information." That second version just says "information" twice!

So, I'll ask again: How about changing Option C from

"Verifiability on Wikipedia is a reader's ability to check..."

to

"Verifiability on Wikipedia means that readers can check..."?

--Tryptofish (talk) 19:38, 30 May 2012 (UTC)

• Support Tryptofish's proposal for the reasons stated. Scolaire (talk) 10:11, 31 May 2012 (UTC)

• Verifiability refers to both readers and editors so this isn't quite accurate but still its better than "a reader's ability to check..." seems to me.(olive (talk) 16:27, 1 June 2012 (UTC))

Yes, that's always sounded a little uncomfortable to me too. But this has gotten a lot of discussion in the past, and the consensus has tended to be that all editors are readers too (ie, editors are a subset of readers). And there have been arguments against using the word "editors" here, on the grounds that it implies that editors are responsible for checking one another's sourcing, although I personally don't find those arguments very persuasive. --Tryptofish (talk) 23:21, 1 June 2012 (UTC)

• The new sentence would be,

"Verifiability on Wikipedia means that readers can check reliable sources that directly support the information in an article."

This has a similar problem in that the reader can't check it if the reader can't find the reliable source that supports the info. This is also the case for the long-standing version.

"The threshold for inclusion in Wikipedia is verifiability, not truth—whether readers can check that material in Wikipedia has already been published by a reliable source, not whether editors think it is true."

I don't recall this objection being raised regarding the long-standing version, so it may be OK in that regard, but they would share that flaw. With an explanation that doesn't mention the reader here, one can speak of verifibility meaning that an RS can be found in principle, even if it can't be found by most readers googling, etc. --Bob K31416 (talk) 20:51, 1 June 2012 (UTC)

Bob, if I understand you correctly, the problem with the reader being unable to find the RS is a matter of, for example, not having access to a library that contains the source, right? (I figure that you don't mean that it's a matter of the RS not being found on the page, typically as an inline cite, in which case that's the point of WP:V in the first place, so it wouldn't really be a problem with saying it this way.) That gets into WP:PAYWALL and similar issues lower on the policy page. I'm not convinced that it's a big enough problem to make this revision a bad idea, is it? --Tryptofish (talk) 23:17, 1 June 2012 (UTC)

The point wasn't a matter of library access, paywall, or anything like that. Part of the point was that verifiability doesn't depend on whether or not there is an inline citation. Information can be verifiable even if there isn't an inline citation. For the purposes of understanding the definition of verifiability, consider the case where there isn't an inline citation. When the proposed version says "readers can check reliable sources", it assumes that they can find the reliable sources to check if there isn't an inline citation. The needed reliable source may exist freely and with easy accessibility on the internet, but some readers may not be able to find them because of not knowing where to look. Thus some readers can't check the reliable sources, yet the information is verifiable because the reliable sources that directly support the information exist.

I guess it involves what people interpret "can check" to mean. If it is interpreted to mean they can check it if they are sufficiently skillful in finding the reliable sources, then it's OK. Also, it depends on the interpretation of what "readers" means. If it is interpreted to mean "all readers" then it wouldn't be true because some readers aren't skillful enough to find the reliable source to check it. Personally, I would avoid these complications by not using "readers" in the explanation. To each their own. --Bob K31416 (talk) 00:34, 2 June 2012 (UTC)

(e/c) As I understand it, Tryptofish is saying that this is another issue for another day. Both you and North8000 above make valid points about verifibility meaning only that an RS can be found in principle, but this is something that might be better left until after VnT is dealt with one way or another, and the page has been unprotected. "Verifiability...means that readers can check reliable sources" may not be strictly correct, but it is less obviously incorrect than "Verifiabilty...is a reader's ability to check reliable sources". For that reason, and because it involves minimal change to Draft C, I believe it is the best way to address this issue in the short term. Scolaire (talk) 23:33, 1 June 2012 (UTC)

"Verifiability on Wikipedia means that reliable sources that directly support the information in an article can be checked." That overcomes any question of any individual reader's ability to access or check each and every source themselves. Pesky (talk) 03:31, 2 June 2012 (UTC)

Again, there's no point in going half-way. If we don't want to infer that verifiability is a property of the reader, then we also don't want to infer that it is a property of sources. Verifiabilty is property of information. Therefore:

"Verifiability on Wikipedia means that information in an article can be checked by referring to reliable sources that directly support it."

I am in favour of a minimal change on the lines suggested by Tryptofish, to tide us over until after the RfC, but if there is to be substantial change it should not be from something wrong to something equally wrong. Scolaire (talk) 08:11, 2 June 2012 (UTC)

I think we are trying to answer three distinct questions in one short sentence (which may be a mistake). The three questions are: 1) What needs to be verifiable 2) Who needs to demonstrate verifiability and 3) Why do they need to demonstrate it. The answer to what is: The specific statements of opinion and fact that are added to an article. The answer to who is: The editor that adds the statement. The answer to why is: So readers can check that the statement accurately reflects what is said in the sources (and, thus, is not original research). I think it might be worthwhile to lay all this out in more than one sentence.

That said... I agree with Tryptofish that this would be better addressed as a follow-up discussion... after we hold the RfC and settle the issue with VNT. The reason why we have created these "options" is to present different thoughts on how to resolve the VNT issue... not to resolve every single issue and problem in the lede at one fell swoop. Stop trying to make the options "perfect"... focus on the issue at hand... resolve that, and then go on to fix other issues. Blueboar (talk) 12:49, 2 June 2012 (UTC)

So, to clarify, you would be in favour of changing the first sentence of draft C to ""Verifiability on Wikipedia means that readers can check reliable sources that directly support the information in an article.", then revisiting the question after the RfC? Scolaire (talk) 17:44, 2 June 2012 (UTC)

Scolaire, FWIW I think your suggestion is much better, i.e. "Verifiability on Wikipedia means that information in an article can be checked by referring to reliable sources that directly support it." --Bob K31416 (talk) 18:31, 2 June 2012 (UTC)

Thanks, Bob. Right now I'm just anxious that people agree on something. If other people agree to that wording it would be great, but I'll go with whatever gets consensus, so long as it's different from what's there at the moment. Scolaire (talk) 19:21, 2 June 2012 (UTC)

If I understand correctly, what is on the table now is to change the opening sentence of Option C from:

"Verifiability on Wikipedia is a reader's ability to check reliable sources that directly support the information in an article."

to either:

"Verifiability on Wikipedia means that readers can check reliable sources that directly support the information in an article."

or:

"Verifiability on Wikipedia means that information in an article can be checked by referring to reliable sources that directly support it."

To me, it comes down to balancing the point about making the fewest changes outside of VnT possible, which argues for the first option, against what Bob says about the fact that not every reader can check as well as every other reader, which is what the second option solves at the cost of adding additional verbiage about "by referring to" and "it". Personally, I prefer the first option. If, as we seem to be making a habit of in all these discussions, we really overthink it, Bob's issue still remains in the second option, because it can be argued, if one really wants to push the issue, that not everyone can refer to the sources in order to check. One has to argue, instead, that it's possible for the right person, who has the access and know-how and so forth, to refer to the sources where they exist. And that argument can also be made about the "readers" in the first option, without the cost of the more complex wording. --Tryptofish (talk) 21:44, 2 June 2012 (UTC)

My issue with the first option, if I overthink it, is that verifiability doesn't mean that readers can check reliable sources. Reliable sources don't need to be checked, by definition. They're reliable because they have already been checked. Verifiability means that readers can check in reliable sources to see if information in an article is supported by them.

If I don't overthink it, I'm happy with the first option, as I already said. I'm glad that there has been discussion on this, because that is what I came here for. What I'm anxious about, however, is the possibility that the present wording, which nobody really wants, will end up being kept because nobody can agree on a single alternative. Scolaire (talk) 22:25, 2 June 2012 (UTC)

"...because nobody can agree on a single alternative"... that just about sums up the last year and a half. Lots of people agree that there are flaws in the wording of the policy... but no one can agree on wording to fix those flaws (and everyone has their own favorite flaw that they want to see fixed first). Blueboar (talk) 14:15, 3 June 2012 (UTC)

It's just a small change in a draft. There seems to be consensus that both suggested changes are an improvement, so what if we just have a poll and choose the one that has a simple majority. After all it's a draft, not the actual policy page. --Bob K31416 (talk) 17:43, 3 June 2012 (UTC)

Point of order: since when did we have "consensus" that both of these changes are an improvement? There was an emerging consensus that one of them might be an improvement. The poll below seems to me to be an end-run around the previous drafting of the group drafts. --Tryptofish (talk) 21:12, 3 June 2012 (UTC)

Poll re first sentence of Draft C

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The result was to use (a). I note that this has already been implemented by Bob K31416. — Mr. Stradivarius ^{(have a chat)} 12:05, 5 June 2012 (UTC)

---

Regarding the opening sentence of Option C,

"Verifiability on Wikipedia is a reader's ability to check reliable sources that directly support the information in an article."

please choose from the following:

a) change to

"Verifiability on Wikipedia means that readers can check reliable sources that directly support the information in an article."

b) change to

"Verifiability on Wikipedia means that information in an article can be checked by referring to reliable sources that directly support it."

c) change to

"Verifiability on Wikipedia is the ability to cite reliable sources that directly support the information in an article."

d) don't change.

Support (a)

1. And I really don't like either of the others! --Tryptofish (talk) 20:49, 3 June 2012 (UTC)
2. Support (a). Will explain reasons in discussion area below. Kalidasa 777 (talk) 00:07, 4 June 2012 (UTC)
3. Prefer this to the others... but I think this is a secondary issue that should wait until after the main RFC. Blueboar (talk) 00:42, 4 June 2012 (UTC)
4. Although my personal preference is for (b). I believe that consensus is more important than personal preference. Scolaire (talk) 06:28, 4 June 2012 (UTC)
5. Some improvement is better than no improvement. --Bob K31416 (talk) 11:41, 4 June 2012 (UTC)

Support (b)

1. Avoids problems of "readers" (a,d) and "ability" (c,d). --Bob K31416 (talk) 21:03, 3 June 2012 (UTC)

Support (c)

1. North8000 (talk) 17:58, 3 June 2012 (UTC)

Support (d)

1. I could also support no change from what Draft C says now. --Tryptofish (talk) 20:54, 3 June 2012 (UTC)

Discussion

Where did (c) in the poll come from? Since when is verifiability an ability? If verifiability is a property of the text, how can text have an ability? --Tryptofish (talk) 20:54, 3 June 2012 (UTC)

(c) was the stable version on the policy page between 31 January and 2 March this year. Scolaire (talk) 21:15, 3 June 2012 (UTC)

Well, it wasn't stable enough to stay there now, and I increasing despair that anything stable will come out of this mediation process. --Tryptofish (talk) 21:20, 3 June 2012 (UTC)

You need to ease up on the attititude. You asked where the wording came from and I answered your question. Of course nothing is going to come out of mediation if people are going to be relentlessly negative. Scolaire (talk) 21:46, 3 June 2012 (UTC)

If you thought that I was directing that at you, I wasn't. And I'm pleased with the outcome of this discussion. --Tryptofish (talk) 23:03, 4 June 2012 (UTC)

Whoops, looks like I've been leaving things alone for too long! I can understand people's frustration here, as we have been discussing step 7 for a good while now, and the current discussion about the wording really should have been done in step 6. But don't worry - we are almost done. It seems we are pretty much agreed on the wording here, and the only big thing we have left to agree on is the general RfC structure - after that we will only have a few small details to sort out. I'll be posting a discussion later on today so that we can sort out the RfC structure once and for all. (I've already written half of it, so posting it today shouldn't be problem.) — Mr. Stradivarius on tour ^{(have a chat)} 04:04, 4 June 2012 (UTC)

My reason for opposing (b), which I've already explained earlier in talk, is that it adds clumsy excess verbiage ("by referring" "it") that will give respondents more reasons to oppose. --Tryptofish (talk) 21:07, 3 June 2012 (UTC)

What it took me a long time to learn for situations like this is that wording that that covers it and does so precisely is poor prose. The norm is something that is slightly imprecise/incomplete (= not overly wordy) which communicates the point. So personally I'm less concerned about that. But, IMHO, the first two are somewhat misleading in a way that could easily fundamentally mislead people. "A" and "B" are basically say that verifiability means that something is sourcED. The is not a correct summary of the universal requirement of the policy which is that material be sourcABLE, not that it be sourcED. (It also requires that material challenged or likely to be challenged be sourcED, but that requirement is only for those cases.) Sincerely, North8000 (talk) 22:39, 3 June 2012 (UTC)

I agree with North that communicating the point is more important than the elegance of the prose. However, I don't see how the wording of (a) "readers can check reliable sources" implies anything more or different from the current wording (d) "a reader's ability to check reliable sources", except that (a) is simpler and clearer.

While I don't personally have a problem understanding wording like "a reader's ability", I can see why some find this illogical as a definition of "verifiability". I agree with something Tryptofish wrote earlier in this thread: "Logically, verifiability is actually the property of text that confers on the reader the ability to check sources and so forth." Verifiability is about the relationship between the text and the reader. In simpler words, a verifiable text is one that readers "can check", as sentence (a) says. Kalidasa 777 (talk) 00:37, 4 June 2012 (UTC)

I agree that it is an attribute of material. The imprecise "ability of the reader to" obviously means this, but agree that if you look at it closely it sounds silly. Once that is settled, then it depends on what we are saying "verifiability" is. Which of these is it (and I'm going to argue against myself here.)

1. That which is required by this policy? If so, then the first two items in the poll are wrong (and only "C" is correct), because they describe an attribute of sourcED material.
2. The general concept/situation/property which choices "a" and "b" in this poll describe. And here you could take it either way. Easily verifiable material means sourcED material. But you could also argue that sourcABLE material also is verifiable by the reader if they do the research. Under this interpretation, "a" & "b" in this poll would also be fine.

North8000 (talk) 14:09, 4 June 2012 (UTC)

Of the three, only (c) uses the word "cite". Neither of the others require sources to be cited, only that you would expect them to exist, and therefore that they could be checked if desired. Option (a) adds the requirement that they be checkable by a Wikipedia reader, whereas (b) says that a fact is verifiable if anybody in the world could find a reliable source that would support it. Therefore I would say that any and all of the options refer to sourcABLE material. Scolaire (talk) 15:43, 4 June 2012 (UTC)

It looks like it's time to implement (a). --Bob K31416 (talk) 21:36, 4 June 2012 (UTC)

I implemented it. --Bob K31416 (talk) 23:05, 4 June 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Are we going too far?

If there is one thing I have learned in the last year or so, it's that the more we tweak and change the wording of the policy at one time, the more likely it will be for people to find something to oppose. The baby will be thrown out with the bathwater.

To be honest, I find I am having an increasingly negative reaction to all the tweaks and minor changes being suggested. It is getting to the point where I am coming full circle... I was originally a strong opponent of changing the VNT language... but was talked around to seeing its flaws and attempting to resolve them. But now I am leaning towards going back to supporting the old (2011) language of the policy (even though I completely agree that it is flawed)... for the simple reason that all the other options are being tweaked to death. While I like a lot of those tweaks when taken individually, they all add up... and I am not sure I can support any of the options. With with the old language, I was at least familiar with how Wikilawyers could misinterpret the policy, and I had learned how to counter their arguments. The policy had flaws, but I knew what they were and could deal with them. Looking at the amount of changes being proposed in each of our options, I am coming to the conclusion that returning to that language (despite it's flaws) will probably do the least amount of harm. I suspect that the rest of the community will feel the same way... every editor will like bits and pieces of each option... but they will also find something in each option to oppose. And because of this, they will end up rejecting any change, no matter how good it might be. Blueboar (talk) 15:10, 4 June 2012 (UTC)

In short... I think our eagerness to "fix" the entire lead has gotten out of hand. I think we have gone too far and over reached. So... have fun arguing among yourselves about minutia. I'm done. Let me know when the RFC actually happens. Blueboar (talk) 15:15, 4 June 2012 (UTC)

If we take it that the RFC is about the core item (the treatment of VNT) of each proposal, with all other aspects being secondary & changeable afterwards, then I think it gets simpler and addresses that concern. Also my concern which is that this is getting mired down and in danger of dying under it's own weight/complexity. Sincerely, North8000 (talk) 15:40, 4 June 2012 (UTC)

This is a subsection of the "Issue with the opening sentence" section, so I get the impression that you think that after all the discussion and tweaking of the last four months, this small change to five words of the opening sentence will be the straw that breaks the camel's back. Somehow, I don't think that that will be the case. In fact, if the change is not made, you may be sure that I will raise my objection in the RfC, so the probability of "people finding something to oppose" will not be increased by making the change, and may be marginally reduced. We will be in the endgame within days now; there is nothing to be lost by letting the poll reach a conclusion in the meantime. Scolaire (talk) 16:03, 4 June 2012 (UTC)

There is only one small change pending and it is supported by a strong majority. It should be implemented now. --Bob K31416 (talk) 21:34, 4 June 2012 (UTC)

I agree with what Blueboar said about the dangers to this process, and what he said explains quite well what motivated my earlier comment about "despair". But, on the other hand, I'm entirely happy with the outcome of the discussion about the opening of Option C, even though, a day ago, I thought it was going off the rails. --Tryptofish (talk) 23:12, 4 June 2012 (UTC)

Archive 1

Archive 2

Archive 3

Archive 4