Yes

Neutral

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)
2. 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)
3. 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)
4. 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 ^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 | email | 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 | email | contribs ) 09:25, 9 July 2010 (UTC)

Page sighting

Question: 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 — 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. --darklama 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, $wgFlaggedRevsOverride = false 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 validate 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. --darklama 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. --darklama 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  $wgContentNamespaces = NS_MAIN, 102, 110;  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. --darklama 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 ;-) QU ^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? --darklama 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 accuracy for $wgFlaggedRevTags 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. --darklama 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. --darklama 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. --darklama 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:#". --darklama 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 Wikibooks: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. --darklama 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 | email | 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 $wgFeedbackTags = array('reliability' => 3,'completeness' => 2,'npov' => 2,'presentation' => 1);, 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 $wgFeedbackTags = array( 'quality' => 1 ); but with tags being weighted I dunno what sort of effect a single tag would have on that extension. --darklama 05:01, 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?

Other than these two I see no objection to the proposal. Kayau ( talk | email | contribs ) 08:04, 27 June 2010 (UTC)

I would like to have this clearly stated on the Wikibooks: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 Wikibooks: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? --darklama 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. --darklama 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 Wikibooks: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 —showing the most recent version instead of the most recent sighted version— 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-20the 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. --darklama 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-20the highway 20:08, 28 June 2010 (UTC)

As far as I know, this should not have been on. As recorded at Wikibooks: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)

Question: 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—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 | email | 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 | email | 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 | email | 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 — 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. --darklama 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. --darklama 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. --darklama 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. --darklama 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. --darklama 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 $wgFlaggedRevTabs = false; 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. --darklama 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. --darklama 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 . --darklama 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? --darklama 22:56, 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 — 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 — but I too haven't RTFM) — 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.

--Pi zero (talk) 23:43, 30 June 2010 (UTC)

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. --darklama 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 — 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. --darklama 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 Wikibooks: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 Wikibooks: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 — 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 | email | 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 | email | 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 | email | 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. --darklama 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. --darklama 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. --darklama 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 Wikibooks: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. Wikibooks: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. Wikibooks:Revision review 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 Wikibooks:FlaggedRevs Extension/Unstable a low-level record of the configuration effects. Wikibooks:Revision review 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)

• Neutral 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. --darklama 23:40, 3 July 2010 (UTC)

1. Support, 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 #Reconfigure Wikibooks), which is the specification of record of how the configuration is to be changed — 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.

[{{fullurl:Wikibooks:Reading room/General#Reconfigure Wikibooks|oldid=1873833}} rev 1873833]

--Pi zero (talk) 17:32, 5 July 2010 (UTC)

Support

1. Support proposed code configuration in rev 1873833. --darklama 13:08, 29 June 2010 (UTC)
2. Support: I fully support configuration as defined in rev 1868918 or rev 1873833. – Adrignola talk 01:15, 3 July 2010 (UTC)
3. Support configuration in rev 1873833. --Pi zero (talk) 14:07, 29 June 2010 (UTC)
4. Support rev 1868898 which is almost equal to 1868352. —I-20the highway 19:48, 29 June 2010 (UTC)
5. Support the configuration defined in rev 1868352 or rev 1868918 or rev 1873833. QU ^TalkQu 20:28, 29 June 2010 (UTC)
6. Support as defined in rev 1873833. Arlen22 (talk) 16:07, 2 July 2010 (UTC)
7. Support rev 1873833 as summarized in this version of Wikibooks:FlaggedRevs_Extension/Unstable. --Panic (talk) 15:24, 5 July 2010 (UTC)
8. Support for the proposed reconfiguration at rev 1873833. Soeb ^{talk|contribs} 08:55, 7 July 2010 (UTC)
9. Support the proposals in the summary Purplebackpack89 (talk) 17:38, 24 July 2010 (UTC)
10. Support I'm not even an editor! but well. :P Diego Grez (talk) 17:40, 24 July 2010 (UTC)

Oppose

1. Oppose: I oppose configuration as defined in //en.wikibooks.org/w/index.php?title=Wikibooks:Reading_room/General&oldid=1873833#Reconfigure_Wikibooks 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)
2. Oppose: 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 ^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 ^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 | email | 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 Wikibooks: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) <comments removed> 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:

1. disrupt the continuity of a book;
2. 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;
3. 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 | email | 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.  – mike@en.wb:~$  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. --darklama 14:39, 2 July 2010 (UTC)

4. 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)

Follow-up

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", ...? --darklama 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. --darklama 23:04, 23 July 2010 (UTC)