Wikipedia talk:Flagged revisions/Trial/4

---

Question re tagging

One feature of Flagged revisions, is that edits by logged on users (who aren't reviewers) and bots will not be seen by everybody if they are on top of an un-reviewed edit by an IP until the version is reviewed. While for general edits this may merely be a nuisance, what about more time sensitive edits, such as (particularly) prodding an article or adding an Afd tag. In this case the fact that not everyone can see the tag could mean that IP or non-logged on users will not realise that an article needs help until possibly it is too late. Would it be possible to tweak the way we do things so that the clock doesn't start on these processes on a FR page until the tag has been "sighted" and anyone can see it? What happens on de and pl about these issues?Nigel Ish (talk) 18:40, 8 January 2009 (UTC)

I guess you could hard-code the interface to disallow the addition of tags to unreviewed pages. I guess it is pretty pointles even saying that benign tags like {ref-improve} should potentially not be seen by IPs. MickMacNee (talk) 19:15, 8 January 2009 (UTC)

A user who is experienced enough to be adding CSD/XfD tags to articles is experienced enough to ask for and receive the 'reviewer' flag in almost all proposed implementations. Happy‑melon 21:32, 8 January 2009 (UTC)

2005 WP:Block all anonymous edits

A very old discussion (short) where some of the same concerns we have now were raised several years ago. Collect (talk) 19:11, 8 January 2009 (UTC)

You wouldn't know it from some of the support votes, but Flagged Revisions is being proposed so that we do not have to force all editors to register. MickMacNee (talk) 19:19, 8 January 2009 (UTC)

As I've commented before, flagged revisions does not make it more difficult for anyone to make a contribution; it only delays the publishing of their contribution. This is the distinct difference between FR and no-anonymous-editing. That's not to say it has no negative effects, but it's a different thing. Dcoetzee 23:24, 8 January 2009 (UTC)

'More difficult' depends on which set of articles it is applied to. If it is going to be applied to every single BLP, irrespective of whether they were being protected beforehand, then obviously it is going to be more difficult for IPs to edit. If it is going to be applied to all articles, even more so. If applied just to protected articles, then it depends if you think changing from having to ask to edit, to having to wait for an edit to be approved, is making anything any easier. This is why asking for a poll when every supporter has conflicting reasons for believing it of benefit was unwise. Nobody can make a conclusive argument and nobody cna make a conclusive counter argument, because even the basic issues such as which article set to apply it to have not been agreed. 15:18, 9 January 2009 (UTC)

I fail to see why this is the case. The poll needs to be held separately, if nothing else, because the devs don't care about our policies and the way we'll use it. They just want to know if they should turn the software on or not. Since no specific trial is proposed, having the software turned on will not make a blind bit of difference to the daily running of Wikipedia - no pages will be flagged or anything. In that sense then, having this poll is just as good as having a poll on a specific trial. Since no trials can run without another community discussion, in which the different factions of faith in FR will have to come to some consensus about it, I don't really see why a lot of the people above are opposing it (except those who are against FR on principal, which I completely understand) Fritzpoll (talk) 18:23, 9 January 2009 (UTC)

The logical benefit from deciding which general but incompatible uses have the most general support to go forward for specific trials before you switch it on is just obvious to me. These discussions are already way too complex, convoluted and hard to follow without intentionally making it more so further down the line by not even starting with some basic assumptions, all seemingly just for the convenience of devs. It is horrifying to think what percentage of the community (mainly IPs) are already automatically disenfranchised from just this poll, never mind the future massively complex multi-way multi-aspect discussions that are due to come under your model. MickMacNee (talk) 19:00, 9 January 2009 (UTC)

I agree, there might have been some aspects that could have been discussed first, but as far as I can see, these are just the parameters for the technical implementation. Everything else that would be needed for a trial can be determined by the parameters of individual trials. A sitenotice announcing this poll might have been a good idea, except that it doesn't really affect them at present. I would oppose the implementation of any trial that wasn't advertised on a sitenotice where all (including IPs) could see it, FWIW. Fritzpoll (talk) 19:19, 9 January 2009 (UTC)

That's not the only such discussion. Disabling editing by people without accounts is a perennial proposal, also to be found at m:Anonymous users should not be allowed to edit articles and repeatedly at the Village Pump and elsewhere. It is perennially countered by those who point out that people without accounts are actually responsible for most of our content, and that in some cases it is the people without accounts who are quietly fighting the vandalism of the people with accounts. Uncle G (talk) 01:46, 10 January 2009 (UTC)

Closing time for this poll

The straw poll on implementation will be a week old in about five hours, and the rate-of-change of both !votes and discussion is inevitably declining. What is a suitable time to close the poll and present it to the developers for evaluation? This evening? After it is ten days old? Two weeks? Happy‑melon 12:06, 9 January 2009 (UTC)

Two weeks at least, ideally a month IMO for such a change. MBisanz ^talk 16:07, 9 January 2009 (UTC)

IMO practically any time now, except that at least 24 hours notice should be given. - Hordaland (talk) 17:36, 9 January 2009 (UTC)

No reason to close yet, people are still voting, Wikipedia will still exist after this is over. Give it at least another week. — neuro^(talk) 18:00, 9 January 2009 (UTC)

I agree that we should not close at such a time as to prevent significant numbers of contributors from participating; however I think we approach the point of diminishing returns - leaving it on the watchlist for a month would not result in significantly more participation than leaving it for just a few more days. I concur that the close should be announced well in advance. Happy‑melon 22:05, 9 January 2009 (UTC)

The reason why I say a week is because we are not in a rush to get this implemented - we will still be here no matter how long we wait. There is no harm in waiting for a little bit of time, I'd say at least 5 days warning would be preferable. — neuro^(talk) 22:51, 9 January 2009 (UTC)

Because this affects IP users in a huge way, can this please be placed in a place where IP users will see it? And can something be added to WP:Flagged revisions? It's hard to get here from there. I hope this isn't closed before IP users find out about it and have a chance to comment. 141.151.174.108 (talk) 21:50, 10 January 2009 (UTC)

Close it out it out at the end of January. Not everyone edits every day or even every week, and while I've been editing every day for the last week I only noticed the message about this on my watchlist a few hours ago (just didn't see it before that, others might see it and might not have time to click on it, or might click on it and not have enough time to read and understand what in the hell is going on here). There is absolutely no reason to close this early. Let people comment, ask questions, and discuss. The more people are aware of/invested in this process the better. If there's a way to let regular or semi-regular IP contributors know about this, then we should absolutely do so. --Bigtimepeace | talk | contribs 22:01, 12 January 2009 (UTC)

