Wikibooks:Reading room/Proposals/2010/July

These awful breaks
Everybody always writes conversations like this:

Something here
 * Reply to Something here
 * Reply to Reply to Something here
 * Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here

Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here
 * Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Reply to Something here

And on it goes. It gets kind of tiresome. Arlen22 (talk) 15:48, 2 July 2010 (UTC)

Why don't we take an idea from Google Wave, and only start a new level if we are replying to something in the middle of the conversation, and then go down like that. Then,

Arlen: Hello all
 * Someone: Arlen, it's "Hi all"
 * Arlen: Of course, all in your way of looking at it
 * Someone: Hi, Arlen, what's up.


 * Arlen: I have this problem

Arlen: Hello all
 * Someone: Arlen, it's "Hi all"
 * Arlen: Of course, all in your way of looking at it

Someone: Hi, Arlen, what's up.

Arlen: I have this problem

Do you all like that idea? Arlen22 (talk) 15:48, 2 July 2010 (UTC)

Arlen22 (talk) 15:48, 2 July 2010 (UTC)


 * I'd sooner support Extension:LiquidThreads. As a side note, I think you mean "these awful outdents". The breaks are due to sheer length (not helped by the above). – Adrignola talk 16:14, 2 July 2010 (UTC)


 * Well, the indents are the trouble. The outdents are a symptom. Here is a prime example, under the old method I would have indented this reply one more than yours. Arlen22 (talk) 16:36, 2 July 2010 (UTC)


 * Woe, LiquidThreads looks amazing! Arlen22 (talk) 16:43, 2 July 2010 (UTC)


 * I get what you mean now, yes I did mean indents and outdents, not breaks (or markers/pages/etc) Arlen22 (talk) 20:01, 2 July 2010 (UTC)

I don't know, LiquidThreads seems weird to me... I just... don't like it. Kayau ( talk &#124; email &#124; contribs ) 23:43, 2 July 2010 (UTC)

At least you can customize it. Like nested vs flat, and so forth. Arlen22 (talk) 00:10, 3 July 2010 (UTC)


 * LiquidThreads is in my experience great for social chatting, and unsuitable for serious discussion. For example, Wikinews is currently striking a good balance, I think, by using LiquidThreads for the "Have Your Say" pages about articles, but not for talk pages (where they use the usual highly effective indentation techniques).  --Pi zero (talk) 01:23, 3 July 2010 (UTC)


 * Well, we don't have comments pages on WB. Does that mean we can't strike a balance? Kayau ( talk &#124; email &#124; contribs ) 04:12, 3 July 2010 (UTC)


 * I don't see anything at Wikibooks that I consider a good subject for LiquidThreads. (How and whether one applies the word "balance" to that is probably a distraction.)  --Pi zero (talk) 13:41, 3 July 2010 (UTC)


 * I think we should have a smartcode for enabling it on a page. Soemthing like __LT__ Arlen22 (talk) 14:00, 3 July 2010 (UTC)
 * LiquidThreads works by adding to a page. --Yair rand (talk) 02:46, 4 July 2010 (UTC)


 * @Pi zero: I was just kidding. :) I agree, there is little we can do about liquids here. Kayau ( talk &#124; email &#124; contribs ) 14:24, 3 July 2010 (UTC)

Wikibooks Barnstar equivalent
Wikipedia uses barnstars for awards and such like. What is our symbol on Wikibooks? Arlen22 (talk) 12:19, 3 July 2010 (UTC)


 * Most of the pre-made images in Category:Wikimedia user awards are based off barnstars. It'd be a lot of work to generate such a collection with a new symbol.  – Adrignola talk 12:33, 3 July 2010 (UTC)
 * So we might as well use barnstars then. Arlen22 (talk) 12:34, 3 July 2010 (UTC)
 * Indeed. Though there might be some resistance similar to what I experienced when I began importing the most commonly used Userboxes. Wikibooks is serious business. – Adrignola talk 12:45, 3 July 2010 (UTC)
 * I've proposed barnstars last year, but all it got was a comment from another user (IIRC it was Pi zero) saying that (s)he doesn't like the idea that much... If anyone is interested in importing barnstars here, it may be important to note that there is currently a proposal on ENWP regarding upgrading the barnstars to more cartoonish ones (some say they're cheap plastic; others say they're smooth and shiny). See w:WT:WPWPA (Last section). Kayau ( talk &#124; email &#124; contribs ) 12:54, 3 July 2010 (UTC)



It doesn't take long to make something unique for Wikibooks when it was done already years ago: --dark lama  13:32, 3 July 2010 (UTC)


 * Can you alter the W? Kayau ( talk &#124; email &#124; contribs ) 14:25, 3 July 2010 (UTC)


 * It is SVG, and the positioning of the book is horrible. I am working on getting the correct angle from GMAX. Arlen22 (talk) 14:26, 3 July 2010 (UTC)


 * If we're going to use some such device, I'd actually favor using barnstars as such. Customized, probably.  Even Wikinews, where they are deeply suspicious, with some cause, of all things Wikipedian &mdash;they rarely even call it by name, using indirections like "The Other Place"&mdash; uses customized barnstars (e.g., this); so it's very clear barnstars are not an idiosyncrasy of Wikipedian culture.  I imagine us forging our own traditions about when to use them (promotion of a book to featured status springs to mind), and my guess is that generic barnstars would probably never catch on here.


 * The remarkably short proposal thread from last year that Kayau refers to is one that stuck in my mind; I worried for months after whether the doubts I'd expressed were any reason not to try it and see, and worried that the early death of the thread might have been due to a difference in how confident the participants were of their place in the Wikibooks community, rather than due to anything about the issues raised. (Okay, so I worry a lot.)  My thinking has evolved since then, not least my perception of how much good a vibrant tradition of barnstars can do for the morale and interpersonal good will of a project, though the second paragraph of my post then still pretty much makes sense to me.  That thread is archived here. --Pi zero (talk) 17:55, 3 July 2010 (UTC)


 * I've changed the angle/positioning of the book. I also changed the style to reflect Wikibooks' updated logo somewhat. --dark lama  19:33, 3 July 2010 (UTC)


 * It does look better that way. The base seems a bit too sharply tilted toward the viewer.  BTW, how does it reflect the updated logo (somewhat)?  --Pi zero (talk) 20:10, 3 July 2010 (UTC)


 * Unless I've remembered wrongly, it uses the same font and there is a dash of blue. The effect is suppose to be subtle. --dark  lama  20:18, 3 July 2010 (UTC)


 * Subtle is good. :-) The blue does look the same.  The font is different, though; WIKIBOOKS on the logo, now on the upper left corner of my screen, is sans serif.  I also notice &mdash;though I can't decide whether this would be subtle or not&mdash; that the logo has WIKI in black and BOOKS in blue.  --Pi zero (talk) 20:57, 3 July 2010 (UTC)


 * Actually, in the logo, WIKI is navy. Arlen22 (talk) 21:01, 3 July 2010 (UTC)


 * Changed the base and the font. Any better? --dark lama  10:41, 4 July 2010 (UTC)


 * I think it's looking quite neat. Seems like it might be possible to have two motifs of awards, medals and... what's a really good word for this?  "Trophies"?  --Pi zero (talk) 17:13, 4 July 2010 (UTC)


 * Arlen22 (talk) 00:39, 8 July 2010 (UTC)

Several of these threads have been rendered unreadable by redacting other people's comments to remove the indentation. It's an impressive demonstration of why lack of indentation is a terrible idea, but that doesn't need to be demonstrated further, and more to the point it's inappropriate to redact other people's comments. (I find having my comments systematically redacted deeply offensive, as a result of which I'm saddened to realize I can't afford to risk contributing to the content of this thread.) --Pi zero (talk) 15:43, 3 July 2010 (UTC)


 * I am sorry it is so hard on you, in this case LiquidThreads suddenly become much more needed. Now I know what one active contributor thinks about redacting, or rather, lack of indentation. I have always been trying to figure out a better way of conversation than we currently have, and this apparantly doesn't work. Anyone else have any thoughts on straight down the row conversation? Arlen22 (talk) 15:50, 3 July 2010 (UTC)
 * Can you read it easier with these lines in between like this? Or what did you mean about it being unreadable? After all, conversations are supposed to go straight down a page. Arlen22 (talk) 15:52, 3 July 2010 (UTC)


 * You're trying to turn it into the equivalent of an IRC chat, where you have to continually say @Person in order for others to know who you're replying to. With no indentation or nesting, they're just comments in the wind and you get confusion on serious subjects where people misinterpret comments that didn't apply to them. If someone wants to reply to a comment said earlier, they can't indent to make it apparent their statement was made out of the normal flow, as I've deliberately made this one. – Adrignola talk 16:36, 3 July 2010 (UTC)


 * Most discussion systems in the English language use some form of left intention to indicate who the target of a response is to. Even email uses multiple levels of ">" at the start of lines to quote the person that is the target of a response. LiquidThreads even uses left intention to make it easier to tell who the target of a response is. I have no idea if this is true for other languages, but this is English Wikibooks anyways. --dark lama  16:39, 3 July 2010 (UTC)


 * This thread points out some problems to my idea of having vertical, rather than indented, threads. Thanks everyone for convincing me. Now, back to the drawing board. Then, while my back was turned, they brought in this thing called LiquidThreads. I didn't know it, I designed a system, turned around and said "look at this". And there it was, already implemented. Well, I am not planning on doing that, but I think LiquidThreads will be great. Arlen22 (talk) 18:56, 3 July 2010 (UTC)

Sorry, but I'd prefer we stick to the topic (barnstars) here, and continue the discussion about LiquidThreads up there. As a regular of WP's WikiProject Wikipedia Awards, I'm quite convinced that 80% of WP's awards don't fit in WB, and given the fact that most people who are involved in the community also do all kinds of maintenance work as well as work on their own books (this is completely different in WP. In WP, some people stick to maintenance work, some to content creation, and some to reverting vandalism.) Therefore, lots of barnstars don't really apply here. And our difference from WN is that we aren't in a great big rush. So really, one barnstar or award is sufficient for WB, IMHO. Kayau ( talk &#124; email &#124; contribs ) 01:31, 4 July 2010 (UTC)


 * I think since Wikibooks is book related that Wikibooks should follow the practice of giving out medals instead of barn stars. National Book Award Medal and John Newbery Medal to name two examples. --dark lama  02:38, 4 July 2010 (UTC)


 * I agree that medals are a lot better. That is why I brought it up here, because barnstars just didn't quite do it. What medals do we have so far? Arlen22 (talk) 02:56, 4 July 2010 (UTC)


 * The one image I mentioned above is the only thing I know of that Wikibooks has had. I have called it a Golden Wiki when I've used it before, which is a subtle reference to Golden Tickets from Charley And The Chocolate Factory. When I originally created that image, I was thinking a bit more broadly, for example looking at various awards presented and broadcast on television, and fictional awards. --dark lama  11:04, 4 July 2010 (UTC)


 * The name could use a tweak, since there's an award called the Golden W over at WP. Kayau ( talk &#124; email &#124; contribs ) 11:14, 4 July 2010 (UTC)


 * I don't see the need to tweak the name nor the issue involved with continuing to call it the Golden Wiki. --dark lama  11:28, 4 July 2010 (UTC)


 * Well, who wants to work on our first medal? Let's see what we come up with. We should also have a tireless medal (rotating) and an admin medal (with the broom and such). Arlen22 (talk) 11:53, 4 July 2010 (UTC)




 * Wikimedia Commons has some that are used by Wikipedia too that I wouldn't call barn stars exactly. The quality of some aren't so good though, and others are too Wikipedia specific because they include Wikipedia in the name or used the Wikipedia puzzle. I think some could be modified for use by Wikibooks, but I think they should be made more general/generic like saying "Wikimedia Medal" or "Wiki Medal" instead, so they can reused across all wikimedia projects or across all websites that use a wiki. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  13:12, 4 July 2010 (UTC)

If barnstars aren't "working out", please request deletion of Barnstars and Template:The Original Barnstar. – Adrignola talk 14:02, 4 July 2010 (UTC)
 * Yeah, ok. I won't be too quick to ask for deletion. Arlen22 (talk) 22:10, 4 July 2010 (UTC)



I'm proposing a new one. (Glad I borrowed that Inkscape book from the library.) Feel free to be bold and tweak it. (Note: If you think I was talking about the tweak tool of Inkscape, then consult a doctor immediately. :D) Kayau ( talk &#124; email &#124; contribs ) 13:51, 4 July 2010 (UTC)
 * Looks great. Now, do we need Gold, Silver, and Bronze? I doubt it. What medal shall it be first? Arlen22 (talk) 22:35, 4 July 2010 (UTC)


 * I don't like having silver, bronze, and gold. It seems to imply that a user receiving gold is superior to one receiving silver or bronze. The only place where the 'gold', 'silver' and 'bronze' may apply is when there is a fixed criterion (such as WP's DYK.) Kayau ( talk &#124; email &#124; contribs ) 06:19, 5 July 2010 (UTC)


 * Yeah, I know what you mean. Also, I thing the medal should look like a real gold medal, even if silver and bronze aren't usable, though that is just my opinion. Then we can make service awards with it and what not. Remember that all pictures have a history, and if someone likes an older version for somthing, they can use the older version. Give you a way to hone your Inkscape skills. Cheers, Arlen22 (talk) 14:26, 5 July 2010 (UTC)


 * The distribution of letters WIKI around the perimeter doesn't work for me (notwithstanding that as pure abstract art it's quite elegant). It took me some moments to come up with a theory as to what the letters were supposed to be doing, and further time to reach a substantial level of confidence in the theory.  However I try, I just can't see those letters as spelling WIKI; what always instantly leaps to my eye is two consecutive I's.  It might be a matter of regional variations in idioms for representing writing &mdash; one could imagine that words proceeding linearly around the perimeter a disk would be a more common idiom in purely alphabetic writing traditions.  Alternatively, it might be some subtle interaction with the direction of the lines in the graphic at the center.  (Alas, so far I don't have a specific constructive counter-proposal, which is exactly why I've been hesitating to comment on this.  What I really should do is get up to speed on Inkscape myself... as if there was any chance I'd find time for that this month.)  --Pi zero (talk) 14:43, 5 July 2010 (UTC)

I'd like to encourage people being motivated by this to learn Inkscape to contribute to Inkscape. Off topic I know, but felt it should be thrown in there. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  14:51, 5 July 2010 (UTC)


 * I'd be against any "barnstars" on Wikibooks. What's the use of them?  Do people really need a virtual award to encourage them to edit?  Seems like a waste of time just as it is on Wikipedia - just a way for people to show off.--ЗAНИA [[Image:Flag_of_Italy.svg|15px]]talk 21:29, 8 July 2010 (UTC)


 * Yes, in fact, many people aim for barnstars before they become serious editors, at WP. Kayau ( talk &#124; email &#124; contribs ) 09:08, 9 July 2010 (UTC)

Voting
I have a question. Do we need unanimous support or just a majority when voting on something? Just cast your vote, discussion is discouraged. I am trying to figure out what the majority thinks, not to decide on what to do.

The question is "Do we need unanimous support?" Vote in the appropriate section with #~ Arlen22 (talk) 00:31, 8 July 2010 (UTC)
 * Voting on voting. Cute.  But the question is flawed, because we don't vote. We determine consensus. Even when seeking consensus, not everyone will necessarily agree with the final determination, however. This thread will rub a sore spot with those not happy with the process above. – Adrignola talk 01:05, 8 July 2010 (UTC)
 * I, for my part, will do my best to stay in a good humor. Thenub314 (talk) 09:20, 8 July 2010 (UTC)

No

 * 1) Putting an entry here to create a paradox for those who might believe we need unanimous support to support unanimous support. – Adrignola talk 01:05, 8 July 2010 (UTC)
 * Lol, I'll second the first and will try to subvert the paradox into a unanimous objection. --Panic (talk) 01:15, 8 July 2010 (UTC)
 * 1) Well, I may as well join the unanimous group since I see your points. I finally get the point. Arlen22 (talk) 12:48, 8 July 2010 (UTC)
 * 2) Does this vote require a clear majority?  :) Voting has its disadvantages but it'd probably work better than this wiki consensus thing where those who shout the loudest or are more addicted to Wikibooks get their way.  Consensus on Wikibooks and Wikipedia is just another way to ensure that the "elite" can pass the policies that they want without having to bother with other people's thoughts.--ЗAНИA [[Image:Flag_of_Italy.svg|15px]]talk 21:33, 8 July 2010 (UTC)

Voting is evil

 * 1) Voting is evil. Imagine some dummy supporting a proposal through sockpuppetry or meatpuppetry. Or both. Even if there are 100 empty supports and only 3 opposes with detailed explanation, lots of valid points etc, the proposal should not pass. At least, IMHO it should not. Kayau ( talk &#124; email &#124; contribs ) 06:11, 8 July 2010 (UTC)
 * 2) Kayau's wisdom exceeds his age, as usual. I don't think I could have explained it better myself.  The concept of voting encourages various puppeting problems and inappropriate canvasing, and is discouraged by our guidelines. And my question would be unanimous support for what? I don't think I have been part of one vote here that has had unanimous support for anything.  Though I am sure someone will correct me.  Thenub314 (talk) 09:20, 8 July 2010 (UTC)
 * 3) Unanimity and consensus aren't the same but can coexist, I presume consensus was select for the decision model because it is the only process that reduces the issue of the active minority, since the majority of the community will always remain in silence due to the volatility of the participation. The distinction is that unanimity requires all to state support, and consensus only requires that no one states objection, the implication on the requirements of participation in decisions becomes obvious, and why consensus is optimal for our volunteering setup. We can with great confidence state that a unanimous community decision is an impossibility and that every time community consensus is reached it will never reflect all the community, but permits giving special power to supposedly minority views in the form of a block. --Panic (talk) 18:16, 8 July 2010 (UTC)
 * Pi zero's RFA on RFP. Xerol Oplan (talk) 21:18, 8 July 2010 (UTC) (UTC)
 * Ha HA! You've done it, I knew someone would contradict me and find a unanimous vote I was part of. Well done Xerol. Thenub314 (talk) 22:16, 8 July 2010 (UTC)
 * Do you mean that there can be no objections? This is not the commonly used form of consensus used on Wikibooks. Usually consensus means that there are no overwhelmingly significant objections to something, and the objections that are there are not the majority. If there is one support vote and a whole bunch of objections with weak reasons, then it would be blocked, of course, even if no one had a significant reason for objection. But two-thirds is the key principle in most consensus on Wikibooks, not the two-thirds fraction, but the two-thirds principle. Arlen22 (talk) 18:28, 8 July 2010 (UTC)
 * I don't participate on Wikipedia, but what you describe without taking in account the arguments is a decision by majority (the active majority), it also deals with the level of regard given to the opposition and if the opposition is willing to be productive.
 * There can be blocking objections (objections that can't be accommodated in the discussion process). Since the system of decision is based on system of good reasons, by irrationality or without taking in consideration the responsibility of blocking a decision, that objection will lose value. If it doesn't gather more support or a compromise can't be reached, bypassing a block is extremely dangerous and all efforts should be made to avoid it. Consider a decision where only two participants interact, if consensus fails and a block continues to exist what is the outcome ? That is why a justifiable block should be respected and why numbers do count (in good faith a minority view has to consider that its position may be flawed since others don't agree with it). --Panic (talk) 18:42, 8 July 2010 (UTC)
 * Comment - Pi zero's RfA was not a voting. As there are no opposes, there are no against points to address, so Mike ended it after a significant amount of time, by snowballing. Kayau ( talk &#124; email &#124; contribs ) 09:25, 9 July 2010 (UTC)

