Wikibooks talk:FlaggedRevs Extension

From Wikibooks, the open-content textbooks collection

Jump to: navigation, search

Contents

[edit] My thoughts

Here's my two cents on these proposals:

- Is it really necessary to flag templates? I think this would be a bad idea if it is necessary to re-link all of the references to the template to the stable version...though I confess I don't know how this flaggedrevs thing will work.

- I think instead of 4 flags we can just make sure that the flagging page has an (easy to see) link to the requirements (if we have any) for something to be considered "stable", and to WB:FB to show what the featured book requirements are.

- What is the fourth level? I assume that it is "unstable" and doesn't count under $wgFlaggedRevValues?

- What is meant by editcomments? Why is this a requirement?

- Agree about the email.

- I don't think it should be necessary for them to have a user page, since this is about content in the main spaces anyways...

What do you all think? Regards. Mattb112885 (talk to me) 01:03, 5 June 2008 (UTC)

The idea with requiring a userpage is that they need some level of dedication to the project. If you have a userpage, that reflects some (small) level of dedication.
editcomments means using the edit summary - this is some indication the user is a serious contributor
There are no longer 4 levels.
 – Mike.lifeguard | talk 22:18, 6 June 2008 (UTC)

I was looking at the current default settings and comments for this extension and noticed that there seemed to be some assumptions wrong based on how some things were set. Whether this is due to some confusion that we might need to have clarified from the developers or changes made by the developer since Mike first prepared a general proposal for the settings, I don't know. I've updated the proposal, but I doubt its what Wikibooks would want to use. From what I understand after reading the comments for the default settings, each flag has an associated level between 1 and X, with a corresponding system message we'll need to set. Do we want just one flag than? Like a quality flag between 1 and 3 with 0 being unset, or something different? There is also a minimum level for each flag for a revision to be considered a quality revision and a minimum level that all flags must be set to for a revision to be considered "featured" --darklama 00:36, 7 June 2008 (UTC)

[edit] Bot approval for inital sighting of authoritative pages

moved from Wikibooks:Reading room/Administrative Assistance#Bot approval for inital sighting of authoritative pages

I am User:Melancholie, bureaucrat and sighter on the Alemannic Wikipedia, SysOp and sighter on the German Wiktionary and operator of MelancholieBot for example. I want to apply for the "editor" right (= sighter) also on this wiki:

The reason for this request is that I do have a bot script available that can help you with the initial sighting process ("FlaggedRevs") for foolproof pages! Why? Not-yet-flagged pages will appear with a red exclamation mark, even if a sighter edited it. A sighter will have to sight it afterwards, even if the page has only been edited by absolutely trustworthy users in past! That's much much unneeded work!

My script will minimize and fasten up your extra work on this by sighting (flagging, marking) the latest revision of all reliable and clean pages (templates, images, articles; redirects) automatically, based on a user whitelist!

  1. Step #1:
    • Currently, only all SysOps of your wiki are on this list.
    • If you could confirm that your flagged bots did and still are working well (in respect of hidden spam/vandalism) I will add them too, what would be very important for the efficiency within the article namespace!
  2. Step #2:
    • Furthermore, please confirm that the content contributions of your sighters have been - respectivaly are (the latest revision gets flagged only) - free of spam and vandalism. With adding also all sighters to the whitelist, you could have the biggest benefit in respect of unnecessary work you will not have to do manually on your own!
    • Are there any reliable users, that are not yet allowed to sight?

You will be able to have an eye on that process all the time at Special:Log/review, by the way! But first I have to have the right to flag (sight) on this wiki. --- Best regards, Melancholie (talk) 05:51, 27 November 2008 (UTC)

