Open main menu

UESPWiki β

UESPWiki:Administrator Noticeboard/Archives/Dropping the Ball on Vandalism

< UESPWiki:Administrator Noticeboard/Archives
This is an archive of past UESPWiki:Administrator Noticeboard/Archives discussions. Do not edit the contents of this page, except for maintenance such as updating links.

Dropping the Ball on Vandalism Among Other Things

(Note: The following has been re-organized into subsections and may therefore occasionally read a little oddly. Some discussion unimportant to the larger issue has been removed - specifically, the "asked and answered" topic of contacting Daveh and the occasional introductory clause or comment that had no substance of its own.)

So recently, we have had two major attacks on the site: one on the Template namespace (by someone who obviously knew what they were doing) and another most likely by an automated function. The server is still struggling to keep with the edits that took place a while ago, so something must be done in order to prevent this in the future.

I also proposed some revisions to the Deletion Policy that no one has responded to, so I might as well put it here as well.

I know this is a lot to think through, but I have been thinking about this for a long time. Recent events have just spurred me to mention it a little bit sooner. –Elliot talk 19:07, 30 November 2009 (UTC)

Auto-confirm Age and Count

Proposal: We could lengthen the current $wgAutoConfirmAge and $wgAutoConfirmCount settings to further hinder the ill-intentioned. $wgAutoConfirmAge is currently set at one day while $wgAutoConfirmCount is currently nonexistent. I believe it would be best to set $wgAutoConfirmAge to 3600*92 (four days) and $wgAutoConfirmCount to something around 20. And with both of these set, a user would have to fulfill both conditions in order to move into the autoconfirmed group. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: Noticeably, Wikipedia now has a 4-day policy, plus a much harsher policy for Tor users (see here). I have no problems with adopting a similar policy here. One-day was appropriate a few years ago, but as wikis become more common, so does vandalism, and I think that a 4-day policy, while unfortunate, is probably appropriate at this point. I have no particular opinion on the Auto-confirm Count, though noticeably Wikipedia has theirs set at 10 currently, so that may be something to consider. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
I don't think it is that harsh, since the only privilege they receive is being able to edit semi-protected pages. This would strengthen the defense for template vandalism. –Elliot talk 01:15, 1 December 2009 (UTC)
One thing I meant to ask is, how is Wikipedia identifying Tor users? If they've got an automated method other than the "Tor check" on the User Contributions page, it could be useful to find out how they're doing it. —Robin Hood (Talk • E-mail • Contribs) 23:40, 2 December 2009 (UTC)
I would rather keep to Wikipedia's counts than the ones proposed. I especially feel that 20 edits may be a bit too much. It's not much for established editors, but for new editors it may take a while before reaching it. An editor can perfectly prove him/herself within 10 edits. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
I am fine with the 4 days/10 edits setup. –Elliot talk 17:12, 1 December 2009 (UTC)
I have no problem with using Wikipedia’s standards, or keeping the same ones we have now. --Ratwar 04:36, 2 December 2009 (UTC)
I think we should use Wikipedia's for awhile. –Elliot talk 16:37, 2 December 2009 (UTC)
I'm good with the 4 days / 10 edits policy on this one. –Eshetalk 00:24, 5 December 2009 (UTC)
Four days / 10 edits sounds reasonable to me. --GKTalk2me 02:10, 5 December 2009 (UTC)
Consensus
Set $wgAutoConfirmAge to 4 days and $wgAutoConfirmCount to 10 edits. –Elliot talk 02:32, 10 December 2009 (UTC)

Creation Protection

Proposal: I think we should utilize the new feature of Creation Protection. Perhaps this could be a parallel discussion with the Protection Policy, but we will see how it goes. I think that pages deleted via prod (perhaps just DRed) should be protected from creation for a lengthy period (I was thinking along the lines of about 6 months) to ensure that we don't have to waste time dealing with what will eventually end the same. If someone really wanted to create the page, then we could have them establish a copy in their userspace; and if an admin deems in suitable, they will allow them to create it.

Also, there are :Category:Spam-Blockers|spam blockers that are also made unnecessary due to this feature. I think they should be deleted and indefinitely salted (something WP uses to define creation protection). –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: Given that the feature now exists, it seems reasonable to use it. Unless I've misunderstood, this essentially fills the same purpose as the Spam-Blocker pages, only it's built-in instead of a workaround, so why not use it? —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
Yes, the spam blockers are no longer necessary. –Elliot talk 01:15, 1 December 2009 (UTC)
To clarify, I only meant that we should use this to replace those pages that we've already salted, since it's the built-in method and not a kludge of a workaround; I don't agree that we should salt all deleted or speedy-deleted pages, unless of course there's clear-cut repeat vandalism occurring. —Robin Hood (Talk • E-mail • Contribs) 23:40, 2 December 2009 (UTC)
I can't recall any example of where a page was recreated after it had been deleted, other than by a spammer or vandal. I believe we already had something of a blacklist, and I feel it needs only be used to prevent vandalism and spam. If the same page is recreated after it was deleted it can simply be proposed for speedy deletion, and the creator can be advised on the workings of consensus. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
The Elder Scrolls V was created about 2 months after originally being deleted. And guess what? It is sitting there prodded, wasting other people's time. That is why we should salt DRed pages for 6 months. –Elliot talk 17:12, 1 December 2009 (UTC)
If an article is created against consensus, it can be speedy deleted. Marking it and deleting it is easy enough. It doesn't happen often enough to create a system for it. --Timenn-<talk> 14:07, 2 December 2009 (UTC)
I still think, that after a deleted page is speedied after an unnecessary creation, it should be temporarily salted. And the spam blockers need to be deleted and salted as well. –Elliot talk 16:37, 2 December 2009 (UTC)
I’d be fine using it as a spam blocker, a little bit more iffy on it becoming a regular part of Proposed Deletion. Like Timenn, I don’t see it as a problem, and since we’re supposed to assume good faith, it could be seen as counter to that policy. I just don't see one simple example as a reason to do it to hundreds of pages. --Ratwar 04:36, 2 December 2009 (UTC)
Then we will have to add it to the speedy deletion "clause", saying that it is permissible to add a speedy tag to recreated pages. –Elliot talk 00:05, 4 December 2009 (UTC)
Yes, that is a good idea. It fits almost entirely in the consensus policy already, but making an extra note about it wouldn't hurt. --Timenn-<talk> 12:21, 4 December 2009 (UTC)
If we're having trouble with frequently recreated pages, why don't we just simply redirect those pages to the correct page? For example, 'The Elder Scrolls V' could be redirected to General:The_Future_of_TES_Games. I mean, this would have to be done on a case by case basis, but if a page is recreated, we can only assume that either people want an article on that subject, or can't find the current article on that subject.--Ratwar 16:38, 4 December 2009 (UTC)
It is the case in some instances, but that can't be done for all of them, as you have stated. So it is best to have a policy for all instances. –Elliot talk 20:37, 4 December 2009 (UTC)
That is a good point. I'd be fine with it as long as it only covers pages that need to be deleted twice or more.--Ratwar 21:55, 4 December 2009 (UTC)

I'm okay with using this with pages that are frequently created for spam or nonsense, but other than that I think it would be a little tricky. Besides, if people keep creating an article, we might need to revisit whether we were wrong to delete it in the first place. I'd say clear-cut vandalism/spam/nonsense only, with a...2 month duration or so. –Eshetalk 00:24, 5 December 2009 (UTC)