I for one would have missed voting in the poll had it been closed after a week or so. Even after two months off from editing, the only thing I've checked for updates is my recent contributions list - as you can only sit still for so long in a southern clime. I think for most of the Australian editors, the watchlist is simply too big to manage right now, and a month's grace period should mean that everyone sees this page. Ottre 03:41, 14 January 2009 (UTC)

participation

No matter which side you're on, it sure is nice to see 450+ people chiming in. Both sides are making very compelling arguments. I'm glad to see so many people care so much about this project. Cheers to all, Kingturtle (talk) 17:12, 9 January 2009 (UTC)

Indeed. Too bad so many people hold the wrong opinion. :) --ElKevbo (talk) 21:53, 9 January 2009 (UTC)

I don't want Wikipedia becoming a walled garden. That's why I oppose. doktorb _words^deeds 10:02, 10 January 2009 (UTC)

Vandalism problem

If flagged revisions do become policy (to which I am strongly opposed), what happens when the vandals figure out that they can still vandalise pages by creating huge backlogs? E.G: Possibly submitting up to 100 revisions with nonsense like "Mr. Example is a load of poo" and/or "I have hairly legs, hehe" in them. Huggle can quickly revert normal vandalism, will it be able to quickly dismiss silly revisions that vandals submit? - Sorry if this has already been covered or if i've missed the point of flagged revisions completely! But this possibility is bothering me. John Sloan (view / chat) 17:23, 9 January 2009 (UTC)

It's no different than now is it? People still have to revert such nonsense now, and people can still be blocked just the same for vandalistic edits even under FR system. ♫ Melodia Chaconne ♫ (talk) 18:13, 9 January 2009 (UTC)

Doesn't seem pertinent to the poll in question. Sounds more like something to consider as part of a trial - else we'll never know. Fritzpoll (talk) 18:19, 9 January 2009 (UTC)

In fact it would be nice to be able to flag a revision "bad", which would eliminate the need to revert, and make the whole process quicker and lighter-weight than now. The idea would be that if you click "edit" by default you get the most recent non-bad revision. You could still start from a bad revision via the history list, just as yout can start from an old revision now. The ability to flag (or unflag) "bad" would be part of the same package as the ability to flag (effectively "good") in the present implementation. This would also reduce history overload on pages which currently go vandal - rvv - vandal - rvv etc, making it easier to follow the useful history of the page. (Off topic, I know, but people are reading this page...) PaddyLeahy (talk) 18:42, 9 January 2009 (UTC)

I think doing that WOULD give credence to all the oppose votes who think this goes against the "anyone can edit" edict. As it stands on WP now, you click edit, you edit the most recent version of the page, whether or not there's been a change. This is something that FR should not change one bit -- which is why all those oppose votes don't hold much candle IMO. ♫ Melodia Chaconne ♫ (talk) 20:25, 9 January 2009 (UTC)

Flagging an edit a bad is not a good idea, in that it will still need to be reverted from the draft eventually. The biggest problem we have today with vandalism, comes when there are multiple new edits and the newest ones are valid edits. It is too easy to assume that the vandalism was removed at the same time as the good edit was added. Dbiel ^(Talk) 20:55, 9 January 2009 (UTC)

The point of my suggestion is that with this change we don't have to revert, ever. You only need to edit the text if you have something constructive to add. Seems like a benefit to me, but each to his own! I also don't see why being flagged "bad" would be any more traumatic to new editors than having their edit reverted (with a dismissive edit summary), which is what usually happens now. PaddyLeahy (talk) 19:56, 10 January 2009 (UTC)

No, we still would have to revert, because the vandalism would still be present in the draft revision. Remember, when you edit the article, you always edit the most recent revision, regardless of whether it's been flagged. This situation would be no different than it is now; just revert the vandalism. Pyrospirit (talk · contribs) 23:38, 10 January 2009 (UTC)

Flagging bad means the "current draft" becomes the previous non-bad version. Functionally, my proposal is equivalent to a revert except that it doesn't create a new entry in the history list. For frequently-vandalised pages this would cut the history list almost in half and make the actual development of the page much easier to follow. PaddyLeahy (talk) 11:59, 11 January 2009 (UTC)

Your proposal, would, in that case mean the deletion of all the edits since the bad one. A terribly bad idea, and one which would discourage people from editing completely - why edit if its going to be deleted because of something an IP slipped in before you. It would also be liable to abuse.Nigel Ish (talk) 18:29, 11 January 2009 (UTC)

Good point, the rule should be "latest non-bad" version; I was assuming that only the latest draft is likely to be flagged. PaddyLeahy (talk) 18:50, 11 January 2009 (UTC)

toothpick or blanket

All the discussion ahs been around using flagged revisions as a blanket approach, in the section above Wikipedia_talk:Flagged_revisions/Trial#statistics_please in there the discussion said that only around 3-7% of edits would be within the target of this proposal. That means we are talking about applying it to 93-97% edits where its unnecessary, this makes a blanket approach very hard to justify, I think long term even if implemented many editors will become lazy and just review all edits as a matter of course.

So how do we use this as a tool like a toothpick, against the 3-7% of edits? What if flagged revision was available as an admin tool like semi-protection and full protection are. Could it be made into a user specific condition for arbcom/ANI remedies where an editor could be restricted to having their edits reviewed ie an enforced mentoring. Gnangarra 03:18, 10 January 2009 (UTC)

The main point of FlaggedRevs is to apply a minimal level of checking before our passive readers see the page, but in your model there's lots of visible disruption before any sanctions are taken, which defeats the point (why not just ban these users, as now?). I don't see a positive flag as "unnecessary": this check will significantly improve our reputation if we make it clear to the public what is going on. And flagging is mostly light work: edits by experienced users and bots would be automatically sighted, so reviewers only have to take positive action for edits by non-reviewers (IPs and newly-registered users). And of course we want to shut out a larger fraction of these than 3-7%. For instance from HappyMelon's statistics, 25770/238100 = 11% of IP edits were reverted manually, and then there would have been lots of bot reversions which he didn't count. And that was a low-vandalism period. PaddyLeahy (talk) 20:33, 10 January 2009 (UTC)