A proposal about module names.
Someone mentioned to me recently that did not care for the phrase "module" in describing the units of a book here. I would like to propose we change this to "page". As one usually thinks of books as consisting of Pages, sections, chapters, etc it would be be IMO intuitively pleasing to call our basic units of a book by the phrase "pages". Thenub314 (talk) 15:23, 9 July 2010 (UTC)


 * It seems to me that "page" has a different and more general meaning. Consider Help:What is a module.  The term I've usually encountered, and used, for this is "content page".  --Pi zero (talk) 16:18, 9 July 2010 (UTC)


 * I think model was picked at the time because people felt works could be broken up into units smaller than a traditional paper page. I tend to think that isn't particularly important though. "Wikibooks is not paper" and all that. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  16:25, 9 July 2010 (UTC)


 * The only problem with module is that it seems interchangeable and self contained, for instance when moving pages from Wikibooks to Wikibooks some special considerations have to be taken as each Wikibooks is an independent work. I don't think I ever used the word "module" to define any type of page on Wikibooks. --Panic (talk) 16:41, 9 July 2010 (UTC)


 * I agree with Pi zero that page is not suitable for this purpose. Perhaps we can just leave things as they are. I don't think any confusion has arisen yet, but when it does arise we can deal with it then. Kayau ( talk &#124; email &#124; contribs ) 01:13, 10 July 2010 (UTC)


 * I'm not sure that Pi zero is saying that. He's said he's seen and used "content page", not "module".  My interpretation is that the statement is that "module" is not suitable for this purpose. I don't see anything wrong with changing it to "content page".  Take a look at this page, which has its tab labeled "project page". – Adrignola talk 01:58, 10 July 2010 (UTC)


 * "Content page" also has some ambiguity, anything wrong with "book page" ? --Panic (talk) 02:06, 10 July 2010 (UTC)
 * I've searched for "module" and only a few locations use the term, Help:What is a module, some categories and some policy, proposal/drafts texts that mostly have a link to Help:What is a module some exceptions are Be bold, Decision making guidelines, haven't checked them all. --Panic (talk) 02:14, 10 July 2010 (UTC)


 * Here's a rather miscellaneous example of what the term looks like in the field, so to speak; this is from Serial Programming/Serial Java:
 * This module discusses both JavaComm and RxTx.
 * Despite the fact that I'm not fond of "module", I admit that it works better in this sentence than any of the two-word choices we've mentioned.


 * My understanding of the meaning we're looking for &mdash;based, ironically, on my understanding of the word "module", because I find I can't actually confirm or deny this from Help:What is a module&mdash; is that these are the pages that contain the actual information content of a book, as opposed to the overhead pages such as contents, cover, print version, talk pages, and templates.


 * I'd like to find a term that works better than "module"; but the further into this we get, the more unsure I am that we're going to find a term that works better. Another one that I don't like: "article", which suggests too little continuity between content pages, as at Wikipedia or Wikinews.  (Oddly, "aritcle" is used once on Help:What is a module.)  [Correction: it's used several times there, apparently in the technical sense borrowed from magic words such as  .]


 * I may consult thesauri, next. (Not tonight, though.)  --Pi zero (talk) 03:13, 10 July 2010 (UTC)


 * I don't think a single word can substitute to convey what is indeed a qualifier of a broader word "page", we could do well with the word page if we weren't in a WEB environment, this creates layers of second meaning that can't be addressed without a qualifier, books are made of pages creating artifacts or abstractions like "modules" and others (for instance in the books I work I often mention "sections" when providing a link to the middle of a chapter).
 * A "module" implies modularity, that components may be separated and recombined, this doesn't reflect our "content pages", in that regard a Wikibook is a module of Wikibooks.
 * Regarding "articles" at Wikipedia I don't see an issue, I get the meaning that it refers to an "encyclopedic article", not all Wikipedia "content pages" are "articles", they can be biographies. As for Wikinews I don't know I rarely been there but I think there "article" refers to "news article", in any case I accept that the projects put the "article" reference in the right context. But here "page" would continue to be ambiguous because of the WEB involvement. --Panic (talk) 03:42, 10 July 2010 (UTC)

It may be worthwhile to note that it may be a moot issue, in that the book pages are called "page" in the tab under the Vector skin. – Adrignola talk 16:49, 15 July 2010 (UTC)


 * I have trouble keeping the names straight, is vector the "new look" that has been advertised for a while now? Thenub314 (talk) 17:09, 15 July 2010 (UTC)


 * Yes it is. Assuming you've done nothing else, you're currently using Monobook.  By the end of this month, the Wikimedia Foundation will make the default Vector for logged-out users, which is what you see at Commons/Wikipedia, and also change the selected skin of logged-in users (though you can always change it back at Special:Preferences).
 * Actually, the mainspace tab name in vector is based at MediaWiki:Vector-namespace-main. It is currently set to "Page", but it is completely modifiable. --Yair rand (talk) 22:48, 15 July 2010 (UTC)

Software Books and software versions, Part 2

 * This discussion has been moved to Projects due to general acceptance. Xerol Oplan (talk) 10:36, 16 July 2010 (UTC)

Enforcing that our reading rooms are not reference desks
What about an editnotice to inform newbies that our readings rooms are not reference desks, as well as a friendly template to put in their talk pages and direct them to WP's reference desk? Thanks Kayau ( talk &#124; email &#124; contribs ) 11:45, 24 June 2010 (UTC)