By the way: If you should have any general problems (layout etc.) with the FlaggedRevs extension, please let me know. --- Best regards, Melancholie (talk) 06:07, 27 November 2008 (UTC)
The new set of tools are on a trail phase yet, until we figure out if the advantages and existing limitations (some that are particularly problematic to the Wikibooks setup were we have almost self contained multiple sub-projects) are worth all the "trouble".
After the test and if the decission is to keep the new system, further deliberation and reshuffling work is needed to make things clear to the community until we can use something like a sighters whitelist. I would also like to know if your script can be examined (source)?
In any case all this makes your request a bit premature... --Panic (talk) 06:33, 27 November 2008 (UTC)
See the newly approved Wikibooks:Bots policy and place the request in the Wikibooks:Requests for permissions when you feel it is right. (You will probably have to replicate most of what you already stated here.) --Panic (talk) 06:40, 27 November 2008 (UTC)
Do you have some good links to discussions about that "some that are particularly problematic to the Wikibooks setup were we have almost self contained multiple sub-projects" issues? --- Best regards, Melancholie (talk) 22:18, 27 November 2008 (UTC)
Most of what has been said has been done on the IRC channel but you may find some useful comments on some of the problem on Wikibooks:Reading room/General, I could repeat them here for you but it will all need to be well argued later, on the future discussion to keep/or not the toolset, consider the implications regarding our particular setup (the differences from Wikipedia or Wikitionary), even that dictates how the community interacts differently within the project, this has impact on several issues from content quality to licenses.
Personally I'm not enthusiastic about the new setup, the issues it addresses aren't as relevant to us (Wikibooks), and most can be resumed to cosmetic (all improvements) and procedural alteration with no particular benefit to us (I do see some as useful to other Wikimedia projects), some of the features would be great if the toolset were directed more to our particular needs. One of the discussion I remember on the IRC was on the limitation created by only the last review being shown to the users, some great alternative approaches were advanced by Darklama (if you want to talk to him on IRC his alias is darkcode.
If you think this issue needs more clarification we should probably move this and centralize it on Wikibooks:FlaggedRevs Extension talkpage, I think it is the best pace to have a real discussion on the subject in a way the rest of the community can fallow and contribute. --Panic (talk) 23:34, 27 November 2008 (UTC)
I like this idea very much, in some ways. However, I am not sure it makes good sense for us here right now. We're naturally drifting towards using this extension to judge page quality, not just to verify that it doesn't contain spam or vandalism. A bot just can't use the same kind of judgement that a human can when judging a page for quality. Marking a page as being "trusted" to not contain vandalism is interesting, and maybe other editors will be supportive of that (I might support it too, after some consideration), but I'm not sure that is something that's helpful to us. I would definitely like to hear some more opinions on this matter. --Whiteknight (Page) (Talk) 15:19, 28 November 2008 (UTC)
I think being able to trust the accuracy of a page is much more important to readers than whether a page is free of vandalism and spam. At least if I was going to read a book from Wikibooks, accuracy would be more important to me anyways. I think vandalism and spam would often be obvious to most readers. However I also think a page that has correct spelling and grammar, good structure, consistent style, is verifiable and has good or great coverage is going to be both free of vandalism and spam, and be what readers are going to be looking for. --darklama 17:02, 30 November 2008 (UTC)
I think it makes sense to use the lowest values on the three criteria for this purpose. That is intended to mean "free of vandalism" and can easily be set by bot. For ratings higher than that, we of course need humans to flag pages. So, I support the idea (I'd like to look at the bot's proposed settings etc before saying I want the bot to actually run. But the idea is definitely good!)  — Mike.lifeguard | talk 17:07, 30 November 2008 (UTC)
I disagree that using the lowest values for this purpose makes sense. Doing so could lead to associating poor quality with vandalism when poor quality is not always due to vandalism. Associating all forms of poor quality with vandalism would be to fail to assume good faith. For example poor quality could be the result of a non native speaker who is doing their best to try to help improve a page. I think calling a person a vandal or their contribution vandalism due to only being non native wouldn't be good and would only diminish the friendly and open atmosphere of Wikibooks. Even a native speaker who knows a lot about a subject might not be that great at expressing concepts, but can still help improve books. --darklama 17:46, 30 November 2008 (UTC)
I don't see how that follows from the suggestion that flagging some pages as "not vandalism" is a good idea. Perhaps you misunderstand that saying "not vandalism" isn't the same as saying "not good quality" -- it is a minimum, not a maximum. That a page is flagged at the lowest level doesn't mean that it isn't even better quality than that - only that the page hasn't been flagged to a higher standard yet.  — Mike.lifeguard | talk 17:59, 30 November 2008 (UTC)

[edit] Autopromotion requirements

I would like to recommend that we drastically lower and simplify the requirements for people to be autopromoted to +Editor. I don't know what the current requirements are, but I do know that it's a complicated list. We have had requests for promotion from several people who definitely should have been flagged for autopromotion, but had not been for unknown reasons. I suggest that users be autopromoted to +Editor at the same time and under almost the same conditions as the software currently uses for +Autoconfirmed status. Here are the requirements I propose:

  1. Have an account for at least 4 days. This is the current requirement for +Autoconfirmed.
  2. Have at least 10 edits of any size in any namespace.

We need more good people to be automatically flagged and promoted by the system. This is the only way that we are going to be able to get pages reviewed and keep them up-to-date with reviews. Also, it will help to reduce several problems I've been seeing. One example of a problem is the case of class projects, where students are making edits that are not visible by default. This happens when one prolific editor (like a teacher) makes an edit to a page, which automatically marks the page as sighted. Then, when the non-editor students edit the page, their contributions are not visible without review. This is obviously terrible for class projects, and can be very difficult to work around for very large books or for very large class sizes. Thoughts? --Whiteknight (Page) (Talk) 19:57, 6 February 2009 (UTC)

I think the spacing and benchmarking settings are the two that are seriously delaying auto promotion for people who should be able to review pages. I think we need to understand better what those two settings do exactly before messing with them. I don't think changing any other settings will make much difference without first trying to improve those two settings. I think possibly those two settings are causing a delay of 45 days or more for auto promotion. I think if those two settings were lowered there should be less delays.
I also think some people are overestimating the problem. About 87% of pages are reviewed if I'm reading the statistics correctly. --darklama 21:55, 6 February 2009 (UTC)
Not sure you are reading that right... 6.42% reviewed is the figure the stats give me. Unusual? Quite TalkQu 09:57, 10 February 2009 (UTC)
Personally I think 10 edits and 4 days just isn't enough. In that time the user won't have even begun to learn the basics of the manual of style, the appropriateness of content here and so on. The current settings are perhaps too long though. Unusual? Quite TalkQu 22:01, 6 February 2009 (UTC)
Although I do still think there needs to be better clarity around what the requirements are as this would reduce the number of requests for the permission and more likely to stick around contributing until it was met. To use me as an example of why I think this is a problem, based on the latest stated criteria:
  • Account is 30 days old - First edit was 2 October 2007 - pass
  • 100 edits (excluding deleted edits) - about 1,500 - pass
  • 15 edits spaced at least 3 days apart are needed (which takes at least 42 days) - since 23 December, which was 45 days ago I have 1,500 edits - pass
  • 10 recent content edits (50 content edits total) on 10 unique pages. As above, pass
  • at least 50 edit summaries used. Every edit has a summary - pass
  • Must have an email confirmed and enabled in Special:Preferences - Yes. Pass
  • Must have a userpage (min size 1 byte) - Yes - pass
  • Must not share an IP with other users (at the moment when promotion occurs) - Pass
  • Never been blocked or demoted from Editor or Reviewer (such users may make a request, since they will never be autopromoted) . Pass
So, obviously I've read something wrong because the software hasn't autopromoted me yet... but it sure isn't clear what that "something" is. I've been around the Wiki projects for three years, so if I'm confused you can guarantee real new users will be! Unusual? Quite TalkQu 18:46, 7 February 2009 (UTC)
Ya if what that "something" is could be determined, the requirements could be clarified or could possibly try to update that "something" so its no longer a factor. --darklama 19:29, 7 February 2009 (UTC)
The delay could still be the "15 edits spaced at least 3 days part" criterion. It seems we don't know exactly how the system judges "at least 3 days apart", nor how it chooses benchmark edits. If I start with your most recent edit as a benchmark, then go to the next one that's at least 72 hours before that, and so on, I count 17 benchmarks (the 17th is your first edit, back in October); but if, say, the system rounds down to the day based on dates, so that each pair of edits have to have dates that differ by at least 4, then you've only got 14. If that were the case, then you'd be autopromoted sometime in the next few days. If that were the case and they really meant 15 intervals rather than 15 benchmark edits (or if they define benchmark edits in a way that has the same net effect), then you'd be autopromoted sometime within the next week. --Pi zero (talk) 20:23, 7 February 2009 (UTC)
Well, when it auto promotes we'll have a better idea (maybe!)... I admire your effort in counting through my edit history as well! Unusual? Quite TalkQu 21:37, 7 February 2009 (UTC)
I think 10 edits and a period of 4 days is not enough to stop vandalism by Editors. The vandalism warning on the wikijunior main page currently says that reviewed pages are "guaranteed" to be free of vandalism. Even now I find this statement quite risky. If we lower the requirements to 10 edits and a period of 4 days, I would think that reviewed pages have only a slightly higher chance to be free of vandalism than non-reviewed pages. The whole idea of reviewing would make very little sense to me. --Martin Kraus (talk) 14:13, 8 February 2009 (UTC)
I agree. The criterion for autopromotion should be strong enough to make vandalism by Editors unlikely. I believe the only criterion that's probably too stiff right now is the 15 benchmarks spaced 3 days apart — and I'm waiting to see just when QuiteUnusual gets autopromoted before deciding how I think those numbers should be adjusted. I do think a large number of benchmarks is desirable, because it's an excellent measure of commitment to the project (and, on the flip side, gives the user an opportunity to develop commitment to the project). The biggest question in my mind is what "n days apart" actually means, and therefore what number of days between we ought to be asking for. --Pi zero (talk) 16:01, 8 February 2009 (UTC)
My first reaction is to not do anything drastically. I agree with darklama that this isn't necessarily such a big issue.
Still, all we really need is to set the criteria high enough so that we can catch "bad" contributors before they get editor status (as opposed to identify the "good" ones so we can "promote" them). I think the spacing criteria is unnecessarily complex and unless it's really useful and can be easily epxplained to users (it seems that we don't have a good idea of how it works ourselves) we should just drop it. I looked at the extension and help page on MW, but couldn't find details on what constitutes a "recent edit". Does anyone know?
The others are mostly fine. A hundred edits is reasonable, but we could safely bring the account age down to a couple of weeks (hardly too long for committed contributors). I'd be weary about changing too many of these at once. --Swift (talk) 17:54, 9 February 2009 (UTC)