If it's a speedy delete for spam/nonsense/vandalism, then it makes sense to prevent recreation, but I'd rather not make it a fast rule for all deleted pages. It makes more sense to me to just make a decision as special cases come up. --GKTalk2me 02:10, 5 December 2009 (UTC)
I think it would be best to the spam blockers deleted and salted (saves space). I guess someone can propose them for deletion if necessary. And we seem to have a bunch of pages spammed that have the word "Journal" in it (whether it's a key word or just some spammer trying to fool us doesn't really matter), so I think that after 2 deletions it can be salted for about two months. And, we will need to add a clause that states that recently DRed pages (deleted, obviously) are reason enough to be speedy deleted. Any objections or notable issues? –Elliot talk 11:40, 5 December 2009 (UTC)
I'm having trouble finding the discussion, but didn't Nephele implement a similar system earlier? I could recall a blacklist being made for page creation, and some of the spam blockers being deleted (as they were no longer deemed necessary). --Timenn-<talk> 17:03, 7 December 2009 (UTC)
Yeah, I remember something of the sort, but the creation protection was never really implemented (she didn't think that going back and deleting the spamblockers was necessary). I think deleting and protecting them is better as they are listed in Special:ProtectedTitles. –Elliot talk 21:19, 7 December 2009 (UTC)
It should be used but not as suggested. I already killed a number of spam blocker pages (or rather, I nominated them and somebody else killed them) that were no longer needed because of the title filter we have (this is the one Timenn is mentioning - MediaWiki:Titleblacklist). Permanently preventing creation of a talk page is totally wrong and should never be considered. Preventing creation of articles... maybe. But if somebody really wants to create a badly-informed article on TESV, they'll just use a different name (TES5, TES V, TES 5 or whatever). Where it's a page like /index.php/whatever then yes, permanent creation protection is sensible. I like the idea of adding a new criterion to the Speedy Deletion policy though. –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)
I am fine with the first part, but we need to use it for the spam blockers. I am fine with taking the others with a case-by-case look. –Elliot talk 23:05, 7 December 2009 (UTC)

\=> Thanks for linking that blacklist rpeh, that is the one I was looking for. I think we can manage with that list for the more persistent spam titles. --Timenn-<talk> 16:56, 8 December 2009 (UTC)

At the moment, 14 of the 21 spam-blockers end in "/". There's no reason why a page should end that way so adding (I hope) ".*/" to the blacklist should mean those 14 can go.
In general, a rule is preferable over an exception so things that can go on the blacklist should be prefered over protecting individual pages. Whichever admin updates that blacklist should remember the content1/content2 problem - both servers may not update straight away. –rpeh•T•C•E• 22:41, 8 December 2009 (UTC)
I'm fine with that, but what about the other 7? Creation protection should be used in in the case of the exception. –Elliot talk 22:51, 8 December 2009 (UTC)
Certainly. I can no longer see deleted edits but if there was definitely a history of vandalism on those pages, they should have protection applied on an individual basis. –rpeh•T•C•E• 22:54, 8 December 2009 (UTC)
We need to decide about talk pages. Titles with "journal" have been hit a lot (talk pages), and they are recreated a good majority of the time. I know permanent protection is a bad idea, but I can't see a way around it. –Elliot talk 23:15, 8 December 2009 (UTC)
Consensus
Add .*/ to the MediaWiki:Titleblacklist. Salt the rest of the spam-blockers for an indefinite amount of time. And add a note in the protection policy that salting be used at the administrators discretion. –Elliot talk 11:53, 11 December 2009 (UTC)

Deletion Policy - "Contested"

Proposal: This proposition is fairly small and has to do with the word contested: The deletion review is where pages that are contested or potentially controversial are debated. There have been some pages that are proposed for deletion, with the user who created the page removing the prod. This has been viewed as contested before, but I don't really understand why. It is a natural reaction to contest something that you delete. A recent DR was made after the creator contested the prod, and was the only one who contested it. It went to DR and was (nearly) unanimously chosen for deletion. Defining this word will allow for some quicker actions to be taken on the more obvious terms. And the definition I want is that contested implies a challenge from a third party. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: I can understand the idea behind this, but I can't agree with it, if for no other reason than that it violates the spirit of the "everyone's vote is equal" concept. If we modify the policy at all, I would say that we should introduce an exception to the DR policy that if one admin and another admin/patroller apart from the creator and prodder agree with the deletion, it can be deleted without the need for a DR. This would mean that a minimum of three people believe it should be deleted, at least two of whom have experience with what's normally considered deletable. If others later object, the pages can be undeleted and it can proceed to a full DR. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
You misunderstood. It only disallows the creator of the page to contest the prod. I mean, of course they are going to contest it. So it would only save time from the inevitable (a deletion). –Elliot talk 01:15, 1 December 2009 (UTC)
I'm not sure I misunderstood about the "contested" thing. I consider the creator of the page to be equal and still have an equal vote - you can't just dismiss his/her vote because they're the creator. It's not a given that they'll contest it, though it's obviously more likely. —Robin Hood (Talk • E-mail • Contribs) 01:34, 1 December 2009 (UTC)
But if they are the only one that contested the deletion, would a deletion review be necessary? –Elliot talk 01:39, 1 December 2009 (UTC)
If it's one person vs. another, then I don't the the creator's vote should be trumped just because they're the creator. If nobody else has commented, then I think opinions should be solicited from other "staff" (as suggested above) or maybe even long-time users and if the creator still disagrees and can find someone else who does as well, then it should go to a deletion review. —Robin Hood (Talk • E-mail • Contribs) 01:44, 1 December 2009 (UTC)
Well, it won't be one v. one because of the admin deleting the page decides what to do. If they see a problem with it, then they will mention something, and not delete it. –Elliot talk 01:48, 1 December 2009 (UTC)
(outdent) True, but even one vs. two is a slim margin to declare something deletable. It's still essentially trumping the creator's vote. Anyway, I'm off for dinner, I'll let others (hopefully) give opinions on everything, as well as this particular issue. —Robin Hood (Talk • E-mail • Contribs) 01:52, 1 December 2009 (UTC)
However, you forget that the prod remains up there for 7 days. So by not refuting it, editors implicitly agree with the proposed deletion. But obviously, the defense must show itself explicitly. And that is done by the creator of the page on the talk page. –Elliot talk 06:02, 1 December 2009 (UTC)
I agree with Robin Hood's statement that "everyone's vote is equal". I prefer to spend a bit more time setting up a deletion review, than to give the creator's the impression he is being overruled simply because he is less experienced. I think changing this would only sour the atmosphere here on UESP. Subtle bureaucracy can sometimes save an environment from changes that are made on the whim of one editor. I'm not saying that all prod's contested by the creator should be turned into a deletion review, but I don't want it to be a policy that another editor has disagree first. The spirit of proposed deletion is that the one who proposed it is probably right, but may have missed something, so another editor can jump in on time. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
Where is the implication that this would invoke some form of mild-totalitarianism? Basically it would say this: You want the page kept? Prove to US that it deserves to be kept on the talk page. If the prodder still disagrees, and there are other editors that agree with the creation, THEN can it go to a DR. I am not trying to say that someone's vote is being overruled by just one person. If no one else agrees with the creation of the page, then why would we waste time on a DR? To make people actually give their opinion when the "chips are down"? –Elliot talk 17:12, 1 December 2009 (UTC)
I don’t really like the idea of automatically demoting the creator of the page (especially when many are created by new users) to a second class citizen. I mean, the Deletion Review Page is far from clogged as it is as there is only one active deletion review and that is the only Review in about a month. --Ratwar 04:36, 2 December 2009 (UTC)
I agree with Ratwar on this, there are few enough deletion review snot to be hindered by them. I rather waste a little more time on a DR than not to see it done properly. Deletion Reviews are easier seen by more editors than a remote article, so it's easier for more voices to jump in (and a potential extra defendant). --Timenn-<talk> 14:07, 2 December 2009 (UTC)
It's not really demoting them. It's saying, "If no one else agrees that we should keep your page, then what is the point of keeping it?" –Elliot talk 07:00, 3 December 2009 (UTC)