Hello? Anyone interested? Kayau ( talk &#124; email &#124; contribs ) 12:23, 30 June 2010 (UTC)
 * It's like pulling teeth to get any participation, isn't it? It'd have to be linked with the "post a comment" button link.  We don't have the automatic edit notices that Wikipedia has.  If you put forth a statement you think would work and it sounds good, we can go ahead and link it from the button link. – Adrignola talk 14:09, 30 June 2010 (UTC)


 * Hey! There are quite a few very lengthy conversations going on at the moment. Keeping up with them takes some effort. I don't think (in this reading room) we are really pulling teeth to get participation :).  Anyways I am not a fan of wikipedia's reference desk and don't find it particularly appropriate that we advertise them.  The type of edits where people ask inappropriate questions happen rarely enough that it is not much work to undo them and point the people in the right direction by hand. Not to mention it gives the wikibooks a lot more personal touch. Thenub314 (talk) 15:24, 30 June 2010 (UTC)


 * Sorry Thenub, but I suspect that's a case of w:WP:IDL. *shrug*. Also, what does pulling teeth mean? Kayau ( talk &#124; email &#124; contribs ) 13:15, 1 July 2010 (UTC)
 * "To do something that is especially difficult or effortful." I suppose another argument might be if Wikipedia's Reference Desk is advertised why stop there? Add Wikiversity's Help desk, and any other similar pages that other projects might have. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  13:28, 1 July 2010 (UTC)
 * Dunno, but I think WV's help desk is a bit less popular... Kayau ( talk &#124; email &#124; contribs ) 14:39, 1 July 2010 (UTC)
 * Anyway, whether we promote RD or not, we should add that our reading rooms are not general reference desks and asking knowledge questions are not allowed here. Kayau ( talk &#124; email &#124; contribs ) 11:39, 17 July 2010 (UTC)
 * I think it would be helpful to have some kind of RD just to direct people at books on particular subjects. Even with all the various filing systems we're using, it might just be better to point people at particular books if they're looking for a particular subject - sort of like a real library. Xerol Oplan (talk) 11:42, 17 July 2010 (UTC)

Template:User book
I've created a template that takes as its one, unnamed parameter the title of any book, and produced a userbox &mdash;customizable on a per-book basis&mdash; like this:

It also adds the user to a category.

My idea is that if we could manage to nurture a widespread habit at Wikibooks of declaring interest in the books one contributes to, that would help users to recognize each others' interests, and help to promote local- and even intermediate-level community interaction. There are a bunch of unanswered questions about this, ranging from nuts and bolts to broad community organization. Some that come to mind: BTW, with reference to a remark Kayau made on an earlier thread about the number of discussions here &mdash; that may be an advantage of this name for a reading room, that it encourages more discussion of what to do to improve things, which is great. --Pi zero (talk) 21:29, 19 July 2010 (UTC)
 * Right now, the category it generates is   , such as     .  I was thinking of wiring BookCat so that it would make these categories subcategories of the book categories (similarly to what it now does for book-specific template categories), but I'm not really sure whether I've chosen the right name for the categories, nor whether they should belong to the book categories.
 * I'd like to generalize the facility to handle units larger than a single book, and to handle Cookbook in some useful way; but I really haven't got a clue how best to go about it. To start with, what units (other than books) does one want to be able to specify?
 * Once we've got the template the way we like it, what can we do to encourage people to use it, so that over time it comes to be widespread enough to get a network effect going?


 * I'd prefer the adding people to the book's category, say, of the form <tt>Book/Users</tt>. The base category above, <tt>Category:User book</tt> doesn't really represent what would be contained inside it.  It sounds like an alternative to Category:Collections for breaking out books saved in a user's space.  I don't know if it'd be simpler to use a system like subject box where settings can be specified as a subpages of the parent template and then all they have to do it specify a parameter when using.  That's also how user language and programming language work. – Adrignola talk 21:38, 19 July 2010 (UTC)


 * Typo on my part: it's .  (I corrected it above.)  I'm not sure whether you'd think that answers your criticism, though.  If we go with , then there will have to be a means provided to override that choice of category name on a per-book basis (which should be technically possible, I think), so that if we ever do have a book with deep filing and a section called Users, there will be a way of dealing with it already in place.  --Pi zero (talk) 22:15, 19 July 2010 (UTC)


 * I also prefer Adrignola's version. Kayau ( talk &#124; email &#124; contribs ) 07:07, 20 July 2010 (UTC)


 * I've rewired the code to generate category, with a mechanism to override that with some other category name on a per-book basis.  --Pi zero (talk) 19:18, 20 July 2010 (UTC)

Renaming Renaming
Would anyone have a dire objection to mmoving Reading room/Administrative Assistance/Renaming to Reading room/Renaming? It'd be to shorten the names of the archive listing when using PrefixIndex. – Adrignola talk 02:58, 17 July 2010 (UTC)


 * Go ahead, JFII, nothing wrong with that (as opposed to widening the scopr of feature requests page and moving general discussions to the new proposals page, because this time it's just a move.) Kayau ( talk &#124; email &#124; contribs ) 11:38, 17 July 2010 (UTC)


 * I'll just ask, since the question is coming up, whether we'd want to call it, since without the word on the end it would be the only one of the assistance reading rooms without the word "assistance" in its title. It would still be shorter than it is now, and have fewer slashes in it.  --Pi zero (talk) 11:48, 17 July 2010 (UTC)


 * Might be even better to have all the pages as RR/Assistance/___ with RR/Assistance describing all of the subpages to direct users to the right place. Could even be linked from the sidebar as "Get help" or similar. Xerol Oplan (talk) 12:35, 17 July 2010 (UTC)


 * That would seem to be more involved. It was even proposed to not have a general assistance room.  So now we have three potential destinations, other than its current location.  Anyone else care to provide input?  —The preceding unsigned comment was added by Adrignola (talk • contribs) 19:22, 18 July 2010  (UTC)


 * There are only 2 implications in the change, the navigational one (since this isn't a book a navigational aid can easily fix that) the other one it the logic organization, since renames is an administrative action it should be related to the administrative Assistance in some way, I don't know today what the movement is on the rename page, do we need a special page for that ?
 * I understood the split of the previous structure, now we are adding the proposals page, we should make an effort to keep the number low and the structure stable, alterations are highly disruptive in this types of pages, a user that is absent should come back and have the expectation of this pages showing on the watch-list. I don't have a special opinion on the subject, just that this pages should be few and stable. --Panic (talk) 20:23, 18 July 2010 (UTC)


 * It's my understanding that when a page one someone's watchlist is moved, the old and new names both end up on their watchlist. If I'm right about that, not only does it mean that renaming needn't cause watchlist problems, but it also means that a split could be arranged not to cause watchlist problems either:  When splitting page A into pages A and B, first move A to B (so putting both onto the watchlist of anyone who had been watching A), and then split some of the content from B back to A.  Alternatively, if the split was originally done by cut-and-paste from A to B, after the fact one could move B to C, move A to B (deleting a redirect to make room), then move B to A, and move C to B (deleting a redirect to make room).  Which should leave A and B both on the watchlists of anyone who was watching A or B before.  --Pi zero (talk) 21:51, 18 July 2010 (UTC)


 * If so than the problem is reduced (but does not cover splitting pages). I would like someone that knows to confirm that? and if that was always so? My understanding was different (mostly on editing a book I sometimes find pages that I don't have a watch and I original was the creator), this is especially annoying to me because of the different talk pages. I was going to perform a test but since I can't clean up after myself, any info would be appreciated. --Panic (talk) 22:04, 18 July 2010 (UTC)

I've been watching all the reading rooms. If I go to view and edit my watchlist in Special:Watchlist, I have the Proposals reading room and its old location at Feature requests on my watchlist. – Adrignola talk 22:13, 18 July 2010 (UTC)


 * That was expected since you where the one that performed the split and no other move occurred (note that it depends on the default setting on page creation or the intentional action to start monitoring the new page). What Pi zero said is that after a page move all Wikibookians watching the original page will get the new page added to the watch-list (the A and B example above). --Panic (talk) 22:17, 18 July 2010 (UTC)


 * In my experience what Pi zero said about the watchlist is true, and has been for many years. Is that the confirmation you are after? If you want pages you edit or create to be automatically added to your watchlist by default you need to look at your watchlist preferences. There are preferences of the form "Add pages I (edit|move|create|review) to my watchlist". --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  23:18, 18 July 2010 (UTC)


 * I've also just confirmed it by experiment, using Pi zero and another (legacy) account that has no privileges beyond autoconfirmation. As Pi zero I created User:Pi zero/A, and put that on the watchlist of the other account.  Then as Pi zero I moved User:Pi zero/A to User:Pi zero/B, and that resulted in both pages being on the watchlist of the other account.  I tried a few variations on the test, and got the same result each time:  the watching account ended up watching both the old name and the new name.


 * As I remarked earlier, this can be used to split a page into two in such a way that anyone who had been watching the original page will end up watching both pages after the split. We could, for example, use this technique to add the new Proposals reading room to the watchlist of anyone who is now watching the General reading room but wasn't watching Feature requests.  (Once we've done it, though, there's no way for us to undo the additions to people's watchlists.)  --Pi zero (talk) 23:28, 18 July 2010 (UTC)


 * Well, this enables further possibilities should anyone be so brave as to put them forward. It certainly means that Xerol's idea wouldn't be a problem for people watching the pages.  I don't know that anyone should worry too much about this room; only two people really need to watch it. I'm tempted to go with Pi zero's suggestion, as it won't involve renaming a ton of subpages in the form of archives and would leave other rooms alone. – Adrignola talk 21:11, 20 July 2010 (UTC)


 * It's occurred to me that the way the page is used and structured, it belongs more with the requests pages than the assistance pages. Therefore, I'm thinking now that "Wikibooks:Requests for rename" or "Wikibooks:Requests for renaming" would be more appropriate.  The former matches up with the verb in "Requests for import" while the latter matches up with the current name's verb.  Which sounds better? – Adrignola talk 12:42, 22 July 2010 (UTC)


 * I think it works better as "renaming" (rather than "rename"). (RFI is fine as-is, since "import" is routinely used as a noun.)  --Pi zero (talk) 14:44, 22 July 2010 (UTC)
 * I completely agree with Pi zero. Kayau ( talk &#124; email &#124; contribs ) 13:48, 23 July 2010 (UTC)

Reconfigure Wikibooks
The MediaWiki:Revreview-editnotice interface text is shown to non-editors trying to edit pages with reviewed revisions and lends credence to those worried that the system discourages participation. The call to remove the [unreviewed] markers in recent changes in the technical assistance reading room was just a symptom of the larger problem&mdash;only 21% of main space pages are reviewed according to Special:ValidationStatistics.

In the same page linked above for the technical reading room, Jomegat suggests only three levels, including unreviewed. That makes sense to me. Visit http://en.labs.wikimedia.org to see what it could look like (with an old database of our content, even).

Editors would see: File:Wikibooks editor.png

Reviewers would see: File:Wikibooks reviewer.png

Examining our configuration, we should remove <tt>$wgFlaggedRevValues = 4;</tt>, change to <tt>$wgFlaggedRevTags = array('quality' => 2);</tt> and change to <tt>$wgFlagRestrictions = array('quality' => array('review' => 1, 'autoreview' => 1) );</tt>, This would give us what you see at labs, but with "quality" instead of "accuracy". The labels "sighted" and "good" are able to be modified by the MediaWiki namespace interface text. Additionally, we're migrating files to Commons, so there's no need for it to remain on for that namespace. In fact, I'd propose only having it on for Wikijunior with <tt>$wgFlaggedRevsNamespaces = array(110);</tt>. I also suggest <tt>$wgFlaggedRevsComments = false;</tt> to remove the comment box as I don't believe anyone takes the time to add in a comment when they sight. Additionally, I should note that though<tt>$wgFlaggedRevTabs = false;</tt>, I still see the "latest draft" tab on an outdated page. Finally, to correctly implement autopromotion regardless of namespaces applied, <tt>$wgContentNamespaces = 0, 102, 110;</tt> should be set to have edits to the Cookbook and especially Wikijunior count.

The CSS coloring the boxes wouldn't be needed because we'd be using a check box/radio buttons. The CSS hiding [unreviewed] wouldn't be needed because it'd only be Wikijunior pages showing it until reviewed. Main space pages would revert to patrolling using the same ! that we've seen already. And flagged revisions wouldn't be pointed to as a reason for declining participation and wouldn't be a cause of it.

I've revised the above since first posting. – Adrignola talk 15:29, 26 June 2010 (UTC)


 * My experiments so far have not confirmed your claim that that notice is displayed when a non-editor is logged in. If I'm not logged in at all and edit a sighted page, I do see that notice plus the warning that I'm not logged in; but if I edit the same page while logged in on an account without the edit bit, I don't see the notice.  Under what circumstances do you claim I would see the notice?  --Pi zero (talk) 03:40, 26 June 2010 (UTC)


 * This is one techy proposal, though looking at the summary, I think it has my support. Pi zero, I have seen this message while testing on flaggedrevs.labs.wikimedia.org. Kayau ( talk &#124; email &#124; contribs ) 05:12, 26 June 2010 (UTC)


 * I tested this editing logged-out. By definition an unregistered user would be a non-editor.  An autoconfirmed user doesn't get any additional rights beyond an unregistered one with respect to flagged revisions. – Adrignola talk 12:13, 26 June 2010 (UTC)

I've said before that $wgContentNamespaces needed to be changed to include the Cookbook and Wikijunior, so I agree there. I can also agree with one criteria "quality". I can also agree with turning commenting off. However I think editors should still be able to continue to rate all levels as before, otherwise more work is placed on Reviewers. I also think we should continue to have autoreview turned off because that was a source of problems before. I also think that flaggedrevs should continue to be done for the main, cookbook, and wikijunior namespaces. We should try to see if simplifying the criteria to "quality" is enough first before talking about removing it from the main and cookbook namespaces.

I would also like to propose $wgFlaggedRevsLowProfile = true; if its not already set. I would also like to propose as part of these changes that we enable the ReaderFeedback Extension like English Wikinews has and have $wgFeedbackNamespaces set to the main, cookbook, and wikijunior namespaces too. My rational is to see whether more pages will be rated if anyone can do so, and if the information it provides would be more useful overall than flaggedrevs for contributors, and what is learned from that might help future proposed changes to flaggerevs.

So what do you say? --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  08:59, 26 June 2010 (UTC)


 * Sorry, but what is that in plain English? What will be the changes? I don't know a thing about this posh MediaWiki code thingies... Kayau ( talk &#124; email &#124; contribs ) 10:49, 26 June 2010 (UTC)


 * Flagged revisions continue to be on for the same namespaces.
 * Three levels other than unreviewed. Editors can mark revisions as acceptable, good, and excellent. No need for reviewers.
 * No comment box
 * Include Cookbook/Wikijunior in autopromote to editor
 * Make flagged revisions keep a low profile
 * Use ReaderFeedback Extension so readers can provide additional feedback for pages in the main, cookbook, and wikijunior namespaces.
 * Is that better? --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  12:09, 26 June 2010 (UTC)


 * I thought of using <tt>$wgFlaggedRevsLowProfile = true;</tt> but that makes the review box disappear for reviewed pages, which will keep reviewers from rating the page to a higher level if it's been rated to a lower level by an editor. I don't know why you say editors should be able to continue to rate all levels; they currently can't rate to the highest level, which we've termed "featured quality". Only reviewers can rate to that.  Most editors just hit the "submit" button to sight a page and so the two levels above the base level go unused.  The highest level for reviewers-only allows highly visible pages to be changed to show the highest level to logged-out users rather than any level, and to have admins/reviewers examine the page.  Otherwise anyone autopromoted to editor can rate to that highest level.   And since November 14, 2008*, we only have 1/5 of the main pages sighted (compare to 99% for 1mil+ pages at German Wikpedia ), leaving the other 80% to standard page patrol.  Simplifying the criteria to "quality" with two levels makes it more convenient for people using the system, where it's used, but it appears to me that it's not caught on for the main space.  If you want to keep it for the Wikijunior, Cookbook, and even templates, I'm okay with that. I'd like to keep reader feedback as a separate issue, at this time. – Adrignola talk 12:13, 26 June 2010 (UTC)


 * Well if keeping a low profile is a problem, I can agree not to do that than. I mean editors should continue to be able to rate all the levels they could before. I guess we could give editors two choices besides unreviewed: acceptable and good, and let reviewers have the third choice excellent, but the idea is to remove the need to have both editors and reviewers. I wish we could autopromote people to reviewers instead and get rid of the idea of editors since people confuse the two anyways. FlaggedRevs was suppose to be opt-in for each book after the last time we made changes, and I think we need to do a better job of that being the case by discouraging people from sighting revisions in a book unless they want both the benefits and hassles that come with using FlaggedRevs. There is no reason or need to go overboard with sighting revisions for all pages in all books. Even when regular patrol was used people didn't stay on top of it and it was mostly an ignored feature. I see no issue with ignoring FlaggedRevs too except when its wanted for individual books. I think we need to have reader feedback as part of this issue, because it can compliment FlaggedRevs and perhaps help us find a middle ground for reviews and gaining the feedback that people are after. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark  lama  12:37, 26 June 2010 (UTC)


 * In all truth, I didn't expect a lot of support for turning it off for main space (though you're the only objector at this stage). But I'd want it turned off for files, since they're being exported.  If you look at Wikipedia's configuration, they remove the editors group and only have reviewers.  But could we set it for autopromotion on reviewers?  Or maybe we should turn off <tt>reviewers</tt> and assign their permissions to <tt>editors</tt>, then rename "editors" in the interface to "reviewers". We also need to set $wgFlaggedRevTags such that the top level is "pristine", the second-from-top is "quality", and leaving the base as "sighted" if we use three levels rather than two beyond unreviewed. For others looking to decipher this, see mw:Extension:FlaggedRevs and . – Adrignola talk 13:25, 26 June 2010 (UTC)


 * Turn off for files? Maybe I'm missing something.  The single biggest vulnerability of Wikijunior to vandalism is that it's got lots of images in it that aren't local and therefore aren't subject to flaggedrevs.  I've suggested before, and have been mulling over suggesting again, that we make local copies of all images on Wikijunior, just so we can review them all and have them covered by flaggedrevs.


 * BTW, nobody has answered my question as to under what circumstances that notice appears, that you started by objecting to. That seems to me to matter a lot, because as far as I can see it would be trivially easy to simply suppress the message &mdash;just one example of simple measures that could be taken to completely eradicate various drawbacks of flaggedrevs&mdash; but I wouldn't want to suppress it without knowing what situations would be affected by the suppression.  --Pi zero (talk) 13:39, 26 June 2010 (UTC)


 * I wonder how or even if flaggedrevs works for files from Wikimedia Commons. If it works like locally uploaded files, I think it should continue to apply to the Files namespace too. If it work differently from locally uploaded files, I wonder what the difference(s) is/are. If files from Wikimedia Commons are ignored than there really is no point to keeping it enabled for the Files namespace. Another possible consideration is if is Wikimedia Commons has or plans to use flaggedrevs for their files and if so would sight revisions of files be used across projects over unsighted revisions? I think having some answers would allow us to make better decisions for the files namespace. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  14:23, 26 June 2010 (UTC)


 * Assigning reviewer permissions to the editor flag and renaming editor in the interface to reviewer sounds like it could work. I also like the sound of being able to keep the three meaningful levels that flagedrevs has sighted, quality and pristine which is why I suggested three levels to begin with. Only since we are dealing with "quality" as a rating criteria they would refer to acceptable quality, good quality, and excellent quality respectively. Although maybe average quality might make more sense than acceptable quality. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  14:52, 26 June 2010 (UTC)


 * Wikinews found they were only using the editor bit, and they thought calling it "editor" was confusing anyway, so they renamed "reviewer" to "super-reviewer", renamed "editor" to "reviewer", and then deprecated super-reviewer. How does this suggestion compare/contrast to that?  --Pi zero (talk) 15:06, 26 June 2010 (UTC)


 * Sounds like we would be doing the same thing as Wikinews, while skipping some steps to get there. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  15:10, 26 June 2010 (UTC)

Page sighting
I seem to recall being told in some earlier discussion that admins can switch between showing the most recent sighted version and showing the most recent version whether it's sighted or not. Is that correct (and if so, what's the handle for it &mdash; and is it per page or per book)? The reason I'm asking now is that this seems to me to be a possible key element for counter-proposals. --Pi zero (talk) 14:45, 26 June 2010 (UTC)
 * Yes that is correct, that is changeable per page because like most extensions it wasn't designed with books in mind. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  14:57, 26 June 2010 (UTC)
 * If we could have anything we wanted, it seems to me we would want the default behavior to be that on Wikijunior, files, and templates, the most recent sighted version is shown, while on mainspace and cookbook the most recent version is shown regardless of whether it's sighted. Assuming we can't have that, the next best choice would seem to be that the most recent version is shown by default, and we manually set all the Wikijunior pages to show the most recent sighted version (a largish job, but nothing compared to the other way around that would require manually reconfiguring every page on mainspace and cookbook).  Indeed, once that was in place we might want to turn back on $wgFlaggedRevsAutoReviewNew.  --Pi zero (talk) 16:48, 26 June 2010 (UTC)
 * At least for the latter, <tt>$wgFlaggedRevsOverride = false</tt> would be the option to use. – Adrignola talk 17:19, 26 June 2010 (UTC)

Auto review
I'm curious about a recent addition Darklama added. You want to turn off autoreview for sysops but not anyone else? Why would feedback be enabled for templates? Why are editors getting rollback? Also, removing <tt>validate</tt> from sysops means they won't be able to review at the top level, or so I was led to believe. – Adrignola talk 18:13, 26 June 2010 (UTC)
 * I thought autoreview would be turned off already for everyone else. Templates are used on pages, feedback on their usefulness could be useful. I noticed that often if someone makes a request for the editor flag they also often ask for rollback, and Wikinews give rollback to editors, since we are cutting steps I thought it would be a good idea to do that here as well. Wikinews doesn't have validate on for its configuration and the only proposed difference between us and them is what we want to call this one criteria. I think:
 * $wgFlagRestrictions = array( 'quality' => array('review' => 2, 'autoreview' => 2), );
 * $wgGroupPermissions['sysop']['review'] = true;
 * makes the top level accessible to sysops. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  18:52, 26 June 2010 (UTC)
 * If I edit a sighted revision I want my edit to be sighted too, automatically. Wikinews specifically wanted that off for editors/reviewers and sysops to have others sight the edit as part of some double-check; we don't have the manpower for that. – Adrignola talk 19:03, 26 June 2010 (UTC)
 * Without validate, you can't limit the top level to sysops. Without review added to sysops, admins will not be automatically reviewers; they will have to specifically members of that group.  The FlagRestrictions will depend on the levels and whether any is limited to a group with "validate". – Adrignola talk 19:15, 26 June 2010 (UTC)
 * Fine, so add validate back. Been over this point before and the need for separate privileges continues to make no sense to me. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  19:26, 26 June 2010 (UTC)

It's not essential, but if we don't use it, then we don't need FlagRestrictions, only FlagRevTags. And if we don't restrict the top level, then we probably don't need so many review levels. After all, how many people will then care if it's at excellent versus good if you can't change the settings to show excellent, then good. It'd just be limited to showing most recent (default with above code) or stable (changed by admins for Wikijunior). – Adrignola talk 19:36, 26 June 2010 (UTC)

Content Namespaces
What became of the <tt>$wgContentNamespaces = NS_MAIN, 102, 110;</tt>  suggestion? It was in the original proposal, I see darklama expressed approval of it... and I don't see it in the current draft. Did it get lost in the shuffle? --Pi zero (talk) 20:07, 26 June 2010 (UTC)
 * Looks that way. I added it. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  20:15, 26 June 2010 (UTC)

Files
Broadly I'm happy with the current proposal. On the file namespace, it might be useful to have FlaggedRevs on as I have, for example, used it to indicate for FU images that the rationale had been checked and was complete. We will always have some files hosted here. Don't turn it off for the Cookbook, not after I spent two months reviewing the whole thing ;-) <font color="#E66C2C">QU <font color="#306754">TalkQu 21:11, 26 June 2010 (UTC)


 * I didn't add that line to the box because it will go into another configuration file other than the one linked above. But we can have it there as a reminder.  Along that line, I suggest that feedback namespaces match up with content namespaces.  Templates aren't supposed to be seen directly, so readers shouldn't be visiting them to provide feedback.  Additionally, how would one rate a template on reliability, completeness, neutrality, and presentation... – Adrignola talk 21:38, 26 June 2010 (UTC)
 * I think you meant this as a rhetorical question, but I decided I would answer anyways. A template is reliable if it works as documented. A template is complete if people feel there is no missing functionality. A template is neutral if it can be used in many contexts. A template's presentation can be judged many ways like is the style good, is the appearance pleasing to the eyes, does the template convey its information in a meaningful and useful way? --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  21:58, 26 June 2010 (UTC)
 * That's an interesting analysis, but it seems to me that the templates that would have enough content to possibly be non-neutral are likely going to be book-specific anyways, and the ones that don't have enough content to be anything but neutral are going to be as interesting as, say, BookCat.

Problems switching to single criteria
A thought occurred to me just now, however, in that we should maybe use <tt>accuracy</tt> for <tt>$wgFlaggedRevTags</tt> internally and change the display of it in the interface to "quality", as I'm worried that if we change all the internal values all the currently sighted pages will be reset to unsighted. – Adrignola talk 22:25, 26 June 2010 (UTC)


 * They would likely need to be reset anyways going from 3 criteria to 1. Which might be one consideration against switching from 3 to 1. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  23:12, 26 June 2010 (UTC)


 * The two removed would just leave additional values in the database that would no longer be used. I think going to one criterion, with the internal label of that the same as one of the criteria used before, will work out. And that should change it to radio buttons instead of drop down menus. – Adrignola talk 23:30, 26 June 2010 (UTC)


 * Depends on how the values are stored in the database. The result could correspond to composition rather than accuracy, if order matter. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  23:37, 26 June 2010 (UTC)


 * Checking out the review log for manual reviews, it would appear that the majority of them are using the default values selected in the drop-down menus; that is, the lowest rating that reviews the page. In other cases where the rating is higher, all the menus are set to the same numerical value. Thus whether the value that gets assigned to quality had been originally assigned to accuracy, composition, or coverage ought to not matter in the vast majority of cases. – Adrignola talk 23:48, 26 June 2010 (UTC)


 * If order is what determines it and not the name, than we should be fine using "quality" internally. I guess we should look into the table structure for flaggedrevs. It might also be possible to reassign them to quality if its by name. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  23:55, 26 June 2010 (UTC)
 * Looking at the SQL, looks like it stores tag:value pairs. Which means for any given revision there might be "composition:1\naccuracy:1\ncoverage:1\n". I think a SQL command could be created and ran to replace all occurrences with "quality:#". --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  00:08, 27 June 2010 (UTC)

Test Trial
I've been flowing this discussion and as expected and as I always claim in this topic. Things are being done in reverse. The flagged revision was (and still is) a test trial, that was what was proposed and adopted, it has been continuously tweaked with or without consensus especially in the first months. It has failed satisfy all the requirements it was meant to address (except the reduction of vandalism) and even the proponent of the test of system has expressed the wish to see it terminated.

The experience I have on the subject is as a user and is commonsense, the more complex or nonstanrd a system is, the less I want to use it. Unless I'm obligated or get a sufficient reward for going trough all the loops and the learning curve. In a volunteering basis this seems simple enough to be categorized as a barrier for participation.

Empirically I also noted a decrease in contributions especially from unregistered users and a reduction of vandalism (bear in mind that vandalism edits have always been low and under control here).

The system adoption has also some added controversy. Most of the defendants of the new system are the ones that are directly benefiting from it. If a real benefit exists. Consistent editors and mostly users in administrative tasks, are in general terms a minority of the community, but the active majority.

With the system on, consistent editors get a level of power over revisions this is especially interesting to people dedicated to a specific tasks but it also alienates newcomers. Another clearly obvious issue is that the system is not designed for our (project) it was designed for Wikipedia (this has several implications and consideration some of the changes needed were already covered before and Darklama enumerated very interesting concepts on that regard). There are other implications, even the recent decline in administrators can be correlated with the evaporation of the page patrol system, as most of the admins did came from Wikibookians participating on those types of tasks...

In regards to the proposed changes I wish that any change, if to keep the "new" system, has a low impact and preserves the works already put into it (I did spend considerable time reviewing and categorizing pages). --Panic (talk) 01:29, 27 June 2010 (UTC)


 * You've stated this before, but after doing a thorough read of the talk on FlaggedRevs Extension and through reading room archives prior to the date of implementation, I cannot find anything saying it was temporary. From the amount of discussion, I might say it was implemented without much actual discussion, but I don't see anything on a trial period. – Adrignola talk 02:51, 27 June 2010 (UTC)


 * I think I might know what Panic is talking about. There was some discussion about the FlaggedRevs extension on IRC prior to discussion on wiki. Panic and I both voiced concerns about its use, and some other people suggested that the extension could always be disabled later if it turns out the extension isn't as useful as hoped. After that it was mostly just agreeing to have some initial configuration that could always be changed later too. I had also voiced the opinion on IRC that Wikibooks would be better off in the long run using something else. All that might be where Panic is coming from with the idea that the extension was meant to be a temporary setup maybe. However I refuse to get dragged into an argument on whether the idea of FlaggedRevs being temporary was ever the case or because of differences in interpretation of past events, anyone involved could of left that discussion with a different idea of what was to happen. In any case "temporary" is ambiguous and could be a long time for a wiki and with time new people can have different plans for something initially planned to be "temporary" and a new consensus can develop which has happened already several times with FlaggedRevs. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  04:08, 27 June 2010 (UTC)

Document Changes in English
I understand most of the stuff in the proposal, but not all of it... can someone translate that into plain English too? (I don't think I have the ability to read through this long discussion...) Kayau ( talk &#124; email &#124; contribs ) 02:13, 27 June 2010 (UTC)


 * I've added a summary in plain English just underneath the code that has been hammered out so far. – Adrignola talk 04:06, 27 June 2010 (UTC)

I've added additional configuration options for reader feedback; namely, to increase the length of time ratings of a page are valid for. The default is a week. That's too short for our level of activity, so I set it to 60 days. It could be increased further. I also decreased the threshold of reviews for an average rating to be determined, from 15 to 10. That could be decreased further. Both of these are not firm, but I don't believe the default values would be acceptable for Wikibooks. Also, we need to determine if the default to have anonymous users be able to rate is acceptable. Additionally, do we want the default rating options and how much weight do we give each of them? The default is <tt>$wgFeedbackTags = array('reliability' => 3,'completeness' => 2,'npov' => 2,'presentation' => 1);</tt>, with a higher number giving that criterion greater weight. Do we want fewer/different criteria or different weights? – Adrignola talk 04:41, 27 June 2010 (UTC)
 * Yes I think anonymous users should be able to rate pages, that is the whole point in enabling it most readers are going to be anonymous. Unlike FlaggedRevs, ReaderFeedback just provides information that lets contributors know how well they are doing, it doesn't effect what people are shown. I thought about proposing <tt>$wgFeedbackTags = array( 'quality' => 1 );</tt> but with tags being weighted I dunno what sort of effect a single tag would have on that extension. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  05:01, 27 June 2010 (UTC)

Other than these two I see no objection to the proposal. Kayau ( talk &#124; email &#124; contribs ) 08:04, 27 June 2010 (UTC)
 * I believe that 60 days is a bit short - most of our pages are not particularly popular. Extend that to 180?
 * I believe 10 reviews is a bit too high - perhaps 5?

I would like to have this clearly stated on the FlaggedRevs Extension, not as a policy or guideline but as the generally accepted and as the consistent practice. Since the flags (editor and reviewer) aren't really covered by any policy or any other text except from what is stated on the Requests for permissions since it will now include rollback ability a defined way to remove the flags must be provided in a stable text. --Panic (talk) 22:05, 29 June 2010 (UTC)
 * I'm not sure if you meant to oppose this proposal or not. The only interpretation that I was able to come up with in which you could of meant to oppose this proposal is along the lines of "Oppose because a policy isn't in place". I think rollback isn't defined anywhere in policy either. So why is a policy needed now? --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  22:17, 29 June 2010 (UTC)
 * I'm supporting my interpretation of the issues Thenub314 raised, and expressed my requirements to have the opposition removed. I don't see an issue on not having rollback clarified since abuse of the tool will be categorized as vandalism. On the other hand I see as a need to have an agreement on what consists non compliance with the quality of the revision system (by editors and reviewers) and what would constitute acceptable grounds for removal of the flags to preserve the value of the system.
 * Thenub314: Did I understood correctly the core of your objections ? --Panic (talk) 22:30, 29 June 2010 (UTC)
 * Undo and saving a previous revision could also be abused, but there is no policy on that either nor for that matter a 3RR. There is even a script somewhere that provides the same functionality as rollback that anyone that can edit could use. There is nothing special about rollback. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  22:38, 29 June 2010 (UTC)
 * And both of us have suffered by not having a consistent and established practice in respecting the 3RR (edit conflict), this has somehow been addressed when and how the BeBold was approved and the recent adherence and respect conservationism ("blocking" in decision processes) has been gathering. In any case the request I make to come to a written understanding (without being a policy or a guideline) in this respect doesn't seem problematic and will save further debates, establish the responsibilities and requirements. Without them and as implied by Thenub314 (on the comments above) the flag system will effectively cease to have any purpose. --Panic (talk) 22:50, 29 June 2010 (UTC)
 * Can you move these comments to the discussion section above? You're making the opposition side look overweight.  Please also see Wikibooks:Rollback. – Adrignola talk 23:44, 29 June 2010 (UTC)
 * I've moved my comments but in this thread since the reply to my position is from Darklama the decision should be his. No objection here.--Panic (talk) 00:23, 30 June 2010 (UTC)

I have now satisfied my reason to object to the proposal (lack of clarity) with the help of Adrignola. The page FlaggedRevs Extension/Unstable makes it now intelligible and attempts to remove any required technical background by restating the proposal as defined in [ rev 1868918] (as indicated in the majority of the supporting votes). My neutral position is because I'm not comfortable with two aspects. Granting admins the exclusive right to decide what constitutes excellent/feature material (putting the classification under a personal decision), I would support it if the use of that upper qualification was based on an open decision process. And second, the freedom granted to them regarding filters (it has also other implications since automation will put stress on other practices like user blocks for instance). I fear that without proper scrutinizing the changes, there will be errors made, able to have serious impact on the project, it also depends on how quickly we notice them and how we chose to resolve them. Overall the proposal is an improvement on what we have now, it democratizes some processes, removes redundancy and seemingly all barriers to participation I've lamented about. There will be need for corrections later on but at present I've nothing to object. --Panic (talk) 00:53, 3 July 2010 (UTC)

KISS
I am joining this conversation a bit late unfortunately. For what it is worth I am strongly in favor of removing Flagged Revisions on main space pages, in my experience it causes more problems then it is worth and is alienating to new editors. I suspect they see Flagged Revisions as a type of approval of their edits, (see this comment for example) and since so few people actively review things they never receive any sense of approval. Whether or not this causes them to leave I do not know, but in the case of this comment that expression of frustration was the last edit he made here. Also in my recent attempts to shorten the old reviewed pages, it is clear that pages that get marked as sighted are not always read, just scanned for any obvious vandalism, no present then accept. This seems to me the wrong tool for this job.

It should be kept on wikijuinor, and a lot of work as gone into the cookbook which shouldn't be wasted.

I also don't like new pages to be reviewed by default. I have in the past only noticed it later and then had to spend time unreviewing pages, which is annoying. So I would like to see the default to have new pages be unsighted.

I will think a bit more about reader feedback. But I think it goes against Kayau's KISS philosophy, and I am worried that it will further push away editors. I worry that, rather than encouraging readers to fix problems themselves, they may feel they can just leave a bad review and let the people here fix it and we could loose out on editors as a result. Thenub314 (talk) 10:15, 27 June 2010 (UTC)


 * The first item in the summary &mdash;showing the most recent version instead of the most recent sighted version&mdash; seems to me to be a game changer, as far as the effect of flaggedrevs on mainspace is concerned. (Which is why I suggested it; I've had it in mind since the last time the configuration of flaggedrevs came up, and would have suggested it then except that that discussion was clearly petering out without changing anything.  Since we're serious about making changes this time, this time I suggested it.)  --Pi zero (talk) 11:24, 27 June 2010 (UTC)


 * I don't see a need to grant rollbacker along with reviewer. Thenub314 (talk) 11:37, 27 June 2010 (UTC)


 * Examining Special:ListGroupRights and comparing it with Wikinews', we need to make additional tweaks to support reviewers with rollbacker. Having reviewers get rollback automatically makes the separate group for rollbacker pointless, as who would get rollback assigned if they hadn't even done enough to become a reviewer.  And if you think about it, if you're reviewing pages, you'll need a way to quickly undo vandalism at the same time.  So I changed the above to remove the separate rollbacker group now that the only right assigned to that group is assigned to the reviewer group.  I also suggest removing the patroller group, as it is not used with flagged revisions; all the namespaces that would use page patrol have been overridden by flagged revisions.  This makes us match up with Wikinews.  See n:Special:ListGroupRights to compare. – Adrignola talk 14:13, 27 June 2010 (UTC)


 * I also reflected above Kayau's suggestion on the reader feedback configuration. None of this should limit any debate over reader feedback or flagged revisions being used at all, or prevent further discussion of configurations.  I'm just trying to keep track of where we're at. – Adrignola talk 14:17, 27 June 2010 (UTC)


 * I thought I'd throw this out there. I see that Wikinews is using Extension:AbuseFilter, so it could be either a supplement or replacement for flagged revisions in the main space if anyone thought it prudent. – Adrignola talk 14:26, 27 June 2010 (UTC)


 * I am in support of this purposal, but I think that we need to lower the auto promotion limits a little. — I-20 the highway  20:48, 27 June 2010 (UTC)


 * Although I think the autopromotion criteria aren't off by much, and I wouldn't be upset if we just left them alone, I do think we might lower the number of edit intervals needed ("benchmarks") from 10 to 8. My purely subjective impression is that when someone requests the bit because they're impatient waiting for autopromotion, and their case has some merit, the hold-up is usually that they're a bit shy on that number.  Going from 10 to 8 might therefore make a substantial difference.  Changing that number from 15 to 10 was my suggestion, to fix a massive problem with autopromotion being much too sluggish, and I think it worked quite well (compared to what things were like before).  The number 10 was meant to be a substantial enough change to drastically reduce the misadjustment without going overboard, but I figured when I suggested it that by putting us into the right ballpark it might allow us to make a more precise estimate for fine-tuning it later.  --Pi zero (talk) 21:36, 27 June 2010 (UTC)


 * Updated to reflect that. Seems pretty innocuous to me. – Adrignola talk 02:43, 28 June 2010 (UTC)


 * Really I think we didn't get many requests that wasn't satisfied automatically soon after. Some people were a bit impatient or felt they shouldn't have to wait to become an editor. I think the later is likely due to the name being misleading which we are already proposing to fix. Having all 3 content namespaces count towards promotion as proposed already as well should also help those that mostly or only contribute to the cookbook or the wikijunior namespace. I really don't see a need to lower the intervals because of these other changes, but I'm also not really going to urge that it not be done at the same time. Since we are proposing changes to auto promote now, I think what would be helpful is to lower the number of contributions that need to be present in recent changes at the time of the promotion check from 10 to 5. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  11:34, 28 June 2010 (UTC)


 * I also think we could drop the unique IP requirement. For example, if 2 sisters edit from the same house (constructively), then none of them can be promoted automatically and they will need to request. — I-20 the highway  20:08, 28 June 2010 (UTC)


 * As far as I know, this should not have been on. As recorded at FlaggedRevs Extension, we voted to turn it off in April 2009, and it was supposedly done in May 2009.  Not sure what happened, but I've changed it in the proposal code.  --Pi zero (talk) 20:35, 28 June 2010 (UTC)

Importer group
It occurs to me that Internoob in the above section may feel left out in all this. So I've added the code for adding people to the "transwiki importer" group. Additionally, the "importer" group is unused and the only technical difference is importing via a file. That group currently cannot be granted either. So, like the "editor"/"reviewer" groups above, I suggest removing the "importer" group and then renaming the "transwiki importer" group to "importer", for simplicity and matching up with the "uploader" group. There have been two recent requests for this and they could not be fulfilled even if we wanted to. So I suggest we enable the technical means to do so and determine in the future how we apply it either generally per policy discussion or per situation. – Adrignola talk 12:05, 29 June 2010 (UTC)


 * No response on Extension:AbuseFilter, just as before when I had it by itself as a proposal. Well, I added code to the above that would enable it; please comment if you object, as I can't read minds.  w:Special:AbuseFilter shows possible entries that would stop vandalism in its tracks by detecting clear vandalism, such as page blanking, adding "poop" to pages, or writing in all caps.  Such would reduce the burden on reviewers by preventing such edits from being made in the first place.  It'd also more appropriate to rename it "edit filter" in the interface. Actions taken can include slowing a user down, flagging their edits with a tag in the page history, showing a warning to the user (most common), or even preventing the edit entirely.  Those actions and what to detect are entirely customizable by administrators; but none of that is possible if it's not enabled in the first place.  If desired, a new group can also be added to allow others to edit filters. I can't prove it on wiki, but when I discussed this extension in IRC in the past, both Darklama and Mike.lifeguard were in favor of it. – Adrignola talk 12:33, 29 June 2010 (UTC)

What is the technical significance of the importupload group that you're proposing to unset, and what is the technical significance of unsetting it? --Pi zero (talk) 13:15, 29 June 2010 (UTC)


 * It allows importing from an XML file. Unsetting it means the currently-named "importers" group should disappear.  It will clean up Special:ListGroupRights with groups not used not listed; same with removing the patroller group.  Keep in mind that not even administrators can import from a file&mdash;they can only transwiki import, and nobody can be added to the currently-named "importers" group.  So in practice nothing will change but we'll be able to rename "transwiki importers" to the shorter "importers" without having the unused group of that same name hanging around. – Adrignola talk 13:23, 29 June 2010 (UTC)

Rollbacker
According to the proposal the rollbacker right will be removed so it's part of reviewer. However, I a worried that some editors may use it to roll back edits that are not blatant vandalism. If one continues to misuse the right, we warn them, and they still misuse rollback, then we must remove his reviewer right as well. Won't that be a bit inflexible? Kayau ( talk &#124; email &#124; contribs ) 14:29, 29 June 2010 (UTC)


 * If they're misusing rollback then I wouldn't trust them with the ability to review either. They could make malicious edits to a page and then review the page or make malicious edits that are automatically reviewed to a page already reviewed. – Adrignola talk 14:33, 29 June 2010 (UTC)


 * Adrignola, if a reviewer is autopromoted because all (s)he does is work on one book, and is not involved with the community, doesn't know what rollback does etc, then (s)he can easily mistake rollback for undo. That is abuse, but honest abuse. Kayau ( talk &#124; email &#124; contribs ) 01:24, 6 July 2010 (UTC)


 * I'd call that "misuse" rather than "abuse".


 * I think they'd notice it was different from undo in fairly short order.


 * It would be nice if a canned message could be automatically added to a user's talk page on autopromotion, but I don't think there's a hook for that. --Pi zero (talk) 14:59, 6 July 2010 (UTC)


 * What about a bot? Kayau ( talk &#124; email &#124; contribs ) 05:58, 7 July 2010 (UTC)

Thenub314's position
I thought I restate my opinions for ease of reading. I am mostly in favor of the changes to FlaggedRev's but I don't think we should have new pages be sighted by default, particularly when in the past we were of the opinion books could opt into flagged revs if they want, the new configuration sounds like books would have to consistently work at opting out. I oppose implementing Reader Feedback, which should be a separate conversation to be a separate conversation and not bundled into the changes with Flagged Revs. I also would hope to discuss further the possibility of turning off Flagged Revs on the Main space pages, but I can see that this is a long shot, nonetheless it should be discussed. Thenub314 (talk) 15:14, 29 June 2010 (UTC)


 * Regarding turning off flaggedrevs on mainspace, I'll clarify my position: I think having the latest revision shown by default changes the psychology so drastically that there is no grounds for extrapolation to the psychodynamics of the proposed configuration (specifically, whether or not it would discourage casual contributors) based on any observed (or perceived, it doesn't really matter which) psychodynamics of the current configuration.  Not trying the proposed configuration (I'm only talking about the two issues of default view and on/off, here) would simply mean giving up without knowing whether one is justified in doing so.  The psychodynamics of the current configuration is an entirely unnecessary question if it can't be extrapolated to the proposed configuration.


 * On Wikijunior, AutoReviewNew is clearly preferable, IMO, as the first thing we (almost) always want to do when a page is created at WJ is get it into adequate shape to sight, so that we don't have unreviewed pages lying around there. Elsewhere, the point of viewing the current version by default is to make it okay for there to be an earlier version that is sighted, thus removing what I believe to be a major reason there aren't more pages on mainspace that have sighted versions.  I, for one, stopped sighting previously unsighted mainspace pages a long time ago, exactly because I didn't want to be constantly under the gun to very rapidly review changes to every last one of them.  Flaggedrevs might be far more widely used and more effective, as well as not discouraging to new users, with the latest draft shown by default &mdash; and then, failing to autoreviewnew would simply be preventing a potentially effective tool from being (as) actually effective.  --Pi zero (talk) 15:45, 29 June 2010 (UTC)

I see no need to consider this as bundling things together. Configuration changes can take awhile to be acted on when a bug request is filled out. I think letting them know all the changed we want at once will make their job easier. I have clarified the summary in hopes that people can better understand what the changes will mean. I also made one change. I noticed bureaucrats could remove the flood group, but not add it. Since flood is intended to be used temperately as an alternative of the bot group, I think administrators should be able to add and remove it. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  18:05, 29 June 2010 (UTC)

Continuing with what Pi Zero had said I do admit the making the most recent version the one that is visible by default does definitely change the impact it will have on new users. So I will try not to extrapolate. But the more I think about this the more confused I get. If the flagged revision is not shown by default, then Flagged Revs is no longer seen as a deterrent to vandalism. Nor is it being used to make sure we are in general putting forth high quality content. I suppose interested users could hunt through the edit history to make sure they have good quality version of the page. And some registered users could make this their default preference.

I also find it a bit disturbing that any new page a that gets created will be sighted, and may go on being automatically sighted as average quality without anyone ever checking it over. Over all, on pages that show the draft version by default I am not sure what Flagged Revs is helping to do for anyone beyond creating another maintenance task to keep up with. And there is still the issue that it will get used as a vandalism patrol because we don't have any other tool for that, the result being that our average quality article will simply mean "vandalism free" even if the grammar, formatting, etc is atrocious. This sounds a bit harsher then I mean it to, but I am confused about what we are hoping Flagged Revs will accomplish for the main namespace in the current setup. Thenub314 (talk) 21:49, 29 June 2010 (UTC)


 * Only new pages created by a reviewer will be sighted as average, not any new page. Part of this proposal also includes AbuseFilter which will provide us a tool for vandalism, and may help reduce motivation to use FlaggedRevs for vandalism patrol. FlaggedRevs will accomplish nothing in the main namespace in the proposed setup unless people ask to be opt into it. If people are asking to use FlaggedRevs, there will hopefully be reviewers to ensure that average means more than vandalism free. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  22:09, 29 June 2010 (UTC)


 * That's not harsh. That's exactly how I view it and use it, at least in the main space, much of the time.  I've used it for templates like QuiteUnusual has for the Cookbook, but in the main space, I view it for vandalism patrol.  However, I've seen that there'd be resistance to turning it off, and with it in place in the main space, we avoid the need for a "patroller" group.  With three levels and proper tagging in place for each, you will be able to go to Special:ReviewedPages and view "average" (vandalism-free), "good" (higher than base by reviewer), or "excellent/featured" (marked only by admins for stable versions of featured books). – Adrignola talk 22:22, 29 June 2010 (UTC)


 * I think we ought to be harsh against the use of FlaggedRevs for vandalism patrolling and viewing it as vandalism tool. IMO that has been a big part of the problem. Even with FlaggedRevs not showing specific revisions, people can look through a page's history and see what revisions are considered good and choose to read a revision marked as good or excellent. I honestly don't understand why there isn't a tab available to let people switch between a draft and stable version though, that would give people a choice. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  22:31, 29 June 2010 (UTC)


 * The first change will in practice remove flanged revision, the degradation of the system for readers and the "wall" for anonymous contributors. I suppose that "Anonymous/Unregistered users see the current revision instead of the latest reviewed revision, except when overridden by administrators." means that in vandalized or stable works (low level of edits) admins will reactivate it. So I see it as an overall benefit.
 * The second is more problematic but required, I also expect that it will increase the responsibility to editors, since it only affects users with a flag I expect that consistent disregard for quality will result on removing the flag (a non problem since the user wasn't really using it). --Panic (talk) 22:07, 29 June 2010 (UTC)

To reply to something DL was telling me earlier. Thanks for clearing up that it is new pages reviewers make that get sighted. That doesn't really affect the problem I have with it. Maybe I should have phrased my sentence as "I find it disturbing any new page I create ...", because the first time I hit save the only quality I feel I can guarantee is vandalism free. My English is terrible, my sense of still is bizarre and I am very prone to errors. And I don't usually trust other people more than myself. So, I wouldn't want to see new pages get sighted automatically regardless of the users permissions.

I will have to return to my objection about reader reviews latter... have to run. Thenub314 (talk) 16:49, 30 June 2010 (UTC)

Flood group
I am tempted to oppose the recent change. It was already such that administrators could add and remove the flood flag from themselves. Bureaucrats could remove the flag if an administrator has gone rogue or forgotten to take the flag off. Allowing administrators to apply the flood flag to anyone allows them to circumvent bureaucrats and make anyone the equivalent of a bot. On the other hand, the cumulative changes to rights management above already do quite a bit to marginalize the bureaucrat group and maybe that's the point... – Adrignola talk 18:28, 29 June 2010 (UTC)


 * Actually I've never been able add and remove the flood group on myself, so that isn't the case. I'd be fine with changing it back, but I don't see the point in bureaucrats being able to remove it without being able to add it too, since they wouldn't be able to undo themselves if they made a mistake. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  18:57, 29 June 2010 (UTC)


 * That's strange, because Special:ListGroupRights says that you should be able to add/remove the pseudo-bot flag on yourself. Our project policy is that you can't become a bureaucrat unless you're an administrator, so any bureaucrat would be able to add it back on to themselves if they removed it from themselves, by virtue of administrator group membership. If you're thinking they might accidentally remove it from an admin who assigned it to themselves and be unable to reassign it, that would be possible with the current configuration.  But that could be solved by having bureaucrats be able to assign the pseudo-bot flag to anyone.  The current configuration assumes that the community would never trust anyone but an admin with the ability to vanish from recent changes without the full-blown discussion associated with the bot flag. – Adrignola talk 19:15, 29 June 2010 (UTC)


 * Yes I'm thinking they could accidentally remove it from another administrator and not be able to give it back. I'm indifferent whether only bureaucrats should be able to give and take the flood group from anyone. Much in the same way I wouldn't consider it a big deal if administrators could give and take the bot flag. Anyways I tried something slightly different that I think I hadn't tried before and in the process I uncovered a bug in the management of user groups. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  19:41, 29 June 2010 (UTC)


 * (edit conflict, making this comment mostly useless). I have at least confirmed by experiment that I can add and remove the pseudo-bot flag on myself. So it sound to me like we should give bureaucrats the right to add the pseudo-bot flat to anyone. Thenub314 (talk) 19:43, 29 June 2010 (UTC)


 * I've reflected Thenub's comment. When it comes down to it, if a non-admin really needs to vanish, they can ask for a temporary bot flag.  Even if admins could grant that, I don't think too many would go ahead and do so without at least some discussion.  Granting it is, to me, a high-impact decision, and by convention those rest with bureaucrat group.  – Adrignola talk 19:59, 29 June 2010 (UTC)

The removal of <tt>$wgFlaggedRevTabs = false;</tt> from the current configuration (note it's not included above) should show those tabs. However, I already see them whenever I view a page with pending changes. Must be somehow related to you not being able to add/remove the pseudo-bot flag. – Adrignola talk 22:37, 29 June 2010 (UTC)


 * As long as the most recent version is shown by default, I don't see any strong line between using flaggedrevs for tracking quality and using flaggedrevs as an anti-vandalism tool. The most basic level of quality control is absence of vandalism.  I see flaggedrevs at its most basic as a bookkeeping tool for anti-vandalism.  When we made the big push to sight all of Wikijunior, for instance, I found that some pages had above-graffiti-grade vandalism that had gotten woven into their revision histories years before, apparently because there was such a long period between when the edit was made and when someone more responsible next came along, that they didn't look closely at a long-standing edit that wasn't glaringly obvious vandalism.  In a situation like that in mainspace under the proposed configuration, when a reviewer does come along, even if it's many months later, they'll know that there's a particular edit that hasn't been vetted yet.  --Pi zero (talk) 22:45, 29 June 2010 (UTC)


 * I might not of come across any/many pages with pending changes than maybe. Is this limited to reviewers? If so I meant a tab anyone could use, like between the book/page and edit tab and could be used even when there aren't any pending changes, assuming only that the last revision FlaggedRev would show is different from the most current revision. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  22:47, 29 June 2010 (UTC)


 * File:Draft tab.png shows what I see. I don't see that when the latest revision has been reviewed.  – Adrignola talk 23:02, 29 June 2010 (UTC)


 * For what it is worth, if I log out and view an old review page as an IP editor there is a latest draft tab, so it should be visible to everyone. Thenub314 (talk) 09:11, 30 June 2010 (UTC)

As vandalism tool
So it sounds like several of us think it is appropriate to use flagged revs as an vandalism patrol tool. In fact, we sort of have to, we don't any other way to mark pages as vandalism free to keep the people patrolling recent changes from checking the same thing multiple times. So why don't we call a spade a spade, if the lowest level is really only to mean "valdalism free", let's call it exactly that instead of "average". Thenub314 (talk) 15:28, 30 June 2010 (UTC)


 * Group names, revisions levels; they're all configurable in the MediaWiki namespace. That's not something that should block the proposal. – Adrignola talk 15:57, 30 June 2010 (UTC)


 * "Vandalism free" isn't friendly and is harsh. The point seems to be to have a minimal level of quality that is below average but has been checked. In which case I'd rather just keep using 4 levels (like now) for 'quality', and just call them minimal, average, good, and excellent. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  16:03, 30 June 2010 (UTC)


 * I guess alternatively could stay at 3 levels and call them minimal, average and good, since Wikibooks is already using good books and featured books somewhat as synonyms . --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  16:31, 30 June 2010 (UTC)


 * I agree that a name isn't something that should block the proposal. But not having a clear sense of what we want this tool to accomplish for us is a reason to put the breaks on.  I am proposing we try to come to a consensus about whether or not this the bottom level be for marking pages as free of vandalism (regaurdless of what we call it).  If that is its purpose on the main space the I can understand having it there.  If we do not use Flagged Revs for vandalism patrol we should disable flagged revs on main space pages so we can use existing patrolling tools, because in my opinion patrolling for vandalism is more important than having a page somewhere in the history that is flagges as "we thought this was good".  I am sure others disagree with me on this point, but honestly I see that as being little benefit to anyone.  It does gives a new way to semi-lock pages and that is nice, but so very vital.  But lots of people seem to be reading through the RC list looking for vandalism and giving a way to coordinate the effor would be a good idea.

Reader Feedback
(returning) Here are some my issues with reader feedback, and please correct me if I misunderstand something.


 * Grids at the bottom of every page are disrupting to a contiguous text. Especially large grids with stars like wikinews has, but even smaller ones would break up the flow of a book.
 * As most books/modules have no one working on them. The vast majority of cases no one will read or act upon the reviews.  I suppose I am trying to say it is not so helpful a tool for us, perhaps latter if there are more editors running around.   All I see this doing is creating a big red flag saying "Yes most of modules are under developed."
 * I feel it will discourage new contributions. Rather than being bold fixing a problem with a page readers are being it encourages readers simply to give it a poor rating and hope the books (non-existant) author will fix it.

Unfortunately I am guessing I have not made a convincing case to remove ReaderFeedback from this round of changes. But I can offer at least one idea about how to change the configuration. Since I haven't had time to read threw the mediawiki doc's forgive me if this is nonesenical. But instead of turning it on in the Main and Wikijunior namespaces turn it on in the corresponding discussion name spaces. This way the rating will not break up the text, removing the first issue I mentioned. I also think if a reader is mature enough to go to the discussion page it is more likely they will still be bold and edit the page anyways, so I am less concerned about the third point. The cookbook is a separate case, and I think reader feedback would be good there in every respect, and should appear on the recipe pages and not their talk pages. Thenub314 (talk) 22:08, 30 June 2010 (UTC)


 * How is it any more disrupting to a contiguous text than categories or flaggedrevs at the bottom of pages? Maybe some styling could help with that?
 * I'm skeptical of any theories concerning Wikibooks' activity level, and disagree with using it as a reason to do or not do something. What is wrong with knowing whether or not people think most of Wikibooks' modules are under developed? If that were the case it could possibly help us to do something about it, which I think would be a good thing.
 * People can leave feedback on the discussion page or add maintenance templates to pages without contributing any content to pages. How is providing a means to do so directly on pages any different?
 * Enabling reader feedback on discussion pages instead sounds reasonable to me, I can't think of any reasons not to atm. Why is the cookbook a separate case? Why should the cookbook be treated differently? How do your concerns not apply to the cookbook? --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  22:56, 30 June 2010 (UTC)

--Pi zero (talk) 23:43, 30 June 2010 (UTC)
 * The idea of calling the minimal acceptable level "minimal", or something of that sort, appeals to me. I wonder if we can come up with a better choice, but "minimal" conveys the sense of what I'd like that level to mean, and as pointed out, finding a better choice for the same meaning doesn't have to hold up this proposal.  (Addendum: It seems obvious rereading that that "acceptable" is a contender.)
 * Notwithstanding my slightly melodramatic remarks earlier about AutoReviewNew, I suggested turning it on because I really didn't think there would be any harm in doing so once the most recent draft is shown. Although for my own use I'd somewhat prefer to have it on, since Thenub gives a perfectly respectable reason why they'd rather have it stay off, I'm willing to go along with leaving it off.  (This is similar to why Wikinews recently disabled autoreview &mdash; of course it's in the nature of their different use of flaggedrevs that they'd already had AutoReviewNew turned off.)
 * I have no commitment to the feedback thing; although I've been vaguely skeptical, I didn't have any clear objections worth opposing it. I'm very foggy on the details of it, really, although it's my understanding that those over at Wikinews who do track it have been extremely pleased with it.  Which doesn't necessarily mean anything about whether it's appropriate here.  However, if we're willing to relegate it to the talk page (which I'd think might not work anyway unless one turned on flaggedrevs for the talk spaces &mdash; but I too haven't RTFM) &mdash; if we're willing to relegate it to the talk page, I think I may be opposed to it altogether, because where Thenub has suggested it would compete with actually improving the page, I see it as competing with the talk page.  If people are coming to the talk page at all, either on their own or because we directed them there, it makes more sense to me that they should just comment on the talk page, which is simpler.


 * I'm fine with leaving AutoReviewNew off as well. I've been pleased with what I've seen of ReaderFeedback on Wikinews as well. ReaderFeedback is not dependent in any way on FlaggedRevs being enabled anywhere, unless the documentation I've read has simply failed to mention a dependency on it. ReaderFeedback provides graphs that show how reader feedback has changed over time, much in the same way as the contributors graphs shows how contributions to Wikibooks has changed over time. I remember a time when Wikibooks has a lot more graphical statistics which IMO contributed greatly to community growth and participation. Wikibooks only stopped doing that because the format of database dumps changed. Wikibooks use to have a top 10 list of most active books that was updated each month with how far books jumped or dropped in activity since the previous month for example. I don't think we can really say whether ReaderFeedback will be good for us or not without giving it a try. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  00:24, 1 July 2010 (UTC)


 * I'll concede that there's no real competition between the talk page and ReaderFeedback. I have doubts about whether the talk page idea can work (granted, the idea that it had anything at all to do with flaggrevs was almost certainly daft).  It looks to me as if one would have to make the talk spaces rateable instead of the content pages associated with them &mdash; and then one would also have to make sure that a talk page was actually created for every single content page.  That doesn't seem very practical.  (If one could make the talk page idea work, one might wish the feedback were at the top of the talk page rather than the bottom.)


 * Of Thenub's three bulleted concerns about ReaderFeedback,
 * The second bullet doesn't work for me. It's not clear to me that having lots of underdeveloped pages presents any problem for feedback that it didn't already present for its own sake.  As for the rest, if someone comes along and decides to spend some time on an inactive book, the accumulated feedback would be no less useful to them than to someone who had been working on that book all along.
 * On the third bullet, we really don't want anything to interfere with a visitor investing that small bit of effort to make their first edit.
 * On the first bullet, non-reviewers don't see any junk at the bottom of the page because of flaggedrevs (only reviewers are treated to that); and there's no analogy with Wikinews on this since (a) Wikinews doesn't have the continuity concerns of a book and (b) Wikinews already has sources and "share this" icons at the bottom of each article.
 * It does occur to me, in passing, that if it were possible to put the feedback machinery on the lefthand sidebar, that would eliminate the continuity problem, and might go a long way to redress the discouraging-from-edits problem too since the feedback would feel like more of a separate issue from the actual content. (I see no evidence that that's remotely possible, but suggesting that it isn't possible would be getting into esoterica that are well beyond me.)  --Pi zero (talk) 01:53, 1 July 2010 (UTC)
 * Being able to have both the feedback and flagged revs machinery on the sidebar would be great. Maybe worth making that a feature request. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  02:15, 1 July 2010 (UTC)
 * I'd like to get at least the majority of the changes that can be agreed upon above implemented in the next year, however. – Adrignola talk 03:35, 1 July 2010 (UTC)

Let me answer some questions directly asked to me. First to Panic, yes I think you had the idea of my concerns that it was not clear to me what we where attempting to do with Flagged Revs. Mostly my concerns were about the bottom flag, and it sounds to me your asking the subtler questions of "When do we demote/promote a module?" and you want to set down clearly at least what our goal is in WB:FlaggedRevs Extension. But I do think we are in the same ball park of "What are we going for?"

Let me try to answer Dark Lama's questions in the order asked.


 * "How is it any more disrupting to a contiguous text than categories or flaggedrevs at the bottom of pages?" Currently, internal to most books the only category that appears is one corresponding to the books name. This is very easy to passively ignore just as are headers with the title or section in a dead tree book.  Adding a feedback form is specifically seeking for the reader to stop reading/thinking about the books material and start thinking about its quality before moving on to the next page.  This seems to me a bit distracting.  Any styling that would help would necessarily come at the cost of making the feedback form less visible to the reader, and result in less feedback.  But yes some balance could be struck.  I was hoping the talk page would be good.  This is currently where the WB:WikiProject Languages is placing their rating schemes which made me think it might be the right place for ReaderFeedback ratings as well.
 * "What is wrong with knowing whether or not people think most of Wikibooks' modules are under developed?" Nothing really, it is the truth of the matter. At the same time I don't want to over emphasize that fact  either, in the fear that people have the impression that this is a dying project.  I have personally given up on and avoided wiki's that had "bitten off more then they could chew".  Mostly because I recognize how difficult it would be when something happend to finally bring the project to an end. (I would have been crushed if I were an active Simple English Wikibooks editor at the time the wiki was locked.)  I recognize it is folly to think that there are other people like me, or to predict behavior of groups on what I feel.  At the same time it is still something I am concerned about, and I think it is a reasonable concern, so I mention it.
 * "People can leave feedback on the discussion page or add maintenance templates to pages without contributing any content to pages. How is providing a means to do so directly on pages any different?" Again I suppose it is personal experience, after having shown a few people where the edit and discussion tabs are I am left with the opinion that "If you've noticed that a discussion tab, you've probably noticed the edit tab as well. And you know you can contribute.  On the other hand if your annoyed enough with something being of poor quality then you look for the tools to fix it."
 * Why is the cookbook a separate case? The structure of it is so very different from the other things here. For one thing all of the recipes I have seen are complete and on one module, and there by and large no ordering to its pages.  My comments about interrupting continuity simply do not apply. For another thing it is difficult to tell the quality of a recipe before cooking the meal.  So ReaderFeedback will of a greater benefit to readers and contributors in a way that it would not be for other books, because it is very difficult to assess quality simply by reading.

--Thenub314 (talk) 10:38, 1 July 2010 (UTC)


 * Thanks for the reply. I think that most supporting votes are at this moment in a possition of selecting the less of two evils, it is clear that FlaggeRdevs has no real function other that the reduction of vandalism and that can only work if we make it dificult to contribute content. So the real choise is between attemt yet again an alteration (that functionally removes FlaggedRevs) or acepting to stop using it.
 * I've never been a supporter of the scheme as permanent, that wasn't what I approved, and after all the implications became clear and as we started stated that we are doing it wrong. I particularly don't approve this adhoc process for passing high impact decisions, the FlaggeRdevs discussion started here was then turned in a "proposed configuration" that moved the discussion to the FlaggedRevs Extension (notice that the adoption of the scheme was turned into the adoption of an acceptable configuration, the first was just assumed as consensual, that had an impact on the process) as I voted on the configuration in June 2008, it is clear that the full implications of the alteration were unknown and the comments of Whiteknight and Rob Horning clearly stated an understanding that the concept would be revisited and validated. Whiteknight the proponent of the idea already stated his wishes to have the scheme removed.
 * So my view is that the needed proposal would be "Should we keep using FlaggedRevs?" and get a consensus on that if we can. Since the adoption of FlaggedRevs never got a discussion (as we all didn't know what was implicated when we agreed to the "test").
 * Since I don't see people agreeing to accept the needed reversal, we are left with a new attempt to reduce the impact it has on the project, in this convoluted way, without fixing what we supposedly are agreeing to (the proposal should be clearly stated and run in the FlaggedRevs Extension page), that is the core of my objection for the rest my position is similar to Mike.lifeguard, with the added realization that we are doing it backwards to fix the never gathered consensus for keeping FlaggedRevs... Panic (talk) 12:44, 1 July 2010 (UTC)

Anti-vandalism definition
Panic - I've gotten the impression (now and in the past) that you've been defining anti-vandalism to mean preventing it from happening in the first place. Although I find that premise surprising, my suspicion that you're operating on that premise is supported by its excellent explanatory power for two of your positions: (1) You claim that flaggedrevs can't reduce vandalism unless it makes it more difficult to contribute, which would only make sense (regardless of whether one accepts the judgment implied about the effect) if one's definition of reducing vandalism excludes measures that aid in reliably repairing vandalism after the fact. (2) You claim that making the current draft visible by default would functionally remove flaggedrevs, which is only true if one postulates that the sole function of flaggedrevs is to, as you put it, make it more difficult to contribute. I do agree that it functionally removes a basic reason (I'd thought, the basic reason) for your opposition to flaggedrevs.


 * Only on Wikijunior would I endorse the operational objective of preventing vandalism from happening in the first place (where by "happening" I mean "becoming visible by default"). Elsewhere, I consider our operational objective regarding vandalism to be reliably removing it after it happens.  That objective is served more effectively by flaggedrevs if the current draft is shown by default; for example, as I've remarked somewhere above in this absurdly long discussion (though there's something bemusing about a discussion where when you preview your comment you get a table of contents), I've stopped reviewing unreviewed pages in mainspace because I couldn't keep up with the burden of very-rapidly reviewing changes to every page I review &mdash; so that showing the most recent reviewed version is an obstacle to the smooth functioning of flaggedrevs, rather than being necessary to it.


 * Possibly, the difference of premise might also explain why you claim that we're not addressing the problems with flaggedrevs. I'm not sure, though; there may be some other fundamental difference of premise behind that one.


 * This is the highest-profile and therefore best venue for this discussion. It's very reasonable to put a notice of this discussion at Wikibooks talk:FlaggedRevs Extension (wish I'd thought of that; I'll do it next if no-one beats me to it [note: yup, you'd already done it]), despite the practical unlikelihood that anyone who would see the notice there isn't already aware of the discussion here.  Especially since anyone who has been following our gradual improvements to the flaggedrevs configuration over time is already aware that not all the consensus discussions take place there (which is why I added a list of pointers to consensus discussions to the page).  --Pi zero (talk) 15:11, 1 July 2010 (UTC)


 * Indeed anti-vandalism actions can be preventive or corrective. Since we work on a volunteering basis corrective practices are extremely costly (time and effort). Preventive actions have a better return but in the case of flaggedRevs I find the cost unacceptable as it makes participation difficult. Btw this is also the reason I've requested that the proposal is clearly formalized, there are simpler and rational steps that can prevent confusions, a better understanding among Wikibookians and a reference for historic background. If we don't preserve the historic memory we are bound to incur on the same mistakes.
 * As for the seemingly safe assumption you are making that any and whatever vandalism occurs is fixable at a later time. I can confidently state that the assumption is false, without entering in details (we shouldn't give anyone ideas), all edits are layered and any corruption of the content if not detected in a timely fashion will be, if not obvious, extremely difficult to recover from. If on that corrupted layered actions an administrator deletes the page then they are indeed impossible to recover from..
 * In regards to the reasons. I oppose the scheme mostly is the barrier it creates, next is that the scheme isn't designed to support our project needs (regrettable but factual). If we remove the first what other benefit do you see on the scheme, clearly the categorization of the pages will never work as we would like (hence my second motive to oppose it). What are the redeeming features that you see if we continue to use the scheme (with this last batch of changes) will benefit the project ?
 * The why I make an effort to specify that we are doing it backwardly is simple, at this moment it is clear to all that there is not a consensual agreement to use the scheme now. This has a clear implication on the order we discuss the subject since the status quo is still the non adoption of the flaggedRevs (since the test has clearly failed and isn't fixable). So if people validated that the use of the tool permanently was never a consensual decision (fact) the burden would be in providing a reason and a solution that validates the time and effort put on keeping it alive. Failing that a resumption of the previous state would occur.
 * I've added a note on the talk of Wikibooks talk:FlaggedRevs Extension but this proposal is a change to what is the subject matter covered there as such that is the core of my standing objection to the alteration, I feel like others have now stated that some of the changes will have implications beyond what we are signing on for. This as you state is a simple thing to do but even I haven't the full understanding on what is now on the proposal (and technical know how) or I would do it myself as an unstable version of that page. If done and people continue to validate that text as the proposed changes, I will modify my vote to neutral and remove my block of the process. --Panic (talk) 17:50, 1 July 2010 (UTC)


 * This proposal is clearly formalized. It has the exact changes to be made to the code provided and a summary of each and every change.  I'll update the flagged revisions page when we get consensus on this and the changes are made to the configuration.  Removal of flagged revisions entirely is an extreme position.  Concessions have already been made to change the default view state of pages and to make it easier for people to become reviewers.  A lot of time has gone into reviewing pages already and there is concern about losing that, not time spent maintaining the system.  If you're looking through RC diffs for vandalism, it's not any more or less intensive than clicking the review link for changes.  Failure to spend the time reviewing pages or investing the time looking for vandalism won't make vandalism go away.  I would disagree that "it's clear to all" that there is not consensus, unless you somehow are counting neutral positions as opposition. Your position won't block the process; consensus doesn't require every last person to be on board. The layering of vandalism is something flagged revisions works well at preventing, in that it highlights all changes since the last review–not just the last diff. – Adrignola talk 12:26, 2 July 2010 (UTC)

I'm going to suggest, in hoping to reduce Panic's concerns about the edit filter, the removal of the possibility of creating filters that will result in a block or removal of administrator/bureaucrat groups. I'll reflect that change above. Description of the remaining actions can be found at Extension:AbuseFilter/Actions. – Adrignola talk 00:32, 3 July 2010 (UTC)

Rollback and trust
On Mike's opinion for rollback with reviewer group, I'd like to point out the interesting tidbit that Wikipedia's use of flagged revisions believes that "reviewers are users with a similar level of trust to rollbackers". So it's not just Wikinews holding that position. As pointed out earlier, the alternative is submitting an old revision, which if done improperly will cause loss of data. – Adrignola talk 12:25, 1 July 2010 (UTC)


 * Adrignola, abusing rollback does not mean one is not trusted. One can be completely ignorant about the use of the rollback feature and use it for other purposes (eg people added redundant BookCats, which I just undid in RC!) Just because someone does something in good faith does not mean he or she cannot do it the wrong way. Kayau ( talk &#124; email &#124; contribs ) 13:13, 1 July 2010 (UTC)


 * Then let me clarify: trusted with the tools. If you can't use them correctly, you've no need to use them at all. – Adrignola talk 12:10, 2 July 2010 (UTC)


 * Adrignola, you can't expect someone who hasn't read our policy but got autopromoted to know what rollback is and how it's different from undo etc. Kayau ( talk &#124; email &#124; contribs ) 15:38, 2 July 2010 (UTC)


 * Also, some people may not to any RC patrol, so that some of the reviewersmay be annoyed about having an unused button appearing on watchlists, RC, and contribs. Kayau ( talk &#124; email &#124; contribs ) 11:21, 4 July 2010 (UTC)

Difficulty of removing enabled extensions
The comment above "Removal of flagged revisions entirely is an extreme position" reminds me of something I meant to say but never got around to. (I do not disagree with statement) At some point the claim was made that it was not possible to know how ReaderFeedback would work for us until we try it. But the problem is that these changes gain momentum, even if they are not good. I find Mikes comment that "I simply don't think the community is capable of supporting a robust reviewing scheme; we struggle just to create content." is spot on. So Flagged Revisions in the main space has mostly created a new maintenance task to try to keep up with, but it is an extreme position to get rid of it because we are throwing away lots of hard work that has been done by all of us. In the same way, we need to be very careful about applying that same "we can just test it" mentality that was apparently part of the IRC discussions about Flagged Revs to new extensions. After we have had it hear for a while it will be difficult to through away feedback data that our readers and ourselves generated even if we recognize the tool is not working for us as it should be. More generally speaking it is simply a lot harder to take tools away then it is to add them. Thenub314 (talk) 12:50, 2 July 2010 (UTC)


 * Sure it can be hard to remove tools once they are enabled. On the other hand momentum over time has leaned more and more towards decreasing a dependency on FlaggedRevs. I think people took it upon themselves to create a new maintenance task out of FlaggedRevs. For whatever reasons, people wanted to be able to tell what revisions were previously checked, when they managed and were able to do without it before. Doing that is a convince that people took upon themselves to do and that is what created the new maintenance headache. I certainly didn't lean my support with that in mind and I think anyone else that supported it didn't make it clear they intended to use it in that way. In short I think how it is used makes the difference. I think someone mentioned before that Wikinews uses it for different reasons, and I've been inclined to believe the difference in use and not the configuration is the source of the problem. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  13:44, 2 July 2010 (UTC)


 * I am not sure it doesn't create a new maintenance task. I have never liked FlaggedRev's and aside from a small number of pages, never flagged pages for the first time.  Nonetheless every time I log in and check my watchlist I have a bold orangish strongly worded message telling me I need to review pages with pending edits. I didn't seek this task out greets me every time I log in (I think it is the unique maintenance task that does this).  And occasionally because I get sick of looking at it I acquiesce and spend some time reviewing pages.  When you say wikinews uses it I am not sure if your mean it to be FlaggedRevs or ReaderFeedback.  I'll Assuming you mean flagged revs since we are discussing its configuration more and your next comment was about configuration If your correct and it all comes down to a question of use, why are we using it in the Main name space?  I understand Wikijunior but that is the only place I clearly understand what we want to do.  But as I point out below, there is a bit of a conflict between the using it as a vandalism patrolling tool and the way we have been using it in the past.  Thenub314 (talk) 14:11, 2 July 2010 (UTC)


 * I was not around during the time this extension was discussed, nor was it ever decided to properly document the motivations for enabling it. It was very bad form to discuss this on IRC entirely the first time, especially for a wiki configuration, with the wiki used only for collecting positions.  Panic mentions a historical record being desirable and I would agree.  I do use flagged revisions as a vandalism tool, at the most basic level.  That means I do use the lowest level as vandalism-free and will not rate higher than that otherwise.  The notice on pending changes in orange is only if you are watching pages with revisions sighted, which assumes that you care about the content on that page.  If a book wants to use flagged revisions for stable versions of a certain quality, then they need to have an admin change the page settings to show the highest or second-highest review levels by default rather than any review level or the latest revision.  If people are against my use of it for vandalism patrol, informal or otherwise, then I'm going to revert to my position that it should be turned off in mainspace and stand with Mike on that point. – Adrignola talk 14:17, 2 July 2010 (UTC)


 * I thought more discussion should happen on wiki too, but didn't think it was going to happen, because of the lets see what happens nature of the situation. I think a few people that wanted it did have in mind to use it as a vandalism tool, but some people like me did not. I guess there wasn't really a consensus on how the tool was to be used which could also of been bad form and perhaps it shouldn't of been enabled for that reason. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  14:25, 2 July 2010 (UTC)

It sounds like we should along with our proposed changes make a propose rationale, which can later be turned into documentation. This is what it sounds like what is being proposed about Flagged revs and the a little bit of what we are thinking as to why it should be this way. Everyone please feel free to improve the rationale below, as someone who would hope to remove FlaggedRevs I probably am not the one to write this... Thenub314 (talk) 15:31, 2 July 2010 (UTC)

FlaggedRevs rationale

 * FlaggedRevs will be our primary vandalism patrol/prevention anti-vandalism tool.
 * To encourage new editors, all edits will be visible from the moment they are made. Except for pages particularly sensitive to vandalism (such as Wikijunior) which need to be configured separately (it will be pages at the "good"/"average" level that will be displayed).
 * Reviewers will have all new pages they make sighted at the lowest level, since they are expected not to vandalize. Of course this means reviewers who vandalize for what ever reason will likely have their tools removed, and will have to request they be given back as an RFP.
 * We will have three levels at which modules may be rated. The lowest level is intended to mean "vandalism free" but we may choose a friendlier term. The second, optional level, that a module may be flagged at will indicate this is a "good" module.  The final level, "excellent" only administrators will have access to grant.  This allows us, after configuring the page to show only this highest level, to almost lock sensitive pages but still allow unprivileged users to contribute to it, and when the changes are ready an administrator can approve it.  Thus we may have sensitive pages that everyone can contribute to.
 * As a non-enforceable but documented bit of culture, Reviewers will be discouraged from reviewing modules in books at the "good level" if the book contributors do not want to take part in having their modules reviewed. This may seem to beg the question why have a good level?  It could certainly be useful as a matter of internal review by the book contributors, or an external review such as in a request to have the book be Featured, etc.  This is a hangover from the current scheme, but one that I like, others may want to remove this bullet.
 * Reviewers now have rollback permissions. As our primary defense against vandalism it makes sense to allow them a tool which makes fighting vandalism easier.
 * Everyone who contributes positively can help remove vandalism so we have made it easier in various ways to to become a reviewer.

Note this doesn't yet cover all of the changes listed above! Keep that in mind when adding support below. Thenub314 (talk) 16:41, 2 July 2010 (UTC)

On first reading, I pretty much like this. I'm not clear if the non-enforceable-but-documented bit is meant to be opt-in or opt-out, though. --Pi zero (talk) 15:55, 2 July 2010 (UTC)


 * Yes, My idea was a book may opt out of FlaggedRev's except for the bottom vandalism free level. Every page should be checked for vandalism. Thenub314 (talk) 16:41, 2 July 2010 (UTC)

I don't like this. I think FlaggedRevs is not a vandalism, patrol, or prevention tool. Ratings are incrementally good, with each level rating above the previous being better, which is good for quality control and is what it was designed to do. If it was intended for vandalism, ratings would be incrementally worse instead, or it could mark pages as having been checked with a single click without a need for a form at all like was the case before FlaggedRevs was installed. People can still vandalize pages and the vandalism is still present in a page's history so it doesn't work as a prevention tool either. FlaggedRevs is good for showing revisions where everything on the page is grammatically correct, spelled correctly, and everything is well worded. The fact that revisions can also be shown that might have no vandalism on it is more of a side benefit than a functional use. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  16:23, 2 July 2010 (UTC)

Those who want new pages automatically reviewed likely use flagged revisions for vandalism patrol. Those who don't likely use it for quality control. Because flagged revisions removes page patrol, I've never been able to use that for anti-vandalism. And with flagged revisions enabled in the main space, and no use allowed for "vandalism-free", you've taken tools away from us in patrolling. And 80% of the pages don't use it and so don't benefit from it. – Adrignola talk 16:42, 2 July 2010 (UTC)


 * I'd failed on first reading to properly register that word choice on the first bullet. Even on wikijunior there is no actual prevention involved.  The use of the tool is different from what I understand to be the usual wiki sense of "patrol".  So it's neither "vandalism patrol" nor "vandalism prevention".  I've suggested "anti-vandalism"; note that that first bullet makes no claim that that's the only or even primary function of flaggedrevs, just that flaggedrevs is foremost among things that address that function.


 * I disagree with the idea that anti-vandalism is a side benefit of flaggedrevs. To my mind, it's the primary benefit of flaggedrevs; I'm confident of it, and not convinced that the higher ratings will be of much use by comparison (though I see no earthly reason not to give them a chance, and would be happy to see them work out well).  With vandalism-free as the minimal level of sighting, by whatever name, the anti-vandalism function is automatically present along with whatever other use there might be.  As long as the most recent sighted version is visible by default, though, neither the anti-vandalism nor any higher-rating use on mainspace can function properly, because that default creates a new and overwhelming maintenance task, rapidly reviewing all edits to previously sighted mainspace pages.  With the most recent version visible by default, reviewing becomes an incremental task over time, which wikis are good at, rather than a matter for urgent rapid action, which wikis are bad at.


 * It seems to me that, since the rationale doesn't claim that either function (anti-vandalism or multi-level quality rating) is more important than the other, it should be possible for people who disagree about which is more important to nevertheless find a version of the rationale that they can all agree on. --Pi zero (talk) 17:54, 2 July 2010 (UTC)
 * (Okay, rereading that I think I'm overstating slightly: one usually does a bit of fixing spelling and such at the same time that one certifies vandalism-free, which is in fact a good argument for not calling it "vandalism-free" (not that anyone is promoting that name since others have been suggested). But I still consider that a side benefit of the minimal rating.  --Pi zero (talk) 18:56, 2 July 2010 (UTC))


 * Hmm... not sure if I know the usual sense of patrol. Let me say, my thinking was all about the  !  that appears in Recent changes and watchlists.  By marking pages with some vandalism free setting it will disappear and we can see which pages have been checked, thus helping us coordinate our efforts.  This is what I was thinking when I used patrol.  Prevention was clearly silly, though I have heard it claimed FlaggedRevs curbs vandalism by not allowing IP vandals to see the fruit of their work (not sure I believe it). I am happy with the current version.  Thenub314 (talk) 18:27, 2 July 2010 (UTC)
 * I think the "usual" sense is the software feature described at New page patrol. So it's just as well to simply avoid the term.  --Pi zero (talk) 18:56, 2 July 2010 (UTC)
 * My use of patrol above is simply adding Special:OldReviewedPages to the standard Special:NewPages. In both cases, reviewing the page (or any changes) removes the  ! .  Same idea, but wider scope.  One could see why anti-vandalism would come to mind after using it in practice. – Adrignola talk 19:06, 2 July 2010 (UTC)

The conversation over the rationale for flagged revisions (rather than its configuration) can continue at Wikibooks talk:Revision review, with Wikibooks:Revision review on the process and customs related to flagged revisions at Wikibooks. – Adrignola talk 02:39, 3 July 2010 (UTC)


 * I support the move, this thread is becoming humongous :), the target has already shifted several times, support is diffused by several versions and most of the neutrals can be moved to support as the requests and observations they make are some how in accordance with the status quo. --Panic (talk) 18:27, 3 July 2010 (UTC)


 * This thread (FlaggedRevs rationale) should be cut off, but the overall "Reconfigure Wikibooks" will continue if needed (though I think it's winding down). The reading room discussion and listing of support positions is the location for linking to when filing a bugzilla request. FlaggedRevs Extension/Unstable is for the benefit of those who have not been following the conversation in the reading room and for whom the summary in the reading room is not sufficient.   is a complement to Help:Revision review to document what flagged revisions means to us, not how to use it, and not how it is configured.  The reading room discussion is low-level and temporary with FlaggedRevs Extension/Unstable a low-level record of the configuration effects.   and Help:Revision review are high-level documentation and not concerned with what's going on in the reading room. – Adrignola talk 18:40, 3 July 2010 (UTC)

Highest review level

 * I have one stipulation for giving support: We need to have a separate group who can mark pages as featured. That way the Admins won't have such a load. We can just call it "Featurer", but it is necessary, so as to not tie up the admins with featured books. If anyone has a good reason for not having a separate group, I don't mind withdrawing this stipulation, it is just something I thought would be good. What do you think? Arlen22 (talk) 19:00, 3 July 2010 (UTC)


 * One reason for not having a "Featurer" group is that it creates the two groups that are solely for reviewing pages and can create confusion. We currently have editor and reviewer (with reviewer able to rate the highest level) and this proposal seeks to eliminate one of those two groups and just call it reviewer.  If changes are to be made such that reviewers will not have any limits on them in terms of what they can rate, then we only need two levels: one for the basic, vandalism-free version and one of higher quality that has actually undergone a content review. Otherwise there is no functional difference between the second and third levels if there is no restriction on who can rate to the highest level. However, there have been objections from yourself, Darklama, and Panic on that top level being restricted.  Eliminating the restriction would get your and Panic's support (I believe), but we may want to simplify things with two levels. A book is not going to be featured simply because all its pages are at featured quality in the review system, as it must still go through the nomination process. – Adrignola talk 19:28, 3 July 2010 (UTC)


 * I would say get rid of the third entirely, as it is of little to no use anymore. All in favor? Any objections? Arlen22 (talk) 21:43, 3 July 2010 (UTC)
 * Arlen22 (talk) 21:43, 3 July 2010 (UTC)


 * Not that it is really of much relevance since I am the only one objecting, but my oppositions still stands. Though now my only concerns are about ReaderFeedback. Thenub314 (talk) 22:43, 3 July 2010 (UTC)


 * Well, I don't really care, it is just that to restrict it to admins is overkill when the highest level doesn't have any use anyway. Arlen22 (talk) 23:03, 3 July 2010 (UTC)

With the three levels being minimal, average, and good, minimal can mean that the revision was quickly scanned and appears to be free of any obvious vandalism by patrollers, average can mean that the revision has been proofread with grammatical and spelling errors fixed, and the revision is understandable/comprehensible by WikiGnomes and the like, and good can mean that the revision has been thoroughly exampled and determined that the structure makes since, the revision is accurate and cites its sources, and nothing else of importance is missing by someone that knows the subject. That is basically why I see no need to limit the highest level to administrators. When most or all pages in a book have a revision that is considered good than maybe people might consider nominating the book to be featured. Rather than using the level to indicate featured the level can be used to determine if a book might be ready to be featured. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  23:40, 3 July 2010 (UTC)


 * , great idea. Arlen22 (talk) 23:43, 3 July 2010 (UTC)


 * In looking for Arlen22's and Panic's support, as well as mitigating Darklama's concerns, I've removed the code above that would restrict the top level of reviewing to administrators. This also eliminates the desire to have a second reviewing group just for that top level. – Adrignola talk 14:51, 4 July 2010 (UTC)
 * Point 5 says "Administrators can set pages show the most recent excellent revision for Anonymous/Unregistered users." Why not have them be able to set it to any level? Arlen22 (talk) 15:08, 5 July 2010 (UTC)
 * My reading of it, considering the last 2 changes, means that admins can fix the page to the optimum quality. Making it possible to select between several rating wouldn't serve any purpose and again permit the selection to become arbitrary. --Panic (talk) 15:37, 5 July 2010 (UTC)
 * Good point, we have totally defeated the purpose. Perhaps instead of calling it "featured" or "excellent", we should call it "static" or "stable" or "protected", and restrict it to admins again. After all, this would be used only on high traffic pages. The main reason I wanted it removed in the first place was that it was required for featured status and it should not necessary for an admin to mark a page as featured since it has to go through the process anyway.
 * We might as well just leave it like this (anyone can set page to top level) for now and come back to it later if needed. Arlen22 (talk) 18:58, 5 July 2010 (UTC)

About voting
What are we voting on below? Is it the summery at the top? Arlen22 (talk) 15:41, 5 July 2010 (UTC)


 * We are actually voting for the "Proposal code" at the top of this section (at <tt>#Reconfigure Wikibooks</tt>), which is the specification of record of how the configuration is to be changed &mdash; in whichever particular version, or versions, one votes for. The summary, just below that, and the separate page are valuable aids to understanding the proposed changes to the configuration; but they aren't the subject of the actual vote.


 * Note that, in order to make the vote crystal clear for purposes of confirming consensus, it is probably most useful that votes should identify what is being voted for using markup similar to the following. This example uses the particular revision that is currently identified by the other page as the subject of its description; I don't mean to herd anyone into a particular position by that, but it seemed like the choice least likely to cause confusion.
 * [ rev 1873833]
 * --Pi zero (talk) 17:32, 5 July 2010 (UTC)

Support

 * 1)  proposed code configuration in [ rev 1873833]. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark  lama  13:08, 29 June 2010 (UTC)
 * : I fully support configuration as defined in [ rev 1868918] or [ rev 1873833]. – Adrignola talk 01:15, 3 July 2010 (UTC)
 * 1)  configuration in [ rev 1873833].  --Pi zero (talk) 14:07, 29 June 2010 (UTC)
 * 2)  [ rev 1868898] which is almost equal to 1868352. — I-20  the highway  19:48, 29 June 2010 (UTC)
 * 3)  the configuration defined in [ rev 1868352] or [ rev 1868918] or  [ rev 1873833]. <font color="#E66C2C">QU <font color="#306754">TalkQu 20:28, 29 June 2010 (UTC)
 * 4)  as defined in [ rev 1873833]. Arlen22 (talk) 16:07, 2 July 2010 (UTC)
 * 5)  [ rev 1873833] as summarized in this version of Wikibooks:FlaggedRevs_Extension/Unstable.   --Panic (talk) 15:24, 5 July 2010 (UTC)
 * 6)  for the proposed reconfiguration at [ rev 1873833]. Soeb talk&#124;contribs 08:55, 7 July 2010 (UTC)
 * 7)  the proposals in the summary Purplebackpack89 (talk) 17:38, 24 July 2010 (UTC)
 * 8)  I'm not even an editor! but well. :P Diego Grez (talk) 17:40, 24 July 2010 (UTC)

Oppose

 * : I oppose configuration as defined in as per my comments above. (As part of any formal record, I want to say the whole process was sort of rigged, as per my comments below.  Not sure if the whole conversation will be archived, so I include this opinion here.)  Thenub314 (talk) 13:05, 7 July 2010 (UTC)
 * : Can't see the proposal working in practice. Somebody else has already pointed out that WB struggles to get simply content let alone reviewing of such content.  Low levels of vandalism, sillyness and people adding misleading information don't warrant reviewing either.  The problem on Wikibooks is a lack of contributers and readers and not an excess of vandalism or dodgy information! --ЗAНИA [[Image:Flag_of_Italy.svg|15px]]talk 00:10, 7 July 2010 (UTC)
 * This makes no sense because flagged revisions is already enabled. This proposal is primarily a reconfiguration of it. If you want to take the position that flagged revisions should be disabled, then please make that clear. – Adrignola talk 00:25, 7 July 2010 (UTC)
 * It seems possible that Xania might have missed the key point that this proposal is a solution for the problems of flaggedrevs, by making the most recent draft visible by default instead of the most recent sighted version (except on Wikijunior). So that sighting doesn't interfere with contributors, and reviewers aren't actively discouraged from sighting previously unsighted pages, and flaggedrevs is set free to be a bookkeeping tool that functions over time, rather than an administrative problem that demands rapid review of all edits to previously sighted pages.  --Pi zero (talk) 00:33, 7 July 2010 (UTC)


 * Fucking hell! It's an oppose vote. Let it be and stop questioning everything!  No, Xania hasn't "missed the key point" of this vote and takes offence at being told otherwise.  The whole idea of flagged revisions is a waste of time so therefore I'm not going to support any proposals which "reconfigure" it, extend it, reduce it or otherwise.  The only one I'll support is one to remove it.  Stop questioning people's votes.  --ЗAНИA [[Image:Flag_of_Italy.svg|15px]]talk 10:29, 7 July 2010 (UTC)
 * Well, you are blocking its demise. Arlen22 (talk) 10:31, 7 July 2010 (UTC)
 * No he isn't. Thenub314 (talk) 10:48, 7 July 2010 (UTC)
 * Xania, I hope you don't mind that I've changed your # to a *. This will make consensus clearer. Also, please be civil. Kayau ( talk &#124; email &#124; contribs ) 12:38, 7 July 2010 (UTC)
 * I agree with Thenub314 in that respect, Xania is free to express his opinion as he sees fit, but since this is a discussion to gather consensus when one takes a position of objection he must provide a rational for a compromise or a reason for others to support his objection, if not he excludes itself from the process.
 * In a process where ones view is a minority there are tree routes, establish that the minority view has grater value and gather support for it, attempt to reach a compromise at middle ground or concede to a change of vote to non-opposition. Political processes varies but all (even monarchies and dictatorships) involve some sort of negotiation, on our system stating that one is being pressed to chance his position is a copout, since in our setup no-one should have any power over the other. In fact it shows that others are willing to address your position, the alternative would be to ignore it or a permanent block on the discussion. --Panic (talk) 14:14, 7 July 2010 (UTC)

(edit conflict) Nonsense! There is no must in a discussion like this. And it is not a discussion to gather consensus, it is a proposal, gathering should not be part of the lingo, it goes towards the whole vote rigging feeling I expressed below. Sometimes it is helpful to offer ideas for compromise, but it is not a requirement. There is absolutely no need to concede, A single persons position will almost never blocks a proposal. But mostly makes this comment nonsense is the part about excluding positions from considerations if they do not provide rationale. Should we exclude the positions of support made by people who gave no reason and in now way took part in the conversation? Shall I strike them through now? Or maybe there is some asymmetry between the support and oppose side of any proposition? It makes me wish I were on the support side and allowed not to have a thought in my head. At least none I would later be interrogated about.

I would like to think that someone could choose to support or oppose based on arguments already given. Which was how I read Xania's now removed position. Thenub314 (talk) 14:59, 7 July 2010 (UTC)


 * Must is they key word there, it what divides a rational discussion from a simple list of ramblings. We need to be clear on our positions. You can't make it work with should or without requiring people to back their position with objective reason.
 * From Introduction to Sociology, "Politics is the process by which decisions are made for a given society. The method of making decisions for groups varies, but the act of decision making is the key component that characterises politics."
 * From our Decision making, "The most important tools that wikibookians have to make decisions are compromise and consensus.", "We will use the term discussion to mean the process of wikibookians voicing their opinions and working towards compromise. Wikibookians do not "Vote" on anything, but we discuss points, compromise, and try to reach consensus.", "Ultimately the state of "community consensus" involves the vast majority of users agreeing on some decision. Wikibooks is not a democracy, and a simple voter majority is not the default, nor the recommended method of deciding any discussion.".
 * From Cognitive Psychology and Cognitive Neuroscience, "No matter which public topic you discuss or which personal aspect you worry about – you need reasons for your opinion and argumentation. Moreover, the ability of reasoning is responsible for your cognitive features of decision making and choosing among alternatives.". --Panic (talk) 15:36, 7 July 2010 (UTC)
 * (Edit conflict) It seems the bug report is now submitted, and I will respect the "full stop!" Thenub314 (talk) 15:53, 7 July 2010 (UTC)

(discussion of Thenub314's oppose vote)
 * From you last comment above "...my only concerns are about ReaderFeedback." and as I search references on those concerns I see only that you raise an issue about the reliability of the gathered information, is this correct ? --Panic (talk) 15:36, 6 July 2010 (UTC)


 * Perhaps I don't know what you mean about reliability... but that is not the word I would choose to describe my concerns. I basically feel that ReaderFeedback will:
 * disrupt the continuity of a book;
 * discourage new user edits by creating the impression that telling us what is wrong will lead to the being book fixed by us, instead of encouraging readers to be bold and fixing it themsleves;
 * not significantly help improve the books here as as most pages are do not have any active contributors.
 * Though I don't feel these concerns really apply to the Cookbook.


 * I haven't said so elsewhere, but probably we should choose different criteria should be chosen for Cookbook recipes, because at least I expect most readers to rate a recipe on its ease of preparation and taste regardless of what we call the criteria.


 * As a compromise I suggested enabling the reader feedback forms on the talk namespaces for main and wikijunior instead of the spaces themselves. Then make sure the reader feedback messages clearly states that actual page is being rated and not the discussion page.  Assuming this is possible.  (I still haven't RTFM).  But there is no particular support for this idea. Thenub314 (talk) 16:17, 6 July 2010 (UTC)


 * PS I also thought that once turned on it would be difficult to turn off even if it doesn't work out for us. Somehow this ended up under its own separate heading above which kind of destroyed the context of what the objection was about. But my comments in the  "difficulty of removing an extension" section were about the difficulty or removing ReaderFeedback once enable. Thenub314 (talk) 16:21, 6 July 2010 (UTC)


 * My reference to the reliability of the gathered information referred to your statement «I find Mikes comment that "I simply don't think the community is capable of supporting a robust reviewing scheme; we struggle just to create content." is spot on». --Panic (talk) 17:13, 6 July 2010 (UTC)


 * Most of you concerns are valid but they are based on suppositions they can just as well have the reverse effect. In any case the way we do it now is no better so I see no great change, only that we will democratize the access to the classification.
 * I would prefer not adopting the extension and keeping that classification the way it is to see the use of each work talkpage reinforced, as I don't see as a good structure to have a talk page for each page of a work, but accept that as a system limitation to us (it does the work well on Wikipedia), this option would also aggravate the issue of visibility.
 * Other alterations that could address the issue is by way of adding the right information on the interface box, ask users to fix issues could suffice.
 * The third point you make seems contradictory, a book has contributors or has not (pages in themselves are a bit irrelevant), I don't work on pages I do work on books. I do maintain a watch in a multitude of pages and as a contributor I don't see the reader information as having that much of an impact, it may be useful, but not at the stages of development most books are. In my view, regarding that rating and even the other one, quality classification beyond average, will only have a real use for and when someone decides to publish a Wikibook. Between now and then I expect that other alterations have addressed any negative consequences.
 * The only solutions now seems not to adopt the extension (and keep the way we do that review, that has most of the same issues) or alter the extension in a way that addressees your objection. I would like that anyone on the know to see about what can be done to address the second possibility. --Panic (talk) 16:48, 6 July 2010 (UTC)


 * The reader feedback extension is for reader feedback, not editor or reviewer feedback. It has no relation with the reviews assigned by flagged revisions. If it's bothersome, it can be hidden in per-user or per-book CSS.  Reader feedback classifications cannot be customized per namespace, at least in the current form of the extension.  This one remaining objection will not be able to be reconciled with revision 1873833 that everyone has now updated their support for, where reader feedback is enabled. – Adrignola talk 22:44, 6 July 2010 (UTC)


 * Just to be clear, with the acknowledgment that both schemes support concurrent classification regarding presentation. When you make a distinction on the providers of the feedback and state no relation, my understanding was that any editor or reviewer is also a reader, even if not all reader at present can participate on the categorization the value or relation regarding the interpretation of the feedback is, we cannot say equal, but similar. Correct? Can't a request to participate in the improvement of content be added to the interface? (that would go more toward resolving Thenub314 concerns) --Panic (talk) 23:21, 6 July 2010 (UTC)


 * Yes, reviewers are also readers, but that's getting into semantics. The reason for the reader feedback is for those who are not reviewers to be able to assess pages in a way that doesn't serve as a vandalism or quality revision check. Feedback in the toolbox would be even worse than putting it on the talk page.  It will be overlooked, and even with our measly minimums for feedback, no pages would get the minimum required to produce meaningful numbers.  If one were seeking a way to marginalize the extension so badly that the next time it comes up it's removed, that would be the solution.  And under Vector, the toolbox is often hidden and so readers wouldn't even see the link for it in the toolbox.  That's not even considering the additional coding time that would be required to make it appear there, which would delay the start and the finish of this proposal's implementation by the developers.  Possibly a compromise to not risk interrupting the flow of pages while maintaining visibility would be to have it show up only on the root page of a book.  But the extension's not designed for that, as like most aspects of the software, it was designed with Wikipedia in mind first and foremost. – Adrignola talk 23:31, 6 July 2010 (UTC)


 * I don't see the relevancy on the distinction you make on who provides the feedback or how we can guaranteer the value of that information. I see it as an helping tool for prioritization not as exact indicator on what is lacking. I suppose vandals will also provide their own feedback, so the power of the extension is in the averaging out of the information we get from all Wikibookians (without any particular distinction). If you disagree and because the interpretation of the data isn't been defined on the proposal, lets move this point to your or mine talk page as it has no relevance to the current objection.
 * I didn't say "feedback" I said if it is possible to include a statement in the interface to indicate that we value more active contributions than participation in the rating system (not in so many words). This seems to be the core objection of Thenub314 that users will see it as the optimal way to contribute to improve the project in place of adding/contributing to the content. --Panic (talk) 23:49, 6 July 2010 (UTC)


 * Thenub314, will it satisfy you the possibility to hide the extension as Adrignola indicates? We could also try to get more Wikibookians to take a position on the proposal, would you concede to change your position to non-objection, if more people express their support for the proposal ? Do you have any viable proposal to resolve the impasse ?  --Panic (talk) 23:21, 6 July 2010 (UTC)


 * Adrignola's suggestion about using CSS to turn it off in particular cases is a good idea. Unfortunately my concerns mostly stem from the fact that I feel enabling this extension is a bad move for the project, and not so much from concerns about the books I work on.  I don't understand why the number of people expressing their support should effect my opposition.  The whole point of a consensus is that we don't have to all agree.  I am unfortunately out of ideas for a way to improve ReaderFeedback, it is a shame it can't be configured per namespace, but that is life.


 * Overall I would like to point out that something is going awry in the conversation. I think the atmosphere unintentionally... I am not sure of the right word.  But there is a lot of politics going on to get people to change their positions, and it doesn't sit entirely well with me.  Are four editors really necessary to jump on 3AНИA's hasn't read and understand what is going on?  That is just... toxic.  If I were him I would really be fuming.  And what is so unreasonable about his position?  He doesn't see this working out for us because we have too few editors, it wasn't unreasonable when Mike made the same suggestion.  If he doesn't like the tool being about why should he support some reconfiguration of it?  Even neutral comments are now drawing discussion along the lines of "Perhaps you didn't understand."  I always thought going around to talk pages and trying to get people to change their positions was considered bad form.  But a lot of that seems to be going on.


 * So could we keep comments about this thread in this thread? (Including the "please clarify your position" comments on talk pages?) It splits up the conversation Really, how should we interpret I-20's response?  Is that intended to be part of this conversation?  I have no idea.  It would also keep two editors from expressing their confusion over 3AНИA vote here along with two at his talk page, which seemed to be sort of a double whammy to me. Thenub314 (talk) 10:47, 7 July 2010 (UTC)


 * As a PS, I do think Mike's comment is spot on, but I think you may have misunderstood that comment, it has nothing to do with the reliability of gathered information. Thenub314 (talk) 10:47, 7 July 2010 (UTC)


 * This isn't a vote! These are position summaries. This is the equivalent to a debate in a political arena and an attempt to try to satisfy the most people and address the most concerns possible. When someone opposes a proposal, naturally a desire is there to see if the concerns can be addressed.  But if the concerns are not outlined properly, that makes it difficult to address them.  Thus people ask for clarification, not a change in position.  If people hold so little value in their position that they aren't prepared to defend it or justify it, then so be it.  This proposal's pretty much done and I'll file a bug report later today. – Adrignola talk 12:13, 7 July 2010 (UTC)


 * Look I didn't mean to offend anyone. Adrignola, as far as your comment goes you clearly asked for a clarification.  And no one understands this isn't a vote better than I do, but the word was being used at Xania's talk page when he was asked to reconsider and I suppose I let it slip.  But let me be clear that I was explicitly asked to change my position.  At Xania's talk page he was told to "please change either your vote or your reason", and told he probably didn't understand what the changes were about.  (And he is understandably annoyed).  FWIW, I don't think Xania does not value his position so little, it is simply that all the defense and rebutle etc that lead to his position is already accounted for in this conversation. No need to lenghten it, and he was a bit annoyed at the forceful response to his "vote".


 * More subltly going around to talk pages and asking only one side to update their support for a particular revision is also a subtle rigging fo the process. Just as you say that if someone doesn't care enough to defend their postion then so be it.  If someone cares so little as to not pay attention to the changes should we be considering their point of view as part of the consensus.  Perhaps they just updated it with a  "yeah sure, whatever" attitude.  This kind of behavior ruins the whole process.  I don't say that as a way to try to block this change, but just to say that IMO something very bad happend here.  Maybe something woth talking about later. Thenub314 (talk) 13:01, 7 July 2010 (UTC)

That's pretty harsh for a proposal that is of this length and went through so many revisions since initially being put forth. I don't blame people for wanting to conduct discussion off the beaten path and out of the limelight or inform others of easy-to-overlook changes that were made to address key concerns of theirs. – Adrignola talk 13:32, 7 July 2010 (UTC)


 * Maybe it is harsh. I thought it was all a bit innocent at first.  But put yourself in my shoes.  I became the unique person to have a section title after him (two if you count this one).  I was asked to restate my opinions and then told all my opinions subjective and could easily go the other way (how does ReaderFeedback improve continuity?). Then pressured into changing my position. It is a bit hard not to feel singled out.  Then when two new people state opinions that are not favorable toward flagged revs, they draw comments suggesting they do not understand, they are being self contradictory, etc etc.  Xania was effectively bullied, not on purpose granted, but our collective reaction was quite harsh towards him.  They were bad mistakes made in good faith.  And people did only go around talk pages seeking support for one side.  It is easy for me to empathize with Xania's comment that "I refuse to be pressurized by a small minority who seem to think that they're in charge." I am not sure about the small minority part, but as I said before, something bad has happened here.  After today, to me this whole conversation smells like three day old fish.


 * It is clear that the changes will pass despite my objections and I am fine with that. My point is we really should aim to do better.  With changes this major we should be trying doubly hard to make sure our process is beyond reproach, and we have not achieved that. Thenub314 (talk) 14:08, 7 July 2010 (UTC)


 * ReaderFeedback improve continuity by providing the contributors the information about more silent readers, not all readers will become active contributors but it is admissible that a fraction of the now nonparticipating users will interact with the extension, this provides editors clues on what parts of Wikibooks (in general) or project are of more interest to the community and work on them.
 * I personally like and do reinforce my participation when I see activity on the pages I work on, as this validates the work I've put into those works.  --Panic (talk) 14:48, 7 July 2010 (UTC)
 * continuity - logical sequence, cohesion, or connection, uninterrupted connection or union. --Panic (talk) 15:11, 7 July 2010 (UTC)


 * (edit conflict)In regards to Xania's recent edit, like I said, something bad happened here. How can we read this and know if other people didn't add their view of oppose because they weren't up to the fight?  How many people have we scared away from expressing their opinion?  I suspect none or not many, but who knows.  In the end I don't blame him for feeling like he was continuing to be harassed.  And I am sure he wouldn't be please with me continuing to lengthen this already long conversation.  Submit the bug report quickly before this turns anymore sour. Thenub314 (talk) 14:59, 7 July 2010 (UTC)


 * It is clear that you are not talking about the same type of "continuity" as I am. And I can only guess at which definition your using.  But I don't wish to pursue this any further, I just thought you'd like to know we misunderstand each other completely on this point. Thenub314 (talk) 15:05, 7 July 2010 (UTC)


 * Why thank you Panic! That definition makes everything crystal clear and in no way came across as dismissive or condescending. Thenub314 (talk) 15:19, 7 July 2010 (UTC)


 * Take it as you will but that was not my intention. I was just making sure others got what I was talking about. You did dismiss the issue, if you wish to debate it further I'm available to further our mutual understanding.
 * I do believe that most Wikibookians actively avoid participating in discussions, I did so actively, for most of my first years here. This is why we should extend protection to fringe views and opinions. Regarding Xania be assured that he is well capable of speaking for himself. I read his position a bit differently than you, his observation, disregarding his frustration with the time we take debating things, was in line with what Mike's states bellow, but that position can't be acted upon, the level of consensus for the alteration is greater than for the removal of FlaggedRev. That is why I changed my position and probably part of the reason Mike didn't made it the subject of an opposition.   --Panic (talk) 15:57, 7 July 2010 (UTC)

Neutral

 * 1) I have no opinion as yet on the proposal. I have no opinion about the part where new pages are automatically marked as patrolled. That seems to run against the current FlaggedRevs philosophy, though in a sense it makes life easier. I am also skeptical about assigning the editor rights with the rollback right. I am worried that an editor may not read our policy on rollbacks and misuse it because they have been autopromoted to editor but know little about it. Therefore, I have no opinion yet whether to oppose or support the proposal. Kayau ( talk &#124; email &#124; contribs ) 05:51, 30 June 2010 (UTC)
 * 2) I'd rather remove flaggedrevs entirely and go back to new page patrolling, or maybe full diff patrolling. I simply don't think the community is capable of supporting a robust reviewing scheme; we struggle just to create content. I also don't think it makes sense to merge rollback with editor. I don't think AbuseFilter is going to be a big help, but I don't see any problem with using it. –   02:00, 1 July 2010 (UTC)
 * 3) Still making my mind, there are lots of changes proposed (thanks for the summary box, BTW; after a ten-day break there was no way I would get through that huge discussion otherwise :) ). In principle I like many of the proposals, particularly FlaggedRevs becoming opt-in. --Duplode (talk) 17:06, 1 July 2010 (UTC)
 * There is some confusion somewhere. Does the current proposal make FlaggedRevs opt-in? I thought by making all new pages automatically flagged, it even more difficult to opt-out if you wanted to. Thenub314 (talk) 13:20, 2 July 2010 (UTC)
 * The whole opt-in/opt-out thing doesn't make any sense. If flagged revisions is enabled in the main namespace, you're opted in, no way around it.  There's no way for you to prevent any reviewer from coming along and reviewing all your pages as vandalism free or whatever other criterion they decide the review represents.  Additionally, there is no policy stating that I have to leave pages unreviewed if the original creator didn't review them.  The only way that it could be opt-in in any way would be if you're thinking of possible requests to an admin to make pages show the most recent reviewed revision by default. – Adrignola talk 13:36, 2 July 2010 (UTC)
 * When darklama had said earlier that "FlaggedRevs was suppose to be opt-in for each book after the last time we made changes, and I think we need to do a better job of that being the case by discouraging people from sighting revisions in a book unless they want both the benefits and hassles that come with using FlaggedRevs." I took this informal opt-in as what was supposed to be the status quo left over from last time. Sure there is no way to stop a reviewer from flagging any page he or she likes.  It is a shame it can't be turned on/off book by book but it is a limitation of the software.  But if our current aim is to allow editors/reviewers to opt-in particular books, it makes sense to interpret the word as it has been used before.  As an informal (and sadly undocumented) idea that reviewers should not flag modules of books that the people working on them do not want flagged.  One of the reasons I wanted to be clear about whether or not we intend to use Flagged Revs as a vandalism tool is because it does runs into conflict with this idea.  Which is why I am very confused as to what we are trying to accomplish in the Main namespace. Thenub314 (talk) 13:57, 2 July 2010 (UTC)
 * I think there was some unstated assumptions and probably a lot of that going around throughout the whole life in which FlaggedRevs has been used. I believe last time it was learned that reviews could be undone/cleared and so simply clearing all reviews from books that didn't want it combined with disabling autoreview would be enough to make FlaggedRevs opt-in since with no reviewed revisions the current revision would be shown. That didn't work because people continued to review revisions anyways. If it had worked there would of been no need to ask administrators to change the stability setting, since it didn't the next step seems obvious to have stability setting off by default and that is exactly what was proposed. I just think it would of been better if people would of stopped reviewing all revisions because than administrators wouldn't need to do more work and people wouldn't need to seek an administrators to opt into it. Not requiring administrative action is more ideal, but seems like it might be unrealistic now, especially with people still wanting to use it as vandalism tool. Wanting to use it as vandalism tool combined with wanting to turn it off seems rather contradictory to me, which always brings me back to the idea that how people use it and what its used for should be what changes. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  14:39, 2 July 2010 (UTC)
 * 1) After reading through the proposal for the first time, I think it's better than what we have now (especially considering, as others have mentioned, the difficulty we have generating content), but it would be better to just get rid of it. I haven't been here for a while, so a question for all of you: does it happen often that someone makes an edit to a reviewed page (even a good one) and it just sits there because no one has watched it and "accepted" the revision? Mattb112885 (talk to me) 01:59, 7 July 2010 (UTC)
 * The discussion is way too long to read through, IMO anyway, so here's the key point as I see it: Once the most recent draft is visible by default, rather than the most recently sighted one, flaggedrevs not only loses its downsides, it is enabled to serve a potentially valuable function that it's now being prevented from freely serving.  The problem isn't that pages wait a long time to be sighted (they do; see Special:OldReviewedPages), the problem is that it matters that they wait a long time like that, because the most recent sighted version is visible by default.  With the most recent draft visible instead, flaggedrevs becomes a bookkeeping device for keeping track, over the long term, of what has and has not been vetted.  Wikis are good at doing things gradually, which is what flaggedrevs aids under the proposal; wikis aren't so good at rapid customized response to unique actions across a broad front, which is the sort of administrative mess that flaggedrevs tends to create in mainspace now (without the proposal).  --Pi zero (talk) 02:36, 7 July 2010 (UTC)

Implementation
Bug 24304 has been submitted. – Adrignola talk 15:47, 7 July 2010 (UTC)

Rollback
I remain skeptical about giving out rollback rights along with editor, though that concern may be resolved by the programming of a bot to inform the new editor once (s)he has been autopromoted. Kayau ( talk &#124; email &#124; contribs ) 06:18, 8 July 2010 (UTC)
 * Because I didn't know what rollback was, I didn't touch it. And when I learned what it was about I didn't need it so I didn't use it. I would say it could be given out manually, but automatically is fine for now, I would say. Arlen22 (talk) 12:08, 8 July 2010 (UTC)

Proposal to change the icon and definition of "tranwiki" at the RfDs
Proposal and changes to it are now open and will end after 7 days of inactivity, there is no need to express support, please add comments or propose changes. --Panic (talk) 09:06, 16 July 2010 (UTC)

For some time I have felt that Wikibookians don't fully appreciate the implications behind a transwiki in the context of a RfD and those that understand the meaning of transwiki don't understand the benefits behind the closing of a discussion as transwiki. In general terms a transwiki is a request for an administrator to perform a copy (not a move), in the context of a RfD it also implies a deletion, but the action is in fact a request for content push from us to another community. I don't know but expect that some of these unrequested copies of content are simply deleted at destination (if you have any knowledge about that it would be interesting to know). The proposal is to change the icon now labeled as traswiki to state "savable" (prevent waste or loss of, to conserve), that clearly indicates that the position taken on the RfD is that at the present time the content has no place in the project, but has intrinsic value and we recognize the effort put in providing it, as Pi zero said on a RfD, that the content is "not trash", this of course doesn't remove the possibility of indicating a transwiki location to save the work, but puts emphasis on our classification of the content not on how it will be disposed of. The other related change, I propose, is that that if a clear location for a transwiki is established and it is the outcome selected that the content should be pulled, this requires that the community we defined as a destination should be notified and accept the content, we can establish a procedure as we discuss the proposal. This proposal is now open and will end after 7 days of inactivity, there is no need to express support, please add comments, express your opposition or propose changes. --Panic (talk) 19:07, 14 July 2010 (UTC)
 * I think having a better relationship with other websites where works are suggested to be copied to is a good idea. In the past people from StrategyWiki have posted a comment on the RfD discussion when they have adopted a work. I think the current name "transwiki" and icon is good enough. A person's opinion of what to do with the work can be influenced by whether or not a website is willing to take the work. Some people might be willing to support copying to another website because at least it would have a home, but might want to keep the work otherwise. Some people say "transwiki or delete" which can be useful for understanding what people would like to see done with the work if target website is not interested in the work for example. I think it would be nice when a consensus is reached to transwiki that the consensus be noted on RfD, but the discussion is left open until we hear back from the website where the work is to be copied to, so if the website doesn't want it the community can decide what it wants to do instead. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  19:25, 14 July 2010 (UTC)


 * I also understand the more experienced Wikibookians don't see this as a great issue, but since the RfDs are in my experience now the primary location that new Wikibookians select to participate in the political process of the project some extra attention to details and for clarity should be taken.
 * On the idea of the "transwiki or delete" not all content of value will have a destination, not all will be accepted, that doesn't reduce the future usefulness on it. Closing every deletion of such content in a distinct manner permits to in the future for Wikibookians to easily identify content that at present wasn't seen as fit for a keep (here and elsewhere) and an easier way to separated it from empty stubs and other "trash". --Panic (talk) 19:38, 14 July 2010 (UTC)

Comment Withdrawn


 * I've attempted to make clear that this wasn't a vote/poll, before everyone starts to take sides, I would request that you let your opposition stay but remove the icon as it has a connotation linked to the normal straw poll we perform. I was attempting to avoid that at this early stage...
 * I don't understand what you are opposing. In fact what you describe as "slippery slope" is what normally happens, that is why I proposed the second modification. From a push to a pull.
 * You don't seem to be disagreeing that the normal position of transwiki relates to the value of the content under discussion, the renaming of the icon (that is misleading since a transwiki is a request for a copy) and I've made clear that the new label, that can be anything (I just found that "savable" was well suited to indicate the position), will continue to signify a possible transwiki but also situation that a destination project can't be found or doesn't accept the content. We must remember that we are in a volunteering basis actions are not obligations, this also raises the bar to make people examine the contributions of others beyond What is Wikibooks? (even if some of us already do that). This would mean that any OR (if it has actual content would be tagged differently than an empty stub or gibberish. This would reduce the feeling that some Wikibookians get of alienation and frustration after a deletion of their work. --Panic (talk) 20:59, 14 July 2010 (UTC)

Comment Withdrawn


 * I'm glad that you see that you are objecting to what normally happens when someone opts for the position of transwiki.
 * When in a RfD, I select to argue for a traswiki, I'm recognizing that the work proposed for deletion has an intrinsic value that while not useful in Wikibooks will be useful elsewhere, I'm making a position about the value of the content I don't know how you can separate the two. Since a traswiki position has no impact on the destination community, we are in fact evaluating the content.
 * In any case what normally happens isn't on the proposal, so I'll ask you to clarify any objection to what is proposed, a simple renaming of the position of transwiki that will clarify the situation where it is refused at destination or the content can't be accommodated elsewhere, and an alteration from the practice of "push" to a "pull" from the other community. Do you have objections to these issues ? --Panic (talk) 22:46, 14 July 2010 (UTC)


 * I am opposed to this proposal. Panic here seems to be a transwikist. Anyhow, I don't like the idea of calling transwiki 'save', then decide on which community we shove it to. I believe that WV is currently a place to dump random scraps of educational material, but that's unrelated. I don't think that we should use transwiki as an excuse for saving material that may be considered good but is useless for the community. Nowadays you don't see people commenting, 'transwiki to so-and-so' at WP XfDs. What I believe is, transwiki should only happen when the work a) is not nonsense (and the book contributors can help us understand that; b) be are absolutely sure that it fits in the scope of another wiki and c) there is someone to do the transwiki. In case of copy-and-paste transwiki to a wiki which does not allow transwiki from WB, such as Wikia, then not only do we need to find an appropriate place in a strange wiki, but we also have to make sure that the contributors there want it and then care about the attribution etc. IMO, such transwikis should only be done if the book contributor(s) want it. Kayau ( talk &#124; email &#124; contribs ) 00:42, 15 July 2010 (UTC)


 * Again, in general you are expressing opposition to something that is the common practice, as did Thenub314, even that it should be clear that the second part of my proposal addresses that issue, the custom dumping of content will stop.
 * In what regards an argument against this proposal, you state that you object to 'save', in fact I avoided that word intentionally and opted by a derived one 'savable' that qualifies the content not the action, I'm attempting to make it clearer the position taken on the RfD, how it will be closed is still open, and 'transwiki' will probably continue to apply especially if some consensus is gathered for the change advance by Darklama to request a state of hold on the RfD until the transwiki is completed. (There are alternative solutions and problems with this method but lets leave it as is for now and address what was tabled first, we will come back to it later)
 * I'm not stuck on the 'savable' term, if you have a better one put it forward, the intention is to clarify that the old transwiki and the icon we normally use are not fit for the function that we normally use it. We don't need a consensus to alter or adopt a new icon, anyone can state the position as they like I'm only attempting to establish a best practice and mutual understanding to enable a cleaner running of the discussions. If we agree fine if not I've made my point and will start using the term myself now that I've explained why, but the usefulness will be diminished and contribute to increase the confusion, just the opposite of what the icons were meant to do.
 * More experienced Wiibookians can understand the nuances of the transwiki position and what it implies on the context of an RfD, but most newcomers, even from sister projects don't, in that regard the link you provided has no bearing on this project and how we use transwikis. I can't seem to grasp what you intended by pointing out transwikist, can you attempt to explain it in another way ?
 * I take the chance to make clear to you is that what you believe and aspire to and what happens seems to diverge (and with a great difference of latitude), when you say "I don't think that we should use transwiki as an excuse for saving material that may be considered good but is useless for the community", that is just what we normally do, it is not for us to decide what another community sees as useless we only "have power" about what is on this project, and there is no other way to do it unless as I propose we reverse the practice of transwiki so that you aspiration about point c) is realized.
 * Another point is that as you state when participating in a RfD we are not only validating content for Wikibooks but also examining the value of the work, a requirement for your points a) b), this effort that we make when participating on a RfD if extended a little bit further can help on archival to indicate to future Wikibookians or even outside communities that some works do have some other intrinsic value. This is not only helpful for us but for the contributor that took the time to commit the work to us and in the future it can serve to rescue some works if and when the views of our or other community changes, it is clear to anyone participating on the RfDs that the outcome are often inconsistent and extremely dependent on the ones participating on the process. It is my strong belief that this is not only beneficial to us but that we owe this consideration to the volunteers that do provide us the content. --Panic (talk) 02:02, 15 July 2010 (UTC)