There is a toothpick proposal at WP:Flagged protection. Testing for that purpose, and with safebuards, would be acceptable to me; if we could avoid giving the impression that it was the camel's nose in the tent, it might be acceptable to a substantial supermajority. But the proposal is still, sensibly, under development. Septentrionalis PMAnderson 01:18, 11 January 2009 (UTC)

I actually support the use of flagged revisions as a blanket measure on all articles, as long as there's a technical provision to sight pages that haven't been edited in a certain time (e.g. 24 hours, but I could see this go as low as just an hour or two, it would still do good). I believe "anyone can edit with minimal effort" is what matters, not instant gratification; it's natural and acceptable for there to be some predictable amount of delay, no different from posting to a moderated mailing list. Dcoetzee 02:29, 11 January 2009 (UTC)

Wikipedia's greatest obstacle

The underlying assumption of flagged revisions is that we are frustrated in achieving the goals we have set for our encyclopedia primarily by editors who make contributions "the rest of us" think are unhelpful (see e.g. {{uw-test1}}). With flagged revisions, we could prevent those contributions from becoming immediately visible, and it is asserted this will improved the "appearance" of our encyclopedia.

The flaw in this thinking is that having an encyclopedia that sometimes includes "test" edits or vandalism isn't our greatest obstacle. Our goal is nothing less than to build a completely comprehensive encyclopedia of all human knowledge. Our greatest obstacle is that we don't have enough contributors to do that. Anything that discourages new editors will make it more difficult for us to achieve our goal.

Flagged revisions would discourage new editors; flagged revisions would make our greatest obstacle even more difficult to overcome. (sdsds - talk) 08:10, 11 January 2009 (UTC)

I can agree with the spirit of this post. The problem I have with 'flagged revisions' is the implied snobbery of some editors thinking it is acceptable for them to grant others the right to edit an article. But in my years here, I have found the existing fight against vandalism or dodgy edits to be good enough (just), a situation which I cannot see improving if there is a backlog of revisions in the inbox of a select bunch of "respected" editors.

I must also wonder if, by accepting this proposal, we are not putting a fireblanket over the ability of editors to create such articles as the 2008 Mumbai attacks, or current Gaza/Israel conflict article. How could we ensure that an editors own POV leanings don't come into the choosing which version of an article to allow? doktorb _words^deeds 08:47, 11 January 2009 (UTC)