\=>Hm, swapped a few replies here, as they used to be in a different order. (How could I agree with Ratwar before he made his argument?)

The problem is whether creators of articles will truly feel the way you say. Such pages are usually created by new editors, still learning the tricks of the trade. Taking their opinion on their contributions very seriously can make them feel more welcome. This is different from normal edits, as they can easily be reverted (deleted edits cannot be). --Timenn-<talk> 12:21, 4 December 2009 (UTC)

Elliot, the problem I see here is that a 'Proposed Deletion' doesn't really say that no one (other than the author) thinks that we should keep the page. All it says is one editor (or maybe even a few editors) thought the page could be deleted.--Ratwar 16:41, 4 December 2009 (UTC)
The point I am trying to establish is that the person who made the page, rather than remove the prod on the page, state their case on the talk page. If the prodder, any one else, or the deleting administrator agrees with the user, then they can remove the prod. If some people still feel it should be deleted, then they take it to a DR (kind of like the senate in killing the debate). So please, stop implying that I am taking away the (often unused) voice of the page creator. –Elliot talk 20:37, 4 December 2009 (UTC)
I still don't like it. There is no need for it as I've previously stated, since the DR page is hardly clogged by anything besides cobwebs. If a deletion is opposed, take it to Deletion Review, or if the opposing side is small, convince them it ought to be deleted.--Ratwar 22:21, 4 December 2009 (UTC)
if the opposing side is small, convince them it ought to be deleted Wasn't that exactly what I said? –Elliot talk
Ummm... Not anywhere that I can see... By that comment I was merely saying that under current policy it is quite acceptable to convince new editors that the page should be deleted without going to deletion review. Only when that fails do you move to a Deletion Review. This both allows the page to be deleted quickly and respects the opinions of the page creator.--Ratwar 00:14, 5 December 2009 (UTC)

(outdent) I can't agree to this. Everyone's vote is equal, so if a reasonable explanation for why someone thinks a page should be deleted does not change the creator's mind, it should go to a deletion review, per our current policy. –Eshetalk 00:24, 5 December 2009 (UTC)

I find it dismissive and rather rude to assume that if a deletion is disputed by the page's creator then it's not worth considering their thoughts on the subject. Current policy works just fine. --GKTalk2me 02:10, 5 December 2009 (UTC)
I still don't see where you people are coming up with the prospect that they lose heir opinion. Obviously the administrator is going to view their opinion. I still fail to see how everyone jumped to that conclusion...
  1. The page is prodded.
  2. The author makes their case on the talk page.
  3. Other members make their statements for the next 7 days.
  4. If it is going to be controversial, then an editor or admin takes it to a DR. If it isn't, then the admin deletes it.
Basically this cuts down the need for a DR. And also, we should mention that the creator makes their case rather than bluntly removing the tag on the tag itself. –Elliot talk 11:40, 5 December 2009 (UTC)
Actually, the Proposed Deletion notice invites anyone (it does not limit the people who may do it) to remove the notice if they have any objections, but you propose to change that?
I don't feel happy with that. The Prod is intended for pages that almost automatically go to the grinder. The 7 days is a failsafe to protect the pages that do not deserve deletion. --Timenn-<talk> 17:03, 7 December 2009 (UTC)
What I don't want is an edit war over a small thing like a tag. If we leave it on for 7 days or so while people discuss, it will put the focus on the conversation, and not the tag. –Elliot talk 21:19, 7 December 2009 (UTC)
Kind of Agree. There have been several cases where the only person to question a Proposed Deletion tag was the author and it therefore had to go to Deletion Review. There has never been a case where such a contested deletion didn't end up with the page being deleted with a huge majority. I think the best case was the Punching horses page. It ended up with Nephele adding one sentence to an existing article. Nobody apart from the article author had anything to say in defence of the article but the whole process dragged on for several days. Even the addition Nephele made had to be qualified massively to get it away from being a real "good idea". People are always going to defend their articles but in almost all cases, if there's nobody else willing to stand up for that article, it should be killed. Perhaps another addition to the deletion policy would work here? Add a param to the Proposed Deletion template to indicate that the creator has objected. Then the deleting admin will be able to spot a potentially tricky problem more easily and either give the deletion more time, move it to DR or, if there's been no debate on the talk page beyond "I object" - delete it. At the moment a fairly effective way of trolling the site would be to create a dozen basically useless articles and object to all the deletions. Some poor admin then has to create DRs for each. I know that hasn't happened yet, but since this is about picking up the ball, it's worth mentioning. –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)
I think the idea of adding a parameter is a good idea; it should mention on the tag that the author has made a defense on the talk page. I think with no defense on the talk page, then it shouldn't be an issue to deleted. –Elliot talk 23:05, 7 December 2009 (UTC)

\=> Always creating a Deletion Review when a creator objects to a deletion was never the issue. The reverse is what I'm opposed to. When a creator objects to a deletion, it shouldn't automatically lead to a DR, but neither should it ignored by default until someone else opposes it too.

I'm just wondering if adding the extra parameter will only make it more complex, especially considering very few Deletion Reviews have been created after a creator objected. Usually the existence of a talk page should warn the administrator that the Prod might have been objected to. --Timenn-<talk> 16:56, 8 December 2009 (UTC)

It will be more complex, and that's an argument against this. Maybe the talk page is all that's required, but I know from experience it's easy to miss. It'll need a policy tweak though in any case. Maybe... give it one extra week if the creator objects? –rpeh•T•C•E• 17:03, 8 December 2009 (UTC)
Well, on Wikipedia, they have a "hangon" template that the creator uses to make note of their case. WP only uses it for speedy deletions, but it seems like something we can use as a mold for our own. –Elliot talk 09:01, 10 December 2009 (UTC)
Consensus
Nothing to change. Ask the creator of the article to defend his position on the talk and try to reach an agreement. If nothing is worked out, take it to the DR. –Elliot talk 11:53, 11 December 2009 (UTC)

Deletion Policy - Single Active Admin