Comment Withdrawn Comment Withdrawn

Comment Withdrawn


 * Ok, I have withdrawn any objections, please continue the conversation with the other contributors. Thenub314  ( talk ) 00:53, 16 July 2010 (UTC)

Reshuffle 1
As could have been expected by some and it is now clear, Wikibookians aren't basing their stance on RfDs discussions on the same sets of requirements. This reinforces the understanding that arguments behind the positions is what really counts on those discussion, sadly enough we often use the simple count of the positions, not the value of the arguments used and this of course has implication on how the discussions are closed. One of the reasons why I advanced the idea of a simple rename was to clarify and aggregate similar positions around the value of the content. But one must realize that the use of the position indicator icon seems to make things that already start by promoting a deletion worse and invite the felling of a "vote", with supporting "votes" often reinforcing the acceptance of the request and reducing the chance of anyone putting forward a challenge to the final deletion. Taking in account the increased (and recently even if partly as a joke) expression of dislike for votes the RfD still suffers from being seen as a vote (even the rename hasn't helped changing things much), should we drop the icon completely and restructure the formalization of a RfD as a request for Wikibookias to state opposition to it and for instance add time-out for holding for the participation of the work's editor/community, to be given a chance to be the first reply to the request. In a similar way to what we do for example for some of the system flags. This of course without disregarding what was already said and not discarding the beneficial changes that can be made to he transwiki decision. Does any one oppose dropping the use of the icons and restructuring the RfD around a request for opposition and comments ? Or a better idea to avoid the use of icons that permits seemingly equal, but different positions, as to valued to be counted together. --Panic (talk) 07:06, 16 July 2010 (UTC)


 * I think we're all clear that voting is evil, and that RFDs aren't votes. I don't think there's any problem with RFD, except perhaps the subtle and linguistically challenging difficulty that because "vote" is such a short and common word, it's easy to fall carelessly into the shorthand of calling the declarations of position in such discussions "votes".  I'll be amazed if I hadn't slipped up that way myself from time to time.  The only thing I think we might do to improve the RFD process is to find another short common word to use instead of "vote" (clearly the word "vote" gets no serious competition from "declaration of position"), and then find ways to embed that different word in our idioms and habits.  --Pi zero (talk) 16:18, 16 July 2010 (UTC)


 * I do think that, well I won't call it broken, but it has problems and it can be improved. The topmost one is that people working on the projects are rarely present in the discussions, and in the instances that they are, few cases end in a satisfactory way so that the "responsible" Wikibookian understand why the work has been deleted, that we recognize the effort made. Mostly by the RfD action we alienate people from the project.
 * The process also is unbalance regarding re-evaluations, a process that is keep can be continuously evaluated until someone manages to pass a deletion, undeletion request only occur shortly after the deletion, probably because they lose completely any visibility and are relegated to the archives without any special distinction. RfDs are in general unfavorable to abandoned works.
 * On the issue of transwikis we already seen that some of the closes as transwiki are null actions, and minority views on a transwiki aren't considered even if they in what relates to us are equal to deletions (on the context of RfDs), and the fulfillment of the closing verdict isn't guaranteeable.
 * Most of the RfD are direct and clear, the only issue arises is when the work under RfD isn't clearly rejected by the WB:WIW (mostly because of OR considerations) or has other intrinsic value incompatible with Wikibooks.
 * It is also clear that there has been inconsistencies and confusion on the closing RfD discussions, that in cleanup spreed a deletionist frenzy is created and that band-wagoning occurs. Supporting votes are unnecessary most of the times and the request intention is not always clear (if really promoting a deletion or merely asking).
 * Another point is that we are losings relevant work, even if evaluation of the works under RfD is only assumed (there is no way to know how informed anyone is before he takes a position, unless he makes an argument in support of that possible), I always presumed (and it seems I was wrong) that when analyzing works people did it in broader terms, even if not in compliance with our project, in most cases people attempted to make a judgment regarding a works worth. I for once have always expressed what I found good about any type of work on my comments and posterity is losing a chance to easily benefit from this quality analysis that would at least help at a later time find a new life to the free content that was provided to us.
 * The final item is that the icons we use to distinguish positions, do serve to do head counts, that are indeed votes and numbers do in fact shape the outcome and as seen in the parent thread not all icons mean the same to all, so I do think we can do better. --Panic (talk) 19:26, 16 July 2010 (UTC)


 * Maybe "view", "stance", "point", "debate", "aim", ...? --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  19:44, 16 July 2010 (UTC)

