Wikipedia talk:Semi-protection policy/Archive 2
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Technical comment
I was asked to comment on this subject on my talk page regarding the feasibility of a technical implemtation of it. First of all, the expensiveness of figuring out the edit count of a user is currently too large to be able to make that check on every edit (and it won't be any less expensive if the user has fewer edits). Secondly, although our current page restriction scheme could be hacked to support it we'd really need a proper ACL system for this. —Ævar Arnfjörð Bjarmason 08:16, 3 December 2005 (UTC)
- Hah, I knew it...then we're back to the demanding only registered editors edit and that didn't fly.--MONGO 08:21, 3 December 2005 (UTC)
- Note that the comment only applies to the current code and DB schema, if this was deemed important enough both could be changed to accommodate for it. —Ævar Arnfjörð Bjarmason 08:34, 3 December 2005 (UTC)
- Oh, I wasn't mocking you, just figured that something involving money would impede the progress of this. I for one, am much appreciative that you've chimed in here...thanks! In the event that this is "deemed important enough", how complex a matter does this become and what kind of potential timeframe are we looking at?--MONGO 09:41, 3 December 2005 (UTC)
- Note that expensive doesn't mean costs a lot of money in this context but rather refers to the execution time of the code required to implement the proposed functionality. —Ævar Arnfjörð Bjarmason 12:13, 3 December 2005 (UTC)
- Ævar, we are still in the middle of figuring out exactly how semi-protection should be implemented, but assuming we come up with a reasonable working proposal and get somewhere in the range of 100 signatures supporting it, what chance do you give this proposal getting through? Would the support of Mr. Wales in the matter make any headway towards getting this implemented by developers? --kizzle 22:36, 3 December 2005 (UTC)
- Might have some effect but probably not a lot, Jimbo announced in june that we'd make an API for the KDE project and AFAIK not a single line of code has been written to implement that. Talking from experiance, if you want something done with MediaWiki (or any other voulenteer project for that matter, including Wikipedia) you basically have to do it yourself or pay someone to. —Ævar Arnfjörð Bjarmason 02:06, 6 December 2005 (UTC)
- True, but we could recycle a lot of code from the page move function and using it in the semi-protection functions, so it isn't that radical of a change... Titoxd(?!? - did you read this?) 02:18, 6 December 2005 (UTC)
- Might have some effect but probably not a lot, Jimbo announced in june that we'd make an API for the KDE project and AFAIK not a single line of code has been written to implement that. Talking from experiance, if you want something done with MediaWiki (or any other voulenteer project for that matter, including Wikipedia) you basically have to do it yourself or pay someone to. —Ævar Arnfjörð Bjarmason 02:06, 6 December 2005 (UTC)
- Ævar, we are still in the middle of figuring out exactly how semi-protection should be implemented, but assuming we come up with a reasonable working proposal and get somewhere in the range of 100 signatures supporting it, what chance do you give this proposal getting through? Would the support of Mr. Wales in the matter make any headway towards getting this implemented by developers? --kizzle 22:36, 3 December 2005 (UTC)
- Note that expensive doesn't mean costs a lot of money in this context but rather refers to the execution time of the code required to implement the proposed functionality. —Ævar Arnfjörð Bjarmason 12:13, 3 December 2005 (UTC)
- Sigh. --Woohookitty(cat scratches) 08:51, 3 December 2005 (UTC)
- Oh, I wasn't mocking you, just figured that something involving money would impede the progress of this. I for one, am much appreciative that you've chimed in here...thanks! In the event that this is "deemed important enough", how complex a matter does this become and what kind of potential timeframe are we looking at?--MONGO 09:41, 3 December 2005 (UTC)
- Note that the comment only applies to the current code and DB schema, if this was deemed important enough both could be changed to accommodate for it. —Ævar Arnfjörð Bjarmason 08:34, 3 December 2005 (UTC)
- Don’t we already do something like this for page moves? Would it be possible to make the check only when trying to edit semi-protected pages? Susvolans ⇔ 12:00, 3 December 2005 (UTC)
On appearances and aging vs. editting
I am wondering what the people hear want the user experience to be like when visiting such a page. Either we explain that it is semi-protected or we don't. Previous comments seem to favor offering a clear explanation of the situation, but doesn't that just tell the vandal that he has to go attack 10, 20, 50 other pages first and then he will get rewarded by being able to attack GWB? Okay, so maybe we would catch and block most such vandals before he got to 20 or 50 edits, but if semi-protection amounts to "You can't vandalize here, go vandalize somewhere else", I'm not sure the encyclopedia is really any better for it. Of course, if one doesn't explain what is going on then you end up with a page that looks perpetually protected from the point of view of random visitor (or worse, random visiting journalist). Dragons flight 18:10, 3 December 2005 (UTC)
- If a user is blocked from editing something a clearly defined reason must be given. Personally I think partially protected pages should scale on account creation date as well as number of edits, so if you have some newly-created vandal they'd have to wait a month and survive through 50 vandalism edits before they could edit a frequently-vandalized page. --Cyde Weys [u] [t] [c] 18:28, 3 December 2005 (UTC)
Also, it is unclear to me whether you want this to apply to anons and registered users alike. If it applies to all, then the AOL superproxy system would make it often ineffective against this large class of (often irritating) anons who share IPs and hence would often already have a significant edit history. Dragons flight 18:10, 3 December 2005 (UTC)
- Anons shouldn't be allowed to edit partially protected pages since there is no way to keep track of their number of edits. --Cyde Weys [u] [t] [c] 18:28, 3 December 2005 (UTC)
Might I suggest that if one is going to be asking for software changes, it might be easier to create a semi-protection policy based on account age. In other words have some semi-protected pages that can only be edited by registered accounts, or accounts that have been registered for at least X days (for some variable setting of X). Most wikipedians seem to support allowing anons to edit, but I don't think the community would be too upset if they were prevented from editting a small number of pages that are heavily vandalized by anons. Similarly, we already have code that forces people to wait several days after registration before they "earn" the right to move pages. Also, even if we have a message explaining that one's account must be X days old before editting a given page, that doesn't really encourage a vandal to go attack something else (as the current proposal might). Dragons flight 18:10, 3 December 2005 (UTC)
- This also sounds good to me. I think is a lot more doable (in terms of coding) than keeping track of number of edits. Frankly, I'd just be happy if there was a "Protection against Anonymous peoples" that we could place on a page, as that would solve the vast majority of vandalism. --Cyde Weys [u] [t] [c] 18:28, 3 December 2005 (UTC)
Vandalism Statistics
I like this proposal, but it occurs to me to wonder if anyone has tried to determine what the necessary threshold for semi-protection should be. i.e. of vandalism done to the GWB page, how many of those vandals had already performed edits on other pages? How many had 10 edits under their belt? How many had 20? etc.
It also doesn't seem to take into account the fact that frequent vandals will have lots of edits to their name anyway; they will just have been reverted by other users. I don't know if there's a good way to take that into account when totting up someone's edit history, and distinguishing a responsible user from an active vandal. Tim Pierce 18:42, 3 December 2005 (UTC)
- The main problems are from anonymous users, which would be blocked totally under this proposed system since their edits can't be tracked. If vandals are actually registered users then they become a lot easier to deal with. --Cyde Weys [u] [t] [c] 18:47, 3 December 2005 (UTC)
- Frequent vandals who have racked up an edit count with a registered account are easily traceable and blockable. If an account has 100 edits and all of them are vandalism, it should be a no-brainer to an admin to indefinetely block, thus we shouldn't see too much of a problem with this concerning semi-protection. --kizzle 22:25, 3 December 2005 (UTC)
Semi-protection proposal v.01
I have been immensely impressed by the discussion above; I'd just like to take a second and thank everyone for their wonderful ideas in fleshing out this sorely-needed concept. I don't think I've ever been part of a more productive discussion on Wikipedia. I am going to summarize what seems to have been concluded so far as to what semi-protection should resemble, keep in mind I might include certain ideas that you still disagree with, by all means share your thoughts. I just want to summarize the progress that has been made so far and re-focus the debate. You can place a support vote if you agree with the way a certain passage is framed, or discuss why you believe it should be a different way. Also, don't be afraid to put your signature under the disagree part, even if its a little minor tweaking, as this isn't mean to be a vote whether the certain aspects "passes", but to polish the concepts down. --kizzle 23:16, 3 December 2005 (UTC)
Levels
From a software standpoint, semi-protection will have built in variability to address different wiki implementations. It has been brought up before that different wiki implementations may want different thresholds to combat vandalism. However, policy will dictate its usage by admins in the following levels for the English version of Wikipedia:
- Level 0 - Open
- Level 1 - No moves allowed
- Level 2 (minor vandalism) - 25 minimum edits / 5 day minimum account life
- Level 3 (extreme vandalism) - 100 minimum edits / 30 day minimum account life
- Level 4 - Protected
The minimum account life is meant to address the possibility for vandalbots to rack up edits in an incredibly short time, while the minimum edit count allows us to view the history of a user and see if they have made any significant contributions rather than exclusively committing vandalism. Both of these restrictions are in effect, thus each person must satisfy both conditions. Also, Levels 2 and 3 will require the person to be logged in, as both the minimum edit and account life thresholds become meaningless in the face of the mass of AOL IPs being used by various people. Alternatively, Level 1 can also require just simple registration as a first minor defense against vandalism.
Support:
- --kizzle 23:16, 3 December 2005 (UTC)
- --Can't sleep, clown will eat me 23:25, 3 December 2005 (UTC)
- --Sandpiper 00:31, 4 December 2005 (UTC).
- Please pick only one (most likely oppose.) -Mysekurity 01:21, 4 December 2005 (UTC)
- This isn't a vote. He can choose to sit on the fence if he likes. The weakness of voting is that it confines one to the options and prevents one thinking in shades of grey. -Splashtalk 03:10, 4 December 2005 (UTC)
- FYI, it says "[d]isagree even a little bit"; so fence sitting is allowed, but discouraged. Sorry if I didn't make my reasons more clear. -Mysekurity (have you seen this?) 06:05, 4 December 2005 (UTC)
- if I have to pick one, then I support, but with the reservations below. Sandpiper 09:05, 4 December 2005 (UTC)
- FYI, it says "[d]isagree even a little bit"; so fence sitting is allowed, but discouraged. Sorry if I didn't make my reasons more clear. -Mysekurity (have you seen this?) 06:05, 4 December 2005 (UTC)
- This isn't a vote. He can choose to sit on the fence if he likes. The weakness of voting is that it confines one to the options and prevents one thinking in shades of grey. -Splashtalk 03:10, 4 December 2005 (UTC)
- Please pick only one (most likely oppose.) -Mysekurity 01:21, 4 December 2005 (UTC)
*-- — Rickyrab | Talk 01:28, 4 December 2005 (UTC). But I DO like User:Dragons flight's idea below. I have additional reservations, see below — Rickyrab | Talk 17:01, 4 December 2005 (UTC)
- --BD2412 T 02:27, 4 December 2005 (UTC) (I think the numbers could be played with, but frankly I think it would need to be road-tested to determine the best thresholds).
- Titoxd(?!? - did you read this?) 03:18, 5 December 2005 (UTC) (but I now think the account-age/account-percentage method is much, much easier to implement)
Disagree even a little bit (PLEASE state why):
- How about a 1.5 that requires a logged in user but no other limits? Dragons flight 00:58, 4 December 2005 (UTC)
- logical, but would inevitably lead to creation of vast numbers of one time only acounts Sandpiper
- We already have 600,000+ registered accounts, of which only 140,000 have ever been used and only 40,000 have made more than 10 edits. In other words, we already have vast numbers of one time (and no time) use accounts. Dragons flight 01:23, 4 December 2005 (UTC)
- That doesn't make it right... we need to kill a lot of those accounts, but we shouldn't encourage more. -Mysekurity 01:35, 4 December 2005 (UTC)
- We already have 600,000+ registered accounts, of which only 140,000 have ever been used and only 40,000 have made more than 10 edits. In other words, we already have vast numbers of one time (and no time) use accounts. Dragons flight 01:23, 4 December 2005 (UTC)
- Plus, it's anti-wiki. See Redwolf24's essay on the topic, which I agre whole-heartedly with. Mysekurity 01:21, 4 December 2005 (UTC)
- How is having the option to temporarily exclude anons anti-wiki? It would still be weaker than any of the other proposals being made here. Dragons flight 01:23, 4 December 2005 (UTC)
- The question is: would it be temorary? Let me guess; the first thing you did here was register? No. We all were annonymous at some point (with the exception of maybe Jimbo and the founders), and there's no reason to exclude anons from editing, while allowing new registered users to edit. It just doesn't make sense. The vandalism from both types of accounts is similar. -Mysekurity 01:35, 4 December 2005 (UTC)
- Actually yes, I did register before I editted anything, but that's just me. Imagine someone posts: "Go kill Wikipedia's entry about lollipops on a message board." Then a bunch of anons surf over. If we can put up a barrier saying that editors of lollipop must be registered that will deter some of them. Besides, are you really arguing that more options are bad? I'd prefer the least level of protection that addresses the issue going towards none most of the time. Ideally it would be like the block function with some default options and the ability to customize it to any other state. Dragons flight 01:46, 4 December 2005 (UTC)
- See also: {{high-traffic}}. Should we semi- all pages linked from high traffic sites? No. We should watchlist them, at least temporarily, as a way of encouraging new users to our site. -Mysekurity (have you seen this?) 02:25, 4 December 2005 (UTC)
- Actually yes, I did register before I editted anything, but that's just me. Imagine someone posts: "Go kill Wikipedia's entry about lollipops on a message board." Then a bunch of anons surf over. If we can put up a barrier saying that editors of lollipop must be registered that will deter some of them. Besides, are you really arguing that more options are bad? I'd prefer the least level of protection that addresses the issue going towards none most of the time. Ideally it would be like the block function with some default options and the ability to customize it to any other state. Dragons flight 01:46, 4 December 2005 (UTC)
- The question is: would it be temorary? Let me guess; the first thing you did here was register? No. We all were annonymous at some point (with the exception of maybe Jimbo and the founders), and there's no reason to exclude anons from editing, while allowing new registered users to edit. It just doesn't make sense. The vandalism from both types of accounts is similar. -Mysekurity 01:35, 4 December 2005 (UTC)
- How is having the option to temporarily exclude anons anti-wiki? It would still be weaker than any of the other proposals being made here. Dragons flight 01:23, 4 December 2005 (UTC)
- logical, but would inevitably lead to creation of vast numbers of one time only acounts Sandpiper
- --Sandpiper 01:12, 4 December 2005 (UTC). Don't I just love to sit on the fence? I support it strongly as an alternative to full protection. Less strongly if it, say, doubles the number of protected pages. not at all if it results in many more pages having more then the 25 edit level of protection.
- Please pick only one (most likely oppose.) -Mysekurity 01:21, 4 December 2005 (UTC)
- We should have only one level of intermediate protection, to avoid unnecessary stratification of editors and articles. Either we trust people to edit, or we do not. And we do, until Jimbo or the Board of the Foundation indicates otherwise. -Splashtalk 03:10, 4 December 2005 (UTC)
- I agree with Splash (wow. again). I think one level would help put the kabosh on protection creep, which I know Splash fears. Like I said, this isn't in stone. We can always alter it later if it is not working out. I say...20 edits would work. I just don't see the strong argument for multiple levels. I mean. If this is going to be limited (30-40 articles at most), why divide it in 2? I mean, I think it's only going to be used for severe cases. --Woohookitty(cat scratches) 04:03, 4 December 2005 (UTC)
- I think that having lower account life numbers would achieve the aims. Even something like 1-2 days account life would be a pretty big bar against vandals (usually won't have the commitment to create an account, wait a couple of days before vandalising -- esp. if the account gets killed by an admin after one/two vandal edits). novacatz 06:16, 4 December 2005 (UTC)
- Thats an interesting point: is it intended as a means of seek and destroy of people only making bad-faith edits before they get to/as soon as they get to the magic threshold? And how would someone decide how to nuke a new ID? Sandpiper 09:16, 4 December 2005 (UTC)
- That's actually something I hadn't thought of either. Could people be blocked indefinitely for doing something like this, i.e. try to get around the threshold rule by making minor or bad faith edits in as many places as possible or do one edit on the first day and then wait a few days until they are cleared? It's important since you know at least one person will try it. I don't think it'll happen alot since I agree...most vandals are fly by night...they come...vandalize...and leave. But we'll have a few who will try to get around the semi-protection one way or another. --Woohookitty(cat scratches) 09:25, 4 December 2005 (UTC)
- — Rickyrab | Talk 17:01, 4 December 2005 (UTC) - Not only do I support Dragonsflight's idea, I also think that there should be a "no blanking" and a "no linkspam" category to specifically prevent blanking or linkspamming. Those are two of the most common forms of Wikivandalism.
- I support the idea but I think the restrictions should be minimal and the process should be as simple as possible: start with exactly one level of semi-protection. I would prefer to see it start with even a 1-day account history, assuming that most vandalism happens spur-of-the-moment and on impulse. The numbers can always be adjusted upwards, or new levels of protection added, if it does not put a brake on vandalism. Tim Pierce 02:45, 5 December 2005 (UTC)
- The only part that strikes me as excessively creep-ish is the definition of multiple levels. I'd say just strike out "Level 3". I suspect (or at least hope!) that Level 2 would dramatically reduce the amount of drive-by vandalism. If it proves to not be as effective as we'd hoped, then we can either bump up the numbers or add a new level. —HorsePunchKid→龜 2005-12-06 04:28:32Z
Process for Initiating Semi-Protection
It has been asked why semi-protection, a less restrictive practice than normal protection, requires more scrutiny than protection itself, which can be executed by any admin. It should be fairly obvious that leaving pages in a semi-protected state has clear observable benefits (no vandalism) coupled with unobservable consequences (restricting legitimate anon editors). Because of this tendency, we must be extra careful in what Splash calls "protection creep", or the tendency for this state of semi-protection to grow exponentially where it almost becomes standard practice. Accordingly, semi-protection should be affixed with a renewable time-limit, and the longer a page is semi-protected, the more admins required to validate such a request. If we make it so that leaving pages semi-protected requires an increasing amount of admin concensus along with forcing semi-protection to be renewed, it should help stem such "protection creep". As it stands, the following is what seems to work so far:
- Semi-protection for 1 week: Can be initiated by any admin
- Semi-protection for 1 month: Initiated and seconded by another admin
- Semi-protection for 3 months: Supported by at least (5) admins
Note: Semi-protection can be applied consecutively, such as an admin extending an initial week-long semi-protection for another week. However, after 2 consecutive semi-protections, the third attempt must gain a concensus from 5 admins as well.
It has also been asked why semi-protection has a proposed time-limit as well when normal protection has no such limit. Keep in mind, the only reason why a page needs to be semi-protected is in cases of extreme or heavy vandalism. POV disputes and edit wars should still be solved by protection until the talk page can restore some order. If we semi-protected in certain cases, it would allow certain users to edit while others couldn't simply due to their edit history, which given the lack of vandalism by these new users is fundamentally unfair to them. In these cases, POV disputes can last anywhere from a day to several weeks. In the case of vandalism, we will have no specific evidence that will warrant un-semi-protecting a page. This is the central reason for affixing time limits to semi-protection.
Support:
- --kizzle 23:16, 3 December 2005 (UTC)
- --Can't sleep, clown will eat me 23:26, 3 December 2005 (UTC)
--Mysekurity 01:23, 4 December 2005 (UTC)(changed to oppose 06:07, 4 December 2005 (UTC))
Disagree even a little bit (PLEASE state why):
- --Sandpiper 00:42, 4 December 2005 (UTC). I do think it should have automatic expiry time limits. But further to comments earlier, i think it should be easier to remove than to impose. I think that any single admin should be able to remove it. Now arguably, any single admin should also be able to reinstate it within the original term for which it was imposed. This would allow people to test remove it.
- Auto-removal will not work, simply because it's better to have a human make judgement calls. I was thinking the same thing you were, but there's a reason we don't have regular protected pages automatically unlocked like this. -Mysekurity 01:23, 4 December 2005 (UTC)
- -- — Rickyrab | Talk 01:28, 4 December 2005 (UTC) - agrees with Sandpiper
- --BD2412 T 02:31, 4 December 2005 (UTC) I don't see why the process should be any different than the current criteria for protecting/unprotecting pages.
- Voice of AllT|@|ESP 02:33, 4 December 2005 (UTC). Lets just cut through the new red tape and keep it like regular protection.
- Hard time limits don't allow for fuzziness where it may be needed. The hard time limits offered here don't cover anything like the fine-ness we would need. They offer no means of reversing a semi-protection early. Admins don't work in committees because that would be the formulation of a cabal that only admins can work in. -Splashtalk 03:10, 4 December 2005 (UTC)
- For once I agree with Splash. :) As someone who works on RfP regularly, I am really iffy on time limits. We just need as much wiggle room as possible. I still say that we try this out for a month or so first before we try ANY time limits. --Woohookitty(cat scratches) 03:55, 4 December 2005 (UTC)
- In my view, Semi-protection should be used as something as a brake against specific 'runs' of vandalism (e.g. GW Bush says something controversial and then every vandal and their dog appears to vandalise wiki). As such, I think that SemiP should have flexible (non-fixed) durations. I think that something like (1hr, 1days) would be a more appropriate level. At most something like 3 days if there is really obvious sustained vandalism. AT the moment, vandal are annoyingly common because it is JUST SO EASY to mess up wikipedia. I think that with some apporpriate levels, vandals will find it isn't so easy to cause trouble and they will just go away - so i don't think that long term measures are needed. novacatz 04:46, 4 December 2005 (UTC)
- --Mysekurity (have you seen this?) 06:07, 4 December 2005 (UTC). I'm in agreement with Splash that hard time limits are bad, but should this be a general guideline? Sounds like we should have something along these lines in place
- Titoxd(?!? - did you read this?) 03:20, 5 December 2005 (UTC). WP:PP works well in that aspect. Titoxd(?!? - did you read this?) 03:20, 5 December 2005 (UTC)
- Guidelines in this field are good, but these limitations need to be flexible and not set in stone. Hall Monitor 19:42, 5 December 2005 (UTC)
- Generally acceptable in spirit, in that I think any time a page is semi-protected, an end date should be indicated (though not necessarily on the page itself); however, the comments here have convinced me that the suggested duration categories are not a good thing. —HorsePunchKid→龜 2005-12-06 04:25:25Z
Effect on Visible Content
The page will simply have a notice at the top that says this page is a frequent target for vandalism, along with a internal link to the semi-protection policy page. It should also contain one line that directs new users somewhere else where they can help make Wikipedia a better place, possibly the random article button or the community portal to-do list. After validating whether or not it is technically feasible from a software standpoint, it might be beneficial to still keep the "edit" button active rather than "view source" in order to provide a more detailed response if a new legitimate user clicks on "edit", in order to maximize the probability that the user will not be dismayed by the inability to edit the semi-protected page. This is the implementation that can allow for the previous suggestion of listing all the semi-protected pages so that one can see beforehand what pages are frequent targets so that they don't happen to choose yet another semi-protected page.
In addition, it is important we do not mention how long the page is semi-protected for on the notice, as it will encourage vandals to wait until the semi-protection is over. It will still be determinable by going to the Wikipedia;Requests_for_semi-protection page, which shouldn't directly be linked to the Wikipedia:Semi-protection page, but if the page isn't directly linked, the vandal must already be pretty familliar with Wikipedia to figure out when the time limit will expire.
Support:
- --kizzle 23:16, 3 December 2005 (UTC)
- --Can't sleep, clown will eat me 23:26, 3 December 2005 (UTC)
- -- — Rickyrab | Talk 01:28, 4 December 2005 (UTC)
- --BD2412 T 02:38, 4 December 2005 (UTC) (although not with the "random" idea, but since that's just a possibility, I'll consider it obiter dicta)
- --Titoxd(?!? - did you read this?) 03:22, 5 December 2005 (UTC). Same as Voice of All(MTG), but I'll put it on this column instead. I just don't like Special:Random to be used.
Disagree even a little bit (PLEASE state why):
- --Sandpiper 00:47, 4 December 2005 (UTC). If I had turned up and wanted to add something to george Bush, I doubt I would be impressed by being offered a random article to look at. Better take people to something telling them about wiki and what they can do. Yes, certainly it must explain that the page has been protected and why.
- --Mysekurity 01:27, 4 December 2005 (UTC). Sending them to a random article is not a good idea. Sending them to a page of stuff for them to do, look for other articles that interest them (breakdown hierarchy by categories/the way we do it on the main page) doesn't seem like a bad idea. Random articles will only provide to give them another place to vandalize. Further, if a new user sees "view source" instead of "edit" on the top, they will unlikely be deterred. Nobody tries to edit the main page when they first see it. Only if they are expecting to be able to edit will they get the message. I don't think this is the way to go about doing this, we should encourage expansion of our smaller/non-existant articles, or review of other other, watched, articles before continuing.
- --Voice of AllT|@|ESP 01:21, 4 December 2005 (UTC). Perhaps a link to community portal-open tasks would be nice :-). Moved vote here since I absolutely DO NOT want "random page".
- We shouldn't be trying to obscure out editing practises by operating with smoke and mirrors. This is not our wiki. Don't slap messages on articles that amount to saying "this article is usually rubbish — oh, and we don't think that you can improve it for us, we have better people". -Splashtalk 03:10, 4 December 2005 (UTC)
- The random page idea is a really bad idea. I would rather see a notice like the protection notice we already have with something added that says something like "If you are new to Wikipedia, click here to see how to edit pages" or something like that. I also wouldn't mind a reason in there as to why the page is semi-protected or a link to a reason. Something informative, but that doesn't sound like we're stopping these people because we think that they are bad or detrimental to Wikipedia. --Woohookitty(cat scratches) 03:58, 4 December 2005 (UTC)
- Generally the right idea, but I agree with others here that the "go help somewhere else" link is not constructive. I'm also not sure I see much value in the extra level of obfuscation afforded by not linking to the "Request for…" page from the main WP:Semi-protection page. At the point where you have to click on the Semi-prot link and read it far enough to understand that the time limit is on the Requests page, you've surely defeated most of the drive-by vandals. —HorsePunchKid→龜 2005-12-06 04:19:51Z
KIS(S)
Semi-protection of a page prevents Semi-protection will only be applied if the page in question is facing a serious vandalism problem. It is not an appropriate solution to editorial disputes of any kind since it may restrict some editors and not others. Administrators will thus apply semiprotection in the same manner as current protection against vandalism is applied — either on their own initiative or following an alert on an article's talk page, WP:RFPP, WP:AN/I or some other relevant page. Requests to lift semi-protection should generally be unnecessary in the same way that unprotection against simple vandalism at present is generally swiftly seen to by either the protecting admin or another. Generally, a simple note to the talk page or WP:AN/I should be sufficient, but WP:RFPP can be used if necessary. This is just for clarification in the discussion here; we do not presently have hard-and-fast rules about how to seek ordinary unprotection once vandalism has passed in the case of a forgetful admin. Articles that are semi-protected will be indicated with {{sprotected}} and listed at WP:PP in the same way as protections are at present. |
We can talk about the value of N and/or X, but this is clearly the simplest way to have semiprotection operate. The v.01 proposal fails owing to being laden down with too many instructions, each of which is something to go wrong and something to object to. Suggested template (note the links):
-Splashtalk 05:25, 4 December 2005 (UTC)
- I wholeheartedly endorse this. I can see kizzle's ideas working too but I feel like this idea of Splash's is the most feasible to start with. If it feels like we need more rules and such, we can add them later. Start simple, not complex. I mean if we get overloaded on the RfP page, we can change the process. But this thing with minimum admins and such just has so many holes. As I argued earlier, we'd need to literally set up a committee to do this if we were to have minimum #s of admins needed for each step. I love our admins, but they all do different things. There is just no way to guarantee participation. Hell, even the ArbCom typically has half of their membership inactive at any one time. --Woohookitty(cat scratches) 05:35, 4 December 2005 (UTC)
- Hopefully, no more requests for SP will go through RFPP than do requests for urgent protection against vandalism at present. I presume most such protections originate from RC patrol. (Is that right?) -Splashtalk 05:52, 4 December 2005 (UTC)
- Hard to tell. We get 1-2 protection against vandalism requests daily. So yeah...probably RC Patrol starts the most protections. --Woohookitty(cat scratches) 06:25, 4 December 2005 (UTC)
- Hopefully, no more requests for SP will go through RFPP than do requests for urgent protection against vandalism at present. I presume most such protections originate from RC patrol. (Is that right?) -Splashtalk 05:52, 4 December 2005 (UTC)
- This may be a better first step, keeping it simple is usually best. Can't sleep, clown will eat me 05:40, 4 December 2005 (UTC)
- Even in a KISS world, and I do see some virtue in that, I'd like to restate my preference for account age rather than edits as the deciding factor. If a vandal comes along and gets told all he has to do is go vandalize N times somewhere else... well it only encourages other stupidity. Dragons flight 05:45, 4 December 2005 (UTC)
- Yes, that's something that might be interesting. From memory, I believe that move was/is unavailable to the newest 2% of accounts. At one time, this resulted in Willy on Wheels setting up sleeper accounts, but any numeric threshold is gamable one way or the other. -Splashtalk 05:52, 4 December 2005 (UTC)
- It's the newest 1% of accounts and on en.wikipedia that amounts to ~4 days. Assumming this is only going to be used for short durations, there won't be much advantage to sleepers since the protection would be over after a few days anyway. Dragons flight 06:18, 4 December 2005 (UTC)
- On second thought, limiting access from the newest 1% would probably work better than N number of edits for the majority of vandals. If someone is willing and dedicated enough to wait it out for ~4 days to create a malintended sleeper account, then they will probably find a way to get around anything else we come up with. Can't sleep, clown will eat me 06:23, 4 December 2005 (UTC)
- Honestly, it doesn't matter to me either way. I think either way is workable. Only problem I have with doing it by how old an account is is that would mean anons could not edit the semi protected pages, correct? Or am I missing something? --Woohookitty(cat scratches) 07:00, 4 December 2005 (UTC)
- Anons are excluded from editing SP'd pages in both versions. -Splashtalk 07:15, 4 December 2005 (UTC)
- Honestly, it doesn't matter to me either way. I think either way is workable. Only problem I have with doing it by how old an account is is that would mean anons could not edit the semi protected pages, correct? Or am I missing something? --Woohookitty(cat scratches) 07:00, 4 December 2005 (UTC)
- On second thought, limiting access from the newest 1% would probably work better than N number of edits for the majority of vandals. If someone is willing and dedicated enough to wait it out for ~4 days to create a malintended sleeper account, then they will probably find a way to get around anything else we come up with. Can't sleep, clown will eat me 06:23, 4 December 2005 (UTC)
- It's the newest 1% of accounts and on en.wikipedia that amounts to ~4 days. Assumming this is only going to be used for short durations, there won't be much advantage to sleepers since the protection would be over after a few days anyway. Dragons flight 06:18, 4 December 2005 (UTC)
- Yes, that's something that might be interesting. From memory, I believe that move was/is unavailable to the newest 2% of accounts. At one time, this resulted in Willy on Wheels setting up sleeper accounts, but any numeric threshold is gamable one way or the other. -Splashtalk 05:52, 4 December 2005 (UTC)
I like it, it's pretty :). Oh, and I like the wording too. -Mysekurity (have you seen this?) 06:10, 4 December 2005 (UTC)
- I read these discussions with interest, after being informed of this proposed policy by User:Mysekurity. I think that it is a very valid proposal, in particular as I have deal with this kind of vandalism on a daily basis in RC patrol. I would side with the distinction of newest account rather than on number of edits. ≈ jossi fresco ≈ t • @ 06:49, 4 December 2005 (UTC)
- Agreed. Down with editcountits. The nice thing is, it can already be implimented; we do this for pagemoves already. -Mysekurity (have you seen this?) 06:51, 4 December 2005 (UTC)
- Care to change the text on the proposed policy from editcountits to the new proposal? It wil remove many of the objections stated and will go long ways to gain acceptance. ≈ jossi fresco ≈ t • @ 06:55, 4 December 2005 (UTC)
- I changed the text in the yellow box (in line, so we can still see what else is being discussed). -Splashtalk 07:15, 4 December 2005 (UTC)
- I was just editing the page, but stopped, because I was worried about different levels. Should we have only time be a factor? And if so, should level 2 be the newest .5 or 1% of users, and level 2 be the newest 1 or 2% of users? And just ignore edits in total, not even 10 or so? I dunno, and it seems like the entirety of the editing his happening here. Like good Wikipedia users, everyone's using the talk page, but unlike good wikipedia users, nobody's being bold, and editing the article. I honestly don't know where to go from here, but I can only say {{sofixit}}, as I don't know what to do. This talk page takes too long to read, and the proposal page, while pretty good, is boring, imo (no offense to me or the others who created it). With a few minor exceptions, I wrote the majority; I'm pleased that people like my ideas, but it seems like nobody's really paying attention to it. Titoxd came up with the idea of a custom function, and posted a note on the talk page, but didn't realize I had said something to that effect the day before or so on the project page. Not to single Tito out, but people really do need to actually work on the proposal. The beauty of a wiki is that it's living. We shouldn't just talk about it, we should actually edit. If you edit something stupid into it, it can be reverted, so be bold! -Mysekurity (have you seen this?) 07:06, 4 December 2005 (UTC)
- Hey, don't look at me. I edited the main proposal. :) --Woohookitty(cat scratches) 07:08, 4 December 2005 (UTC)
- See the section title? :) Simple is sweet, and one single extra level will give you everything you're after. -Splashtalk 07:10, 4 December 2005 (UTC)
- Agreed. Sorry I'm a little cranky, it's past my bedtime (it's 2:19 here). Should I edit the proposal with the changes in mind, or do you want to? And yes, Woohookitty, you did. Thank you ;). I really need to get to sleep soon, big day to me tomorrow. -Mysekurity (have you seen this?) 07:22, 4 December 2005 (UTC)
- Be bold! :-D I added the proposed template to use. --Woohookitty(cat scratches) 07:25, 4 December 2005 (UTC)
- Oh, I am so much bolder than you. :P Splashtalk 07:32, 4 December 2005 (UTC)
- Be bold! :-D I added the proposed template to use. --Woohookitty(cat scratches) 07:25, 4 December 2005 (UTC)
- Agreed. Sorry I'm a little cranky, it's past my bedtime (it's 2:19 here). Should I edit the proposal with the changes in mind, or do you want to? And yes, Woohookitty, you did. Thank you ;). I really need to get to sleep soon, big day to me tomorrow. -Mysekurity (have you seen this?) 07:22, 4 December 2005 (UTC)
- But I gave sample code! :P Titoxd(?!? - did you read this?) 03:26, 5 December 2005 (UTC)
- Care to change the text on the proposed policy from editcountits to the new proposal? It wil remove many of the objections stated and will go long ways to gain acceptance. ≈ jossi fresco ≈ t • @ 06:55, 4 December 2005 (UTC)
I would make one general comment about account age: 1% or ~4 days will often be a much higher bar than, say, 20 edits would be. It would be nice if I could edit everything today, no? -Splashtalk 07:20, 4 December 2005 (UTC)
- How did we get to "all unregistered users from editing that page"? I thought that we were only trying to ensure that there was a minimum number of edits before the editor could then begin his/her contributions to tagged articles. Unless there is a software or development reason why IP's must register to be able to edit these tagged pages, then I won't support it.--MONGO 09:41, 4 December 2005 (UTC)
- Wasn't that the point of all this? If not, AOL users and children behind school proxies will be completely immune to semi-protection, which would defeat the entire purpose of account aging. Can't sleep, clown will eat me 09:43, 4 December 2005 (UTC)
- That was already shot down, numerous times...forcing people to register accounts to edit will never get past Jimbo--MONGO 09:46, 4 December 2005 (UTC)
- Correct me if I am wrong, but isn't this something the entire community should decide upon, and not just Jimbo? It seems like there is plenty of support behind this to me. Can't sleep, clown will eat me 09:47, 4 December 2005 (UTC)
- That was already shot down, numerous times...forcing people to register accounts to edit will never get past Jimbo--MONGO 09:46, 4 December 2005 (UTC)
- Wasn't that the point of all this? If not, AOL users and children behind school proxies will be completely immune to semi-protection, which would defeat the entire purpose of account aging. Can't sleep, clown will eat me 09:43, 4 December 2005 (UTC)
- At some point, to get this through it is going to take massive support and my bet is that Jimbo will oppose it, although I may be completely wrong, but if does not support it, it probably won't happen. I may be confused but the proxies and AOL won't be immune but will probably be completely eliminated from editing without registering to do so.--MONGO 09:55, 4 December 2005 (UTC)
- They would not be allowed to edit semi-protected articles, yes. I myself think the anons should be allowed to still edit it if they've performed a certain # of edits. Again Mongo, we'd be talking 20-30 articles, if that. And as has been said, you already have to be outside of the newest 1% of accounts to perform moves, so this isn't entirely new. --Woohookitty(cat scratches) 10:02, 4 December 2005 (UTC)
- Oh, don't misunderstand me as I am in support of this proposal and even the more radical bug in which Kizzle and I fought to try and see if we could demand that only registered editors be allowed to edit pages. I have since altered my viewpoint on the latter, but am concerned about the wording of registered accounts, and I have doubt that this will happen...they'll be crying that it is unwiki and have a valid point in that argument.--MONGO 10:07, 4 December 2005 (UTC)
- I agree with Jimbo anyway. Let the hoi polloi edit Wikipedia without having to register? Fine with me — Rickyrab | Talk 17:10, 4 December 2005 (UTC)
- Oh, don't misunderstand me as I am in support of this proposal and even the more radical bug in which Kizzle and I fought to try and see if we could demand that only registered editors be allowed to edit pages. I have since altered my viewpoint on the latter, but am concerned about the wording of registered accounts, and I have doubt that this will happen...they'll be crying that it is unwiki and have a valid point in that argument.--MONGO 10:07, 4 December 2005 (UTC)
- They would not be allowed to edit semi-protected articles, yes. I myself think the anons should be allowed to still edit it if they've performed a certain # of edits. Again Mongo, we'd be talking 20-30 articles, if that. And as has been said, you already have to be outside of the newest 1% of accounts to perform moves, so this isn't entirely new. --Woohookitty(cat scratches) 10:02, 4 December 2005 (UTC)
- At some point, to get this through it is going to take massive support and my bet is that Jimbo will oppose it, although I may be completely wrong, but if does not support it, it probably won't happen. I may be confused but the proxies and AOL won't be immune but will probably be completely eliminated from editing without registering to do so.--MONGO 09:55, 4 December 2005 (UTC)
- It's a much better solution than preventing everyone from editing an article during a vandalism attack, which is what we're faced with right now. Can't sleep, clown will eat me 10:05, 4 December 2005 (UTC)
- MONGO: As Woohookitty has already said, only registered users who are among the oldest 99% of accounts can move pages. This is exactly the same restriction, just on a different but similar prospect. -Mysekurity (have you seen this?) 15:38, 4 December 2005 (UTC)
MONGO, most AOL IPs have hundreds of edits. Why would that mean anything in terms of them being an established user? IPs are shared, and widely in some cases. A vandal who has never edited before could come along and edit on the back of other people's work, and probably on the back of other's vandalism. That doens't make sense. This doesn't prevent them editing completely, just on the SP'd articles. -Splashtalk 17:54, 4 December 2005 (UTC)
Also, full protection already prevents anons editing, so this is no different. And, of course, this is only for short term protection against vandalism, so they'll be able to edit the article again soon. Noone is suggesting, or I hope no-one is suggesting, permanent protection of any article by this means. Because if they are, the proposal is dead in the water. -Splashtalk 17:59, 4 December 2005 (UTC)
- On the one hand you seemed opposed to the implementation of this semiprotect with your grilling and seeming indication that it is unwiki while now you seem to support it. That doesn't make sense. I am well aware of the protection guidelines. I was merely stating that I actually at one time supported the more radical bug that was discussed that would have prevented all unregistered editors from editing and naturally backed away from that as it was unwiki. I was merely voicing that if semiprotect is going to eliminate proxy or AOL users from editing without registering that we may have trouble getting this accomplished. It's not a matter of how many articles we utilize semiprotect on, it's the limitations it may impose on some editors by demanding they register. I am a strong supportor of this proposal and am not trying to be obstructionist, just bringing the issue to the forefront having previously dealt with the issue of registration as a requirement of editing priviledge.--MONGO 20:39, 4 December 2005 (UTC)
- Yes, they MUST be logged in, otherwise many people can edit a semiprotected article no matter what. IPs tend to accumalate randmom edits, by many different people. Not sure what I think about the "newest percent" plan, definetely worth a try if it is easier on the servers. Remeber it should only query when you click "edit".Voice of AllT|@|ESP 20:41, 4 December 2005 (UTC)
- @MONGO: I can argue both sides of a debate! There seemed to be no-one here disagreeing with the proposal, and that's unhealthy. I will continue to be hard work where I think deeper thought is required. My grilling was laying out all the possible concerns with the proposal. I hope people have considered them. They seem to have. Protection of any kind is unwiki, and I would not want to see this proposal used widely or have too many different restrictions that can be placed on editors. To that end, my boxed idea above reduces the usage to handling simple vandalism, which is from where it originated, and increases the restrictions only so far as is absolutely necessary. Nothing fancy, nothing that filters users against one another more than we have to, and nothing that will be left in place for very long. -Splashtalk 20:58, 4 December 2005 (UTC)
- Protection against anons is a non-issue. We do it already. Preventing anons from editing completely, on the other hand, is a non-starter. -Splashtalk 20:58, 4 December 2005 (UTC)
- Splash, I don't argue that preventing anons from editing is a non-starter. But the wording in the boilerplate you proposed does indeed do just that. There is nothing unhealthy about no one disagreeing with this proposal...in fact, that is a good sign as far as I am concerned. While recognizing that anons can't do page moves in the GWB article, aside from that, how else do we prevent them from contributing? You're boilerplate appears to eliminate them from contributing in articles in which semiprotect is employed. Personally, I could care less if they can contribute and I think that almost all substantive edits come from registered users...that is my opinion and not based on anything other than that. Regardless, I was, once again, merely reminding all that if we are going to get this thing to pass, we will have to address the issue of why we think it is okay to dissallow edits from AOL and proxies, et al in articles in which semiprotect is utilized...so are we then actually stating that we essentially demand that only registered users have editiing rights under semiprotection? Because that is were we seem to be pretty close to being. Deeper thought for you.--MONGO 21:26, 4 December 2005 (UTC)
- No, that's not what I said. When a page is protected at the moment, anons can't edit it. The same would be true of semi-protected pages. It doesn't change the status of anons with regard to protected pages. -Splashtalk 02:50, 5 December 2005 (UTC)
- Splash, I don't argue that preventing anons from editing is a non-starter. But the wording in the boilerplate you proposed does indeed do just that. There is nothing unhealthy about no one disagreeing with this proposal...in fact, that is a good sign as far as I am concerned. While recognizing that anons can't do page moves in the GWB article, aside from that, how else do we prevent them from contributing? You're boilerplate appears to eliminate them from contributing in articles in which semiprotect is employed. Personally, I could care less if they can contribute and I think that almost all substantive edits come from registered users...that is my opinion and not based on anything other than that. Regardless, I was, once again, merely reminding all that if we are going to get this thing to pass, we will have to address the issue of why we think it is okay to dissallow edits from AOL and proxies, et al in articles in which semiprotect is utilized...so are we then actually stating that we essentially demand that only registered users have editiing rights under semiprotection? Because that is were we seem to be pretty close to being. Deeper thought for you.--MONGO 21:26, 4 December 2005 (UTC)
Does the tag have to be {{sprotected}}? Could we make it {{semiprotected}} for a teeny bit more clarity? :-) Tim Pierce 13:41, 7 December 2005 (UTC)
- One could redirect to the other, so that isn't really a problem... Titoxd(?!? - did you read this?) 20:29, 7 December 2005 (UTC)
More features
Why not put into policy something like the following, as well?
or
— Rickyrab | Talk 17:06, 4 December 2005 (UTC)
- In my opinion: absoultely not. Keep it simple, for goodness sake! We're not trying to hamstring new editors. We're just trying to reduce vandalism a bit. And what you are asking for would require significant changes to the MediaWIki engine which does not, at presesnt to my knowledge, have any scrutiny of edits except for forbidden external links. Just make life easy! -Splashtalk 17:54, 4 December 2005 (UTC)
- I actually AGREE with Splash here, that tag would scare me off i I was new.Voice of AllT|@|ESP 20:43, 4 December 2005 (UTC)
I don't see why that message should be displayed to everyone reading the article. Why not display it only after "edit" has been clicked, if the user attempting to edit is affected by the restriction? Rd232 talk 21:28, 4 December 2005 (UTC)
- So that everyone knows up front what the status of the article is. We edit and operate openly here, not secretively. At present the protection notoice is shown to absolutely everyone. That should continue. -Splashtalk 21:31, 4 December 2005 (UTC)
- Yes but. This is one of my more fundamental gripes about Wikipedia - it too often assumes everyone wants to be an editor. I see no reason why someone who merely wants to read an article should be distracted by the mechanics of how the article is being edited. By all means, make the info easily available; but separate. An obvious way is to only show it after Edit is clicked. Rd232 talk 10:23, 6 December 2005 (UTC)
Doing as told?
Splash, you are an admin. No one can tell you what to do! lol Yeah. lol I'm glad we're making progress on this. It won't cover alot of pages, but I think it's a very important proposal for us vandal fighters. --Woohookitty(cat scratches) 07:32, 4 December 2005 (UTC)
Psh, you better take that back (Supreme Lord Chancelor might be listening!). Thanks for adding it, sans grudge ;). -Mysekurity (have you seen this?) 07:52, 4 December 2005 (UTC)
Ooh, Splash, I'm loving the change "many" to "some." Thanks! -Mysekurity (have you seen this?) 07:56, 4 December 2005 (UTC)
calculated bad faith edits.
I thought I posted this last night, but maybe i forgot to save it. Has anyone considered the issue of people whose business is to make bad alterations to wiki? The higher profile wiki becomes, the more people are going to be paid to sit around all day altering articles which their bosses do not agree with. I would be very surprised if there are not people whose job it is to alter pages to read their way, particularly pages like George Bush. Then, people who feel agrieved, who are simply determined to make a mark. The simplest way to remove something would just be to deface it, particular if they could not get consensus. These people are unlikely to be deterred by a simple scheme to discourage random visitors who fancy a laugh, but will jump whatever hurdle is put in their way. So the effectiveness of this scheme might depend on how many of these full time vandals there are. Sandpiper 09:52, 4 December 2005 (UTC)
- That is where we would be forced to implement full protection. It is already going on and I helped fight what definitely looked like paid spammers in the Ray Nagin article. The level of POV being pushed there was well beyond that of a strong minded person, and a number of us there commented that it definitely appeared to be the work of a paid blogger or the like.--MONGO 10:12, 4 December 2005 (UTC)
- Yep. Full protection to guard against vandalism would definitely not go away under this proposal. --Woohookitty(cat scratches) 10:15, 4 December 2005 (UTC)
Where are the devs?
I like this new N%(1-3 or so) idea. Why? Because both version stop vandalism to the protected article, BUT this version will not encourage vandals to rage through other article's first. Less vandalism=better. Can we get a developer now...lets try this out!Voice of AllT|@|ESP 20:47, 4 December 2005 (UTC)
Agreed. Let's go for it! We can even use recycled code from pagemoves, which I love. Anyone feel like contacting someone? -Mysekurity(have you seen this?) 01:51, 5 December 2005 (UTC)
Just wondering...
I'm just reading this talk page right now, and I haven't gone through everything yet. But just how often do we plan on using this feature, if it is enabled? If it is only for a handful of articles, it does not seem to be worthwhile to implement... --HappyCamper 01:47, 5 December 2005 (UTC)
- We're thinking 30 at most, but it will be extremely helpful in combatting constantly vandalized pages (have you seen the history for George W. Bush? -Mysekurity(have you seen this?) 01:50, 5 December 2005 (UTC)
- We're not putting hard numbers on it, but I think that it would more or less replace the need for full protection in the case of vandalism, since most such attacks are anonymous or from very new accounts. So about as often as we currently vprotect things and for about as long. -Splashtalk 01:51, 5 December 2005 (UTC)
Yet more suggestions
Instead of:
What about
But to be honest, I'd prefer to see a system where unproven accounts can edit anything, but their edits have to be accepted/reverted by a proven account before being displayed publically, or at least, before any other edits are made to that page. Accept/revert could be a single click that either approves all pending unproven edits, or rolls back to the last proven version respectively. I realise that doing all that would probably be even more work than the semi-protection proposal, but it might give the benefits of semi-protection to all pages without blocking anybody from making genuine contributions anywhere.
Regards, Ben Aveling 02:31, 5 December 2005 (UTC)
- No. There is no content review process on Wikipedia other than open editing. Instituting content review is a complete departure from how we edit. There will be an article validation feature switched on in January, and that's as far as we're likely to go. I don't see the point of the alternative template, it says the same thing. -Splashtalk 02:45, 5 December 2005 (UTC)
Nearly the same thing, but not quite.
- "Because of" vs "To deal with"
The first is just a statement of fact. The second is sort of a promise. Given that semi-protection can be gotten around by any patient vandal (Create an account, let it age for a week, make 50 random edits somewhere), claiming that this "deals with" vandalism is too strong. It probably helps but that's all. As noted above, it may make things worse because it might just move vandalism to pages that aren't watched as closely, especially if the reward for vandalising 50 unprotected pages in subtle ways or at high speed is that you then get to vandalise semi-protected pages.
- "persistent vandalism" vs "vandalism"
Addresses the question of 'why this page and not that page'. Says that semi-protection isn't for just any page that cops vandalism, but only for those that really need it.
- "currently" vs "temporarily"
I doubt that semi-protection will always be temporary. The word "currently" allows for it to be temporary or permanant, as desired.
- the extra link
Speaks for itself, I think.
Article validation sounds interesting. What will the new feature do?
Regards, Ben Aveling 03:35, 5 December 2005 (UTC)
- Meh, it's just semantics and grammar. See {{vprotected}}, which uses a less sensical ordering of the same words. It doens't matter what it says, it's who it restricts that matters. Semi-protection will alwasy be indefinite. GWB won't be president forever, and the community is unlikely to support even semi-protection on an indefinite basis away from the Main Page. See m:Article validation feature. -Splashtalk 03:43, 5 December 2005 (UTC)
- Semantics matter. Full protection is always temporary and does deal with vandalism, at a cost. What doesn't matter is the fact that most of the community often won't support semi-protection, because they won't oppose it strongly. Whereas the minority who do want a page semi-protected will feel very strongly about it, so the result will usually be semi-protection. Ben Aveling 20:46, 5 December 2005 (UTC)
- There are some major problems with content review. For example, what if an anon proposes a change, and someone else actually changes the page before the proposed change gets reviewed, in a way that would require the anon's proposal to be refigured? BD2412 T 03:11, 5 December 2005 (UTC)
- I imagine that in order for someone else to start editing they have to either accept or reject the change. Unless they themselves are unproven, in which case their changes would 'chain' and the next reviewer will have to accept/reject the lot. Ben Aveling 03:35, 5 December 2005 (UTC)
- I'd be more for with newer accounts then the very new and certainly not a specific # (if you state the number to vandals, they may vandalize just to get to the specific number
- I was thinking of that. I think the 'best' metric might be something like one day after the 50th edit. That give time for the edits to be evaluated by other people plus it potentially reduces the load on the servers. Regards, Ben Aveling 20:46, 5 December 2005 (UTC)
Regarding Time limits
I see that some people are opposed to having limits set on the amount of time a page is semi-protected. For those people, I have a few questions.
- Do you recognize the temptation for many admins to leave a page semi-protected, as it has observable benefits and unobservable consequences?
- If there are no time limits, how do you propose we limit "protection creep"?
- What specific criteria warrants a page to be un-semi-protected? Will this criteria be variable between admins? How will we decide in a conflict?
--kizzle 03:28, 5 December 2005 (UTC)
- Any good admin shouldn't be thinking like that. They should be trying to have as many people edit a page as possible. It has a directly detrimental effect to the way the wiki works. There is nothing to stop Admin B from unprotecting Admin A's protection at any moment they think fit. The system works fine at present, and there's no reason to suppose it will suddenly break.
- Simply by limiting it to dealing with bouts of vandalism, the same way we do at present. That usually only lasts for a few hours. In the case of George W. Bush, well, you're all just overreacting a bit...at the moment, the vandal rate is way down owing to other measures.
- We don't do specific criteria. We trust to the goodness of human judgement on what is a very simple question: "has the vandal gone?" If so, unprotect. In a conflict, we decide on AN or AN/I or talk page as at present. No need to change anytning.
- Splashtalk 03:34, 5 December 2005 (UTC)
- I think we would have protection creep (in terms of number of protected pages) whether we have infinite expiry or not. At least, unless we have some limit on rolling semi-protection. Regards, Ben Aveling 03:38, 5 December 2005 (UTC)
- You're putting way too much faith in the admin's role. This isn't crafting policy, this is a recipe for ambiguity in sp's application. "Any good admin" is not how one creates policy, nor how WP:NPOV or any other policy was created. The temptation does exist, and you can't possibly say that most admins are "good" so we just shouldn't worry about it. Protection is incredibly clear cut, as one can see evidence for its removal in the talk page. Semi-protection has no such evidence, thus there will be no standard of when it gets lifted, and some admins will want to keep it for a long time. What if an admin wants to semi-protect South Park Republican indefinetely? We have no policy that would state otherwise, and he'd be as right as you are. This is highly ironic coming from the person who highlighted the importance of addressing "protection creep", now you are completely ignoring any attempts to account for such a possibility within policy and just "trusting" that admins will use it properly. We are not here to craft a simple proposal purely for simplicity's sake and put it through a test run if we can conceive of highly possible scenarios where its implementation would run afoul. --kizzle 03:43, 5 December 2005 (UTC)
- How is this different from the current full protection? One admin applies, another removes it. Job done. If an admin wants to permanently semi-protect an article, they're going to have to defend that desire on WP:AN pretty quickly. -Splashtalk 03:45, 5 December 2005 (UTC)
- Read my text on the above proposal about why protection is different from semi-protection in the amount of caution we ascribe to it. Like I said, I was just catering to your good point about the possibility for protection creep. You are completely disregarding such a possibility now, and I still haven't heard from you how whether or not time limits or lack thereof will affect the probability of protection creep.--kizzle 03:49, 5 December 2005 (UTC)
- The simpler proposal has no protection creep beyond the minimum. It has one additional level only and is only to be applied in cases of serious vandalism: these articles are routinely protected now, and there's no reason to suppose it would be applied significantly more widely. Indeed, the wording is intended to prevent that. The presence of hard time limits significantly reduces the usefulness of the system, as I described in the section much further up: rarely will one of the options be what I want. Also, any admin can reverse me at any time as with all admin actions, so the limits won't hold up. -Splashtalk 03:54, 5 December 2005 (UTC)
- If a semi-protection is terminated early, I have absolutely no problem with that. My problem is semi-protection becoming standard practice and thus becoming a permanent fixture on articles that really don't need it. The amount of levels is irrelevant to the possibility of protection creep, the creep i'm referring to is the amount of pages semi-protected exponentially increasing, not the intensity of the semi-protection applied on these levels. So far, we know that the temptation exists to use semi-protection in an indiscriminate manner, yet without time limits, you have not provided another solution that will help stem the increase in semi-protected pages over time. --kizzle 03:57, 5 December 2005 (UTC)
- What is there at present to stop the number of protected pages increasing at any given rate? -Splashtalk 03:58, 5 December 2005 (UTC)
- Absolutely nothing, because there is no temptation for protection to stay indefinetely on a page. When a page is protected, there are obvious visible consequences, in that no one can edit the page, and little benefit, in that it's a means to an end for the page to return to order. There is also a "ticking clock" initiated by the editors involved in the page, as they want to get back to making the article better. However, semi-protection has observable benefits (no vandalism) but no observable consequences. Thus, unlike protection, where there is stress put on the system to return the page to an editable state, semi-protected pages are more stable, receive less vandalism, and thus there exists a temptation to leave semi-protected pages longer than the initial flood of vandalism. Hell, I work on GWB and I can't wait for this to be implemented so that it can actually have a coherent edit history, and I guarantee it will be put on for a long time on that page. Thus, in sum, to answer your question, protection requires no measures to prevent the amount of protected pages increasing exponentially because there simply is no temptation to leave it protected; it's exactly the opposite, as most protected pages have editors waiting patiently for it to be un-protected. No editor will be waiting as such for semi-protection to be lifted, as they only see its benefits. --kizzle 04:08, 5 December 2005 (UTC)
- The observable consequences are that some good new editors and all anons will be unable to edit the page. Both things are bad, as a matter of Wikimedia Foundation doctrine. Once admins get used to SP, which will be quite quickly, WP:RFPP and WP:PP (and WP:AN/I) should be able to oversee the process ok. An admin who leaves a page SPd for longer than necessary will be fixed up by another one. Honestly, we admins are moderately capable folk. Those admins who see an opportunity to use this is a means to reduce anon editing should be taken out and shot. Which they will be, fairly publicly, on WP:AN/I and the like. A public roasting can achieve quite a lot. GWB may be long term semi-protected, but that can be effected by a discussion on AN/I like we had the other day, that doesn't come out resolutely against the idea (as that one did). -Splashtalk 04:16, 5 December 2005 (UTC)
- But those aren't observable consequences, they are only inferred. I just think that the lack of specificity you are proposing to wrap around this powerful tool is going to bite us in the ass. I think simply relying on the threat of an admin getting "roasted" at the noticeboard to combat protection creep in the amount of semi-protected pages is insufficient. What if we have a good-intentioned admin who sees it different as you, and wants to semi-protect a moderately vandalized page for a long period of time? Do they deserve to get "roasted" if they simply disagree with your assesment? Remember, there is absolutely no physical evidence besides a lack of vandalism that warrants a page from becoming un-semi-protected, so it will be highly subjective as to when admins feel that a page should be un-semi-protected. If we use your lack of specificity in sp's application, than neither of you would be wrong. --kizzle 04:42, 5 December 2005 (UTC)
- The observable consequences are that some good new editors and all anons will be unable to edit the page. Both things are bad, as a matter of Wikimedia Foundation doctrine. Once admins get used to SP, which will be quite quickly, WP:RFPP and WP:PP (and WP:AN/I) should be able to oversee the process ok. An admin who leaves a page SPd for longer than necessary will be fixed up by another one. Honestly, we admins are moderately capable folk. Those admins who see an opportunity to use this is a means to reduce anon editing should be taken out and shot. Which they will be, fairly publicly, on WP:AN/I and the like. A public roasting can achieve quite a lot. GWB may be long term semi-protected, but that can be effected by a discussion on AN/I like we had the other day, that doesn't come out resolutely against the idea (as that one did). -Splashtalk 04:16, 5 December 2005 (UTC)
- Absolutely nothing, because there is no temptation for protection to stay indefinetely on a page. When a page is protected, there are obvious visible consequences, in that no one can edit the page, and little benefit, in that it's a means to an end for the page to return to order. There is also a "ticking clock" initiated by the editors involved in the page, as they want to get back to making the article better. However, semi-protection has observable benefits (no vandalism) but no observable consequences. Thus, unlike protection, where there is stress put on the system to return the page to an editable state, semi-protected pages are more stable, receive less vandalism, and thus there exists a temptation to leave semi-protected pages longer than the initial flood of vandalism. Hell, I work on GWB and I can't wait for this to be implemented so that it can actually have a coherent edit history, and I guarantee it will be put on for a long time on that page. Thus, in sum, to answer your question, protection requires no measures to prevent the amount of protected pages increasing exponentially because there simply is no temptation to leave it protected; it's exactly the opposite, as most protected pages have editors waiting patiently for it to be un-protected. No editor will be waiting as such for semi-protection to be lifted, as they only see its benefits. --kizzle 04:08, 5 December 2005 (UTC)
- What is there at present to stop the number of protected pages increasing at any given rate? -Splashtalk 03:58, 5 December 2005 (UTC)
- If a semi-protection is terminated early, I have absolutely no problem with that. My problem is semi-protection becoming standard practice and thus becoming a permanent fixture on articles that really don't need it. The amount of levels is irrelevant to the possibility of protection creep, the creep i'm referring to is the amount of pages semi-protected exponentially increasing, not the intensity of the semi-protection applied on these levels. So far, we know that the temptation exists to use semi-protection in an indiscriminate manner, yet without time limits, you have not provided another solution that will help stem the increase in semi-protected pages over time. --kizzle 03:57, 5 December 2005 (UTC)
- The simpler proposal has no protection creep beyond the minimum. It has one additional level only and is only to be applied in cases of serious vandalism: these articles are routinely protected now, and there's no reason to suppose it would be applied significantly more widely. Indeed, the wording is intended to prevent that. The presence of hard time limits significantly reduces the usefulness of the system, as I described in the section much further up: rarely will one of the options be what I want. Also, any admin can reverse me at any time as with all admin actions, so the limits won't hold up. -Splashtalk 03:54, 5 December 2005 (UTC)
- Read my text on the above proposal about why protection is different from semi-protection in the amount of caution we ascribe to it. Like I said, I was just catering to your good point about the possibility for protection creep. You are completely disregarding such a possibility now, and I still haven't heard from you how whether or not time limits or lack thereof will affect the probability of protection creep.--kizzle 03:49, 5 December 2005 (UTC)
- How is this different from the current full protection? One admin applies, another removes it. Job done. If an admin wants to permanently semi-protect an article, they're going to have to defend that desire on WP:AN pretty quickly. -Splashtalk 03:45, 5 December 2005 (UTC)
- You're putting way too much faith in the admin's role. This isn't crafting policy, this is a recipe for ambiguity in sp's application. "Any good admin" is not how one creates policy, nor how WP:NPOV or any other policy was created. The temptation does exist, and you can't possibly say that most admins are "good" so we just shouldn't worry about it. Protection is incredibly clear cut, as one can see evidence for its removal in the talk page. Semi-protection has no such evidence, thus there will be no standard of when it gets lifted, and some admins will want to keep it for a long time. What if an admin wants to semi-protect South Park Republican indefinetely? We have no policy that would state otherwise, and he'd be as right as you are. This is highly ironic coming from the person who highlighted the importance of addressing "protection creep", now you are completely ignoring any attempts to account for such a possibility within policy and just "trusting" that admins will use it properly. We are not here to craft a simple proposal purely for simplicity's sake and put it through a test run if we can conceive of highly possible scenarios where its implementation would run afoul. --kizzle 03:43, 5 December 2005 (UTC)
<reset indent> If two admins disagree they either a)Work it out or b)Take the matter to a community forum and try to establish a consensus. If there is no consensus for an article to be protected, clearly it is unprotected (or not protected). Wrapping ourselves in vagueness works excellently because it provides maximum flexiblity in application and determination. Having a situation where noone is wrong sounds good to me. -Splashtalk 04:47, 5 December 2005 (UTC)
- I am still unconvinced. Your proposal simply does not in any way attempt to address protection creep in the amount of pages protected. Without any limitation to semi-protection, it will become more commonplace than its original utility warrants. --kizzle 05:45, 5 December 2005 (UTC)
- Kizzle, you are missing a major point here. We can change this. You have to start simple and then go more complex. You have to start general before you go to the specific. Otherwise, you are handcuffing the admins. What's going to happen if we put time limits in right away is that admins just won't use the policy because they don't want to have to worry about time limits and # of admins to overturn and all of that. They will just avoid using the tool. And. As for protection creep, if...a month after the policy is initiated it looks as though the # of semi-protected pages is going way beyond what we expected, we can then add time limits. This is not set in stone. You've mentioned several times that "this isn't how you make policy". It is on Wikipedia. We have to be very flexible. It's the nature of an ever changing site with different issues from day to day. We just can't start with the worst case scenario (i.e. that semi-protection is going to get out of hand). Like I said, if it does get out of hand, trust me, we'll figure it out. After all, that's essentially how we got to starting this discussion in the first place, i.e. GWB and others getting way out of hand.
- I think what Splash is trying to explain is that admins are very good at self-policing. If one of us makes an odd block (like blocking an IP for a month), there is usually another admin there to jump in. If someone makes any odd moves, someone is there. If a page is protected that shouldn't be, it can be unprotected. If it's unprotected or protected unwisely, the admin gets yelled at by many many others. Trust me. I know. I mean something else you aren't realizing is that if we implement semi-protection, it doesn't stop the new users or IPs from commenting on the semi-protecting admins page or on Requests for Protection (which has an unprotection request section) or anywhere else. So that's another check on protection creep. Objections by others could lead to the semi protection being lifted. It's not as if we are completely blocking them from Wikipedia. Another point is that admins have alot of unwritten conventions, including IP blocks not going over 24 hours unless it's a repeat offender, pages not being protected if it's not a persistant edit war/vandalism case and many others. As I said, admins are good at self-policing. If things are getting out of hand, informal limits will be developed. They always are.
- So the thing is that there are alot of checks to this system. Another admin could easily overturn another admin and if there's a dispute, it'll go to the administrator's noticeboard. Users stopped from editing an article due to semi-protection are not stopped from commenting on the RfPP page or on admin's user pages. As long as we specify that this is to be used only for severe vandalism, I don't see it getting out of hand. And again, if it does, we can address it later. Start simple and go from there. --Woohookitty(cat scratches) 06:14, 5 December 2005 (UTC)
- The benefits of semi-protection are local. The costs are thinly spread. That's a recipe for creep because it means that, for any specific page, the people who want it are much more motivated than those who don't want it. I really don't see how time limits could be enforced? So I don't think they'd help much. Regards, Ben Aveling 06:33, 5 December 2005 (UTC)
- clearly I have a different interpretation of what semi-protection should be, so i'm going to stay out of this. you guys hash it out, I'm going to take a step back. --kizzle 06:49, 5 December 2005 (UTC)
Only one level of SP
I highly disagree with the proposal to have only one level of semi-protection. There are some cases where we want to stem off a tide of casual vandals without going too far, and sometimes we want to stem off dedicated vandals, like at GWB. Why should we limit ourselves to one level, and the mere reason it is simple is not sufficient. The reason why we're in this mess now is because someone early on only conceived of a page being fully editable or not editable at all, without taking into consideration heavily visited pages that would be vandalized. Let's not make the same mistake and do something stupid purely in the name of simplicity. --kizzle 03:32, 5 December 2005 (UTC)
- There are no dedicated vandals at GWB. They all just drive by and carry on elsewhere. Temporarily protecting against brand new accounts and anons (rather than all accounts and anons) will knock out ~90% of the vandalism since that's where 90% of it comes from. -Splashtalk 03:35, 5 December 2005 (UTC)
- how do you know that? I find it extremely surprising, and someone else above posted they knew a case. But even if there aren't, there will be as wiki becomes higher profile. But I would be absolutely amazed if there were not. It is an obvious thing for politicians to do to articles. Sandpiper 18:41, 6 December 2005 (UTC)
- Splash is right, she and I both know this due to our involvement with Wikipedia and the amount of time we spend reverting vandalism day in and day out. Whenever I review a vandal's contribution history, they generally hit 5 or 6 pages before they are finally blocked. You would be surprised to learn how many times at least one of those 5 or 6 pages is the George W. Bush article. Hall Monitor 18:50, 6 December 2005 (UTC)
- how do you know that? I find it extremely surprising, and someone else above posted they knew a case. But even if there aren't, there will be as wiki becomes higher profile. But I would be absolutely amazed if there were not. It is an obvious thing for politicians to do to articles. Sandpiper 18:41, 6 December 2005 (UTC)
- But why limit yourself to one level? Just like the proposal to make the tool variable itself because of different wiki implementations, we should think about scalability and the future. One level simply doesn't make sense as there will be different situations with a different amount of vandalism. If we stick with 25 edits, that's easily surmountable. 100 edits is too much on certain pages. --kizzle 03:45, 5 December 2005 (UTC)
- It's a question of what the community will accept and what the devs will implement this decade. Too much m:instruction creep is an absolutely, sure-fire guaranteed way of having a proposal fail. A proposal that achieves as much as it can with as little effort as possible has the highest chance of success. Note that the vast bulk of vandalism is from anons. That's all we really need to stop, along with the clever ones who work out that they need an account for a few minutes to have fun. There's no difference between 25 edits and 100 — I can game one just as easily as the other. Just as easily as I can game 1%, too. -Splashtalk 03:49, 5 December 2005 (UTC)
- Keep in mind the software aspect of the proposal given to developers is for a completely variable tool. The levels are set within policy of each Wiki implementation. The difference between 25 edits / 5 days is waaaaay different from 100 edits / 30 days, so you are incorrect in saying one can be gamed as easily as the other. --kizzle 03:53, 5 December 2005 (UTC)
- Well, in my mind, all we ask the devs to do is provide a single level of SP. The less we ask for, the exponentially higher our chances of having the wish granted. I don't see any need for multiple levels, and protection creep up-the-scale actively disuades me from supporting it. -Splashtalk 03:55, 5 December 2005 (UTC)
- Right, but asking for a user-supplied edit count / account life threshold is virtually no more work (and no more execution time) than if we supply standard hard-coded entries. Did you see the previous proposal that different wiki implementations might want different thresholds of vandalism? We need to try and address scalability so that we don't make the same mistake as the first person did in assuming we only need an editable/non-editable dichotomy for article pages. --kizzle 04:00, 5 December 2005 (UTC)
- Well, in my mind, all we ask the devs to do is provide a single level of SP. The less we ask for, the exponentially higher our chances of having the wish granted. I don't see any need for multiple levels, and protection creep up-the-scale actively disuades me from supporting it. -Splashtalk 03:55, 5 December 2005 (UTC)
- Keep in mind the software aspect of the proposal given to developers is for a completely variable tool. The levels are set within policy of each Wiki implementation. The difference between 25 edits / 5 days is waaaaay different from 100 edits / 30 days, so you are incorrect in saying one can be gamed as easily as the other. --kizzle 03:53, 5 December 2005 (UTC)
- It's a question of what the community will accept and what the devs will implement this decade. Too much m:instruction creep is an absolutely, sure-fire guaranteed way of having a proposal fail. A proposal that achieves as much as it can with as little effort as possible has the highest chance of success. Note that the vast bulk of vandalism is from anons. That's all we really need to stop, along with the clever ones who work out that they need an account for a few minutes to have fun. There's no difference between 25 edits and 100 — I can game one just as easily as the other. Just as easily as I can game 1%, too. -Splashtalk 03:49, 5 December 2005 (UTC)
1% of new users
I was away while we decided on using the newest 1% of all users. First of all, in my mind, this calculation seems much more complicated than a simple edit count and account life check, maybe a developer would like to chime in on the feasability of either. Second, how is this in any way shape or form superior to a edit count/account life combo? What are the proposed advantages and disadvantages over such a system? --kizzle 03:36, 5 December 2005 (UTC)
- The ability to move is usually not available to the newest 1% of accounts, so that particular test is already available. -Splashtalk 03:40, 5 December 2005 (UTC)
- By the way, in a test case scenario, can someone tell me what threshold is the newest 1% of all accounts? How many days is that currently? --kizzle 04:01, 5 December 2005 (UTC)
- (edit conflict) It's actually quite simple. Every user has an ID number registered (go to your Preferences to see yours), and then, that number is compared with the number of accounts created (there is a MediaWiki variable to find that, but I don't remember which one... it is visible on Special:Statistics). If
$numberOfUsers * 0.99 < $userID
, then the edit is disallowed. Titoxd(?!? - did you read this?) 04:05, 5 December 2005 (UTC)- If my estimates don't fail me, that is about two days. A user can make 100 edits in the same period of time. Titoxd(?!? - did you read this?) 04:07, 5 December 2005 (UTC)
- 4 days has been indicated above, so you're in the same ballpark. It will decrease over time, of course, so we might need to fix the number of days rather than the %age.-Splashtalk 04:08, 5 December 2005 (UTC)
- If my estimates don't fail me, that is about two days. A user can make 100 edits in the same period of time. Titoxd(?!? - did you read this?) 04:07, 5 December 2005 (UTC)
- Regardless, we probably should have both an edit count check along with a time limit, so whether that time limit is a certain number or simply the amount of time that equals the newest 1% of articles, that is debatable, but we do need both checks to be in effect to effectively combat vandalbots and for other people who simply register an account, wait a few days, then start vandalizing. We want them to both wait and have to make valuable contributions before they can edit these pages. --kizzle 04:11, 5 December 2005 (UTC)
- That is too taxing on the MediaWiki software. The first section on this page was written by a developer. Titoxd(?!? - did you read this?) 04:22, 5 December 2005 (UTC)
- Regardless, we probably should have both an edit count check along with a time limit, so whether that time limit is a certain number or simply the amount of time that equals the newest 1% of articles, that is debatable, but we do need both checks to be in effect to effectively combat vandalbots and for other people who simply register an account, wait a few days, then start vandalizing. We want them to both wait and have to make valuable contributions before they can edit these pages. --kizzle 04:11, 5 December 2005 (UTC)
- Only in the current implementation. Do we want to do this right, or do we want to do this the easy way? --kizzle 04:35, 5 December 2005 (UTC)
- We want to do it the way it gets done. If we require a change in the MediaWiki implementation, that is a sure way of getting our request way on the back burner... :) Titoxd(?!? - did you read this?) 04:47, 5 December 2005 (UTC)
- Titoxd beat me to it. The devs aren't going to implement this anyway; they don't respond to requests, but we might at least persuade some newbie-dev-to-be to take it on. -Splashtalk 04:48, 5 December 2005 (UTC)
- Oh, Splash, look at Special:Cite (a feature request) and this diff, they do reply. Titoxd(?!? - did you read this?) 04:52, 5 December 2005 (UTC)
- I have absolutely no idea why Jimbo isn't participating in this discussion. It's not like this is a fringe debate over a technicality in Wikipedia, this should have been considered from the very beginning given Wikipedia's increasing amount of visibility within the public. I think we should do it right, and then gather enough people to make it happen, rather than put forth shoddy policy. Concerns over realistic constraints such as execution time are valid, but if that is purely because the current way just needs to be re-done, then that's not a excuse not to do it. If we get this policy hashed out and get around 100 support signatures and innundate Jimbo's page with this, I think its priority will get upgraded. --kizzle 04:52, 5 December 2005 (UTC)
- Because Jimbo is a very busy man. I'm not sure that innundating his page will do anything but keep him away from this. If he's interested, he'll come. Otherwise, this is up to us. --Woohookitty(cat scratches) 06:20, 5 December 2005 (UTC)
- Titoxd beat me to it. The devs aren't going to implement this anyway; they don't respond to requests, but we might at least persuade some newbie-dev-to-be to take it on. -Splashtalk 04:48, 5 December 2005 (UTC)
- We want to do it the way it gets done. If we require a change in the MediaWiki implementation, that is a sure way of getting our request way on the back burner... :) Titoxd(?!? - did you read this?) 04:47, 5 December 2005 (UTC)
- Only in the current implementation. Do we want to do this right, or do we want to do this the easy way? --kizzle 04:35, 5 December 2005 (UTC)
- Actually, calculating if someone is in the latest 1% of users is as simple as performing a single database query (getting the date of account creation from the users db). Calculating the total amount of edits from a user could potentially take hundreds of database queries. The new guideline is much more technologically feasible. --Cyde Weys [u] [t] [c] 07:03, 5 December 2005 (UTC)
- This may be how it is at present (I'm not quite sure), but it surely doesn't have to be that way. For instance, give each user an editcount field in the relevant database table, and update present count+1 every time the user does an edit. It's one extra read call, one extra write call per edit, which will increase server load; no idea how much. A small difficulty would be getting the past edit counts at the point this is set up; it might slow the system down a lot when people first log in on the new system and the long-winded editcount query has to be run for each one; but it would be a one-time problem. Rd232 talk 09:10, 5 December 2005 (UTC)
- The number could be cached and recalculated at regular intervals. It's probably a good thingtm if there is a delay between the 50th edit and granting of trusted status. Which raises the question, how do we 'untrust' a user? Ben Aveling 10:46, 5 December 2005 (UTC)
- This may be how it is at present (I'm not quite sure), but it surely doesn't have to be that way. For instance, give each user an editcount field in the relevant database table, and update present count+1 every time the user does an edit. It's one extra read call, one extra write call per edit, which will increase server load; no idea how much. A small difficulty would be getting the past edit counts at the point this is set up; it might slow the system down a lot when people first log in on the new system and the long-winded editcount query has to be run for each one; but it would be a one-time problem. Rd232 talk 09:10, 5 December 2005 (UTC)
{starting over} Agreed. If Jimbo wants to come, he'll come. Otherwise, someone might want to e-mail him, or IRC him with some general info, and see if he wants to get involved. Otherwise, I've been spamming people who've reverted vandalism on GWB with my own template, {{User:Mysekurity/Semi}} (always subst'd), if you want, go ahead and use and even modify the text, I don't mind. As long as we can get as many people here as possible to chip in. Thoughts? -Mysekurity(have you seen this?) 06:26, 5 December 2005 (UTC)
- Let's wait till we get a bit more agreement before bothering the man, I think. Ben Aveling 10:46, 5 December 2005 (UTC)