Proposal: The addendum proposed by rpeh (seen here) should be implemented into policy, rather than having administrators ask for permission to delete prodded pages after four weeks. There may be times when four weeks pass with a backlog of pages that need deleted. I fail to see how this is even minutely controversial. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: Agreed. If nobody has cared enough to take action after four weeks, then a page should be proddable without a second opinion. In an ideal world, a second admin should be encouraged to approve the deletion, but if everybody's inactive, then the one remaining admin shouldn't feel bound by an inapplicable policy. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
It's not necessary to change this policy. There is a backlog of around 40 pages at the moment, which is usually much lower. The situation as was then with rpeh is far different than the one currently. I prefer the way two editors have to check a proposed deletion before it can be deleted. If a similar situation arises as the one past Spring, then we can handle it at that time. There is no need to create a policy for it, and I would not agree with it. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
But at the same time, it is not necessary to not change the policy. If this doesn't go through, then I would help the admin by removing the prod and adding it myself, so they can delete it a week later. I mean, it allows for "fishy" behavior if you don't allow something so harmless to be done. –Elliot talk 17:12, 1 December 2009 (UTC)
The small backlog is almost cleared now, with little enough effort of Ratwar and me. Changing this policy will have us lose the concept of deleted articles being reviewed at least twice, and reinforcing the belief that administrators cannot delete articles simply on their own. --Timenn-<talk> 14:07, 2 December 2009 (UTC)
If you think it needs a second opinion, and only one admin has been on for an entire month, then perhaps a patroller can check off the deletion. –Elliot talk 16:37, 2 December 2009 (UTC)
Actually, changing the policy in that way wouldn’t really help. I just went through the Proposed Deletion Category and found that all three active administrators had pages that they’d nominated that were about a month old. That is to say that nobody is really deleting pages often. I just don’t see it as a pressing issue. --Ratwar 04:36, 2 December 2009 (UTC)
It may not be pressing now, but it could be beneficial in the long run. Plus, I don't see why not letting patrollers check off on the deletion is a bad idea. –Elliot talk 00:05, 4 December 2009 (UTC)
Administrators may be better aware of some of the site's workings to understand which articles are actually still of use. They have been around a bit longer. Sometimes the use of an article is not always very clear (certain redirects, for example). As you say it, a patroller would only check off the deletion as an automatic measure, which is not the intention behind the double-check before deletion. Preventing a single administrator from deleting articles makes sure that no administrator is pursuing his/her own vision of what needs to be deleted without discussing it. You mostly name examples from the time rpeh had to deal with a serious backlog of deletion proposals. As this is no longer the case, I don't feel the need to take these drastic measures. --Timenn-<talk> 12:21, 4 December 2009 (UTC)
So administrators have voice when they are not present? Seems kind of foolish. If there is no one else here, then why would it be such a huge problem, after an entire month, for an admin to delete a page they prodded? If it was so bad, I am sure a patroller would remove the prod if they felt some freak agenda occurring. Elliot talk 20:37, 4 December 2009 (UTC)
I fully agree with Timenn.--Ratwar 22:28, 4 December 2009 (UTC)
I still don't like the implication that patrollers are unable to decide some things. But, to each his own I suppose. –Elliot talk 23:46, 4 December 2009 (UTC)