After surveying the discussion, I feel the second part of Panic's original proposal (making it mandatory to notify the receiving end of a transwiki) is really important. There is no need, however, for it to be accompanied by changes of terminology, abolishment of voting icons and similar changes to the RfD process. At the end of the day, no amounts of linguistic sugarcoating will completely quench the (instinctive?) urge of editors to attempt vote-counting or to join groupthink. The only effective way to tackle that is developing a suitable culture among contributors, and from my brief experience here I think our progress in that direction has been quite decent in fact. Finally, I should add that I find rather unsettling the idea that Panic, as I understood it, appears to outline on the "losing relevant work" paragraph above, namely that our collective inability to judge the Worth of a book should be an argument for inclusionism. --Duplode (talk) 01:34, 17 July 2010 (UTC)


 * The change of terminology is not a change in regards of function but clarification about the aggregation of similar judgments. When someone puts a "stance" for transwiki (with the icon) most of the time they have done an assessment of the content in relation to at least the target of the proposed transwiki (some do more than that), it is important to safeguard that assessment work as a different tag on closing the discussion, it is important to make clear that even minority views on transwiki should be taken in account. It must be made clear that transwikis are not guaranteed and not all content determined as unfit for Wikibooks is equal or transwikable.
 * So yes we have a problem about preserving the work that is done on RfDs, and a responsibility in protecting all contributed freed content (deletion is not an irreversible process), even if we haven't a use for it now, it is important to get this translated on the way we archive the discussion. Do you see any problem in this premises ?  --Panic (talk) 02:57, 17 July 2010 (UTC)


 * I didn't understand why the idea the unsettled you, to err is to be human, but I do you like to err on the side of safety, especially when dealing with volunteer work in the job of the evaluation and the contributions. It is should be clear to all that with open collaboration comes unknown consistency, there is no way around that, unless standard are elevated and participation made hard, if that is promoting "inclusionism" then yes I think we should or at least more than we are now, kept works can always be improved. (Keep in mind that the project is funded by donation) --Panic (talk) 03:19, 17 July 2010 (UTC)


 * While I do think we should not stifle contribution by imposing overzealous standards and give due weight to the potential of a book when ruling on its destiny, once we start thinking too much about "analysing in broader terms" or "posterity" we can become too scared to draw a line and stand for project scope. For kept works are not only improved on but developed towards some goal, and despite our limited capabilities as volunteers we are supposed to judge whether that goal fits with the bigger picture of Wikibooks. In other words, the main issue would be to which extent we are (morally?) responsible for "protecting all contributed freed content" beyond the educational resources we intend Wikibooks to be made of. --Duplode (talk) 03:53, 17 July 2010 (UTC)


 * Ok so we seem to be in accord that raising the standards isn't something we want at least for now with the level of participation we have (I never proposed that in relation to this discussion, I said it is the only way to guarantee consistency). If you look on the RfD most of them are easy decisions. What we have trouble dealing is with the works that fall in the gay area of what is acceptable by WB:WIW, we rarely have people working intentionally outside of the scope of the project. I think small changes in the formalism can serve to reduce alienating contributors and improve the situation without doing any damage. How much we change is open to debate, I started only proposing a rename of the "transwiki" icon to "savable" but after the first round of discussion it seems that the icons itself and how they influence RfD closing to count position and not the power of arguments should be considered.
 * We are morally responsible to the degree we can and are willing to be, in fact, as I said, all the deleted content remains on the system, we could attempt to improve the RfDs to serve as an indication about what is deleted, for instance with special categories that can be used as we archive the discussions, without any special work on our part. Even failed transwikis could be reassessed later by the project that refused them, standards are always in flux, consider for instance the possibility that we decided to cover again video games manuals, working on our archived discussions would be a daunting task. --Panic (talk) 04:19, 17 July 2010 (UTC)