[edit] Account is 30 days old

This doesn't make any sense, especially since we have the requirement below which is 42 days. Why does it need to be this long? A person is autoconfirmed in 4 days, can upload images and move pages in that time. Being an +Editor doesn't mean that the person has a great grasp of our editorial standards (that's what +Reviewer is for), it just means that the person can recognize what is and is not vandalism. +Autoconfirmed is what we already use to weed out vandals (since image and page-move vandalism is the worst, and this is what +Autoconfirmed prevents), so that should be enough to separate the good from the bad contributors. This should be 4 days, there's no need for it to be any longer. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

I disagree. +Editor is intended for people who have a grasp of Wikibooks' editorial standards. +Reviewer is almost completely pointless here. The only thing a +Reviewer can do that an +Editor cannot do is mark a page as feature quality. With that in mind, 30 says is about how long it takes to become familiar with Wikibooks' editorial standards. --darklama 01:05, 11 February 2009 (UTC)
I favor keeping the 30 days. As for the function of +Editors, it seems to me the truth is a bit of each of the two views mentioned. An +Editor is someone who is trusted to judge whether an edit should be allowed in to the default revision, visible to the general public by default. Part of that has to do with vandalism; the +Editor should know what is and isn't vandalism, and there should be exceedingly high confidence that the person did not get the account for the purpose of vandalism (autoconfirmation may cut out the vast majority of vandals, but even I (who don't go looking for such things) have seen vandals create an account and wait four days; and my vandal-exclusion threshold has been formed with Wikijunior in mind). There is also a degree of editorial screening involved, since even beyond subtle vandalism there are things that should be filtered out, things that should be let through in modified form, and, yes, even things that are flawed but ought to be allowed through anyway. I'm comfortable, so far anyway, with the current dividing line between +Editor and +Reviewer. --Pi zero (talk) 18:21, 11 February 2009 (UTC)
If +Editor means that the user requires a working knowledge of all our best practices, then we should change it so that this is no longer the case. FlaggedRevs wasn't really designed to be used as a comprehensive and sustainable grading system, it was designed as a system to mark pages as being vandalism-free and preventing certain users from seeing page vandalism. This design philosophy is evident, and we are seeing a lot of problems because we are trying to make this tool do something that it's not well suited for. +Editor's should be able to view the page in regards to vandalism and mark it yes/no. If this is all they can do, then there is no reason to place stringent requirements on their autopromotion. If the requirements for autopromotion are too high, then autopromotion isn't a useful tool at all. We will simply manually promote people when they demonstrate a need for the tool instead of waiting for an autopromotion that is too slow. Autopromotion either helps us distribute the tools to the people who need it, or it doesn't help. In either case, the people who need it will get the tools, but without an agressive autopromotion Myself and others like me will have to waste our time doing it manually. --Whiteknight (Page) (Talk) 13:28, 13 February 2009 (UTC)
I think we're not getting anywhere fast with these seperate views on the purpose of +editors. I think we can all agree that it should be easy for people to get sighting tools to verify pages as free of vandalism, while reviewing tools can require higher criteria. See below my proposal to redefine the boundary between the two. --Swift (talk) 09:46, 14 February 2009 (UTC)

[edit] 100 edits (excluding deleted edits)

Too many, why 100? A person should be able to become +Editor in 4 days, which is the length of time I recommend. If a person can't reasonably meet the time requirement and the edit requirement at once, they are mutually redundant and not helpful. This should be no more then 40 (10 edits per day). --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

100 edits in 30 days is a very low edit count in my opinion, that is about 3 edits per day, lower than what you are suggesting. I think the defaults for FlaggedRevs is 300+ edits in 60 days which is about 5 edits per day. I don't think 10 edits per day is very reasonable to expect of volunteers. --darklama 01:05, 11 February 2009 (UTC)
100 edits is not lower then I recommend. I recommend no more then 50 edits, and I'd prefer 10-30. +Editor is currently a tool to grade the quality of a page, which means the ideal +Editor is an active reader, not an active contributor. Again, as I mentioned above, if autopromotion doesn't give people the tools when they need it, then it's broken and useless. I will manually promote people long before they reach all the arbitrarily-high standards that we're setting here. +Editor isn't some big deal, it only gives people the ability to make a review and a recommendation about a particular page. We don't need +Editors to demonstrate themselves to be great wikibookians (+Admin requires those kinds of hoops), we only need to require that people be demonstrably not a vandal. 10 edits proves that a person is not a vandal. 100 doesn't prove anything extra. --Whiteknight (Page) (Talk) 13:33, 13 February 2009 (UTC)
I wasn't talking about the total number of edits but the average per day that it comes out to. A vandal can easily make 10 or even 100 edits. Alone this criteria doesn't mean a thing, but combined with other criteria its useful. So far people have shown a strong desire for editors to prove themselves, so promoting people who don't get autopromoted might be a bad practice on your part if consensus is that editors need to prove themselves some. Maybe Wikibooks isn't using FlaggedRevs as intended or maybe it is. I don't think the intended use of FlaggedRevs really matter if people want to use it a different way. --darklama 16:10, 13 February 2009 (UTC)
I don't think that an average number of three edits per day is a huge hurdle. I suggest we don't lower that for the time being. We can always reduce this later. --Swift (talk) 09:52, 14 February 2009 (UTC)

[edit] 15 edits spaced at least 3 days apart (takes at least 42 days)