(outdent) I'd rather leave this one as is. If there's a serious backlog of pages that for some reason need to be deleted (though I can't think of circumstances where this would happen) and they've been sitting around for several months, I'd say it's okay for the same admin to delete them. I'd prefer if the admin made note of it before proceeding to make sure the community is okay with it first. Really, pages that are marked for deletion aren't hurting anybody if they sit around a little longer than a week, so I don't see a need to define this in policy. –Eshetalk 00:24, 5 December 2009 (UTC)

There's no reason to change a policy that's working. If we must change it, I'd say that it be something along the lines of if the number of undeleted pages are having a detrimental effect on the wiki, then it is reasonable for the same admin that prodded a page to delete it. --GKTalk2me 02:11, 5 December 2009 (UTC)
I would be fine with that. (Numbers and set periods of time tend to aggravate people for some reason, rather than concepts...) –Elliot talk 11:40, 5 December 2009 (UTC)
I would prefer to propose that the administrator posts a notice first on the talk page, and do deletions after no one has objected for 7 days. --Timenn-<talk> 17:03, 7 December 2009 (UTC)
I am open for any implementation of this, because I don't like the current state now. –Elliot talk 21:19, 7 December 2009 (UTC)
Well obviously I agree with that one. Ratwar's argument of "I just went through the Proposed Deletion Category and found that all three active administrators had pages that they’d nominated that were about a month old" is irrelevant - the change was suggested when there were pages staying around for months, and even in this case having pages around for over a month is still indicative that a change is needed. Surely we can agree that if nobody has anything good to say about a page inside four weeks, it can be killed? –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)
I agree with rpeh. I don't see how this is a true issue. Administrators shouldn't have a say if they aren't around to say anything. Of course it really isn't a problem now (although there are pages that have been prodded for a month or so now), but it has happened before. It goes into the ex pre facto realm, but I don't see that as a problem. –Elliot talk 23:05, 7 December 2009 (UTC)

\=> So make a notice on the Deletion Policy talk page that you are about the clean up the older articles (older than a month), and will continue if no one has objected after seven days? That has been done before. --Timenn-<talk> 16:56, 8 December 2009 (UTC)

Yes, but there is no policy doing that (so essentially, the admins were wrong in doing so). We just need to add it to the policy page. –Elliot talk 22:26, 8 December 2009 (UTC)
Exactly. I previously announced that I was going to violate policy, and then did so. The fact that nobody complained about either event speaks volumes though. Timenn is right - the policy should be tweaked to allow such actions, but despite the current good maintenance of the deletion list, I really think this is something that needs doing. –rpeh•T•C•E• 22:28, 8 December 2009 (UTC)
Consensus
Any administrator wanting to deleting articles that they proposed for deletion must make mention on the Deletion Policy talk page, wait 7 days for no objection, and then delete the articles. –Elliot talk 02:32, 10 December 2009 (UTC)

Edit Filter

Proposal: Another possible choice would be an Edit filter, which uses regex. There has been some concern over this, but I am just mentioning it as a possibility. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: It might be something to consider if vandalism becomes more of a problem, but right now, it sounds like it's probably more trouble to setup and maintain than we could justify. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
The edit filter is extremely flexible, and my main reason for wanting this is to be prepared for the release of TESV, which everyone knows will be a tad chaotic. –Elliot talk 01:15, 1 December 2009 (UTC)
I don't see it mentioned here or in a quick scan of the link provided, but in a PM, Elliot mentioned that there was a "log only" mode to the filter. If that's the case, it might be beneficial to install this in log only mode and see what it would have blocked and what it wouldn't, then make a decision. In the end, though, there are advantages and disadvantages to such a system, and at least from my perspective, there's no clear argument for or against using it, so I'm neutral on this. As I said above, it may be more trouble than it's worth, but if someone is interested and willing, I won't object, either. —Robin Hood (Talk • E-mail • Contribs) 23:40, 2 December 2009 (UTC)
A definite no here. Regular expressions are a pain to set up if you can't exactly describe what you want to have filtered. Remember that censure practitioners have struggled with this issue for a very long time. Editors will simply come up with a way to break through the filter. A regular expression filter is by no means an intelligent filter, and I fear they would only slow the site down. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
There are more than just 'regular expression' filters. There is a filter that can stop people from editing a certain page until they have a certain edit count (perhaps this is how we protect the templates, eh?). The best thing to do would be to go through WP's filter and see the scope it can achieve. –Elliot talk 17:12, 1 December 2009 (UTC)
The main problem is that we no detailed plan against what we'd wish to set this up. Such filters usually grow very long and tedious to maintain. I also fear for it to slow down the site parser if syntax, or semantic, errors are made in the regular expressions (easy enough to make!). Higher level filters mostly inherit these problems rather than solve them. --Timenn-<talk> 14:07, 2 December 2009 (UTC)
I just feel like it is too easily fooled, and could generate false positives. I may be old fashioned in that respect, but I just don’t see the need. --Ratwar 04:36, 2 December 2009 (UTC)
I think I should guide people here. Simple ones that are extremely beneficial do something like !("autoconfirmed" in user_groups) & (new_size >= 50) & (article_namespace == 0) & (edit_delta < -5000) & !(user_name in article_recent_contributors) & !("#redirect" in lcase(added_lines)). Hardly difficult in any case. Here is a list of all of them. –Elliot talk 16:37, 2 December 2009 (UTC)
I might as well expand upon this idea. With the filter, there is a log-mode and then an action-mode. The log mode allows the edits, but it just informs us of what triggers the filter. This allows for some false positives to be noticed and fixed if the filter were to go completely live. The action mode has some tricks. It can just inform the user that their edit is most likely not a good idea, but it will still let them submit it if they really want to. Other functions stop the edit all together. And it can farther to block a user, but I don't think that is a good idea. This can be used to stop anonymous editors from editing templates. We get a log of edits, a log of changes to the filter, and basically everything you can think of. –Elliot talk 00:05, 4 December 2009 (UTC)
Don't you need to upgrade the site to MediaWiki 1.15.1? You don't have a Special:Tags page. Maybe we should wait for User:Nephele since she handles the MediaWiki configuration and MySQL database. --Michaeldsuarez (Talk) (Deeds) 00:14, 4 December 2009 (UTC)
We are not a wikia, so we don't have (need?) a tags page. Plus, the edit filter can tag edits if we want. And why would we need to be 1.15.1? I didn't find that version in any documentation of the filter. And also, we are 1.14.0. –Elliot talk 00:36, 4 December 2009 (UTC)
What does this have to do with Wikia? Wikipedia has one: wikipedia:Special:Tags --Michaeldsuarez (Talk) (Deeds) 00:39, 4 December 2009 (UTC)
Most of your experience comes from wikias. I checked OblivioWiki, and it had a tags page. Simple synthesis of information. –Elliot talk 00:45, 4 December 2009 (UTC)
(indent) http://www.mediawiki.org/wiki/Manual:Tags and wikipedia:Wikipedia:Tags. --Michaeldsuarez (Talk) (Deeds) 00:48, 4 December 2009 (UTC)
Okay? –Elliot talk 00:52, 4 December 2009 (UTC)
No. Browsing through the list I can see various examples of things we don't have to weed through to find false positives. Prohibiting a user from simply stating that he/she thinks a certain bug "sucks", various filters that would give an alert when people are simply writing fan fiction or filters that will never apply to this site. These are all examples I don't want to weed through when looking at all the positives.
And there are questions like who will maintain that list, and must they apply to all users, or only those not autoconfirmed? It may sure look from a cleaner's perspective how all vandalism looks alike, but trying to catch the bulk of it with just enough filters is a tedious job. I for one don't look forward to maintaining it. --Timenn-<talk> 12:21, 4 December 2009 (UTC)

By using certain regex, you can restrict an action to a certain namespace or even a specific page. Fan-fiction should be writen in the User namespace, and "sucks" could be stated on a talk page (when describing a bug, as you've stated). Maybe you should use the filters only for the article namespaces (Morrowind, Oblivion, Lore, etc.) and not use any filters for talk pages and the User namespace. A lot of blanking occurs in the User namespace by the owner of the user page, so you may not want those actions to trigger a response in that namespace. Unfortunately, adding a "Novel(s)" namespace would also mean that you have to modify every filter.

Also, users could use alternative spellings and "leetspeak" to get around the filters. For example, you could easily block "suck". However, a vandal could get around this by using "5uck", and if you block that, they would use "this wiki sux". You would need to write many, many filters.

Yes, it's going to be a tedious job. --Michaeldsuarez (Talk) (Deeds) 14:19, 4 December 2009 (UTC)

I am shocked that the idea of something being tedious is reason enough to kill it. And plus, I wouldn't mind watching over it. And MDS:
!("autoconfirmed" in USER_GROUPS)
& (article_namespace == 0 | article_namespace == 3)
& (
line1:="\b((yo)?u|(s?h|w)e|they|it?) (5|s)u(ck|x)";
added_lines rlike line1)
& !(removed_lines rlike line1)
I am still learning the Java script part of the regex, but that wasn't so hard (like I said, WP has weeded out many of the pointless filters). I would need out namespace numbers as well, but again, that is easy enough. And limiting fanfiction to the userspace via the filter is absurd... Also, here is another beneficial filter against blanking:
!("autoconfirmed" in user_groups) & new_size < 50 & old_size > 500 & article_namespace == 0  & !(user_name in article_recent_contributors)
& !contains_any(lcase(added_lines),"#redirect", "{{prod}}", "{{proposeddeletion}}", "{{speed}}")
That is why I want to be able to have it for a long time before TESV comes out so we have a functioning filter by then. This won't happen overnight; it requires a lengthy amount of time to build, log, fix false positives, log, and then finish. Also, if you don't want to be a part of it, then don't be. But stating that you personally don't want to do it is a nonsense reason to stop other people. –Elliot talk 20:25, 4 December 2009 (UTC)
(outdent) While it's always nice to have people who are interested and able to maintain things like this, what happens when they leave (NepheleBot and until recently RoBoT, for instance)? Worse, what if there are problems after they leave? I don't rule out an Edit Filter altogether, but I think it should be a last resort that we only reconsider after we see how well any other measures we implement actually work out. —Robin Hood (Talk • E-mail • Contribs) 23:56, 4 December 2009 (UTC)
It can be shut off if I or someone else happens to leave. Or someone else can come up and start working with it if that does happen. –Elliot talk 00:05, 5 December 2009 (UTC)

(outdent) I feel like this is more trouble that it's worth. People who are set on vandalizing aren't going to be stopped by having to pass by another page. Ultimately, I think we'll spend as much (if not more) time setting up and monitoring the thing as we currently spend checking edits without it. When it comes to checking edits, I'd rather have a hu-man doing the work than a script or a bot. –Eshetalk 00:24, 5 December 2009 (UTC)

Elliot, if we had any need of it, I could see implementing it. Otherwise, I just don't see the real use of needing to maintain an edit filter, especially if only one person is trying to manage it.--Ratwar 00:34, 5 December 2009 (UTC)
Granted, I don't really know the intricacies of this kind of thing; that said, from what I've been told about this, I think it could be handy if we use it in log-only mode. It would just give those of us who care a list of edits that are more likely to be shady. I can't see the harm in it, though I have no desire to use it to give editors messages or disallow edits. --GKTalk2me 02:11, 5 December 2009 (UTC)
It doesn't seem important, but I advise members to have this in the back of their minds if the edits start to pick up for some reason. –Elliot talk 11:40, 5 December 2009 (UTC)
These are always more trouble than they're worth. I'm not going to link it, but Google the "Scunthorpe Problem" for a good example. No matter what filter you put in place, good faith edits will be denied. TES deals with a fictional world with fictional names. It won't be difficult to stop a badly-written filter from nixing names like Hassiri and Matilde Petit (I'll leave it to you to work out where a badly-written filter would fall down) but there will be something. In an attempt to stop the more obvious spam, Nephele and I added this little list (I claim more credit than the one edit that history gives me - I pointed out the problem Neph was having getting the thing working). Beyond the kind of filter added by that extension... what do you suggest? This wiki documents a set of games that could go in any direction. Any edit restriction you suggest is likely to be something that could come up in a later game - or indeed, a current one. The Media Wiki AbuseFilter extension seems like overkill. If a site the size of Wikipedia only has 72 active filters, many of which have only been hit a few times, it won't be worth the pain of getting it working on UESP.
Having said all that, if someone can come up with a good solution, I'd be happy. I'm not an admin any more so I won't have to fix it when it goes wrong. –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)
Consensus
No use for the edit filter as of now. –Elliot talk 02:32, 10 December 2009 (UTC)

Namespace Protection

Proposal: My suggestion is that the Template namespace be protected from anonymous editing. I mean, there is essentially no reason for an IP to be editing a template. If it is important, they can simply log in or request an edit be made on the talk page. The simplest way would be to utilize the $wgNamespaceProtection feature on the wiki, which also relies on the $wgGroupPermissions setting. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: I think that's an excellent idea. As mentioned, unlike article space, there's usually little reason for anons to edit templates. In the rare event that there's a typo or something similar that an anon might normally address, they can contact someone or post on a public talk page about the issue. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
I still think this seems like a good idea, even if anons can't edit the Docs, but if we want to protect all the major templates individually instead, as others have mentioned, it does have the advantage of letting anons edit docs and/or less-used templates, so I'm good with whichever way we want to go. I do, however, strongly advocate that we do something permanent along these lines, whether it's permanent namespace protection or permanent semi-protection for each major template. —Robin Hood (Talk • E-mail • Contribs) 23:40, 2 December 2009 (UTC)
If it is possible to only protect the templates themselves, and not the documentation pages, I think we can apply this. Changes can be requested on the talk page. I believe Wikipedia protects a greater deal of the templates as well, following this reasoning. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
I don't believe there is anything that is so define in its action. I think for this, then we would have to protect each template individually.
I fear that if keeping the subpages still unprotected (the documentation pages) this can't be achieved. We need to protect the templates one by one, as anyone should be allowed to tweak the documentations. It's a one-time job though, as not many templates are being created at the moment. --Timenn-<talk> 14:07, 2 December 2009 (UTC)
Most don't even edit the documentation pages, so I don't think that should be a deciding factor. Yeah, it may go against the concept of a wiki, but some wikis don't even allow anonymous edits, so I don't think what we are doing is exactly non-wiki like, especially since it is a defense against vandalism. –Elliot talk 16:37, 2 December 2009 (UTC)
Definitely for it. Anonymous IP’s editing the templates are more often vandals than not. --Ratwar 04:36, 2 December 2009 (UTC)
I guess IPs practically never tweak documentations anyway. Perhaps it is a liberty we need to sacrifice to make it easier to protect the templates. After all, I was asleep with the latest template attack, so I don't have the bad memories (yet) of cleaning it all up. --Timenn-<talk> 12:21, 4 December 2009 (UTC)
Yes, I agree that they don't edit them enough (either they are uninterested, or just don't know how). –Elliot talk 20:37, 4 December 2009 (UTC)