Just a reminder about this proposal discussion. Does anyone object to stop using the the "stance" icons and to the requirement that every RfD that promotes a transwiki be closed stating that the work request for transwiki was acceptance by the destination community (or not) or if no destination is no found for "savable" content (not an empty stub or trash, that it has some other intrinsic value) that the the closing statement indicates it as it is deleted ? --Panic (talk) 22:26, 23 July 2010 (UTC)


 * This discussion was too long and convoluted for me to follow, but I plan to continue to use stance icons. To me if a discussion ends on a transwiki, if it's not accepted at the destination, then it's deleted here as it's been indicated to be out of scope. As for an alternative to vote, the standard at Wikipedia is to use !vote. – Adrignola talk 22:56, 23 July 2010 (UTC)


 * I disagree with your assessment that people often just count positions, though I do think more people should include a rationale or explanation of why a discussion was closed. I think "keep" or "delete" alone is not a rationale or explanation of why a discussion was closed, in the same way as saying "keep" or "delete" within a discussion without an explanation as to why, is reason enough to disregard that comment.
 * "stance" icons are a convenience that people decided to use on their own without prompting or requirement that they be used. I believe there should continue to be no requirements one way or another to their use. I believe anyone that agrees will stop using them, and anyone that objects will continue to use them.
 * I disagree with closing a tranwiki discussion until the target destination has been informed and has had reasonable amount of time to decide whether it wants the work or not, unless people in the discussion have clearly indicated that they support deletion if the target destination is unwilling to take it. I wouldn't object to asking people to clarify what they think should be done with the work if the target destination doesn't want it, so that people don't need to be asked later should the target destination not want it and discussion doesn't need to remain open. Asking people questions on what you don't understand is probably the ideal outcome. --<span style="font: bold 10pt 'courier new', comic, sans, ms;"><font color="midnightblue">dark lama  23:04, 23 July 2010 (UTC)