This is redundant and unnecessarily complex when you consider the above two requirements. Kill this. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

Its 15 edits each spaced 3 days apart actually. I agree that the current settings are bad. I think this should be 4 edits each spaced 7 days apartment. That is 28 days. --darklama 01:05, 11 February 2009 (UTC)
I've been looking at the edit histories of several people recently autopromoted, and in practice it's likely to take significantly longer than 42 days. (BTW, at 7 days between, 28 days would require 5 benchmark edits.) I think a largish number of benchmarks on this criterion is an excellent way of assuring serious commitment to the project (as I've remarked earlier in the general thread), but missing a couple of days — if it happens to be just before a 3-day interval would end — can set the whole autopromotion process back two days, which is excessively stringent. I suggest 10 edits spaced at least 2 days apart. --Pi zero (talk) 18:37, 11 February 2009 (UTC)
I looked at the source code yesterday for FlaggedRevs. From what I could can tell if my first edit was Feb 11 2009 @ 12pm that would be my first benchmark. My second benchmark wouldn't be until at lest Feb 14 2009 @ 12pm. If say I didn't edit again until Feb 25 @ 1pm rather than Feb 14, Feb 25 2009 @ 1pm would be my second benchmark. My third benchmark would due to the second delay not be until at least Feb 28 2009 @ 1pm. So I think how often someone edits effects how quickly they will be auto promoted using benchmarking and spacing criteria. I guess 10 edits spaced 2 days apart (or 11 benchmarks) wouldn't be too bad either and could reduce the problem of not editing that often, while still showing interest in contributing to the project over time. --darklama 19:19, 11 February 2009 (UTC)
Are you saying that N edits spaced at least M days apart means that the system looks for a series of N edits where the n-th one comes no less than M days after the n-1-st? --Swift (talk) 06:25, 12 February 2009 (UTC)
Yes, that sounds right to me. --darklama 13:48, 12 February 2009 (UTC)
Then this is basically a requirement for regular edits, rather than spurts. Can anyone really see a big use for this? I think we can well do without. --Swift (talk) 09:55, 14 February 2009 (UTC)
Howabout no edits over no days? Why do we need this requirement when we already have a mandatory edit count and a mandatory time limit? In the best case this is worthless redundancy, and in the worst case it's a confusing point of failure for a system that doesn't promote people fast enough and already makes too many false negatives. Seriously, this is a very bad idea. --Whiteknight (Page) (Talk) 13:35, 13 February 2009 (UTC)
Inclined to agree here. If we have number of edits and time since registration AND number of recent edits, then this becomes redundant. I'm open to changing my view, if at some point I actually understand how this feature works. Unusual? Quite TalkQu 13:55, 13 February 2009 (UTC)
We don't know that there's anything more wrong with the benchmarks criterion than that the current settings are too big — though there's probably something else wrong too, because frankly the fact that QuiteUnusual hasn't been autopromoted has now passed into the realm of the inexplicable; I'm going to take another look at the source code one of these days, when I can gather together the time to do it properly. Meanwhile, here's why the benchmarks criterion is quite different from time since registration plus recent edits. Suppose the settings asked for 5 edits spaced 6 days apart — not the settings I favor (as I've said above), but simple to explain. Now suppose someone creates an account, makes a slew of edits that day, walks away for a year, and then makes ten more. They've met the criteria for total edit count (what I mean by "a slew of edits"), time since registration, and recent edit count. However, the initial slew of edits only provide one benchmark because they're all within 6 days of each other, and the edits a year later only provide one benchmark because they're all within 6 days of each other. On the other hand, the user could satisfy the benchmarks requirement by making a few edits every tuesday for 5 weeks. (Remember, though, I favor 10 benchmarks spaced 2 days apart; that could be satisfied much faster by a steady contributor, probably in less than a month, but contributing only on tuesdays it would take them ten tuesdays.) --Pi zero (talk) 15:24, 13 February 2009 (UTC)
I agree with Pi zero. We don't know there's anything wrong with spacing and benchmarking other than being too high. There might be a bug in FlaggedRevs that our current settings are getting blamed for. --darklama 16:15, 13 February 2009 (UTC)

This was reduced to 10 edits spaced 2 days apart, on 18 May 2009 via bugzilla:18421. --Pi zero (talk) 14:02, 2 August 2009 (UTC)

[edit] 10 recent content edits (50 content edits total) on 10 unique pages

Why edit more then 10 pages? If a person is creating a new book, they create the TOC, and start working through the book from start to finish. If the person is particularly diligent, it may take a long time before he creates that tenth page. What's the difference really between making 10 edits to 1 page (and making it a very good page) or one edit each to create 10 stub pages? Kill this requirement. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

I think the current defaults make sense. I don't think a person can really understand editorial standards by contributing to just 1 page. --darklama 01:05, 11 February 2009 (UTC)
Again, the ability to review a page is indicative of an active reader, not a prolific contributor. If people who made many contributions were automatically good judges of quality, we wouldn't have so many pages of such low quality. There are lots of user accounts around here who have edited more then 10 pages and edited them all poorly. Having any number of edits, or having edited any number of pages doesn't mean the person is a good judge of quality. The only thing an edit count or a page count can help demonstrate is that the person is not a vandal, which is really the purpose of this extension in the first place. --Whiteknight (Page) (Talk) 13:38, 13 February 2009 (UTC)
Alone this criteria is meaningless, but I think combined with other criteria it helps. I think weeding out editors is a good thing. Wikibooks should want high quality edits to stick out above low quality edits, and in order to do that editors need to have some experience telling the difference to be able to grade revisions correctly. Personally I would like it if there was another criteria that could be used to limit promotion: Must have X number of revisions that have been graded above a certain threshold. That would be a bit better than this, but since this is all we got, this combined with other criteria I think is good enough to make some difference. I don't think requiring people to edit at least 10 pages is asking for much. --darklama 16:23, 13 February 2009 (UTC)
I just can't understand what you are talking about. What benefit is there to having fewer Editors then having more of them? It's not just every page that needs to be reviewed (and we have thousands of pages), but it's every revision of every page going forward that needs it. A page that is reviewed is out of date and needs to be re-reviewed again after a non-Editor edits it. Given our current activity levels, we just don't have the mass of Editors available to keep up with all the good content edits that people are making.
Trying to sequester this tool, and trying to keep it out of more hands does no good and does seem to be causing substantial harm. I have received no less then three separate requests from authors to disable FlaggedRevs from their books, because it is disrupting the ability of contributors to even see the edits that they are making. Now I know that we can't really disable the extensio on a per-book basis, and I've had to send out several appologetic emails in response to tell people this. FlaggedRevs is having the opposite net effect from what we wanted when we first installed it. Instead of improving Wikibooks by increasing page quality and stabilizing books for classes, it's hindering Wikibooks by hiding improvements from readers and preventing class projects from using our site. In an ideal setting, all these different requirements for autopromotion make good sense. I agreed with them all when they were first put onto the table. However, we're seeing the real-world effects of these things now and the system is not working the way we had intended it to work. We have to look at this issue with an eye not towards what we would like ideally, but instead with an understanding of what the real effects are. FlaggedRevs is causing problems, and if we refuse to fix it reasonably, then I'm going to strongly suggest we uninstall it completely. --Whiteknight (Page) (Talk) 19:23, 13 February 2009 (UTC)
This isn't a binary choice between (a) leaving the settings as they are or (b) eviscerating them so that they're pretty much just autoconfirmation. I think everybody agrees that (a) unacceptable. But there's a lot of territory between (a) and (b), and so far I see no reason to assume that the problem mightn't be fixed simply by a moderate reduction in these parameters (for which, as a first attempt, I've suggested 10 edits spaced at least 2 days apart — and if that doesn't work, and we still think this criterion is the hangup, that still wouldn't imply (b)). --Pi zero (talk) 21:17, 13 February 2009 (UTC)
I can't understand why editors would be complaining to you that they cannot see there edits. Are these editors not registered users? I can't understand how you think any of these changes would benefit anonymous editors. Registered users should always be able to see there changes, this includes editors. I don't understand how this is hindering class projects. Are most students editing anonymously rather than registering an account? What does any of this have to do with readers? None of your proposed changes will help readers or anonymous contributors.
I don't think every revision needs to be reviewed at once. Whatever is the current revision near the end of the class day could be reviewed to have any changes since the previous day appear for instance. I doubt people will support uninstalling the extension if they want to keep most of the configuration as is. If you want more people to see things from your point of view I suggest you begin by agreeing to decreasing the rate for benchmarks and spacing first as people seem to agree with that, than if that is not enough people are more likely to consider other changes. --darklama 22:23, 13 February 2009 (UTC)

(unindent) Well, this is a bit away from where this tread has gone, but I think 10 pages is too much. I have worked very hard for a bit more then a month and my editing has been confined to two pages. I suspect that that this criterion is what has kept me from getting editor privileges automatically (maybe not, I have no idea what recent means in this context.) So taking myself experience guide, requiring two distinct modules? If you really take the time to make them them good, that is a lot of work. I have to agree with Pi zero, we have a lot of room to choose from, but I do think the current system is not welcoming to new editors. As a comment on salesmanship, we auto change the term "editor" to "publisher". Anyone who edits a page is an editor. I was an IP editor for a while before I opened an account and even then I was an editor, editing that should not be discouraged. Implying someone is less then an editor even though they actively make changes to modules is discouraging. —The preceding unsigned comment was added by Thenub314 (talk • contribs) 21:22, 15 February 2009 (UTC)

I agree with Darklama that someone working on less than ten modules is well enough aware of the standards to be able to validate pages. For sighting, however, I think it doesn't matter how many pages a user edits. This is one of the reasons I proposed we limit +editors to sighting.
On the recent edits front, I think it is useful to require a certain number of recent edits. Can anyone confirm how recent "recent" is? I think I saw a mention of 30 days, but the extension and help pages on MediaWiki didn't give anything. --Swift (talk) 13:10, 15 February 2009 (UTC)

[edit] At least 50 edit summaries used

I rarely use edit summaries because I feel that many edits I make are self-explanatory and non-controversial. This might not be one of our "best-practices", but I won't support a requirement on new users that's more steep then we require of our older users. Kill this. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

I think using edit summaries is a good practice. With the current settings half of a contributor's edits need an edit summary. I think this is ok, maybe a bit high. I wouldn't object to having this set to 25 so that 1/4 of a contributor's edits need to have an edit summary. I don't think anything lower than that would be helpful. Edits aren't self-explanatory. You would actually have to view a diff to know what was changed. Good edit summaries can help reduce that need. --darklama 01:05, 11 February 2009 (UTC)
Edit summaries are a good practice. Also, considering that the section name automatically generated when editing a section counts as an edit summary, to get past the other criteria with fewer than 50 edit summaries you'd probably have to habitually not write summaries and habitually use the page edit tab for everything. I have no problem asking +Editors to at least have learned how to follow better practices than that, even if they do consciously choose not to follow those practices later on. I'd be tempted to suggest increasing this number, but I don't feel strongly enough about it to justify going against the headwind it looks like I'd encounter. --Pi zero (talk) 01:48, 12 February 2009 (UTC)
I think edit summaries are a very good practice. It is the nature of misunderstandings that you don't expect them and a short notes are an enormous help in tracking down versions in edit histories. There is little or no benefit in omitting these and I'd wholeheartedly support the suggestion to increase the ratio (that should give it a bit of a gust from the stern ;-)). --Swift (talk) 06:13, 12 February 2009 (UTC)
There's a difference between saying that it's a good practice and saying it should be a requirement. Keep in mind that +Editors don't have any special "power" over a page, they can only mark a page as being of a particular quality. If somebody can explain to me how writing edit summaries is in any way related to a person's ability to judge the quality of a page, I would love to hear that. Keep in mind that this is just an automated tally, it doesn't say anything about the quality of those edit summaries. A person who wanted to bypass this requirement could simply put random gibberish into the summary box and it would count. If a person needs +Editor and aren't using edit summaries, they are going to get manually promoted anyway. So in those cases, the autopromotion requirement really isn't a help, it's a hinderance. A system that produces too many false negatives is a huge waste of time and resources, because good editors are going to have to manually promote all the people that the system forgot. Putting in all sorts of unrelated and unhelpful requirements into the system just increases the number of false negatives and therefore increases the workload at WB:RFP. Please, kill this. --Whiteknight (Page) (Talk) 13:45, 13 February 2009 (UTC)
Yes, there is a difference. I'm saying both. The former is simply the rationale for the latter. Filling in edit summaries is a good idea and requiring (part of) them to be filled in is a helps raise awareness of this. This is not a high bar to pass.
Oh, and I seriously doubt that many new users would be so immature that they won't get the point and intionally fill in unhelpful edit summaries just to get this flag. --Swift (talk) 10:27, 14 February 2009 (UTC)

[edit] Must have an email confirmed and enabled

I like this requirement. Keep it as-is. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

I do too. I think contributors who go out of there way to set and confirm there email address are more likely to stick around. Also means people might have another way to get in touch with inactive editors. --darklama 01:05, 11 February 2009 (UTC)

[edit] Must have a userpage

Don't like this, it's requiring a particular form of self-expression. Plus, any vandal can create a disruptive userpage for you, that doesn't mean that you're more trustworthy. Kill this requirement. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

I don't see a problem with requiring a user page. Despite vandals, I think if someone creates a user page that means they see a reason to stick around, rather than editing one day and gone the next. --darklama 01:05, 11 February 2009 (UTC)
I've always thought the legitimate community function of user pages is to let each user offer information about what they might be capable of, or interested in, helping with. That makes the presence of a user page a sign of community involvement — and an inexpensive one at that, since the user page only has to be at least one byte. So either it's a useful requirement, or it's a harmless one. --Pi zero (talk) 21:44, 11 February 2009 (UTC)
I found this especially odious. I don't want a user page, I am happy with an active discussion page. I really have nothing of interest to say on my user page and I would prefer to say nothing. But, I would like to be able to review pages so I "jumped through the hoop". Why should I be required to have a user page, shouldn't my involvement in the community be better judged by my edits? This seems requirement seems really pointless to me. As Whiteknight says above, Kill this requirement. Thenub314 (talk) 08:46, 15 February 2009 (UTC)
I don't think this matters much either way. For those who think userpages are useful, I think the red-links in the signature is motivation enough to set something up. I've seen plenty of userpages for users who never contributed much. My userpage isn't very descriptive and I just use it as a scratch-pad for what I'm up to. Edit counts etc. are better for evaluating dedication to the communtiy. That said, it really is only a single byte. --Swift (talk) 09:22, 15 February 2009 (UTC)
I find the "It's just one byte." argument for keeping this requirement rather weak. Certainly if we require only one byte then we are not specifically asking people to list any useful information. It also has the following effect, an editor may be excellent, but may not bother looking up the details of how auto promotion works. It is my opinion the requirements would be set up in such a way that such people should be auto promoted anyways. This requirement may prevent this from happening. Thenub314 (talk) 09:37, 16 February 2009 (UTC)
Yes, it isn't much of an argument at all. As I don't see the benefit in requiring userpages, I guess we should just scrap this. --Swift (talk) 10:24, 16 February 2009 (UTC)
A possible middle ground occurs to me (though one mightn't have guessed there would be a middle ground on a yes-or-no setting). The problem appears to me to be internet-cultural: As I remarked earlier, in principle it seems to me like a good practice to provide potentially useful, project-relevant information to other editors (small 'e') about one's capabilities and, sometimes, interests; for example, when I first created my own user page on wikipedia, nearly the only information on it was {{User en}}. However, in internet culture, when a website asks for a user page, it's usually about socializing — e.g., "I'm a left-handed transsexual who likes cats and mexican food." So when we say "Thou shalt have a user page", and we don't say anything about why, people think, "Why are you requiring me to talk about cats and mexican food?" Perhaps providing a small hint when listing this requirement, like a reference to Wikibooks:Babel, would remediate this problem? --Pi zero (talk) 12:35, 16 February 2009 (UTC)
It is certainly better then giving no reason for the requirement. But after being wiki-stalked at wikipedia, I have decided I want to include little to no information about myself. My thesis advisor joked I did not speak english as a first language (despite the fact I do not speak any other languages, notably his first language was spanish). I think I would rather be judged solely on my edits, and not have people accept what I claim my abilities are. Thenub314 (talk) 14:58, 16 February 2009 (UTC)
I agree that the user page requirement doesn't make sense to me. If someone has been editing for a month, has edited the required number of different pages, and still doesn't have a user page, there's probably a reason for it beyond non-involvement. Mattb112885 (talk to me) 23:23, 18 February 2009 (UTC)

This requirement was dropped, on 18 May 2009 via bugzilla:18421. --Pi zero (talk) 14:05, 2 August 2009 (UTC)

[edit] Must not share an IP with other users at the moment when promotion occurs

Terrible for places like schools where many users may be collaborating on a project together, from a single IP. This is not only not helpful, but it's actually counterproductive. Kill this ASAP. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

Actually this only requires that you don't share an IP with someone else in recent changes. I guess I don't see the harm in killing this. --darklama 01:05, 11 February 2009 (UTC)
This is mostly useless - it might be worth restricting TOR, but not vanilla IPs.  — Mike.lifeguard | talk 02:03, 23 May 2009 (UTC)
Is there any particular reason your commenting on this now, after this requirement has been dropped? --darklama 16:05, 23 May 2009 (UTC)

This requirement was dropped, on 18 May 2009 via bugzilla:18421. --Pi zero (talk) 14:07, 2 August 2009 (UTC)

[edit] Never been blocked or demoted from Editor or Reviewer

Such users may make a request, since they will never be autopromoted. No opinion on this either way, It's hard for me to imagine what would have to happen for us to take away +Editor or +Reviewer rights anyway. If a person is disruptive we can block them, we won't bother taking away their non-disruptive tools.

I think this is good as is. Anyone who has been blocked or had these tools removed should probably undergo a review by the community first. --darklama 01:05, 11 February 2009 (UTC)

[edit] Comments

So these are my thoughts on this. I also want to mention that we are having significant problems with this right now. Classes are having problems where their students are making edits and can't view them because they aren't being autopromoted fast enough. We also have the case of User:QuiteUnusual who definitely should have been autopromoted so far and definitely has not been yet. Too many false negatives is problematic on many levels. We need to tone this back drastically. --Whiteknight (Page) (Talk) 00:26, 11 February 2009 (UTC)

If the students are registered they should always be seeing the latest revision of a page. If the students aren't registered, none of this is going to make one bit of difference in what they see. --darklama 01:05, 11 February 2009 (UTC)

[edit] Summary

There hasn't been much activity here lately (about a month now). In the interest of moving this long, here's a summary of the discussion above:

#Account is 30 days old
Stays for now. No agreement.
#100 edits (excluding deleted edits)
Stays for now. No agreement.
#15 edits spaced at least 3 days apart (takes at least 42 days)
Lower this to 10 edits, spaced 2 days apart as a first step. This has been identified as one of the major mysteries and potentially the cause why people aren't getting flagged for +editor. Some favour dropping it while others reducing it.
#10 recent content edits (50 content edits total) on 10 unique pages
Stays for now. No agreement as one side wants to get more people sighting while the other wants to ensure the reviewing tools are in proper hands. This impass may be solved by restricting the +editor flag tools to sighting.
#At least 50 edit summaries used
Stays for now. No consensus, general agreement or overly strong arguments either way.
#Must have an email confirmed and enabled
Stays as it is. Consensus that this is useful.
#Must have a userpage
Drop this. Some dislike this requirement and no-one feels strongly about keeping it.
#Must not share an IP with other users at the moment when promotion occurs
Drop this. No-one defends this.
#Never been blocked or demoted from Editor or Reviewer
Stays as it is. No-one objects.

There are a number of changes for which there seems to be consensus. Let's implement the agreed on changes and see what effect they have. Who has access to the extension settings? --Swift (talk) 06:54, 13 March 2009 (UTC)

  • Good summary, has my support to be changed as you describe. Unusual? Quite TalkQu 08:38, 13 March 2009 (UTC)
  • Support. --Pi zero (talk) 12:46, 13 March 2009 (UTC)
  • Support the three changes. --darklama 13:18, 10 April 2009 (UTC)
    See bug #18421 --darklama 13:38, 10 April 2009 (UTC)
    This has been fixed. :-D --Swift (talk) 07:21, 22 May 2009 (UTC)
    Would I be violating protocol if I were to update this project page to reflect the changes? --Pi zero (talk) 13:00, 12 June 2009 (UTC)
    Yes check.svg Done --Pi zero (talk) 15:20, 2 August 2009 (UTC)

[edit] Other changes to FlaggedRevs

While I'm on the subject, what do people like about the FlaggedRevs implementation we have here? What do people dislike about it? I think we've had it active for long enough now that we can start to evaluate what changes, if any, we would like to try to make to it. My personal recommendation is to use only a single metric to grade the quality of the page not three separate ones for composition, accuracy, and coverage like we have now. We could have a single "Quality" metric with values like: Unreviewed (default), vandalism-free (pages get autopromoted to this when a +Editor edits the page, so no manual review is required), Good, and Featured Quality. Less effort to review and grade a page means it's more likely that pages are going to be reviewed. It also means more pages are going to be reviewed in less time. Thoughts? --Whiteknight (Page) (Talk) 19:57, 6 February 2009 (UTC)

I like the three metrics. I think its helpful to know what people think of the page's composition, accuracy and coverage. I think they fit really well with the main things people need to pay attention to to make books better for readers. I think the only downside is that reviews aren't accumulative which means you only get an idea of what the last version who happened to review a revision thought, and not what the average person thinks. --darklama 22:02, 6 February 2009 (UTC)
I would disagree with you completely. If we want a holistic review of the page, we should ask a person for an over-all review of the page. By asking for an arbitrary set of reviews, we're asking the user to focus on a small handful of things and miss the big picture. A page can get good marks in composition, accuracy, and coverage, and still not be a good page overall. I don't want to say it's going to be a common occurance, but we're asking our Editors to ignore the forrest so they can see the trees. If we want to know if a page is good quality, we ask our Editors if the page is good quality. We don't ask them a handful of related questions and try to interpret those three answers to get an idea about page quality. --Whiteknight (Page) (Talk) 00:40, 11 February 2009 (UTC)
I disagree. An overall review isn't going to help editors know what to focus on improving. That is the only benefit I see in having flagged revision. An overview would still leave editors having to guess what other editors consider wrong with a revision, the same sort of guess work that would happen without flaggedrevs, so if we do that, we might as well not have flaggedrevs at all. Editors need to see both the forest and the trees. Editors need to know what needs to be improved in order to improve the quality of pages. I think having feedback from users would also be helpful. Wikibooks needs to turn on the feedback configuration option for that. --darklama 01:18, 11 February 2009 (UTC)
I'm going to have to agree with Darklama here. Assuming that people who are reviewing pages would put in the effort to develop an opinion on what needs to be changed, it is potentially very useful information for those who seek to make improvements. Of course, talk pages could be used for the same purpose, maybe we should encourage this instead? Mattb112885 (talk to me) 00:09, 12 February 2009 (UTC)
I think encouraging both would be good. I think the more ways Wikibooks has for providing feedback the better. Some people will prefer some methods of providing feedback over others, so the more options people have, the more likely feedback will be provided. --darklama 00:26, 12 February 2009 (UTC)
I agree with darklama and Mattb. I think the details give contributors, readers and future reviewers useful information. Should we feel that not enough modules are getting reviewed, we can consider simplifying these to lower the threshold, but I think it's fine for now. --Swift (talk) 05:52, 12 February 2009 (UTC)

[edit] Reducing editor tools to sighting

The recent discussion seems to draw two main viewpoints. One contends that established editors (who would benefit from begin able to sight their own work) aren't being granted editor status early enough. The other that they need more time to get accustomed to editorial standards before getting the tools that allow them to grade the quality of modules.

It seems that a reasonable solution is to limit editors' reviewing tools to mere sighting (which is really all that normal book editors need or, from what I gather, want) but reduce the criteria for auto-flagging to a moderate period that allows us to catch unhelpful contributors, mend their ways or ban them. Reviewers would be the only ones with the tools to actually review and grade content, and could be held to whatever standards we feel necessary. --Swift (talk) 05:36, 12 February 2009 (UTC)

I don't think that change might be necessary. I think changing $wgFlaggedRevTabs to true might give even anonymous editors the option to see the latest revision when editing, and adding "$wgGroupPermissions['autoconfirmed']['autoreview'] = true;" should let any user after 4 days to have there edits sighted automatically even if they cannot review pages until they become an editor. I think these two changes would be less intrusive, but at the same time this means that vandalism can be seen again by readers, unless an editor reviews a page as being of good quality rather being marked as sighted. --darklama 13:50, 14 February 2009 (UTC)
Well, if I understood your proposal correcly, they seem somewhat similar. Your's has +autoconfirmeds doing sighting, +editors doing general reviewing, and +reviewers doing reviewing up to featured. Mine would then be largely the same, but without a special tier for featured, general review has to be manually granted, and we have a bit more control on who gets sighting (auotoconfirmed is just 4 days, right?).
I don't think we should let every four day old contributor editor sight pages as that seems a little easy for small-time vandals to pass. An edit count threshold would help.
Setting $wgFlaggedRevTabs to true might be a good idea whatever way we go.
I think there is a good argument for manually flagging those who wish to validate pages. The criteria needn't be high, people would simply provide a few links to content that they'd edited and unless someone had editorial comments (poor spelling, structure, etc.) they'd get the tools.
The benefits would be two-fold. First off, this simple process would bring interested Wikibookians closer to the community, make them better aware of the standars (how many month-old editors do you reckon will have read Help:Revision review) and uses (as well as pitfalls) of validating pages, and even encourage them to make that part of their Wikibooks activity.
The second is that while passing the current +editor criteria should have given users the time to learn the syntax and get a footing with the Mediawiki software, it in no way qualifies anyone to write good prose. New contributors should nominally be concentrating on writing content, rather than marking books in active development as good quality without realising that this is going to block autoreviewed edits by other +editors. All that most Wikibookians really need (and I count myself in that) are sighting tools. As Whiteknight pointed out, the revision quality is a seperate feature.
Finally, as User:Thenub314 noted in the general reading room, the terminology of +editor being somewhat exclusive is a bit odd. It would be better to make that the most inclusive tier. --Swift (talk) 03:16, 15 February 2009 (UTC)
Yes I think you understand how my proposed changes would work. I don't think you completely understand the effects of your proposal though. "Featured" is a built-in tier too which is met when the maximum rating has been given regardless of what it is called. If we got rid of "featured" as a rating level, revisions that have great composition, great accuracy and great coverage would be considered featured quality instead. I don't like the idea of placing the burden of reviewing edits on reviewers because edits either won't get reviewed above sighted or administrators will get overburden with requests for the review flag.
Honestly I think editors shouldn't be validating or reviewing there own edits at all. I think limiting validation or reviews to reviewers would actually discourage people from contributing to the project and create a bigger divide among community participants, rather than encourage people to understand standards and encourage community involvement. Contributors would have to rely on the judgment of reviewers and hope there is a reviewer interested in reviewing their work, rather than rely on the judgment of their fellow editors or there own judgment.
I think your proposed changes would actually make the editor flag less inclusion. I think the editor flag is more inclusive now because editors can review pages not just sight them. I think allowing autoconfirmed users to sight pages would be a bit more inclusive.
Some other options include disabling autoreview altogether so the latest revision is shown unless sighted or otherwise reviewed, allowing contributors with the editor flag to give and take the reviewer flag from themselves, or dropping FlaggedRevs altogether because Wikibooks could use a more flexible extension more targeted/aimed at grading book quality. --darklama 17:33, 15 February 2009 (UTC)
I wasn't actually suggesting we get rid of featured. I'm only suggesting modifying the +editor tools, not reviewer.
The only way to prevent Wikibookinas from reviewing their own edits is to have them go through a manual process. I don't see us getting over-burdoned with +reviewer flag requests. We normally don't hear much from the vast majority of the over 900 users who contributed to Wikibooks over the last month. I'd call us lucky if we got one percent of these a month. Most people just seem to work on their own corner.
The existance of a reviewer community might actually draw more people into the general community. We could set up a list of books whose authors have requested be reviewed. As Wikibookians cannot review their own work, it is in their interest to review other people's books to reduce the backlog.
My proposal would allow us to make the +editor flag more inclusive: By restricting the tools, we can all agree to lower the criteria and thus let more people get the flag sooner. (Here I understand inclusive to mean number of people that pass the criteria, not the extent of the tools).
Your last option, dropping FlaggedRevs, hasn't been discussed much. I guess it warrants a seperate section. --Swift (talk) 18:24, 15 February 2009 (UTC)

I'm afraid I haven't got enough time to read this in-depth, but from skimming it, I agree with Swift here. We should make editor a lightweight permission suitable for just reviewing vandalism. Reviewer should be the more comprehensive permission requiring a better working knowledge of how Wikibooks works. If FlaggedRevs is going to be successful for us, we need people to use it - currently the requirements for autopromotion are preventing that. This is a wiki & openness is a strength. I think we were too concerned with keeping vandals out when we first discussed this - and that includes myself.  — Mike.lifeguard | talk 21:51, 15 February 2009 (UTC)

The current autopromotion settings are clearly unreasonable; there seems to be pretty wide agreement on that. So, doesn't that mean that we don't have any real experience on which to base judgments about how well the rest of the current arrangement would work if the autopromotion settings weren't out of whack? (I'll stipulate that $wgFlaggedRevTabs is orthogonal to how many or few +Editors there are, so I see no difficulty in judging it now.) It's not at all clear to me that sighting should be merely certifying non-vandalism — for pages in the earliest stages of development, sure, "not vandalism" is probably close to the right criterion for sighting a revision; but as the quality of the page goes up, oughtn't one exercise at least a little more editorial attention in sighting? The arguments against this seem to be that (1) the demand for sighting cannot be kept up with by the available pool of registered users with editorial savvy, and (2) community coherence is ill served by having a small elite group of users who are allowed to sight. Both of these arguments assume, though, that the shortage of +Editors is due to a lack of users with editorial savvy, when we know that the shortage of +Editors is to some (perhaps quite large) degree an artifact of the maladjusted autopromotion settings.
Could we change the benchmarks/spacing to 10 benchmarks 2 days apart, and let the consequences of that play out while we debate these other issues? It seems a bit unnecessary to not do that much just because more might ultimately be needed. --Pi zero (talk) 05:17, 16 February 2009 (UTC)
I agree we should change the benchmarking/spacing now and see how it plays out. --darklama 13:11, 16 February 2009 (UTC)
Yes, let's change the criteria we currently agree on (I've just added a #Summary to the criteria discussion).
One can, indeed, say that we don't really know how things would work if editors were flagged with +editor properly. However, that's not all. We have different opinions of what proper flagging should be. One side wants to give more ready access to sighting tools, while on the other want's to uphold some standars to the reviewing process. What I'm proposing is that these aren't mutully exclusive views — as long as we split the +editor flag up along these lines.
I suggest that for now we split this up to allow lowering the criteria for sighting tools even further while being conservative in whom we grant reviewing tools (as there are downsides to reviewed pages which those wielding the tools must be aware of). Once we get a better experience with this, we can reconsider granting those with the +editor flag the current reviewing tools. --Swift (talk) 07:14, 13 March 2009 (UTC)
I agree these aren't necessarily mutually exclusive views. What I disagree with is that the +editor flag has to be split up in order to achieve your proposal. I think FlaggedRevs can be setup to auto sight any revision edited by an emailconfirmed user for instance. This would allow revisions to be sighted without needing to have the editor flag and would allow editors to continue to review pages without having to be manually given that capability. I think that approach would satisfy people who want minimum requirements for being able to sight pages, while also satisfying people who want editors to be able to review pages and be able to do so using an auto promotion process. --darklama 18:34, 14 March 2009 (UTC)
Actually, I believe there should be a degree of editorial wisdom applied to sighting, a position that is rather fundamentally inconsistent with making sighting trivially easy. I've never been sold on the idea that the FlaggedRevs page review stuff is at all useful here except as part of sighting; I always figured I'd wait and see how it worked out, but it never has worked, nor even failed to work, because the still-unexplained sluggishness of autopromotion has kept editors too few and far between for a realistic test of the review-beyond-sighting concept (which has also interfered with the sighting facet, of course). --Pi zero (talk) 20:41, 14 March 2009 (UTC)
Retrieved from "http://en.wikibooks.org/wiki/Wikibooks_talk:FlaggedRevs_Extension"