(outdent) I'm game. Anybody who needs to edit something as widely used as most of our templates can wait for a seasoned account first. –Eshetalk 00:24, 5 December 2009 (UTC)

I agree that IPs shouldn't edit Template pages, but I don't see why we should prevent them from editing Docs just because it's unlikely. From the way it was explained to me, however, the Edit Filter described in the above section could achieve the protection of Template pages without protecting the Doc pages. If we decide against the Edit Filter, I'd rather just protect the individual Template pages one-by-one. --GKTalk2me 02:10, 5 December 2009 (UTC)
There currently are 110 templates with 100+ usages. So either we protect all of those, or just simply protect the entire namespace. I hardly ever see IPs edit docs, so I really don't think that should be the determinate in this discussion. –Elliot talk 11:40, 5 December 2009 (UTC)
110 pages to protect doesn't seem like much when 5 administrators are working on protecting them. I do believe a number of them are already protected. --Timenn-<talk> 17:03, 7 December 2009 (UTC)
That might be the way to go since we really don't have quick access to the server. –Elliot talk 21:19, 7 December 2009 (UTC)

(u/d)This is something that not even Wikipedia has found necessary. I used to be in favour of it (look back through the admin board archives) but not any more.

A long, long time ago, it was decided (and no, I can't remember where the discussion took place - it'll be on some arcane talk page somewhere) that the most-used templates should be semi-protected and as a result TheRealLurlock semi-protected several templates (on 10 November 2007 to save you searching too hard). I added several more ([1] for instance) on 9 August 2009 on the basis of that policy. If you look back at the history of (for instance) the NPC Summary template, you will see no vandalism caused the protection - it was just a precaution: we wanted to stop vandals hitting our most-used templates. Later on, Nephele split several templates into a code/documentation duo rather than having everything on one page - something I followed up on other templates later. The reason for this is twofold: firstly, it improves site performance. Please consult MediaWiki documentation for full details, but take it from me that performance is better when the site software doesn't have to transclude a mass of documentation every time it uses a template. Secondly, it means the template can be protected while allowing every user to add whatever information he or she feels is necessary to a documentation page. As others have said, most of UESP's templates lack adequate documentation. Timenn proposed a standard that has been followed for newer templates, but older ones are cryptic to say the least. There is no reason why an anon shouldn't add information he or she found useful to the documentation page of a template.

I agree that the most commonly-used templates should be at least semi-protected. With some templates, I'd go further: there is no reason why Template:! and Template:!- should ever be edited. They should be fully protected. Currently, there are many cases where there is no documentation sup-page. In these cases, one should be created, Some templates (<500 uses) aren't worth bothering about as the site will deal with any conceivable backlog: the only reason the latest attack on the Template namespace worked was that most templates had been left unprotected.

There has been a recent attack on the site via templates, and some people have suggested that this implies a prior knowledge of wikis. I hate to point out that this site's sidebar has a link to Special:SpecialPages (why not rename it to "pages that offer easiest ways to vandalise the site" to be even more clear), and that Special:MostLinkedTemplates is one of the pages you get linked to from there. The reason this attack was so damaging is largely down to the views of one admin. I'm interested to see Ratwar's opinion on this matter. He had previously stated that he was opposed to semi-protecting individual templates (I still have those IRC logs): perhaps he would explain his switch to a preference for protecting an entire namespace? –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)

I am now in favor of protecting the big templates one by one, which will allow talk pages and docs to be edited. –Elliot talk 23:05, 7 December 2009 (UTC)
Consensus
Templates with 100+ uses should be permanently protected (this would obviously include any templates used on said templates). –Elliot talk 02:32, 10 December 2009 (UTC)

Rate Limits