Editor threshold
I've heard that WikiJunior edits don't count toward the 100 edits needed to not be reviewed. I think that WikiJunior book edits should count toward the 100. That's the proposal. Purplebackpack89 (talk) 03:40, 24 July 2010 (UTC)


 * This change is already in the works, along with a large package of other configuration changes that include somewhat reducing a couple of the other criteria for autopromotion. Having achieved consensus, we submitted a bugzilla request for the reconfiguration.  How long it will take before the changes are made remains to be seen.  It's a big change, and there was recently some confusion over the proof of consensus &mdash; due, it appears, to the humongous size of the discussion that led to consensus.  As of this writing that discussion is still visible above on this page, at ; in fact, it's larger than everything else now on this page put together.  --Pi zero (talk) 06:55, 24 July 2010 (UTC)


 * I think it will pass. Even Thenub supports the implementation though he opposed the proposal. Kayau ( talk &#124; email &#124; contribs ) 08:47, 24 July 2010 (UTC)

Autoconfirmation
(Oh, well. There are lots of long discussions going on. I guess there's no crime in starting another.) So, anyway, I'm not a big fan of the current autoconfirmation system. I know a lot of people will disagree with me, but IMHO, the current autoconfirmation system is close to useless. I don't understand why someone's account only has to be four days old to get to edit semiprotected pages, move pages etc. It's quite pointless isn't it? If someone wants to do page move vandalism or vandalise semiprotected pages, they just need to wait 4D. Or, maybe someone created an account months ago and decided to come round and vandalise when he was bored. I propose either tightening the autoconfirmation criterion, or getting rid of it once and for all. A good example would be the English WP, where your account must be a few days old AND have made ten edits. We don't have to be as mean as the Chinese WP (50 edits), not even like English WP. Maybe make a new account make five edits before it can get autoconfirmed. That way, if he's a vandal by the time he can edit semiprotected pages or do page move vandalism, he's blocked. Kayau ( talk &#124; email &#124; contribs ) 04:04, 19 July 2010 (UTC)


 * I thought about bringing that up when we did the reconfiguration before, but I didn't want to risk compromising the potential for the proposal to pass. I wasn't quite sure there would be support for it.  Adding an edit requirement and even going as far as Wikipedia in not allowing unregistered users to create new pages would probably stop some vandalism.  – Adrignola talk 12:12, 19 July 2010 (UTC)


 * I oppose to not allowing unregistered users to create new pages. According to my experience, page creation vandalism is much more frequent in WB than WP. On the other hand, regular vandalism is much more frequent in WP than WB. So I suspect the vandals create new pages here, thereby leaving our original pages alone. Kayau ( talk &#124; email &#124; contribs ) 12:48, 19 July 2010 (UTC)


 * Can you clarify your position? I can't tell for sure whether you want unregistered users to be able to create pages or whether you don't (the wording of the first sentence is the problem for me).  – Adrignola talk 13:11, 19 July 2010 (UTC)


 * I want unregistered users to be able to create pages. Kayau ( talk &#124; email &#124; contribs ) 13:55, 19 July 2010 (UTC)


 * So you suspect it pushes the vandals to vandalize where they can. To play devil's advocate, what's to say they wouldn't then make five hard-to-spot vandal edits before then hitting up a major page, creating more work in reverting? – Adrignola talk 14:05, 19 July 2010 (UTC)


 * Have you ever reverted a hard-to-spot vandalism? :) Kayau ( talk &#124; email &#124; contribs ) 14:23, 19 July 2010 (UTC)


 * Yes, I have. – Adrignola talk 14:37, 19 July 2010 (UTC)


 * I also oppose to not allowing unregistered users to create new pages. --Panic (talk) 16:38, 19 July 2010 (UTC)


 * @Adrignola: *RED FACED* however, Adrignola those are test edits. Is there any particular reason that you don't want IPs to make new pages? Kayau ( talk &#124; email &#124; contribs ) 06:13, 20 July 2010 (UTC)


 * It's not a strong position, but if anything, I would expect them to be unfamiliar with Wikibooks conventions such as the naming policy and the scope of the project and would want them to work with some existing pages to get a feel for things before starting a new book. But then this prevents creation of subpages of a book from red links.  Yet another limitation of the software: no way to allow creation of subpages but delay creation of new book root pages.  Many times it's difficult to tell whether a new root page is a "test edit" as you call it above or a genuine attempt at a new book.  Yes, we have query for that, but that's my assessment of the situation. Let's focus on your main concern: autoconfirmation criteria. – Adrignola talk 12:35, 20 July 2010 (UTC)

< > Ten edits look fine to me. At we are talking about it too. — I-20 the highway  06:56, 20 July 2010 (UTC)


 * I think the devil's advocate probably had the right of it: requiring an edit count for autopromotion will just create a new incentive for hard-to-spot vandalism.  The primary function of autoconfirmation is to gently steer the mischief of casual vandals; a lot of vandals are just messing around on the spur of the moment, and aren't going to remain interested for several days to get autoconfirmation.  The ones who do remain interested for several days are a different ilk, and even the ones who, in the event, lose interest in less than a few days might have been incentivized in the meantime.  --Pi zero (talk) 13:38, 20 July 2010 (UTC)


 * FWIW, I-20's discussion is at here it is. Kayau ( talk &#124; email &#124; contribs ) 07:24, 29 July 2010 (UTC)