This (section, not fr's) is one of the more interesting posts in the last several years. Where is the page that discusses Wikipedia goals, shows metrics, with todo lists? I see truly interesting pages deleted for lack of notability. This does not seem to be striving for complete information. I personally have had page creations marked for deleted within seconds (even before I could get to the talk page to add project banners...) By the same token, I do believe that vandalism and inaccurate articles are the bane of our existence. Something HAS to be done about those issues. ANY motion in that direction, I see as a good thing. But I wish the "goals" page existed. -- Mjquin_id (talk) 01:56, 19 January 2009 (UTC)

Canvassing?

I'm not sure what to make of this, which User:Promethean has advertised on a very large number of users' talk pages (eg). The message, "say no to Flagged revisions" with a link to the #Oppose section above, was MfD'd as canvassing, but was snowball-kept after Promethean changed the link to not point specifically to the 'oppose' section. It is rather disconcerting, therefore, to see an edit where Promethean changed the link back just under an hour later, eight minutes after the MfD was closed. Promethean also seems to have substituted a number of these templates, such that the WhatLinksHere no longer accurately reflects the number of transclusions in existence. All of the substituted templates link to the 'oppose' section.

The MfD was open for less than ninety minutes, although I do not disagree with SoWhy's WP:SNOW closure given the content of the discussion. I am more concerned that the discussion was not linked to here and the fact that this template is in use (and links, as of this post, to the 'oppose' section of the straw poll) was not remarked upon. I am interested in obtaining wider comment on the situation. Thoughts? Happy‑melon 12:13, 11 January 2009 (UTC)

Short comment on that: I closed the MfD because its scope was only if the template itself can be seen as canvassing, which I think everyone at the MfD agreed can't be more canvassing than most userboxes. The way it was promoted to talk pages though could be regarded as such (although I doubt it) but we cannot MfD behavior, only pages. SoWhy 10:00, 19 January 2009 (UTC)

Always thought that the anti-canvassing rule on wikipedia was silly and never more so for a major issue like this. I'd be very happy to display a pro-flagging equivalent! PaddyLeahy (talk) 12:21, 11 January 2009 (UTC)

I hate the anti-cancassing rule. But User:Promethean should be blocked for inordinate bad faith manipulation of this whole thing (see the point above about the incorrect issue of 21 days). In my opinion. But that's just me. ♫ Melodia Chaconne ♫ (talk)

I'd already voted oppose and was offered the gawdy userbox to use if I wished. It wasn't added, just offered. I chose to not use it and not respond. If it was only offered to people who'd already !voted no, then it's certainly not canvassing. Spamming, maybe, but not canvassing. - Hordaland (talk) 13:14, 11 January 2009 (UTC)

It wasn't canvassing in my opinion because he only showed the link to those that had already made up their mind. And displaying the template with a link to #Oppose is no worse than displaying a notice about an RfA or similar discussion. Its in my opinion a really trivial thing that shouldn't really have any affect on the outcome Alexfusco⁵ 17:56, 11 January 2009 (UTC)

I got the note and displayed the box until I switched to support, I agree with Alex, this is trivial and should not have much of an effect.--Res2216firestar 18:28, 11 January 2009 (UTC)

Just noting that as the creator of the image I strongly disagree with the mass messaging, but I don't consider it 'canvassing'. — neuro^(talk) 23:08, 11 January 2009 (UTC)

This is not canvassing but certainly aggressive campaigning with the objective to sway consensus in a community discussion. The template also adds to the incomprehension on the subject of this poll, which is not whether we want to massively enable flaggedrevs on all articles, but whether we can enable the proposed configuration in order to make trials that have to be supported by consensus. Those factors will have to be taken into consideration when closing the poll. Cenarium (Talk) 01:04, 12 January 2009 (UTC)

No more so than the repetitious reverence for Jimbo. Anyone who closes a poll of just over 60% approval on a change of this magnitude as anything other than no consensus may expect to explain themselves to ArbCom. Septentrionalis PMAnderson 18:11, 12 January 2009 (UTC)

As I said somewhere above, Wikipedia:Requests for arbitration/Brion VIBBER is perhaps the most amusing idea I've seen all week. Happy‑melon 18:36, 12 January 2009 (UTC)

Yes, four weeks ago on Wikipedia_talk:Flagged_revisions/Trial#RfC_on_implementation you said "A clear consensus is required to present to the developers to have the extension installed". I thought Brion VIBBER is a lead developer ? so whats amusing ? Mion (talk) 19:08, 12 January 2009 (UTC)

The fact that Pmanderson proposes to take the Wikimedia Foundation's Chief Technical Officer to the en.wiki Arbitration Committee for alleged breaches of policy. A clear consensus is indeed required, but to suggest that we have any control over how that consensus is judged is what's amusing. The best we can do is present coherent arguments, and to get widespread involvement. I'm not sure if this is the highest turnout we've had in Wikipedia's history, but it's certainly coming close; that's the definition of "strong consensus": something that reflects the opinions of the widest possible array of Wikipedia editors. What this poll is judged a consensus for is entirely out of our hands. Happy‑melon 19:56, 12 January 2009 (UTC)

So a high turnout = "strong consensus"? Not at all. Wikipedia is not a democracy, and a majority vote is not enough. Septentrionalis PMAnderson 22:18, 12 January 2009 (UTC)

This isn't canvassing; canvassing is an attempt to sway a large number of user's opinions in a community decision. Promethean sent the message to people who had already opposed. –Juliancolton ^{Tropical Cyclone} 18:25, 12 January 2009 (UTC)

Where are the reverences ? Which percentage of users even knows about Jimbo's position ? Jimbo's statements are rather turned in reasons to oppose. What will have to be taken into consideration is that most comments are for or against an unrestricted implementation on all articles like on de.wiki, which is ... off-topic. The majority of comments are not to the point. Cenarium (Talk) 19:16, 12 January 2009 (UTC)

Anybody who glances at the first nine supports; and plainly some have done so. And what percentage of editors have been swayed by Promethean? As his edits say, he wrote those who had opposed. Septentrionalis PMAnderson 19:46, 12 January 2009 (UTC)

Users noticing the template on a userpage, especially from users they know, are driven-by. Even if it's not clearly forbidden by policy, it's a deliberate attempt to sway consensus by inciting users to vote 'no'. More have seen them than Jimbo's !vote, but overall none have a major influence. Cenarium (Talk) 22:56, 12 January 2009 (UTC)

• The point is whatever we decide it is. For those who wish to say this need not be tested because they oppose FR whatever the results (I am not one, yet; although Cenarium may persuade me), that's the point. Septentrionalis PMAnderson 19:52, 12 January 2009 (UTC)

(ec) AGF? If indeed the "majority of comments are not to the point," then the point has been poorly presented. However, it seems to me that some proponents dismiss valid concerns, such as mine. This discussion has already taken hundreds of man-hours. The parameters & evaluations of each trial are to be decided by consensus = hundreds more man-hours. With that much invested, it is human nature to want not to backtrack. Such concerns are not off-topic. - Hordaland (talk) 20:01, 12 January 2009 (UTC)

Please reread what I said, i.e that most comments both in the support and oppose sections are (increasingly as the poll run) directed at whether we should massively enable flaggedrevs or not, which is not was is asked here, but whether we can enable a passive configuration in order to make specific trials, each one requiring consensus. I wouldn't be opposed to use an editnotice to clarify this in a neutral manner (as has been done for the mosnum RFCs). If your concern is that changes won't be visible immediately (and thus decrease participation), then I agree that it is also a concern, and it is one of the reasons I am opposed to a full, unrestricted implementation. But the trials are not of this kind. Trials are limited and require consensus. More long-term proposals range from using a light version of flaggedrevs instead of semi-protection, or a semi-automatic implementation where only edits identified as probable vandalism are not shown. I do not believe that those trials will open the door to a full, unrestricted implementation, the community is too strongly opposed to this, but is is indeed a concern to a few users. Cenarium (Talk) 22:56, 12 January 2009 (UTC)

Example where Flagged revisons would have helped

This is an example of a good faith IP user unknowingly hurting an Wikipedia article. He views the article and sees some very obvious vandalism and edits the article to remove it. (see diff1) The problem with the removal of the vandalism is that it should have been removed using the undo function which would have also added back the valid section of text deleted by the previous IP user who added the vandalism in a single edit. (see diff2) Had flagged revisions been in place, the good faith editor would have never seen the vandalism in the first place. The partial reverting of vandalism is the single biggest problem in Wikipedia in our fight with vandalism. It is also the main reason that most long term vandalism is permitted to remain in Wikipedia. Dbiel ^(Talk) 20:13, 11 January 2009 (UTC)

This is a recurring problem indeed, but it also happens with registered users. It is something that could be partially handled by the semi-automatic flaggedrevs proposal: we could use a special page listing articles with suspect revisions (see this for details, though this is hardly readable), it would detect many such cases. Cenarium (Talk) 20:42, 11 January 2009 (UTC)

No need for Flagged revisions there, the existing tools are Cluebot ,SoxBot III etc they are already able to counter such vandalism. Mion (talk) 20:55, 11 January 2009 (UTC)

If they were able to catch all vandalism, libel, etc, that would be nice indeed. But this is not the case. Cenarium (Talk) 21:02, 11 January 2009 (UTC)

An example was given, the bots are able to handle the given example, and now you're raising the requirements ? Mion (talk) 21:05, 11 January 2009 (UTC)

The bots haven't reverted it, they revert only a small part of all vandalism edits, even when such edits match their filters. And this is a blanket revert, while a combination of the abusefilter and flaggedrevs would defer all suspect edits to the analyse of a trusted user. Cenarium (Talk) 21:17, 11 January 2009 (UTC)

It requires only a small amount of people to run bots like this to handle big ranges of articles compared to the sighter scenario which creates a huge backlog, to answer your other question, the German wikipedia is discussing changes in the criteria for analysis by sighters because the current system isn't working (not all vandalism, libel, etc are caught), by making the criteria stricter, it takes more time, which will increase the backlog. Mion (talk) 21:30, 11 January 2009 (UTC)

The difference here is that in the proposed semi-automatic implementation, only edits that match the filter are 'delayed' to the draft page, and other edits are unaffected, and since most vandalism edits are quickly reverted, the backlog won't grow as big as it would in a total, unrestricted implementation like on de.wiki (that I would oppose very much), since when a new edit makes the latest revision no longer 'suspect', it is shown to IPs. Cenarium (Talk) 21:50, 11 January 2009 (UTC)

the proposed semi-automatic implementation: only edits that match the filter are 'delayed' As other (obvious) vandalism is caught by the bot and directly reverted, 97 % of the edits by IP's is ok, so 2,5 of the edits are questionable, now the German wikipedia needs human eyes to filter this vandalism and libel (see the discussion to raise the criteria), the question comes up: can you show me a ruleset (the filter in the proposal) for a bot, for lets say 100 articles, that allows the passing of the 97% good edits+catching the 2,5% of edits that contain libel and smart in dept vandalism ? Mion (talk) 22:36, 11 January 2009 (UTC)

Your assumption that almost all obvious vandalism is reverted by a bot is incorrect, even if we count quick Huggle reverts or quick manual reverts (less than one or two minutes after the edit), still a considerable part of obviously vandalized versions remain visible for a few minutes or hours, if not more. The semi-automatic proposal would prevent this, and provide a special page listing articles containing suspect revisions, thus detecting incomplete reversions. As you know it, a perfect filter doesn't exist, but we would have much more liberty than in anti-vandalism bots' filters. They could be specialized for certain types of articles, for example articles on living persons, or articles targeted by a sockpuppeteer, or against a specific type of vandalism that can't handle bots without too many false positives. Cenarium (Talk) 00:46, 12 January 2009 (UTC)

This is also the sort of situation where FR are most risky. The anon made an obviously useful edit; there is a risk that any flagger will not check further, but will flag the repaired text; at which point the text lost to the vandal may well be permanently lost, unless someone goes behind the flagging. Septentrionalis PMAnderson 01:14, 12 January 2009 (UTC)

When flagging, the diff to the latest flagged revision is given, so any user with a little understanding of revision history can make the appropriate actions. There are many more cases where text will be saved thanks to flagged revisions than lost because of bad flagging. Cenarium (Talk) 01:57, 12 January 2009 (UTC)

That's precisely the problem. Diff1 by itself is an excellent edit, and any flagger should be tempted to confirm it. Septentrionalis PMAnderson 02:45, 12 January 2009 (UTC)

No, the latest flagged revision would be presumably this one, so the diff to the latest flagged revision would be this, which clearly indicates a lost of information. Anyway, history should always be checked before flagging, but this diff is a signal. Cenarium (Talk) 19:28, 12 January 2009 (UTC)

Except with FR, it wouldn't have happened that way in the first place, so it's something of a strawman to put it that way. ♫ Melodia Chaconne ♫ (talk) 03:09, 12 January 2009 (UTC)

@Cenarium:my assumption is correct, because in the proposal a small set of articles is targeted, you need a bot for this set, so if you take a SoxBot III as a tool to build the filter upon it will revert the obvious vandalism on this set, however in this proposal there is still the problem that you can't create a valid ruleset for the proposed FILTER and thats why this specific trial proposal can't work. Mion (talk) 10:32, 12 January 2009 (UTC)

We have no need for bots, the abuse filter automatically checks all edits and acts based on its own filters. When an edit matches some filter with an action 'deflag', it's 'moved' to the draft page until a no longer suspect revision exists (in particular, when reverted). Cenarium (Talk) 19:28, 12 January 2009 (UTC)

ok, so instead of Soxbot III the abuse filter to handle obvious vandalism, still the additional filter set for the 97% good edits+catching the 2,5% of edits that contain libel and smart in dept vandalism is missing. Mion (talk) 23:36, 12 January 2009 (UTC)

We can't catch everything, but anti-vandalism bots can continue to work as normal (they will never catch and revert every obvious vandalism, but a considerable part, the abuse filter will catch and defer even more). There is more support to enable flaggedrevs on blps, a semi-automatic implementation could help here too: instead of deferring suspect edits, it would allow edits identified as non-controversial (like interwikis, additions of links to an existent page, etc). There I think the proposed expiration system (old enough revisions are visible to IPs, e.g. 48 hours) would help too, as backlogs would still be important. The abuse filter could also be used to report specific edits to blps, like 'death announcements' to a special page (with the option to defer if supported by consensus). Cenarium (Talk) 00:46, 13 January 2009 (UTC)

There is NO support to enable flaggedrevs on blps, as that is no vote but to bring up arguments, and yes the abuse filter can do everything cluebot can, the rest of the arguments is assumption as there are no possitive statistics from the DE wiki, in fact, it doesn't matter if you handle users as second class citizen with a waiting time of 48H, 6 days or 21 days, remember they are volunteers Mion (talk) 01:39, 13 January 2009 (UTC)

From the discussion, there is more support to enable flaggedrevs on a blp that there is on another article. The all or nothing argument is getting weary here, we can enable flaggedrevs on certain articles and/or restrict it to a subset of edits. In any case, and especially in the perspective flaggedrevs is, restricted or not, enabled on a vast class of articles, the additional benefit of a semi-automatic (virtual) flagging will be to avoid deferring most non-controversial edits. It can do better than ClueBot, since it is more adaptable and reactive, and would be especially useful against persistent sockpuppeters, often causing undesirable semi or full protections. If you do not believe that this or an expiration system would be a benefit on the basic implementation like on de.wiki, then fine, but you can't reproach me of trying to find ways to improve the system. As I said, I'm opposed to massive unrestricted implementations, but I still believe that an article with a reasonable flagged revision system is better than a semi-protected one. And I don't see disadvantages to a semi-automatic implementation if the filters are well designed. Also, using flagged revisions (flagging sysop-restricted) in a dispute instead of full-protection may work well. Cenarium (Talk) 03:19, 13 January 2009 (UTC)

There is your IF, show me the FILTERS well designed Mion (talk) 03:25, 13 January 2009 (UTC)

I am not familiar with the abuse filter's filters, so I can't code specific filters. I assume we could initially adapt the filters from the anti-vandalism bots, since they are clear-cut cases, then propose new filters for community approval, then implement them if there is consensus. If a filter causes too much trouble (read too many false-positives), then revise it and remove if it can't be fixed. I can only extrapolate, since there is no wiki where both extensions exist as far as I know. Cenarium (Talk) 03:46, 13 January 2009 (UTC)

Thinking of it, as Flagged Revs is enabled on the de.wiki, why don't you do the proposed trials on the de.wiki, looking at the current state, it can only go up with other approaches ? Mion (talk) 02:12, 13 January 2009 (UTC)

Abuse filter:"Please keep in mind that this extension's aim is not to catch simple vandalism, as some bots already do. This extension will help preventing harm from some known persistent vandals (hagger), with very specific modi operandi. It won't catch childish vandalism or page blanking" Mion (talk) 13:59, 21 January 2009 (UTC)

Requests for Surveyorship?

Continued from New userrights group discussion

Looking by the previous discussion on the usergroup 'surveyor'. So how are we going to choose surveyors? RfA-style? Crats no longer play mere technical roles, but social roles too in determining consensus. We already have enough politics in choosing administrators, we do not need to bring it to a whole new level - where editors start asking how should the usergroups get hierarchically arranged! I support FlaggedRevs in principle, but certainly not implementation in this form... - Mailer Diablo 19:40, 13 January 2009 (UTC)

At least for the duration of the trials, we really shouldn't be adding and removing flagged revisions from articles arbitrarily. Only a few people need to have it just to set up the trials at the beginning. Dcoetzee 00:17, 14 January 2009 (UTC)

It's obvious isn't it? If this thing were to be implemented, then in reality any editor with a proper account and an arbitrary number of edits and time served should automatically be deemed trusted. Say 1,000 edits and active for a year? Something like that. Then they get to OK edits. The last thing we need is more politics, if it's automatic for experienced users then there is no politics. Personally I think anyone with say 10,000+ edits should automatically become an admin and I think arbcom members should be drawn randomly from the community, with say 100 serving at a time. But then I hate hierarchy of any kind, and Wikipedia is doing it's best to turn itself into an authoritarian system "ruled" by those with the best networking and political skills. Alun (talk) 08:50, 14 January 2009 (UTC)

You've confused surveyors with reviewers. Dcoetzee 09:00, 14 January 2009 (UTC)

So we have "sighters", "reviewers" and "surveyors". Any more utterly absurd types of elitist sinecures we should create for the budding "content police". Surely we need a better hierarchy than this. Maybe some more military sounding "ranks" perhaps? Alun (talk) 10:51, 14 January 2009 (UTC)

BTW I didn't use the words "surveyor" or "reviewer". But reading this, it looks to me as if one needs the "reviewer" right to "survey" pages and then mark them as "sighted". So these seem to be all the same thing. Can you clarify the difference between a surveyor and a reviewer for me? Alun (talk) 11:06, 14 January 2009 (UTC)

This "surveyor" doesn't sound like the version that was put on the table for this trial proposal. - Mailer Diablo 14:03, 14 January 2009 (UTC)

Sure. I didn't make up the names, but it is the reviewer who reviews and sights (or flags) revisions. The surveyor is a position that exists only for the duration of the trial; they have the ability to enable or disable flagged revisions on specific articles. The purpose of this is of course to allow us to conduct a structured small-scale experiment. Dcoetzee 18:40, 14 January 2009 (UTC)

Surveyor is already taken Wikipedia:Flagged_revisions/Quality_versions#Reviewer_rights, Reviewers are surveyors who can mark pages as "quality" in addition to "sighted". Or would you like to test Quality versions in the same run ? Mion (talk) 20:46, 14 January 2009 (UTC)

On the de.wiki you get the Sighter status as you're registered for 60 days, you're not blocked before AND you made 300 edits, as a Sighter with "review" rights you can only validate edits from others, if a page is Sighted and you make an edit, your edit is not going live before its approved by another Sighter.

Update The group Sighters has now review + autoreview rights. Mion (talk) 17:25, 14 January 2009 (UTC)

Now discussion is ongoing on the de.wiki because of r45636, autoreview is enabled on the system, with the following set: All users with a confirmed email address, 1 year on the project and more than 3000 edits become autoreviewers, in effect, this group is auto sighting its own edits, the edits go directly live if the last version was a sighted version, if there are edits from others to sight in the article all stay invisible until another Sighter validates, its similar to the Bot-flag on de.wiki. Mion (talk) 10:46, 14 January 2009 (UTC)

Err...we really should just have one group, whatever it's called. Aaron Schulz 18:01, 14 January 2009 (UTC)

I think it should be called "editors". Now there's revolutionary. Alun (talk) 19:19, 14 January 2009 (UTC)

I am very sceptial about FR, BUT, I always say (maybe as a [European] liberal, heh), that it is always best to have a role in a situation which purports to improve the lives of other people than stand on the sidelines shouting. So I would be interested in putting myself forward for this "editor/what have you" role. doktorb _words^deeds 19:29, 14 January 2009 (UTC)

1. Like this

   Surveyor Sighter admin

   1 Sighter (reviewer + Autoreviewer) 300 edits AND 60 days

   2 Admin (reviewer + Autoreviewer)

   3 Registered users 3000 edits AND 1 year (Autoreviewer)

   4 Registered untrusted users (auto confirmed) 10 edits AND 4 days (none)

   5 Registered untrusted new users (none)

   6 Unregistered untrusted users (IP) (none)

SSA would be more clear. Mion (talk) 21:13, 14 January 2009 (UTC)

On the Twelve day of the trial, my b'crat gave to me..... - Mailer Diablo 06:20, 15 January 2009 (UTC)

Don't you think that too much emphasis is put on the "edit count" of an editor. I happen to have a low edit count compared to other users who have been around for about the same amount of time I have. I am confused as to who would have what, because of my edit count would I be considered a "untrusted user" or because of my rollback rights or being here more then a year would I be a reviewer? -Marcusmax(speak) 21:30, 14 January 2009 (UTC)

60 days and 300 edits is enough for reviewer (Sighter), its unlikely that editors with less get rollback rights granted. Mion (talk) 21:39, 14 January 2009 (UTC)

Let's only discuss the trial here, as it confuses to bring up other implementations that we know won't happen on Wikipedia anytime soon.

1 Surveyor (can review and change page configuration) (informally granted for the needs of a trial is best option)

2 reviewer (can review) (any user with no recent vandalism or libel edits with minimal time and edits here)

3 User (can't review, see latest rev per default)

4 IP (can't review, see latest flagged rev per default)

Cenarium (Talk) 21:55, 14 January 2009 (UTC)

Hmm, I'm skeptical about how much sense it makes to show logged-in users the latest rev by default. After all, many logged-in users are only occasional editors and primarily readers. Dcoetzee 00:29, 16 January 2009 (UTC)

Users can configure their preferences to see the latest flagged rev. Cenarium (Talk) 14:29, 16 January 2009 (UTC)

I'm still kind of confused here, so maybe someone can explain it to me in basic terms. I'm not an administrator, I do not plan to be one, and I've a megaton of edits dating back to 2007. I often make a lot of edits a day. If Wikipedia becomes Flagged Revisionpedia - will I be able to make an edit and immediately view it? For a random example, if I go to the page Melissa and change "Full of wrath" to "full of wrath" (or, just to be daring, delete "or Full of wrath" alltogether), will that be visible immediately? All Hallow's Wraith (talk) 11:59, 18 January 2009 (UTC)

First off, there would be FAR more sighters than admins. Secondly, ANYONE can view the most recent version of a page, the main difference is what you see initially. If you're seeing the sighted version, you can click a link to switch to the draft, and vice versa. Also, any edit made by anyone will show the editor the draft version when done. ♫ Melodia Chaconne ♫ (talk) 12:41, 18 January 2009 (UTC)

On the German wiki there are 312 admins and -/+ 50 active sighters, User:Hut 8.5/DEWP reviewer stats/ Mion (talk) 12:50, 18 January 2009 (UTC)

Of course, you would have sighter/reviewer rights. Any user with minimal experience (1 month here/100 edits for example) will be granted reviewer rights, unless s/he recently vandalized or added libel. But why would Melissa have flaggedrevs on ? This is not a proposal to use it on all articles, and most users supportive of a trial would oppose it. Realistic long-term proposals are: using it on blps, on articles instead of semi-protection, etc. Proposed trials are described here. Cenarium (Talk) 13:21, 18 January 2009 (UTC)

A lot of people are confused. From my understanding, the original proposal I saw at Flagged revisions was only 'reviewer', which flags a revision as reviewed. This version of the proposal wants to have 'reviewer' and 'surveyor', with the latter deciding which article is to have flagrevs turned on and only given out by crats. If that is true, it isn't that hard to guess that people probably would have to go through one of the most politicized processes on Wikipedia to ask for it..... - Mailer Diablo 11:03, 19 January 2009 (UTC)

I agree that the terminology is confusing if you try to read the various proposals together. Rather, think of them as progressive evolutions on the same idea; the user groups that are available, and the permissions they have, have changed as the discussion has progressed. As such, it is both impossible and confusing to try to directly compare the groups from proposals that differ in time.

The 'surveyor' permission is intended to be a stricly temporary role, one that is retained only as long as is necessary. The best current analogy is the role of stewards on small wikis. If a small wiki without local oversighters needs an edit to be hidden, they can make a request on meta and a steward will give themselves oversight permissions on that wiki, hide the edit, and then remove the permissions immediately afterwards. In a similar manner, when we have a consensus to start a trial we will have a need for one or more surveyors. We probably use an informal RfA-style process to select a few users who we believe are trustworthy with the extra tools, and the bureaucrats will flag them. Once the trial is completed, the permission is no longer necessary and so the surveyors will either resign (they have the ability to remove their own surveyor status) or be deflagged by a bureaucrat. If we need more surveyors at a later date, we can reappoint previous users or nominate new ones, as desired. But 'surveyor' is not a permanent position. Happy‑melon 13:05, 19 January 2009 (UTC)

Here's my prediction - 'surveyor' becomes permanent (as the "trial" would be) because the community and the originators would not be able to find the momentum to shift the (by then) status quo when the trial is implemented. (hey, we don't even have a bright-line date when the trial ends?) We are running on a Wiki with the size of 2.7m articles, not 270 articles. Are you aware how difficult is it to remove any userright/position that is admin and above over here?

Like it or not, this is how it's gonna actually work. The 'surveyor' usergroup would then be seen as higher than admin but lower than B'crat. People would queue up for them at RfS, thinking as part of the Content Certifying Committee of the Surveyors Socialist Cabal Union of the WWWP they would be able to a exert subtle but more control over articles and an extra hat, adding on to the hierarchies of Wikipedia. Bad, bad, bad idea. - Mailer Diablo 13:28, 19 January 2009 (UTC)

While the analogy is entertaining, I don't believe your concern is justified. On this issue, the proposal is crystal clear: indeed the only imperative clause in the entire proposal is that "each trial must have a definite endpoint". Similarly, the proposal is quite clear that "For each trial, a bureaucrat will appoint several 'surveyor's... At the designated end of the trial, the surveyors will... remove themselves from the 'surveyor' group". There won't be a Requests for Surveyor process, in the same way that there is no RfO for Oversight or RfC for Checkuser - the positions are created only when they are needed. For a bureaucrat to create surveyors outside the scope of a trial would be a violation of the proposed policy, which we trust them not to make (that's why they're 'crats in the first place, because we trust them). User rights such as admin, 'crat, checkuser, oversight, etc, are difficult to remove on this wiki because they can only be unset by stewards, and the only group on en.wiki that has the authority to instruct the stewards to take action is the Arbitration Committee. The situation is totally different with 'surveyor', where they can not only resign (and would be expected to do so at the appropriate time) but can also be deflagged by the bureaucrats. Failing to resign their surveyor status at the end of a trial is an overt violation of the proposed policy, for which a suitable reaction would be... loss of surveyor status. And lo, we have twenty users capable of taking that action. So your doomsday situation can only occur with the co-operation of the entire bureaucrat community. Do you have any evidence to suggest that this is likely to occur? Happy‑melon 13:46, 19 January 2009 (UTC)

"Each trial"...Are you sure one trial can even be completed? A "trial" till this day -> Article creation restricted to logged-in editors on "experimental basis", post-Seigenthaler, Seigenthaler 1 year after

"We probably use an informal RfA-style process"..."There won't be a Requests for Surveyor process" Well, even "RfO" and "RfC" is up for reform and be handed out to more editors who will use them. -> CheckUser and Oversight appointments reform. Furthermore, some WMF projects do hand them out by RfO/RfC.

"So your doomsday situation can only occur with the co-operation of the entire bureaucrat community."
Y not? -> Carnildo's re-promotion, Ryulong's RFA passing at 69.4%!?

What makes you think that everyone is willing to follow policy down to the letter? - Mailer Diablo 14:40, 19 January 2009 (UTC)

So you are comparing a knee-jerk reaction 'experiment' that was announced and implemented unilaterally and without any consideration of a review process, with a proposal that has been evaluated by over six hundred editors and which excludes an explicit prescription that every trial must have an endpoint (a level of prescription that is rarely used in policy, even in core principles)?

You misunderstand the nature of the proposed checkuser/oversight appointment process, which is about as far from RfA as you can sensibly get, if you think it is intended to lead to a proliferation of the CU/OS rights. Checkusers and Oversights will be appointed through that process only when they are required; if anything, the proposed endorsement method enshrines that principle rather than eroding it. Surveyors will be appointed in the same way.

There's really little I can say on your apparent distrust of the bureaucrat community; the examples you offer are like comparing chalk and cheese. Both situations are controversial, but there's a whole world between making controversial decisions, and endorsing an overt policy violation and abuse of power. IAR is not a catch-all "ignore any policy you disagree with" (and remember that there are a number of bureaucrats ranked on both sides of this discussion) but "ignore policy in situations where you ernestly belive that you are following the spirit if not the idea". If you honestly believe that there is a genuine risk of our entire bureaucrat cadre misinterpreting three policy clauses so badly as to essentially invert their meaning, there's very little else I can say. Happy‑melon 15:10, 19 January 2009 (UTC)

Crucial difference between the (successful) German implementation and suggested English trial

There seems to be a small but important difference, which actually matters a great deal to much of the discussed criticism of flagged revisions. In short: While the suggested English implementation arguably severely interferes with the "all can edit"-principle the German implementation does not.

This is how the German implementation works: An article displays in the default mode with a button at the top right (zur aktuellen Version allowing all readers to switch between the default view and the latest edit, when they are not identical. From the perspective of the (anonymous) reader all that the sighted status does, is influencing the default display, but he can always access the latest nevertheless. The default is the determined the following way:

1. if there is a sighted edit, the default display is the latest sighted edit
2. if there is no sighted edit, than the default display is the latest edit.

Note that this means all edits by anyone continue to go live immediately (just not in the default display) and if new articles is created by an IP it is in the default display even.

Here is the suggested English implementation: When FlaggedRevisions are enabled on a particular page, logged-out and anonymous users will see the most recent sighted revision, and all edits to that page can be sighted by members of a second usergroup, 'reviewer'. By default, all logged-in users, reviewers or not, see the most recent version of such pages, although this can be customised in personal preferences.

Here is no mentioning of a button allowing all readers to see the latest edit (and hence ensuring all edits are live immediately).--Kmhkmh (talk) 11:29, 15 January 2009 (UTC)

The proposed implementation in the english wikipedia will also have the button you are talking about. It's true that the text you quoted does not mention "a button allowing all readers to see the latest edit", but that doesn't mean that the button won't be present, it just means that the proposal is not very easy to understand. The actual proposal is at Wikipedia:Flagged revisions/Trial, especially in the "Technical implementation" section of that page. The proposal is phrased in terms of the way certain software configuration options will be set, not in terms of the observable behaviour of the software when it is configured in the proposed way. You can try the Live demonstration on en.labs.wikimedia.org to get a better idea of how the software works. Reading some of the answers to questions asked by other people would also have shown you that "all can edit" and "all edits by anyone continue to go live immediately (just not in the default display)". —AlanBarrett (talk) 12:43, 15 January 2009 (UTC)

well thanks for the clarification, unfortunately this site is rather long, so i didn't read all comments on that matter. However just reading some of the comments seems to indicate that many people are/were not aware of it, so it might be a good idea to explicitly include that fact in the quoted suggestion, which btw was taking directly from "Technical implementation" section of that page. The problem is, that the actual configuration of that button is crucial, i.e. it is not "just" some minor configuration issue to be settled after the test, but it should be an integral part of testing itsself. Also for most readers/editors the behaviour, i.e. the behavioural description, is the only thing that matters. So it's not a good idea to leave out such information from a proposal on which readers/editors are expected to vote. --Kmhkmh (talk) 13:03, 15 January 2009 (UTC)

Oh, I agree, the proposal should have been better worded. —AlanBarrett (talk) 15:32, 15 January 2009 (UTC)

(This is tongue in cheek, don't shoot me!) - The easiest way to word the proposal is done in 5 words. "This idea has been abandoned!" :) Thor Malmjursson (talk) 19:11, 17 January 2009 (UTC)

If hundreds comment or vote here

How come the number of people playing around here measures in the tens? I'm just sayin'. David in DC (talk) 18:17, 15 January 2009 (UTC)

Good question. But most people propbably just read the implementation description (i hope at least) and considered that info sufficient, also you can look at the other WPs already using flagged revisions to see what it looks like. also personally i found it annoying that testing seem to require (yet another) account.--Kmhkmh (talk) 04:17, 16 January 2009 (UTC)

I subscribe to your last sentence, Kmhkmh. That was also my impression when I took a look. - Hordaland (talk) 10:10, 16 January 2009 (UTC)

Thanks for the link David. In this implementation one can sight their own edit, which I thought we are not going to be allowed to do here? BTW Kmhkmh I was a bit annoyed by having to create another account, but then saw the link to unified accounts, so I unified my accounts, it was a piece of cake Special:MergeAccount. I had no idea this was possible before, so that's a real result!! Apparently if you unify your accounts yu automatically get an account in en.labs. Alun (talk) 13:29, 16 January 2009 (UTC)

If you have a global account, you can log in in most Wikimedia wikis. In the proposed implementation, an edit by a reviewer is automatically flagged if the latest revision is flagged, and any user with no recent vandalism or libel can become reviewer on request. Cenarium (Talk) 14:36, 16 January 2009 (UTC)

I tried, it does not work at all. All I could see is that sorry title page; where's the content to be watched? NVO (talk) 06:00, 17 January 2009 (UTC)

This test page is rather worthless from my point of view as it does not fuction anywhere near what we are talking about here. We say that an IP user will not see an unreviewed page. Yet the test page displays the unreviewed page when not logged in. It does include a not that the current version is unreviewed, but the link looks like this [[Help:Page validation|current revision]] - The link should be to the current revision on to a help page. It provides no information on what an IP user will see. And when logged in (after having set your permisions as a reviewer) the only option is to site the article. The test page is just a total waste of time. 207.78.65.254 (talk) 04:57, 17 January 2009 (UTC)

Separate page for votes

I just moved the votes to a separate page because this one is becoming monstrous and most discussions are still too alive to archive. Apologies if this screwed something up, but I don't have the fastest computer and this talk really hangs while loading. Estemi (talk) 17:21, 16 January 2009 (UTC)

I'm sure I've read somewhere summaries of the ongoing polls with # of people pro/cons. Can anyone please provide a link to such a report (also in my talk)? I've been searching for these infos for hours now. --Elitre (talk) 21:44, 16 January 2009 (UTC)

Link was half way up the page. I've added another one at the top.Ronhjones (talk) 22:10, 16 January 2009 (UTC)