Proposal: Another thing we could to is to create a flood control (something often seen on forums), as Ratwar brought to my attention yesterday. We could use the $wgRateLimits function in order to place a limit on anonymous and unconfirmed users (maybe like one edit every one or two minutes). We could even use $wgRateLimitLog in order to keep track of people trying to vandalize the site. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
: I'm not as big of a fan of this, as it discourages anons from correcting their own mistakes when they make them. I wouldn't object strenuously, but I'd definitely vote against if it came to that. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
This is where the edit filter could be more advantageous (more below). –Elliot talk 01:15, 1 December 2009 (UTC)
In light of further discussion, I have no objections to something with a high enough limit to make it reasonably certain it's a vandal. —Robin Hood (Talk • E-mail • Contribs) 23:40, 2 December 2009 (UTC)
I don't feel very happy about this. I've seen IP editors that were quite busy with editing in a few minutes time, but made good edits. I would rather give them the freedom they need to make their changes and learn the wiki and accept the occasional visit of a vandal. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
I forgot to say that it is not limited to 1. See for example: array( 4, 60 ) for a maximum of 4 hits in 60 seconds. We could offer up something along the lines of that. Maybe ( 5, 120) would be a tad better. –Elliot talk 17:12, 1 December 2009 (UTC)
This might be OK if the limit is set quite high, that only a very malicious user or a bot could reach it. I'm with Ratwar on this. --Timenn-<talk> 14:07, 2 December 2009 (UTC)
I like the idea. I think Robin Hood makes a good point about anon editors needing to correct their own mistakes. Really the goal here would be to set a limit that would never be encountered by regular editors. I mean, even the prolific anon editors don’t edit 349 times in the space of 39 minutes. Heck, even a limit of 100 edits per hour would have easily slowed down that attack. So I’d be for a high limit such as that. --Ratwar 04:36, 2 December 2009 (UTC)
If you wanted it high... the last vandal was making edits 6 times a minute. So a logical setup would be array( 6, 60 ) for a maximum of 6 hits in 60 seconds. That is actually pretty high. If you wanted, I guess we could make it array( 12, 120 ) for a maximum of 12 hits in 120 seconds or something along those lines. –Elliot talk 16:37, 2 December 2009 (UTC)
I think 10 edits in 3 minutes could be good enough. It's rare that you ever find an IP editing something 10 times for a good reason. And, they can just wait until the time is up if it is that important. –Elliot talk 00:05, 4 December 2009 (UTC)
Perhaps a little more tweaking? 20 edits in 6 minutes time? --Timenn-<talk> 12:21, 4 December 2009 (UTC)
That would be about three edits a minute, which is normal pace I guess. And it would have stopped that latest attack. I guess I want to have for a longer period of time to give administrators enough time to come and see what is going on. It's not a big deal, but I think anything is better than nothing. –Elliot talk 23:46, 4 December 2009 (UTC)

(outdent) I like this idea too. In fact, I'm not sure why we haven't set it up before. As long as we pick a rate that won't inhibit well-intentioned editors, this should be very beneficial. –Eshetalk 00:24, 5 December 2009 (UTC)

My problem is that sometimes I'll set up several responses or edits, proofread 'em all, preview 'em all, then save 'em all... like now... but, meh, for the betterment of the wiki, right? I'll just slow down.  ;) --GKTalk2me 02:11, 5 December 2009 (UTC)
It can be set to not affect admins, patrollers, and regular members. –Elliot talk 02:18, 5 December 2009 (UTC)
Yeah, I also work like GK does, and I can see even regular editors doing so if they're doing something that spans several pages, so I'd suggest rate limits only for non-auto-confirmed members. —Robin Hood (Talk • E-mail • Contribs) 05:12, 5 December 2009 (UTC)
That would be changed in the $wgGroupPermissions, which is rather easy. –Elliot talk 11:40, 5 December 2009 (UTC)
Ah yes, I assumed it would only apply to non autoconfirmed users, but it's good that it is being said. --Timenn-<talk> 17:03, 7 December 2009 (UTC)
Timenn has already pointed out that there have been many cases of good-faith editors making several edits within a small period of time. There are better options than simple rate limits. I edit another wiki where a user has written what is called a "Vandal Brake". This lets a set of users (probably admins / patrollers in UESP's case) add other users to a group in which they can only make one edit per minute. I believe that's configurable - if not, I dare say suggestions for improvement can be made. I've asked the user who wrote it and he has no problem with that code being used on UESP. This is a better way to punish actual vandals rather than assuming that everybody who makes edits from an IP is acting in bad faith. If UESP really doesn't want anons, it can disable them entirely. The source code is available here - all credit to Nx. (who is a member of this site, BTW) –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)
The point would be to have a high rate so only vandals hit the limit. And if an editor is making that many edits, I think it would be best to stop them (that is why we press the Show Preview issue to many editors). –Elliot talk 23:05, 7 December 2009 (UTC)
There's something I forgot to mention here. By setting a rate limit for everybody, there's an implicit assumption of bad faith - and besides, any sufficiently-determined vandal will get around it anyway. Using the Vandal Brake means you start off assuming good faith for everybody and only people who deserve it are put in the vandal bin. –rpeh•T•C•E• 23:32, 7 December 2009 (UTC)
\=> You will always have the implicit assumption of bad faith. Why are pages protected in the first place? Why are financial records protect? Because you assume that someone might possibly vandalize the page. I think what we would have to worry about is explicit assumptions of bad faith, which are rarely made known. But with the 20 edits in 6 minutes, there is no reason any IP should be doing that much editing. If for some reason they are doing a quick change to many pages, then they can just wait an extra 20 seconds for the period to end, or they can just make one edit every 19 seconds (which is hardly a limitation of the good-faithed editor). I am in favor of implementing both. Since when there are huge attacks, an admin isn't always around. But we would need policy for the vandal break, obviously. Any ideas? –Elliot talk 12:02, 8 December 2009 (UTC)
That doesn't fit in with existing policy: "Unregistered users are to be treated with the same respect as any other user on the site. There have been several very helpful and productive users who choose not to register, and it is entirely their right to make that choice." (UESPWiki:Etiquette#General).
The vandal brake could be given to patrollers or a new group could be set up (there's no reason to restrict options to current groups if it is felt greater granularity is required). It's not as restrictive as a block but still helps minimise disruption to the site, which is the goal here. –rpeh•T•C•E• 12:22, 8 December 2009 (UTC)
Yes, that's all well and good, but it is essentially untrue. They aren't treated the same. They can't edit semi-protected pages. So while in theory they would be on the same level, in practice they are not. It's nothing mind-numbingly terrible. Some things must be taken preemptively and some things must be taken "reactively", so to speak. We can't take AGF as a no-flexibility policy. You can preach the spirit of the wiki is altered by doing so, but when the integrity of the wiki is targeted on a regular basis by such large attacks, I feel that is what is most important at the current time. –Elliot talk 12:32, 8 December 2009 (UTC)
That's what I don't understand about this whole debate. The wiki is not regularly attacked. It happens once in a blue moon. For some reason there has been a massive overreaction about one or two recent incidents. Much more serious vandalism came from named accounts (Benny220, Xbox, Dienerandamovie, Posiden5665 etc etc). Targeting IP editors is plain wrong. –rpeh•T•C•E• 12:42, 8 December 2009 (UTC)
Hm. You're right about that. Local ministry of truth made me "forget" about those individuals. Besides that, the wiki has been attacked by other means as well, so these rate limits would only stop a marginally small amount of vandalism. I prefer the VandalBrake that rpeh mentioned over the Rate Limit. Obviously its rights should be given to Patrollers as well to let it have effect, as administrators can simply block. --Timenn-<talk> 16:56, 8 December 2009 (UTC)
Okay, since I can already see the wheels turning, I won't fight this. We will need to label it as only vandalism though fr the Vandal brake. –Elliot talk 22:24, 8 December 2009 (UTC)
I can't support using VandalBrake. As Timenn said, if we just give it to admins, it will have no effect, and I personally cannot agree with giving it to patrollers. They were not nominated and voted for to be given that type of power. As I've said before, I think a rate limit high enough deter Vandals but not real editors is our best solution, and I think such a solution can be found.--Ratwar 22:56, 8 December 2009 (UTC)
I don't know if I like the implication that patrollers are unable to handle a simple vandal brake. It isn't blocking. And last time I checked, a good majority of the time I have to run and go drag an admin to the wiki when a vandal hits (not all the time, but enough to warrant a mention). Giving it to patrollers will allow a quick action response. If they continue to vandalize after that and a warning, then they can be blocked. Essentially, as with other things, I am for any type of implementation of the subject. But I think both would be good, too. –Elliot talk 23:13, 8 December 2009 (UTC)
After thinking about it a bit more, I do think you have a point. That being said, I still think that we need rate limits as well.--Ratwar 23:34, 8 December 2009 (UTC)
Ratwar, you weren't elected with CheckUser rights. You had those added later. Adding rights to an existing user group is therefore not a reason to vote against this change. –rpeh•T•C•E• 00:17, 9 December 2009 (UTC)
I have no major issues applying the same rights to regular users as well as anonymous ones, since a "dedicated" troll will undoubtedly try to establish several sockpuppet accounts and then just vandalize through those if IP edits are a problem. —Robin Hood (Talk • E-mail • Contribs) 00:32, 9 December 2009 (UTC)
Consensus
Set $wgRateLimits to 20 edits over 6 minutes and implement the Vandal Brake for both administrators and patrollers. –Elliot talk 11:53, 11 December 2009 (UTC)

Rollback

Proposal: Another possible thing that could be implemented is giving patrollers the rollback right. Now don't freak out and say I am power hungry or something along those lines. I am fine with either result. But if patrollers are going to be fighting vandalism, having the edge over vandals is extremely beneficial. With what patrollers currently have, they can only revert at the same pace people edit. If they had rollback, they can get the upper hand on vandals (since it marks the edit as patrolled as well, so cleanup is pretty easy). But this really isn't my main proposal. –Elliot talk 19:07, 30 November 2009 (UTC)

Discussion
There is a feature used on Wikipedia called Mass Rollback. It takes the rollback feature it makes it a tad more powerful (the code can be seen here). It takes every edit by a user that can be rollbacked and reverts it with one click of a button, which is extremely beneficial for massive vandalism efforts (or possibly when a user's edits needed to be reverted based on community consensus). Obviously this should only be used by administrators, even if patrollers are given the right. Yesterday, we had an attack of over 100 edits that each had to be rollbacked one by one. This could simplify this in the future. Although, it opens a window for ever edit rollbacked, so it has to be used with extreme caution. –Elliot talk 19:07, 30 November 2009 (UTC)
This would be useful to patrollers, and not really more of a right than we already have, just a greater convenience. I can see the advantage of Mass Rollback, but I'd suggest its use be strictly limited to administrators. While there are times that an admin is unavailable and a patroller using this might be useful, I think I'd rather see this ability only in the hands of those who've been around for a really long time and have gone through a more-rigorous approval process. —Robin Hood (Talk • E-mail • Contribs) 01:01, 1 December 2009 (UTC)
Yes, as I mentioned, the Mass would only be used by administrators. –Elliot talk 01:15, 1 December 2009 (UTC)
I see the concerns some people have mentioned, but if we give patrollers "regular" rollback rights, I would suggest that we also make it policy that it should only be used on cases of unambiguous vandalism...not cases where user X is being really annoying and disagrees with us or is posting questionable content. I'm fine if we don't have that right as well...it's really only saving a few small steps. —Robin Hood (Talk • E-mail • Contribs) 23:40, 2 December 2009 (UTC)
Mixed feelings here. On one hand, I can't see how the rollback is any different from a person who is fast with buttons and tabs, and quickly revert an edit with the traditional methods. On the other hand, I feel this would invite laziness in editors (I've seen this on other wiki's) as they no longer have to provide edit summaries. Considering how the rollback option is needed so rarely, I think this should stay reserved for administrators. They can block the vandal as well, and can use the rollback option to clean up. Giving this option to patrollers would only speed up the edit wars. --Timenn-<talk> 14:51, 1 December 2009 (UTC)
Basically, the rollback summary says: This is vandalism. But it does so without obviously stating it. This means that rollback should only be used on vandalism. In the past there were admins who used it at will, but they were told to stop. No true harm, not foul. So, I don't think the edit summary excuse has any validity within it. And the patrollers could use it were it is not necessarily an edit war. Vandalism takes many forms. –Elliot talk 17:12, 1 December 2009 (UTC)
I still fear for it being used in (any form of) edit wars. Rollback shouldn't be used to be quicker than the vandal in reverting, but be an easy tool to clean everything up once the vandal has been blocked. --Timenn-<talk> 14:07, 2 December 2009 (UTC)
Definitely in favor of implementing this for Administrators. --Ratwar 04:36, 2 December 2009 (UTC)
Okay, then I think we should give mass rollback to the admins. –Elliot talk 16:37, 2 December 2009 (UTC)
What kind of tool is it, actually? Is it a refined function, or a crude script? Remember that someone can always select a user's contributions, and middle click (opens new tab) in the list like hell. A crude script may have some unwanted flaws, but if the tool is refined (tested) then it may do. --Timenn-<talk> 12:21, 4 December 2009 (UTC)
It's a simple javascript tool. I've used it on Wikipedia a few times and had no problems. The only fallback is the new tabs opening, but I am sure most computers could handle it. –Elliot talk 20:37, 4 December 2009 (UTC)

(outdent) Personally, I say we either give rollback to patrollers or we give mass rollback to admins. However, I'm not really crazy about either. Yes, rollback can be convenient, but the only reason it would be actually necessary to have one of these options in place is to revert massive vandalism, such as a bot attack. I'd rather use the rate limit to control this and leave the rollback rights as they are, but I'm not vehemently opposed to this as long as we use one and not both. –Eshetalk 00:24, 5 December 2009 (UTC)

I'm not sure I agree with giving Patrollers rollback, but I'm not dead-set on it either way. Mass-rollback to Admins, however... I don't see the harm in it. I think most of us wouldn't use it, and Admins are/should be trusted to use it only in appropriate circumstances. --GKTalk2me 02:11, 5 December 2009 (UTC)
I think the common agreement would be to give the admins mass rollback, which I think will benefit the site in case of future attacks. –Elliot talk 11:40, 5 December 2009 (UTC)
It was suggested to me by another sysop that I overused rollback when I had the ability. I disagree, but if what I considered to be uncontroversial rollbacks turned out to be controversial, it suggests that the ability should be more restricted rather than having it extended. There's no big deal in entering "vandalism" as an edit summary in cases of clear vandalism. Personally, I took my usage of the function from Wikipedia, where rollback is often used for cases other than vandalism. If people believe the way in which I used it was wrong then I apologise. I believe I was acting in good faith but I see that it could be seen otherwise. In general, Rollback should be restricted rather than provided more widely. This site gets far less vandalism that others of similar size. It simply doesn't need the more extreme measures suggested here. UESP has survived far worse instances of vandalism and it's difficult to see any need for increased tools to prevent the current low levels of vandalism from occurring. –rpeh•T•C•E• 22:39, 7 December 2009 (UTC)
"Wikipedia, where rollback is often used for cases other than vandalism" Yes, and then they have if removed. I think admins should be trusted enough to use the mass rollback. And there is nothing really special about it; it just makes the job a little easier on them. –Elliot talk 23:05, 7 December 2009 (UTC)
Consensus
No rollback for patrollers; mass rollback for administrators. To use mass rollback, place importScript('User:Elliot/mass rollback.js'); in your monobook.js. –Elliot talk 02:32, 10 December 2009 (UTC)
Retrieved from "https://en.uesp.net/w/index.php?title=UESPWiki:Administrator_Noticeboard/Archives/Dropping_the_Ball_on_Vandalism&oldid=2223310"