Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Allow watchlisting of Special:Contributions/[User] pages

Sub-proposals:

• Proposal for Toolserver prototype
• Shared watchlists and collaboration
• Prototype tool now available
• Upon request only
• Solutions for controlling abuse

[edit=Quintucket (talk) 00:07, 27 January 2012 (UTC)]
I notice that every objection centers around the idea that it would make it easier to stalk users. So I'd like to point out two counter-points which have been brought up in the comments:

1. It's easy to wikistalk a single user. What this proposal would do is allow the watchlisting of a lot of users, which isn't a tool wikistalkers need. They already have what they need, which
2. There's no need to allow watchlisting of registered users. Logged-in vandals are generally dealt with in a timely manner; it's mostly the IP vandals who slip under the radar. [/edit]

I'm surprised this isn't on perennial proposals, but the upside is it means I get to suggest it without (I hope) looking like a total ignorant. I've noticed that the vast majority of anti-vandalism efforts are given either by Cluebot, or with an automated tool like Huggle or Twinkle, which apparently allow first-level warnings. This means that persistent vandals will get a lot of warnings, and often get "final" warnings followed a month later by more first-level automated warnings only. But the users with earlier final warnings in the last year or so I can at least report at AIV. Even more problematic are the users who rack up a large number of first, second, and occasionally third-level warnings, but never get to a final edit. (I generally give users who fit this criteria a third or fourth level warning in line with the total warnings they've accumulated in the past year. I'm not sure this is fully Kosher, but I feel it's completely warranted.)

So I try to check recent changes manually and find these persistent users, and watchlist any pages they've vandalized. This isn't exactly the best way to go about it, and I rarely catch new changes by these vandals, but I don't know if it's because they stop (unlikely in many cases), or because they move on to other pages. But if I could watchlist Special:Contributions pages directly, it would let me follow those persistent vandals without keeping them in a text file (which I've thought about, but I'm lazy, and I've already got quite a large non-vandal to-do list in another file).

While I know this would require software updates, I'm hoping that enough people would appreciate this feature that it can gain the consensus to suggest at Bugzilla. --Quintucket (talk) 10:50, 26 January 2012 (UTC)

WP:STALK. I don't think I can agree that this would be beneficial, however useful. --Izno (talk) 13:20, 26 January 2012 (UTC)

• Oppose: While I acknowledge the advantage of watchlisting vandals but this will have much adverse affects on the constructive contributors who regularly get hounded or stalked. --lTopGunl (talk) 13:29, 26 January 2012 (UTC)

• (edit conflict)Yes, with what Izno points out, and the substantial changes needed to software (I think) to "subscribe" to specific versions of what is a virtual "Special" page, I can't see this gaining much traction. There are so many "stalking" concerns it would be bound to open up, and truly, I share some of them. I think you're stuck with another way of doing this if you need to do it legitimately. Begoon ^talk 13:35, 26 January 2012 (UTC)

• Oppose (reluctantly) Whilst I've often experienced the very same frustration as Quintucket, and have regularly (daily, even) thought how useful this feature would be, stalking vandals' edits shows a failure to assume good faith. We have to assume that they won't reoffend once warned - even if they almost invariably do. Yunshui 雲‍水
  • I don't think I follow the reasoning here. By this logic, we also shouldn't watchlist or protect any commonly vandalised articles, AGF they won't be vandalized again. That's really the exact reason why we would want to watchlist recurring vandals, for the very likely case they will again. —  HELLKNOWZ  ▎TALK 14:16, 26 January 2012 (UTC)
    • We can also remember something that Jimbo pointed out: "our social policies are not a suicide pact." I always try to assume good faith whenever there's any doubt, even with users who add anti-Semitic comments to articles (this is a real example, I tried to reach out to the user). But some vandalism is pretty damn obvious, like adding nonsense or spam. When you see a user who has a long history of vandalism, it's pretty clear that the vandalism will continue until the IP is reassigned or the user grow up.

On the other hand, if a user has a history of non-constructive edits, even if they seems to be in good faith, it runs up against competence is required. I've seen many users who persistently add biased or verifiably inaccurate information despite warnings to stop, and I assume that they genuinely believe they're improving the encyclopedia. When I see these users, I try to add text to whatever template I'm using (this is another reason I refuse to use scripts). These users in particular it makes sense to monitor, because they can become genuine Wikipedians. (I'm a minor case-in-point; my 2004-2005 contribs tended to reflect an anti-Boston bias that I've now outgrown.) Is it better to have Huggle users templating them until a non-script-using user gets fed up and reports them, resulting in a block, or users who can monitor them and attempt to talk to them? --Quintucket (talk) 17:02, 26 January 2012 (UTC)

• Weak oppose. There are very many vandals from different IPs/usernames and some recurring individuals could use an oversight. But I don't think the ability to follow their edits arbitrarily outweighs the enabled misuse of the feature for WP:STALKing. I might consider this if users/IPs were "watchlist-tagged" by sysops. But this does sounds a little WP:SHEDy. —  HELLKNOWZ  ▎TALK 14:16, 26 January 2012 (UTC)
  • Support after reading other arguments. Stalking is probably not as big of a deal, and stalkers already stalk contributions, this will only make it marginally easier. On the other hand, this is very useful for rarely-editing users/IPs so every one doesn't need to be checked manually. Although I'd like for there to be a way to be excluded from this in cases of obvious stalking. Or some other kind of restriction. —  HELLKNOWZ  ▎TALK 17:44, 12 February 2012 (UTC)

• We can implement this feature for IP contributions only to indeed avoid stalking. Then it will make sense for static IP with recurring vandalism issues.--Ymblanter (talk) 14:32, 26 January 2012 (UTC)
  • Really? I think you first need to establish that an IP editor is less entitled to protection from "stalking" than a registered (still possibly anonymous) username. Begoon ^talk 14:38, 26 January 2012 (UTC)

    Well, this is obviously an issue for discussion, but did not the community decide to have higher level of protection from IPs by for instance restricting them to be unable to create new articles? I am not sure the community would support the idea, but I do not think it should be outright rejected as being in contradiction to the five pillars.--Ymblanter (talk) 15:00, 26 January 2012 (UTC)

How about sysops being able to tag only the vandals who can then be watchlisted or monitored through RSS feeds? --lTopGunl (talk) 15:02, 26 January 2012 (UTC)

If they are vandals, why aren't they already blocked? --Jayron32 15:13, 26 January 2012 (UTC)

Because we are talking about recurring IPs. They may be blocked for 6 months, then return after two more months and start vandalizing articles until caught and re-blocked. This could facilitate catching them on time.--Ymblanter (talk) 15:35, 26 January 2012 (UTC)

Aren't we getting a bit close to being back in HELLKNOWZ's WP:SHED, by now, though? Begoon ^talk 16:36, 26 January 2012 (UTC)

RSS feeds are already available for everybody about everybody! I'm already stalking some person by this! mabdul 22:15, 21 March 2012 (UTC)

• Without regard to the supposed moral hazard this presents, I'm not sure that this is technically feasible using the way that watchlists work. Actual "pages" in Wikipedia consist of text which is only changed when someone changes it; the text itself is stored in the database, which is why it can be watchlisted. "Special" pages do NOT consist of existing text, the "special" pages simply pull info from a database and the page is generated on the fly; there's nothing for one to "watchlist" because the things the watchlist looks for (changes to stored text) don't exist in "special" pages. I don't think this is implementable easily. I suppose it could be kludged by the devs, but it isn't something as easy as flipping a switch. --Jayron32 14:46, 26 January 2012 (UTC)

That's why I observed that it might be difficult. However page-protection already shows up in watchlists, and then there's the watchlist itself. It would seem to be a relatively simple matter of transcluding (not the right word, I know), any new user contributions to the Special:Watchlist page, as they would appear on the Special:Contributions page. --Quintucket (talk) 17:07, 26 January 2012 (UTC)

I support the principle here, and know of times myself it would have been useful, but also am worried about the potential for abuse in the form of stalking and hounding. Maybe it could say only work on newbies with >50/25 edits, or something along those lines. Could also be useful for adopters and mentorers to track their adoptee/mentoree easily. I'm not sure if this could be technically implemented though. Acather96 (talk) 16:44, 26 January 2012 (UTC)

• In response to some of the comments I've seen above: I think I agree that if created, this should only apply to IPs. One thing I've noticed is that admins seem to apply a lower standard to blocking usernames than blocking IPs (usually on the pretext of WP:EDITWAR, whether the 3RR is violated or not), presumably on the principle that it could affect more people than just the vandal. And it seems to me that the vast majority of persistent registered vandals are spammers, who can be safely indef-blocked, while most IP vandals seem to have no such external agenda.

The other point I'd like to make is that I've seen a number of cases where problematic IP edits have gone unnoticed for months or even years, and I'm sure there's more we've all missed. All it takes is for a bot or user to revert vandalism by one IP but not the one that preceded it, or for a user to make another edit that hides the edit from most watchlists. (I doubt that the vast majority of recent changes get patrolled by a human user, even one using a script.) Usually these are blatantly POV statements or factual inaccuracies (often inserted in front of an already cited source), which while not technically vandalism, though these users will often have edit histories that contain genuine vandalism. Presumably if users who reverted the obvious vandalism were able these users, these seemingly valid edits would be subject to stricter scrutiny. --Quintucket (talk) 17:22, 26 January 2012 (UTC)

• Comment: I am more than a little puzzled by the fears expressed here about people misusing the capability proposed. On the one hand, there is nothing to prevent anyone from looking at the contributions of a given Wikipedia user at any time so this will hardly be opening up some kind of Pandora's box. On the other hand, I recall that there is some javascript that can be added to a userpage to do exactly this (a search of common tools would probably find it, although I can't be bothered). (On a slightly different note, "stalking" is a serious form of personal harassment which is often criminal - looking at what someone edits on Wikipedia is not stalking by any reasonable definition and the overuse of the word does a disservice to victims of real-life stalking.) Delicious carbuncle (talk) 17:55, 26 January 2012 (UTC)

• Support the idea, although its implementation might not be doable inside the current Special:Watchlist functionality. I don't find arguments about the dangers of stalking to be at all compelling. Stalkers already have a single page where they can see all of their target's contributions, so it's merely a matter of convenience. Stalkers are obsessive and they're already stalking without this tool, so this proposal would only change things for actual vandal fighters who don't watch vandals as closely as they might if it were easier to do so. — Bility (talk) 18:01, 26 January 2012 (UTC)

• I have thought of this too, and here is a perfect example of an IP where this would be needed: User:173.168.93.7. This editor has put in guerilla vandalism across dozens of articles before getting noticed and having the vandalism removed. The editor was blocked 5 times, and as soon as the block is over, the exact same type of vandalism starts again. Now, if we had this tool, I would easily see when this person started editing again, and check to see if they were up the same same shenagins, and perhaps nip the issue in the bud before too many articles were disrupted. Currently, I'd literally have to mark a calender to check the IP once the block is lifted. Angryapathy (talk) 18:41, 26 January 2012 (UTC)

• Comment I watchlist the user pages of some vandal IPs, and when I see Cluebot, et al., leave additional warnings I'll double check to see if they have committed enough vandalism to warrant a block.   Will Beback  talk  20:11, 26 January 2012 (UTC)
• Oppose I can appreciate where the nominator is coming from, but suspect that this will create problems - particularly an increase in unconstructive wikistalking - more than it will bring benefit.--JayJasper (talk) 20:20, 26 January 2012 (UTC)

As another user noted above, stalking users is already possible through the Special:Contributions page. It's also possible to watch vandals the same way, of course. The difference is that fighting vandals effectively requires the monitoring of many pages, while stalking a user requires the monitoring of only one or two. Also, as noted, there's no reason to allow watchlisting of logged-in users. The actions of logged-in users already tend to be subject to stricter scrutiny, I think in part because they're easier to recognize than an IP number, and in part because blocking a user will only affect that user, whereas blocking a vandal may affect other users. --Quintucket (talk) 23:27, 26 January 2012 (UTC)

• Support as a userright - Mentors may find it useful, but its potential for abuse requires it to be a restricted function. Jasper Deng (talk) 06:42, 28 January 2012 (UTC)
• I actually made a userscript that did this years ago - it would take any user pages on your watchlist, then put those names into the wikipedia api, get out their recent contributions then display the results in a formatted list. Unfortunately the api then changed significantly and I haven't had the chance to rewrite the script accordingly. I understand the concerns that people could get stalked - I don't know how big a problem it is but surely the solution to that would be to either restrict access to contributions pages (which is never going to happen) or to just make people more aware that anything they post on here is public, and hence to avoid posting anything they later regret. Even if people here aren't keen on a feature like this, it's perfectly possible for third party websites to implement this sort of thing. Tra (Talk) 17:54, 28 January 2012 (UTC)
• I like the idea, but am concerned that it might be abused for WP:HOUNDing. On the other hand, I've done it myself on occasion with nothing more complicated than a simple bookmark. WhatamIdoing (talk) 21:28, 28 January 2012 (UTC)
• That's my workaround as well -- I make bunches of bookmarks of potential problem-user contribs (typically new user names that remind me of banned users, or historically troublesome IPs, things like that) and then periodically open them all in tabs. Easy to do, requires no software update. Antandrus (talk) 04:24, 29 January 2012 (UTC)
• User contributions can be pseudo-watchlisted through RSS feeds - eg this. It's slightly clumsy (you have to use an RSS reader) but it does work (and it can scale as a long-term solution for mostly-inactive users). Shimgray | talk | 12:03, 29 January 2012 (UTC)
• Support the idea although I don't think it will be implemented any time soon: devs discussed this since 2004 in mediazilla:470. In another project I'm currently using my userscript similar to Tra's above but utilizing browser localStorage. — AlexSm 22:34, 30 January 2012 (UTC)
• Strong support – Enough with the "stalking" crap. Stalkers don't need extra tools to stalk—they are already stalking just fine. (By the way has anyone actually looked at WP:STALK recently?) This is a feature that I have wished for for a long time, and it would be extremely useful. Currently I have a list of a few users and IPs that I try and check up on every so often, but it's pretty difficult without a feature such as this. It seems more like something that would be on the toolserver at least initially, since the toolserver is where most hacked up tools like this go, but this would be a very useful feature to be integrated into MediaWiki. It also fits with the ideology here of openness and usability. I was just thinking of this recently and how it would be similar to the concept of Linux filesystems, where everything, including devices, act as a file and can be addressed as such (procfs, device files, etc.) The watchlist is not a "page" in and of itself; it's more of a "virtual page", so any action performed with/on it that treats it like a "regular" page will involve some type of abstraction layer. We already have crosswiki contributions tools (here is one) on the toolserver which compile contributions from multiple wikis into a single page. I'm a little surprised that watchlisting of contributions has not already been implemented, as it is simply one of the next logical steps in the ideology of how improvements to the usefulness and usability of Wikipedia/MediaWiki are made, and it also fits very well with the open source software mindset as a whole. The idea of having such a feature be limited to being used by or used on specific users is preposterous. Everyone's contributions are already public; it does not make an ounce of sense to make a feature with takes public information and makes it more useful in a way that anyone could do themselves manually or with a script and then make that feature a restricted or private feature. There is no reason to add extra complication to a feature just because it is new when every other similar feature is publicly available and unrestricted. —danhash (talk) 18:17, 31 January 2012 (UTC)
• Support. The benefits of being able to watch for frequent vandals far outweigh any supposed danger of facilitating Wikistalking, and if we really want to prevent users from abusing this feature, why not give it only to autoconfirmed users in good standing? ZZArch ^{talk to me} 22:46, 31 January 2012 (UTC)
• Oppose - It's not good to trace a user's edits. I think it will be approach more to Wikihounding than patroling. ●Mehran ^Debate● 09:45, 5 February 2012 (UTC)
  • The contributions feature has been and will be available. Your opposition is to the entire idea of tracking contributions, which the community and the software already support. Your comment is not about the proposed feature and is therefore not relevant. —danhash (talk) 15:37, 7 February 2012 (UTC)
• Support for both IPs and registered users. It's not uncommon for warned users to "lay low" after receiving a warning, and return to vandalizing a few months later. There are several occasions on which I've failed to follow up on users after giving them a "I will block you if this behavior continues" warning because it's too much trouble. In the past I tried adding links to users' contributions to my user page for my own convenience - I'm not sure if making the list of watched users public encourages or discourages hounding, is this a good idea? If the devs aren't amenable to it, I might consider implementing a Toolserver tool for this, which would be quite simple and probably isn't against the privacy policy. Dcoetzee 22:10, 5 February 2012 (UTC)
• Support I would use this for the students in the classes for which I am an online ambassador. Then I can provide more timely assistance when they actually edit. There already is somthing for this on the tool server, but it is pretty locked down so that it takes a while to get new stuff in. I don't mind if it is a userright or available to everyone, the information is there already, it makes it quicker to access. Graeme Bartlett (talk) 01:44, 6 February 2012 (UTC)
• Support - it's already possible to follow a user's contributions, this proposal would only make it slightly easier to do so. I think the concerns about 'wikistalking' are outweighed by the potential benefits of keeping an eye on vandals and other problematic users. Robofish (talk) 17:29, 12 February 2012 (UTC)
• Oppose It will nearly be flooding a user's watchlist if the user whose contributions are being looked upon edits too frequently. Dipankan ^{In the woods?} 15:44, 16 February 2012 (UTC)
  • The proposal as I understand it was to show only the most recent edit of each of the watched users, which would obviate this problem. Dcoetzee 13:50, 18 February 2012 (UTC)
• Support' I'd certainly find this useful in fighting vandalism. We can deal with stalkers, that's not a good reason not to make this tool available, particularly if it is a userright that we can grant or withdraw rather than a default. Dougweller (talk) 09:57, 21 February 2012 (UTC)
• Comment: Not that I think this tool would enable more stalking, but perhaps if its implementation were very transparent it would help assuage some of these concerns. If the users/IPs being watched were visible on one of the monitoring user's subpages, anyone could see who they're watching and stalking can be easily identified. Likewise the addition of a "Who is watching me" link in the toolbox would be helpful for quickly finding everyone who has you watchlisted. Since it hasn't been created yet we can make a wishlist for the development of the tool, right? — Bility (talk) 14:49, 21 February 2012 (UTC)
• Support. I'm surprised nobody has pointed out that such a tool would likely improve collaboration? WikiProject members, for example, would probably like to know "what everyone else is up to", because it might be fun to join in and help out. Wikipedia is all about collaboration, right?! Mlm42 (talk) 22:08, 21 February 2012 (UTC)
• Support The marginal increase in convenience to wiki-stalkers–nothing unless they are stalking multiple users–is worth the potential for fostering collaboration, as Mlm42 points out, and for adoptors and mentors monitoring the edits of their charges. I wish this sort of option had been easily available when I did more adopting. Danger ^{High voltage!} 01:44, 24 February 2012 (UTC)

  Ah, and I didn't even think of the wonders of being able to watchlist the contributions of corporate/institutional accounts that appear to be abandoned to make sure that they stay abandoned. That would be super for work at WP:UAA. Danger ^{High voltage!} 07:30, 24 February 2012 (UTC)

• Support. This would come in very handy in several ways. One common scenario is a newly-created account that vandalizes a couple of articles, is warned, then stops... for a while. Being able to add their contributions to your watchlist and getting a heads up when and if they resume editing would be extremely helpful. Another case is for long-term IP blocks; it'd be nice to see, when the block expires, whether it served its purpose or another block is needed. The advantages of such a feature far outweigh any downsides, in my view. 28bytes (talk) 02:31, 24 February 2012 (UTC)
• Support My initial concerns are minor compared to the good reasons given for support. Begoon ^talk 02:43, 24 February 2012 (UTC)
• Support. I've often wished we had this. Would be really useful keeping an eye on persistent spammers, whose edits are often not spotted for long periods. I agree that it might be best as a userright that could be withdrawn if an editor is found guilty of hounding/stalking. Not necessary to be a userright, wouldn't be as useful for stalkers as standard Special:Contributions is already.  ⊃°HotCrocodile…… + 02:46, 24 February 2012 (UTC)
• Support - I have wished for this feature and think it would significantly improve our ability to locate and control vandalism. Some ideas for addressing concerns of abuse, if we need that to achieve consensus, (my support is not contingent on any of these):
  • make it an assigned userright (per Jasper Deng),
  • automatically expire watches after N (30?) days,
  • restrict watching to a limited subset of accounts, e.g. accounts with recent level 4 warnings and recently expired blocks.

Jojalozzo 03:45, 24 February 2012 (UTC)

• As noted above, we already allow contributions to be tracked via RSS/atom (e.g., [1]). So there is a precedent for methods to more easily "track" edits. /ƒETCHCOMMS/ 06:22, 24 February 2012 (UTC)
• Comment: From Wikipedia:List of Wikipedians by number of edits, I selected the 10 most prolific named users and made a link to each one's contribution page. Together the 10 links constitute the following list.

• Special:Contributions/Koavf
• Special:Contributions/Bearcat
• Special:Contributions/Rjwilmsi
• Special:Contributions/Waacstats
• Special:Contributions/Woohookitty
• Special:Contributions/Ser Amansup;tio di Nicolao
• Special:Contributions/Dr. Blofeld
• Special:Contributions/Alansohn
• Special:Contributions/Hmains
• Special:Contributions/Tassedethe

Any Wikipedian wishing to make such a list can easily do so. (Here is a link to Special:Contributions/Wavelength.)

—Wavelength (talk) 17:53, 24 February 2012 (UTC) and 19:53, 24 February 2012 (UTC)

• Support. I think that this has become a very interesting discussion. My first reaction had been to oppose out of concerns about hounding, but I've been won over by how useful this could be, both for monitoring problem users and for collaborative projects. I like the ideas of making it a user-right assigned, on request, by administrators, and of having a "who watches here" link available, as two ways of combating misuse. --Tryptofish (talk) 20:32, 26 February 2012 (UTC)

• Oppose Yes, I agree it would assist in tracking problem users. With that said, what about the editors in good standing. Why should they be subject to unnecessary stalking? The potential negativity of this greatly outweighs the potential benefits. Alpha_Quadrant (talk) 20:55, 26 February 2012 (UTC)
  • It's been my observation that stalky types tend to focus on a small handful of editors, often just one or two. They can easily do that now by bookmarking the contributions pages of their targets; are you concerned that these people will expand their stalking to more editors with this feature? 28bytes (talk) 00:34, 27 February 2012 (UTC)
    • I believe it could be possible such a feature would increase stalking problems. Right now, in order to stalk an editor, you have to look up their contributions page. Most editors don't constantly stalk another user's contributions. Additionally, you really can only stalk one person at a time. Even if you used multiple tabs, you wouldn't be able to look through several editor's contributions at once. Adding a feature to the watchlist, allowing someone to bulk watch editors, makes stalking extremely convenient. While it might be useful for watching vandals, it would be highly prone to abuse. Particularly during heated content disputes, making it more likely for a dispute to spill out into multiple articles. Alpha_Quadrant (talk) 00:58, 27 February 2012 (UTC)
      • It could be abused, I agree. I'd hate to lose a useful feature just because people might abuse it, though; there's a case on AN/I right now where action is being tabled because the editor has stopped editing (for now, at least). I would be really helpful to know (without having to remember to check their contribs manually every few days) when they're resumed editing so the issues with their editing can be addressed. 28bytes (talk) 01:26, 27 February 2012 (UTC)
        • I often track multiple users in multiple tabs, while doing other things totally unrelated to Wikipedia, without breaking a sweat. It is already not at all hard to "stalk" multiple people, and this feature would have many very useful legitimate uses. —danhash (talk) 20:58, 28 February 2012 (UTC)

• Support per 28bytes. Eagles 24/7 (C) 04:43, 27 February 2012 (UTC)
• Support as a useful tool to monitor for trouble; suggestions for restriction to IPs are misguided, as plenty of vandalism comes from user accounts, and spammers, COIs, SPAs use accounts too. An ability to only show all fresh edits would be very helpful. Extending this convenience to all editors will have a dramatic net good. Josh Parris 03:03, 28 February 2012 (UTC)
• Support I already use externals tools to do this, not least to follow what people I collaborate with on certain projects are doing, so I can assist, and avoid duplication of effort; the proposal would make life much easier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 28 February 2012 (UTC)
• Support; a tool like this could be quite useful. Personally, a lot of the areas I work in involve editors who aren't outright vandals or perfect editors, but somewhere in the grey area inbeweeen, and a tool like this would be helpful (though I already use a certain offsite tool, that's not a perfect solution). For instance, dealing with educational projects (lots of new student editors).
• Support I really don't see the stalking concerns. I've seen a few vandals start editing dozens of pages as soon as they are off their block before being blocked again. If this tool was available, anybody who reported that user could immediately see when the edits start and check if they are indeed vandalism. At worst, it would prevent editors from having to check dozens of edits in this case. At best, it could prevent guerilla vandalism from staying on pages when no one notices it. Angryapathy (talk) 17:17, 8 March 2012 (UTC)
• Support. Increases effective openness and accountability within WP. Vague concerns about "wiki-stalking" are unconvincing--editing here is not a private act, and any abuses should be handled after the fact, in the normal WP fashion. --Hobbes Goodyear (talk) 02:58, 10 March 2012 (UTC)
• Support. Very useful for vandalism response and at the same time this tool would also allow to help new editors out. No violation of AGF here - at that point then we should stop Huggle highlighting contribs from warned users. Should not really limit to any user group, it would just create another status for no real reason: anybody can check other user's contributions already. --Mark91it's my world 13:30, 12 March 2012 (UTC)
• Support but ONLY for IPs and redlinked accounts. (Easy way for a registered user to not have this work on them: edit their user page.) I also agree that this should be a userright handed out like rollback. (Wikihounding concerns don't seem enough to prevent this tool, but I think they are enough to prevent widespread access.) And further, admins should be given a userright to view who may be watching someone's contributions, for transparency. - jc37 23:15, 13 March 2012 (UTC)
• Support, RSS is already available! mabdul 22:15, 21 March 2012 (UTC)

Proposal for Toolserver prototype

One way to try out this feature before asking the devs to do it, and get much earlier feedback on how useful it is and how to refine it, is to implement a Toolserver tool where you log in (with TUSC or a separate account) and add users to your user watchlist. For the sake of transparency these user watchlists would be public, and you would be able to easily check who is watching a particular user. Just like the normal article watchlist, edits would be shown in reverse order by date/time, and only the most recent edit by each user would be shown (with a link to their full contributions on-wiki). To make it easier to use, a custom Javascript tool could be built to add to user pages a link reading "add this user to my watchlist". I plan to do this and it shouldn't take very long, but would like to get feedback about the design and features. Dcoetzee 19:44, 24 February 2012 (UTC)

That would be great, although I see no need for watchlists to be public. Users could take offense thinking that they are being accused of vandalism or sockpuppetry. But really it's just not necessary. As has been stated, a tool such as this would not add any new information, simply make available information more usable. No use to make lists of watched users public for people to complain about and start asking to be removed from. —danhash (talk) 19:49, 24 February 2012 (UTC)

Well, a number of the supporters above noted it could also be used for collaboration, for Wikipedia in the classroom, for helping newbies, or even a mentor who they follow to learn from, so I think it would be erroneous for people to infer anything from being on someone's list. A notice to that effect could be included. However, such a feature would have actual uses beyond mere transparency (for example, checking whether someone is already watching a vandal, so you can avoid cluttering your own watchlist with them). Dcoetzee 20:04, 24 February 2012 (UTC)

• Sounds good. davidwr/(talk)/(contribs)/(e-mail) 21:01, 24 February 2012 (UTC)

• This does seem like something best done off-wiki, at least for now. But if it ever does come on-wiki, it should be done "by permission only," sort of like "Friends" on social networking sites. Privileged users such as administrators would be able to bypass this provided it was logged. davidwr/(talk)/(contribs)/(e-mail) 21:01, 24 February 2012 (UTC)
  • There is no benefit of the extra complexity and overhead it would take to implement and support such a permission system. People who want to abuse Wikipedia will do so with or without this feature. Even if this tool was used for stalking/harassment it would likely just make it easier to find such users (their contributions could obviously also be watched). —danhash (talk) 20:53, 28 February 2012 (UTC)

• Added note: I've been considering renaming this to "Followed users" and allow you to "Follow/unfollow" a user. The intention is to make it sound a bit less sinister (e.g. "we are watching you") and suggest a similarity with other websites where following just lets you check out what other people are up to (as in "following your progress"). I know this is a small detail but let me know if you disagree. Dcoetzee 00:50, 25 February 2012 (UTC)

Follow/Unfollow is a bit facebooky. Watch/unwatch is probably the most neutral. Another possibility would be stalk/unstalk, but that brings a negative connotation. "Track" might also work. Alpha_Quadrant (talk) 00:32, 9 March 2012 (UTC)

Well I already went ahead with followed users, but on reflection tracked is probably a bit better. I think current name is okay though. Dcoetzee 00:30, 11 March 2012 (UTC)

Shared watchlists and collaboration

• Perhaps more useful for collaboration would be to allow multiple watchlists per account and allow watchlists to be public rather than private. If I could create a public Special:Watchlist/User:Davidwr/WikiProjectPoland then transclude it into Wikipedia:WikiProject Poland/Watchlist, that would be useful. Even better if watchlists weren't owned by a particular user and could be created directly in WikiProject space. davidwr/(talk)/(contribs)/(e-mail) 21:01, 24 February 2012 (UTC)

  You can do the public collaborative watchlist thing now, using Special:RecentChangesLinked. For example, if you want to watch the pages for the letters of the alphabet, you could just go to Special:RecentChangesLinked/Template:Latin alphabet navbox (because that template links to them all). Anomie⚔ 21:51, 24 February 2012 (UTC)

Prototype tool now available

See http://toolserver.org/~dcoetzee/followedusers/. It requires a TUSC login, but provides a link to set one up if you don't already have one. Please try it out and let me know what you think! There is also now a Javascript extension at User:Dcoetzee/Followed_users.js you can add to place "Follow user/Unfollow user" in your toolbox and add "Followed users" to the upper-right. Please help spread the word about the tool so lots of people can try it out and help test it out! Dcoetzee 12:17, 25 February 2012 (UTC)

Any reason why the tool doesn't allow the following of IPs?  ⊃°HotCrocodile…… + 03:07, 26 February 2012 (UTC)

No, I just forgot to implement that. :-) I've updated it and it now allows following of IPs. Dcoetzee 03:14, 26 February 2012 (UTC)

Upon request only

To avoid abuse, access should only be granted upon a request that will have to be approved by an administrator.

• Support as nom. PaoloNapolitano 20:20, 26 February 2012 (UTC)
• Oppose. Ideas of the feature being abused are pure speculation at this point. If someone wants to harass a particular user by following their contributions, it's straightforward to do that today using Special:Contributions. Anyone could reproduce the tool in a couple hours using the public Mediawiki API, and they will if they're denied access to it (and give it to all their friends). The proposal would require a request and approval process that would involve considerable overhead. Any barrier to using it will result in less people using it, and it producing less benefit. I think a better strategy in the short-term is to simply ask me to ban users who are abusing the tool. Since the lists of followed users are public, you can tell if this is happening. Dcoetzee 02:16, 27 February 2012 (UTC)
• Support Liam987 16:00, 27 February 2012 (UTC)
• Strong oppose as nonsense. Not a single credible argument has been made demonstrating the need for this feature to be limited any more than Special:Contributions is limited (which it isn't). There is no way to keep anyone from making an external tool to do this either, since the entirety of this feature request is based on totally public information. So adding this as a MediaWiki feature and then limiting it will not have the intended effect anyway. Also, it would add completely unneeded complexity and overhead to make it a per-user permission and have a request process. It's simply a bad idea. —danhash (talk) 20:37, 28 February 2012 (UTC)
• Support as I was earlier going to make the same point. Glad to see that there's a section. Aslbsl (talk) 20:42, 28 February 2012 (UTC)
• Comment – People should give actual reasons why they think the added complexity of a user right is warranted. The number of votes is irrelevant; it's the quality of the arguments that matters. So far I have not seen a single good argument for making this a user right, and furthermore it doesn't much matter at this point since it is not currently an available feature of the software. Therefore, what would be helpful is a discussion based on reason and argument, not simply on the number of supporters. —danhash (talk) 17:46, 29 February 2012 (UTC)
• Comment I believe people didn't flesh out their rationale here because it synthesizes discussions already made above, i.e. administrator approval is the remedy for avoiding abuse people mention above. Aslbsl (talk) 18:44, 29 February 2012 (UTC)

• My point, though, is that nobody has given any real argument for the necessity of an admin approval process. Everyone just cries "potential for abuse", like that in itself is any kind of worthy argument at all. Look at rollback: there is an admin approval process for getting rollback, but Twinkle, which anybody can use, has a rollback feature as well. Any user losing his rollback priveleges can still rollback i.e. the approval process is more or less useless. Is regular rollback easier than Twinkle rollback? Slightly, yes. But there is no way to stop someone from using rollback or undo or opening a previous version of a page, clicking edit, then clicking save. The point being that there are numerous ways to do what is essentially rollback without going through the approval process, or even if one loses their approval. The same is true for this feature. It is already possible to do exactly what this tool just makes it a little easier to do. I have pointed this out more than once and as yet nobody has given any actual counter-argument, which gives even more credence to the viewpoint that the "potential for abuse" arguments given so far are not well founded. —danhash (talk) 15:19, 1 March 2012 (UTC)

• I hear what you're saying. My response, though, would be to point out, that despite rollback being accessible in other forms to non-admins, there is still an idea that rollback itself should be an admin privilege. So to here, just because there are ways to accomplish the same task without privileges, doesn't automatically mean that limiting it to sysops is moot. It may be debatable whether any admin rights that are mirrored by other functions need be privileges only granted to some, but that's a different question. Aslbsl (talk) 12:16, 2 March 2012 (UTC)

• Adminship, generally, is not a big deal anyway. I know that may be a contentious issue, but people wanting to weigh in on this particular discussion need to give actual reasons, not just "support" or "oppose". Votes of opposition mean nothing without actual arguments behind them; I don't know how many times that needs to be said. There are still, as far as I can tell, no good, actual reasons given so far for making this proposed feature limited by a user right. —danhash (talk) 22:21, 2 March 2012 (UTC)

• Comment I strongly recommend trying out Dcoetzee's prototype tool. From my use of it, I conclude that a similar on-wiki tool would be a pretty poor tool for stalkers. Only showing editors' last edits cannot be as useful to stalkers as Special:Contributions already is as it shows all edits by their target. I have already found the prototype tool very useful (caught the first edit/vandalism from a vandal just released from a block. Reverted and reported to AIV, result is an extended block, probably saving lots of further warnings before reblocking.  ⊃°HotCrocodile…… + 04:03, 3 March 2012 (UTC)
• Support as a right granted in a fashion similar to rollback. I would characterize rejection of this proposal as comparable to gun laws -- more detrimental to people who would use it legitimately than to those who would abuse it. Stalking is already very easy for those who want to do it, and is a silly reason to eschew the benefits this tool could have for vandal fighters. I used to use Tra's script tool a long time ago, back when it worked, and found it very useful for keeping an eye on known vandals who were smart enough to spread out their edits. Equazcion ^(talk) 14:30, 12 Mar 2012 (UTC)

Comment – But why does this feature need to be a user right? You have not given any argument for why you think abuse will be a problem more than with other features. —danhash (talk) 16:26, 19 March 2012 (UTC)

• Support Whether we like it or not, this has potential problems written all over it. Better to start this way, at least for now. I remember the discussions about the implementation of rollback, and how there were those who said that that should not be a separate userright. I don't see much of a difference in argument here. - jc37 23:15, 13 March 2012 (UTC)

Comment – What potential problems does it have that are so serious as to necessitate the overhead and complexity of a user right? If you have an argument regarding the implementation of this feature, it should be listed here, even if similar arguments have been made before about rollback. I was not involved in the discussion about the implementation of non-admin rollback, but a big difference immediately comes to mind between this feature and rollback: the rollback feature adds a link that in one click instantly causes an action, an action which can sometimes be used in edit wars and disruption; this proposed feature is totally different in that it simply gives people information they already have access to in a more convenient way, and in a way that is quite likely to help deal with vandalism and disruption. —danhash (talk) 16:26, 19 March 2012 (UTC)

Solutions for controlling abuse

Because I realise many participants are concerned about the possibility of the followed users tool being abused, as demonstrated by the discussion above, I'd like to open a broader discussion on solutions to this problem. I've spoken to many people about this and collected a number of very different solutions with different advantages and disadvantages. I'd like to get additional suggestions and preferences. I believe a careful discussion of the issue, and gathering of evidence, should precede a straw poll (per meta:Polls are evil).

• Proposal: An administrator must first approve any user before they can use the tool.
  • Advantages: Low potential for abuse.
  • Disadvantages: High overhead; barrier to use leading to less use; unclear evaluation criteria.
• Proposal: Users who abuse the tool are banned from using it; any administrator can be given the ability to do so; misuse can be detected because followed user lists are public.
  • Advantages: Addresses a problem only where one exists.
  • Disadvantages: The damage may already be done before the abuse is discovered; users may stop following others to cover their tracks. (should log and publicise all follow/unfollow actions?)
• Proposal: Permission-only system: non-administrators may only follow other users with their permission.
  • Advantages: Effectively prevents abuse in most cases.
  • Disadvantages: Prevents non-admins from using the tool in anti-vandal activities. Giving permission may confuse newbies in mentor relationships. Adds overhead and delays.
• Proposal: Allow following of IPs only, or users with very few edits only.
  • Advantages: Would prevent abusive following of most long-term users.
  • Disadvantages: Prevents collaborative uses such as mentor/mentee, or following collaborators on Wikiprojects.
• Proposal: Give only to users with rollback.
  • Advantages: Users with rollback already have some degree of community trust.
  • Disadvantages: Rollback is evaluated according to different criteria, and may not be given to users who don't participate in antivandal but want followed users for collaboration.
• Proposal: Create a new user right for it, which is not given initially but then given by an admin.
  • Advantages: Low potential for abuse; can be given based on criteria specific to this tool; easy to add/remove on-wiki.
  • Disadvantages: Requires config changes to Wikipedia; high process overhead; barrier to use leading to low use; unclear evaluation criteria.
• Proposal: A delay is built in where new edits are not made visible for some number of hours.
  • Advantages: Prevents "pouncing" on new edits made by established users.
  • Disadvantages: Prevents rapid response to vandal activity, or prompt replies to discussion.

Various combinations of these may also be appropriate. Thoughts? Dcoetzee 23:27, 2 March 2012 (UTC)

There is no good reason for any of these proposals. Not a single person has given a single good reason on this page for why this shouldn't be a fully available built-in feature if it is implemented. I can respond point-by-point to each one of these proposals, but this shouldn't really be necessary as nobody has given any reasonable, substantive argument for the limiting of this feature, and I have already responded so several of these proposals elsewhere in this discussion. I do not understand what people are afraid of. There are already so many processes in place for dealing with abuse. The "potential for abuse" arguments given so far are useless as they demonstrate no more potential for abuse than other long-accepted core features. There is no need for any of these proposals and not a single person has demonstrated otherwise. —danhash (talk) 14:49, 5 March 2012 (UTC)

I agree with that - in fact I'm not sure exactly what abuse people have in mind other than a vague uneasiness about "stalking". I'm hoping that this set of proposed solutions will at least provoke thought about exactly what the issue is so we can get a clearer explanation. I do believe certain measures - such as logging all follow/unfollow actions, and allowing any admin to block/unblock a user from using the tool - are perfectly reasonable. Dcoetzee 19:15, 5 March 2012 (UTC)

Every action on Wikipedia is already logged, and admins are already able to block/unblock users based on their actions. If a user is abusing Wikipedia (any part of Wikipedia) for harassment purposes, they are already able to be blocked. Why add more complexity? If a user cannot keep themselves from abusing this or any other tool or feature of Wikipedia for harassment or other policy-breaching purposes, they can be blocked. There is nothing wrong with any user following any other users' contributions. The problem comes in what that users' actions are; if a user harasses another user based on stalking their contributions (using this or any other tool), they can be blocked for harassment without any extra complexity of permissions needing to be added to this tool. Why not log every time a user checks a contributions page and give admins the ability to block users from viewing contributions pages? Contributions are public for a reason, and logs of viewed contributions pages are private for a reason. There is no need to add extra complexity simply because it may be easy from a technological perspective. —danhash (talk) 19:30, 5 March 2012 (UTC)

Administrators should be restricted in what they can get away with

I propose that administrators ought not to be allowed to block established editors until they have themselves made at least 25 per cent of the edits that their victim has. Malleus Fatuorum 01:14, 10 March 2012 (UTC)

"edits" defined as "edit-count"? Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 01:18, 10 March 2012 (UTC)

Yes. Malleus Fatuorum 01:30, 10 March 2012 (UTC)

Seems reasonable to me IMO. Rehman 01:27, 10 March 2012 (UTC)

• Strong Oppose I'm not getting the point you are giving. But I don't think this is a good idea. For example, a sysop with only 5000 edits is free to block a user who has around 50000 edits who is revealed to be a sockpuppet of a banned user, as long as he/she has a very good understanding of Wikipedia policies. Also, wouldn't this be instruction creep, a solution in search of a problem? Narutolovehinata5 ^tccsdnew 01:29, 10 March 2012 (UTC)

Ahhh, I get your point now. Neutral because established users are trusted. However, occasional exceptions might apply in emergency cases. Still, this remains a solution in search of a problem. Narutolovehinata5 ^tccsdnew 02:36, 10 March 2012 (UTC)

Come to think of it, I don't think this will be a good idea. Experience is not by number, it is by quality. Also, there will times for emergency cases, like the Bot example I gave, that could go out of control. How can we block a bot with over a million edits? I think only a few people, if ever, will have the technical capability to do so. Narutolovehinata5 ^tccsdnew 04:52, 10 March 2012 (UTC)

• You kind of elaborate on my point. Any so-called sockpuppet that makes 50,000 edits clearly isn't a problem. The problem is the wanky administrator that wades in without thinking. Malleus Fatuorum 01:35, 10 March 2012 (UTC)

I can think of several administrators with less than 10000 edits who have a good understanding of Wikipedia policy. Also, it's not about the quantity of edits a sysop does, but the quality of the work he does. I think there is an essay about that, but I can't remember. Narutolovehinata5 ^tccsdnew 01:39, 10 March 2012 (UTC)

I can't. Malleus Fatuorum 01:40, 10 March 2012 (UTC)

/yawn at silly timewasting. --Onorem♠Dil 01:41, 10 March 2012 (UTC)

Anyway, my point is, it's not the quantity of Wiki-work, but the quality of it. Narutolovehinata5 ^tccsdnew 01:46, 10 March 2012 (UTC)

• Support, but the word "established" in the proposal is either superfluous, or needs defining. --Demiurge1000 (talk) 01:43, 10 March 2012 (UTC)

I think what he means is established, as in prolific users like TenPoundHammer or WhisperToMe. Narutolovehinata5 ^tccsdnew 01:46, 10 March 2012 (UTC)

I did, yes. Malleus Fatuorum 01:54, 10 March 2012 (UTC)

It seems an unnecessary grey area - if an administrator can block someone and then justify their ignoring this rule by saying "in my opinion they were not established in the same way as prolific users like TenPoundHammer or WhisperToMe are", isn't that a huge loophole? Wouldn't it be better to leave out "established" entirely, just on the assumption that the number of operational admins with less than (say) 2500 edits is going to be near-zero? --Demiurge1000 (talk) 02:10, 10 March 2012 (UTC)

• This seems like a basically good idea, I tend to think that only experienced admins should be blocking experienced users. One potential problem, there is one user with almost a million edits, but there are very few admins with 250,000 edits that could block him (not saying he needs blocking, this is purely hypothetical). Also, would this rule be waived if admins are blocking fellow admins? Mark Arsten (talk) 02:04, 10 March 2012 (UTC)
  • I suppose I will Support this as a guideline, noting that exceptions may apply in extreme cases. Mark Arsten (talk) 02:26, 10 March 2012 (UTC)
• Support: Make sense—someone with four times the edit count of an admin (considering it's hard to become an admin with less that 5,000 edits) without already being indeffed or banned isn't likely here to be a nuisance. It would be respectful of that editor's large contribution to Wikipedia that someone with a likewise vestment in the project make the determination on a block. — Bility (talk) 02:05, 10 March 2012 (UTC)
• Support: In general, Admins have too much power and long-term Editors have too little, this goes towards evening out the balance a bit, although ultimately I think the cure is to require Admins to re-run for Adminship periodically. Until then, we can expect Admins to continue to treat Editors with a lack of respect. StuRat (talk) 02:10, 10 March 2012 (UTC)
• Oppose. If an established user gets blocked, they're free to appeal the block via an unblock request. That will get wider consideration of the block. If a block is to be reviewed, I'd rather it be on the merits of the block (editor's history, was the block preventative rather than punitive, is there an agenda with the block/is the blocking admin non-independent) rather than doing math on edit counts. Besides, edit count numbers can be deceiving due to deleted edits. —C.Fred (talk) 02:30, 10 March 2012 (UTC)

  No self-respecting editor would ever appeal a block. Malleus Fatuorum 02:34, 10 March 2012 (UTC)

  I actually agree there to some degree. I wrote WP:EHP a long time ago along those lines. Back then the appeal process needed work, don't have enough experience with it these days to say if things have changed. Equazcion ^(talk) 01:11, 14 Mar 2012 (UTC)

  Leaving aside, for the moment, the question of whether self-respect is necessary to edit Wikipedia; C.Fred, would you then also agree that (if this proposal were successful) if an administrator's block were procedurally overturned on the basis of this rule, without discussion, by another administrator, then that would be acceptable since the blocking administrator could appeal for the reinstatement of their block at WP:ANI or a similar venue? --Demiurge1000 (talk) 03:51, 10 March 2012 (UTC)

  I never suggested that self respect was necessary to edit Wikipedia, simply that noone with any would ever appeal a block. Malleus Fatuorum 04:23, 10 March 2012 (UTC)

  This is false. Many users have successfully appealed incorrect blocks, many of which were simple misunderstandings. Dcoetzee 05:02, 10 March 2012 (UTC)

  I think you missed the point. What I said was that no user would any self-respect would appeal a block, not that no editor would. Malleus Fatuorum 02:03, 12 March 2012 (UTC)

• Question But what if prolific bots like ClueBot NG malfunction? There would be a shortage of admins to do the emergency block. Narutolovehinata5 ^tccsdnew 02:36, 10 March 2012 (UTC)
• Comment. I'm surprised that Malleus Fatuorum hasn't shown up to address this proposal; He can usually be relied upon to argue stridently against the power of privileged, elite editors who are not governed by the same standards of conduct as the newer, less-experienced, or less-connected. TenOfAllTrades(talk) 02:54, 10 March 2012 (UTC)

  Perhaps you missed the fact that I initiated this proposal? Malleus Fatuorum 03:55, 10 March 2012 (UTC)

  Not at all. TenOfAllTrades(talk) 04:33, 10 March 2012 (UTC)

• Oppose, "victim" is WP:BATTLEGROUND language. And that would make it pretty darned difficult to block, for example, Kumioko (talk · contribs)... --SarekOfVulcan (talk) 04:11, 10 March 2012 (UTC)

  it should be difficult to block, not the knee-jerk reaction. Malleus Fatuorum 04:31, 10 March 2012 (UTC)

  ...my point here being that to make yourself unblockable, all you would need to do would be to perform many automated edits, which would lead to gaming in the worst way. --SarekOfVulcan (talk) 19:12, 10 March 2012 (UTC)

  So you make it so that it has to be done at ANI or something and discussed rather than just leave it to one admin to do a "knee jerk reaction". I don't know whats worse in that statement Sarek. The inferance that Kumioko was just some vandal or that an editor that makes a lot of edits, automated or otherwise, is somehow reduced to the notion they are gaming the system. 71.163.243.232 (talk) 04:12, 11 March 2012 (UTC)

  I see what you did there. UltraExactZZ ^Said ~ Did 01:46, 12 March 2012 (UTC)

  You mean here? :-) --SarekOfVulcan (talk) 03:48, 13 March 2012 (UTC)

• Oppose. Utterly silly. Makes it nearly impossible to block accounts with many edits (no matter how minor), even in the case of a grave offense like (say) uploading child pornography, and does nothing to protect established users from abuse, since sometimes the abusive admins happen to be the ones who also have a lot of edits. Moreover, it would provide an incentive for all users to make more edits at the expense of quality - enshrining editcountitis in policy in any manner is a terrible idea. The correct solution is to provide: 1. a good solution for appealing blocks; 2. desysoping of admins who abuse blocks consistently; 3. a policy which would allow (in certain situations) temporary reversal of a block for the purpose of having a consensus discussion regarding it in which the blocked user can participate. Dcoetzee 04:18, 10 March 2012 (UTC)
• Oppose - edit count is not supposed to be a direct metric of user experience.Jasper Deng (talk) 04:24, 10 March 2012 (UTC)

  Can you suggest a better one? Malleus Fatuorum 04:34, 10 March 2012 (UTC)

Try the number of FAs, GAs and DYKs a person has contributed to. Narutolovehinata5 ^tccsdnew 04:54, 10 March 2012 (UTC)

• Judgment by an uninvolved human who can weigh criteria too numerous to list and come to a rationalized decision. - ʄɭoʏɗiaɲ ^τ _¢ 04:56, 10 March 2012 (UTC)

• Oppose - Sounds like a way for an established editor with many edits to gain immunity from a percentage of administrators. If you're pissing people off, no admin that has been entrusted by the community should be prevented from blocking you based on arbitrary edit counts. - ʄɭoʏɗiaɲ ^τ _¢ 04:53, 10 March 2012 (UTC)

Malleus still hasn't replied to my question. Assuming that this proposal is accepted, how can prolific bots be blocked if they malfunction? What do you think Floydian? Narutolovehinata5 ^tccsdnew 05:03, 10 March 2012 (UTC)

Fatuorum's proposal was likely not intended to target bots, so it's reasonable to assume they would be exempted from the eventual guideline. CharlieEchoTango (contact) 10:24, 10 March 2012 (UTC)

• Question. This isn't a completely bad idea, as it would be a good way of preventing admin overreaching or abuse, but I think it would be extremely difficult to maintain as a guideline or policy. So, my question is this: what if an "established editor" repeatedly disrupts an article, a process, or blatantly and knowingly violates policy to the point where a block is necessary? And what if the admin who's the most available has less edits than the object of the block? dci | TALK 06:13, 10 March 2012 (UTC)
• Oppose, the good judgement and/or (in)competence of administrators cannot be measured in the number of edits, and even if it could, it has little to do with the ethics of an administrator when it comes to blocking established editors. As for judgement, it can only be evaluated after the fact, through the proper procedure. Blanket restrictions are not the answer. CharlieEchoTango (contact) 10:19, 10 March 2012 (UTC)
• Oppose - This would effectively mean that a few long term editors could do what ever they want without any chnace of repremand. Editors should expect to to treated equally.Nigel Ish (talk) 10:26, 10 March 2012 (UTC)
• Oppose Both CharlieEchoTango and Nigel Ish have pointed out some obvious problems. And it's hardly appropriate for someone with as many edits as the proposer (who is currently 93rd) in the list at WP:MOSTEDITS to make a proposal that would leave only a handful of Admins available to block him). And as we know, any editor can suddenly develop problems that can only be stopped by blocking them. By the way, do we really have a system of edit counts that is 100% reliable? — Preceding unsigned comment added by Dougweller (talk • contribs) 11:38, 10 March 2012 (UTC)
• Oppose reinforces vested contributors. Furthermore, does not account for minor contributions and AWB runs and page move warriors, so the metric is useless anyway. (For the record, I have 55,000+ edits and am an admin anyway, so there's only a small handful of editors that I could theoretically not block under this proposal; but ideologically, I disagree with it). --Rschen7754 11:54, 10 March 2012 (UTC)
• There are not different levels of administrators. The RFA process is the time to worry about whether an editor has enough edits to be an admin. Once the editor becomes an admin, the issue of whether they have enough experience is settled. Moreover, the proposed system might give a way for some editors to avoid perfectly appropriate scrutiny. So I would oppose this sort of proposal. — Carl (CBM · talk) 11:58, 10 March 2012 (UTC)
• Oppose. Edit count is not a valid measure. —  HELLKNOWZ  ▎TALK 11:59, 10 March 2012 (UTC)
• Oppose. I think this is sound in principle, but flawed in application/proposal. So an established user blatantly edit warring couldn't be blocked by a new-ish admin if that admin is the only one who happens to have come across the warring? Perhaps a compromise solution is reachable; such as requiring a noticeboard block discussion (although I can see that any admin who would 'meet' any criteria could just take one look at the issue and block). If the issue is about admins with less than a certain number of edits then that needs to be dealt with separately. Instituting an arbitrary percentage cut-off is unnecessary. Strange Passerby (talk • cont) 12:05, 10 March 2012 (UTC)
• Oppose - The motive behind this proposal seems to be Malleus' belief that administrators should abide by the same rules as everyone else and should not be given any special treatment just because of their position. I completely agree. I would also extent that to any editor. All editors should abide by the same rules as everyone else and should not be given any special treatment just because of their position - that is regardless of userrights, length of tenure or edit count. I agree that admins shouldn't be given privileged status; neither should anyone else, including those with a high edit count. ItsZippy ^{(talk • contributions)} 12:46, 10 March 2012 (UTC)

• Support: per nominator's idea and Mark Arsten. The obvious exemptions would be intentional unambiguous, repeated vandalism, per consensus or bot accounts. On any other reasons when an experienced admin isn't available, community consensus should be sought. Some one with four times the experience of an admin would have a rather better judgement than him. --lTopGunl (talk) 13:06, 10 March 2012 (UTC)

• Oppose: A solution looking for a problem. If a particular callow new admin is in the habit of thoughtlessly banning experienced editors, or if one or two of my fellow old-timers is a frequent victim, then it's a particular problem not calling for a new general rule. My habit of making fiddly little changes (picture layouts, geographical coordinates, etc) give me a larger edit count than many admins who tend to larger issues but that's not a reason for exempting me from their power, reasonably applied. And if unreasonably applied, sanctions exist which again have little do do with edit count. Jim.henderson (talk) 13:36, 10 March 2012 (UTC)

(edit conflict)

• Oppose as completely unfeasible. Are we seriously going to make a situation where an admin goes, "oh, I only have 24% as many edits as this person, I can't block them for violating WP:NLT." Malleus, I get that you don't like the current admin culture, but this isn't helping. — The Hand That Feeds You:^Bite 13:38, 10 March 2012 (UTC)

• Oppose: Edit counts have no relationship to knowledge or wisdom. ---— Gadget850 (Ed) ^talk 13:57, 10 March 2012 (UTC)

• Comment Would not a reasonable move be to require all blocks of editors with over (say) 8,000 article and article talk page edits to be vetted by at least two admins at the start? For socks etc. I doubt this would be exceedingly onerous a requirement, but it might stop "quick finger blocks" which have a fair likelihood of being overturned later. Collect (talk) 14:05, 10 March 2012 (UTC)

• Oppose Fails to take account of security issues. Sometimes accounts of long-established contributors get hacked and the person goes on a campaign of vandalism. It's perfectly reasonable to block those however many edits they've got. Also, some of our most long-standing admins have few edits, because way back when, it was a lot easier to pass RfA than it is now, when you basically need 10,000 edits minimum. —Tom Morris (talk) 14:38, 10 March 2012 (UTC)

• Oppose: Tagging articles for wikiprojects can inflate edit counts quickly... one could just get around the idea by spending a little time doing that. Best, Markvs88 (talk) 14:52, 10 March 2012 (UTC)

Constant reversions of others edits also does that Mark with no real improvement to the project. Its obvious your referring to Kumioko but I should remind you that the majority of Kumioko's edits where not in adding WikiProject banners but in mainspace? 71.163.243.232 (talk) 13:06, 11 March 2012 (UTC)

Kumioko (your edit history gives you away, btw), this is no place for personal attacks. You've already gone after everyone else you feel has wronged you, and have now finally gotten around to posting again on my talk page. Please stop hiding behind an IP while sniping at me. My vote has nothing to do with you. Best, Markvs88 (talk) 13:43, 11 March 2012 (UTC)

I am not trying to hide. I closed out the Kumioko account, removed the password and scrambled it so its unrecoverable so any edits I make from this point will be by IP. Thanks to you and a few others User:Kumioko is dead and not coming back. 71.163.243.232 (talk) 14:00, 11 March 2012 (UTC)

"You keep saying those words. I do not think they mean what you think they mean...". (With apologies to Enigo Montoya). Best, Markvs88 (talk) 03:24, 12 March 2012 (UTC)

• Oppose. Silly proposal. Obvious incentive for vandals to do millions of edits. Why are people wasting their tie on proposals like this? Dmcq (talk) 15:36, 10 March 2012 (UTC)

  As opposed to their cravat do you mean? Malleus Fatuorum 03:05, 11 March 2012 (UTC)

• Oppose. If there's some statistic that objectively indicates a person's skill and judgment with some degree of accuracy, this might be a good idea. That statistic is certainly not edit count (and if such a thing were discovered, I think it would be a major scientific achievement). PS. This proposal looks pretty pointed to me. Equazcion ^(talk) 15:44, 10 Mar 2012 (UTC)

  I think you may wish to retract that accusation. Or at least you would if you had even a scrap of honesty. Malleus Fatuorum 03:09, 11 March 2012 (UTC)

I don't wish. This proposal had no shot, and whoever brought it is either stupid and inexperienced enough to think it did, or is just trying to stir the pot. And I know you're not stupid or inexperienced. Equazcion ^(talk) 13:31, 11 Mar 2012 (UTC)

It's quite clear that you on the other hand have done no thinking at all. Malleus Fatuorum 01:59, 12 March 2012 (UTC)

Good one. Equazcion ^(talk) 05:34, 12 Mar 2012 (UTC)

• Oppose. Bad metric, even worse idea. ~ J. Johnson (JJ) (talk) 19:14, 10 March 2012 (UTC)
• This is a case of "I know what you mean but..." The fact is that the dynamic of WP administration, especially admin on admin and established editor on established editor abuse is far more complex than that. Many admins start off all starry eyed and AGFy, and "Blocks aren't punitive" and "Leets make this work" and gradually become jaded. Similarly those with specialist knowledge or skills get tired of explaining the same thing to J. Random editor, especially if they have the social graces of a water buffalo in free-fall. But I do wonder if some kind of "hang on - are you really going to block this editor?" intervention would be a good idea sometimes. Especially with what Jon Vandenberg calls the "First mover advantage" (I.E. some action is drawn to the attention of n admins, where n is a large number - if any one blocks, the n-1 will be reluctant to wheel war). Rich Farmbrough, 02:03, 11 March 2012 (UTC).
  
• Support - I also agree that too many administrators have too much power and too frequently don't use it correctly. They frequently take the easiest possible solution without reviewing the whole problem. In general I support eliminating the role of administrator and replace that role by granting the tasks in sets (like rollbacker, File mover, etc.). 71.163.243.232 (talk) 04:05, 11 March 2012 (UTC)
• Oppose - "Support in theory" not practical to implement. Edit history of editors should be taken into account and explanations pursued before action is taken by an admin anyways.Moxy (talk) 04:52, 11 March 2012 (UTC)
• Oppose - Edit count is no measure of edit quality, it is not even a fair measure of edit quantity. It is quite possible to do 10000 legitimate and uncontested edits with no noticeable quality improvement whatsoever, it is also possible to do only one edit, which nevertheless has significant and lasting value, and which could be quite large. Edit counts per se should be considered almost irrelevant, and not only for this application. If there was a way of measuring actual useful contribution, there might be some value in the proposal. Peter (Southwood) ^(talk): 08:08, 11 March 2012 (UTC)
• Comment - I find it rather ironic and hypocritical that so many editors are saying that edit count is almost irrelevant and yet its required in order to submit an RFA (not written in the rules but try and get it without a large amount), get access to AWB (500 main space) and a whole variety of other things. If edit count was truly irrelevant then it wouldn't be required for those things. I also find it a little argumentative to say things like (if they just get millions of edits) well if they do then they probably should be an admin and there probably should be some pause before they are blocked. Lets not forget that even using tools like Twinkle and AWB it takes a very long time to hit a million edits. As far as I can tell no editor has even done yet after ten years. 71.163.243.232 (talk) 13:06, 11 March 2012 (UTC)
  • Lack of a decent edit count is a pretty good indicator that one doesn't have enough experience, sure. But that doesn't mean the converse should be true (that a high edit count means one does necessarily have any sort of qualification), which is the claim being made with this proposal. Equazcion ^(talk) 16:51, 11 Mar 2012 (UTC)
• Comment. Any metric that involves edit count can be gamed in multiple ways. If the intent of the proposal is to give established users "mulligans" or "Get out of trouble free" cards, then that can be done in other ways. What the proposal says, essentially, is that established users get to breach policies at will, if there's the slightest veil of justification. So if I find an edit war, what do I do? Block the newer user and slap the established editor on the wrist? UltraExactZZ ^Said ~ Did 01:46, 12 March 2012 (UTC)

  That's not at all the intention, and I find it quite telling that your response to coming across an edit war is to issue blocks. Malleus Fatuorum 01:54, 12 March 2012 (UTC)

  Yes, clearly we don't block for edit warring. Ever. But the point stands - all other things being equal, the decision to block comes down to how many edits the editor has, yes? If you don't trust the administrator to exercise judgement, then get them desysop'ed. Bad judgement is bad judgement - and established users can screw up just as easily as new ones. Any policy that would exempt editors from compliance with policy due to any form of "tenure" is unwise, inequitable, and not in the best interests of the project. UltraExactZZ ^Said ~ Did 02:13, 12 March 2012 (UTC)

• Strongest possible oppose. Wikipedia:No vested contributors (an essay, but should be policy, frankly). Robofish (talk) 01:59, 12 March 2012 (UTC)

  That's pretty much one of the daftest essays ever written. Malleus Fatuorum 02:08, 12 March 2012 (UTC)

  I'd never read that essay before, but I'm struck by "no editors are more equal than others". That's a nice and cosy ideal, but it just doesn't match the real world. Is a 10-year-old who doesn't even understand what an encyclopedia is as valuable to the project as a university professor? Is a Korean who can't speak a word of English as valuable as an experienced copy-editor? (I've nothing against either 10-year-olds or Koreans, they're just two actual examples I've come across recently). We should be encouraging the competent and discouraging the incompetent. -- Boing! said Zebedee (talk) 12:28, 15 March 2012 (UTC)

• Oppose, per my comments above. UltraExactZZ ^Said ~ Did 02:13, 12 March 2012 (UTC)
• Oppose - This proposal seems to suggest that: All Wikipedians are equal, but some Wikipedians are more equal than others... Um, no, per many well-explained examples/reasons above. As for edit counting, Peter (Southwood) (and others) said it well and clear enough. - jc37 02:33, 12 March 2012‎ (UTC)
• Fascinating proposal. Of course, if it were implemented, I expect more than one admin would make 500,000 or so script-assisted minor edits to a userspace draft in short order so they could continue to block whomever they like. 28bytes (talk) 05:24, 12 March 2012 (UTC)
• Oppose. Basically, I see this as a proposal from Malleus, who has been blocked 17 times so far, that 70% of the admin corps be disqualified from blocking him. WhatamIdoing (talk) 03:31, 13 March 2012 (UTC)

  You would do well to open your mind. Even ArbCom has recently admitted that an unspecifed number of those blocks were improper. Malleus Fatuorum 03:51, 13 March 2012 (UTC)

  It's a rather telling feature of the inequity here that bad blocks remain in the victim's block log, but there's no record in the blocking admin's log. Malleus Fatuorum 04:57, 13 March 2012 (UTC)

  It doesn't really matter if a few of them were improper. Most editors have a perfectly clean block log, and even if fully of half your blocks were truly improper, then you'd still be on the list of people who have a far longer block log than average. As a result, your proposal still smells like an editor who's been blocked a lot of times trying to cut down on the number of admins who could block him. If that's not your goal, of course, then feel free to propose that we do this and that you personally be subject to blocking by any admin regardless of edit count. WhatamIdoing (talk) 19:11, 13 March 2012 (UTC)

  I reckon preventing 70% of admins from blocking Malleus would be of significant benefit to the project. -- Boing! said Zebedee (talk) 12:17, 15 March 2012 (UTC)

  That it clearly doesn't matter to you WhatamIdoing however many of those blocks were improper I think speaks volumes for your lack of integrity. Malleus Fatuorum 02:36, 20 March 2012 (UTC)

• Oppose. That's a most odd proposal. "Edit count" means precisely nothing. I propose that administrators ought not to be allowed to block content editors until they have themselves made at least 25 per cent of the content contribution that their victim has made (whatever that means). Anyway it is an abysmally stupid system we have here, making "admins" out of all sorts of odd people with no clue about adding value to an encyclopedia, and then allowing them to run roughshod over the people who do contribute. The whole mess has ceased to be a joke, and is now mired in unmovable muck. It's a waste of time trying to shift it. --Epipelagic (talk) 04:17, 13 March 2012 (UTC)
• Oppose Since a minimum edit count at RfA has been rejected by the community a fair few times, is this not just a way of bringing up the same issue? As it happens, I do support a prerequisite for adminship, but after a certain point as a few people have said edit count means very little. I'm not going to say that there are no bolshy admins, but sorting out a community de-sysop should be the focus there. Taking myself as an example (as arrogant as that sounds), I have about 10,000 edits, but I've been around, know policies very well, know my limitations and have a level head on me. I have never blocked an established editor, but the idea that I should be able to block someone with 35,000 edits, but not someone with 45,000 seems like madness. Worm^TT · (talk) 08:56, 13 March 2012 (UTC)
• Oppose - editcountitis. RJFJR (talk) 14:39, 13 March 2012 (UTC)
• Support in principal even if its unlikely to be considered feasible. At least. In my experience I've seen some admins who have contributed frankly nothing to the project in terms of content blocking some of our great content contributors who've done 1000 times the amount of work that they have with a weak blocking rationale. And when I've seen it happen its usually when the veteran is in the middle of doing constructive work or plans on improving the content of wikipedia and the admin hampers them from doing so for the sake of playing cop and saying "I'm more powerful than you are". When that happens, it strikes me as out of place in the same way it would the Grade 7 pupil placing his 60 year science teacher in detention. I'm not saying that some blocks aren't justified but to me the rookies blocking the content contributing veterans illustrates one of the main problems with RFA. Although the problem is edit count as such is not really an effective measure of one's constructive contributions, articles created, however, or good articles would be.Oh and All Wikipedians are equal, but some Wikipedians are more equal than others. That's very true and if you can't admit that that's what goes on in the running of wikipedia... Unfortunately it is wiki lawyering for being "more equal than others" which qualifies, not content contribution. I also believe content contributors with years of experience should be given the authority to overide ips or newbies during moments of edit conflicts and trusted to do so. ♦ Dr. Blofeld 15:19, 13 March 2012 (UTC)
• Oppose Under this proposal there are only 8 editors who I wouldn't be "qualified" to block, and a large proportion of admins wouldn't be qualified to block me. Yet a large proportion of my edits are minor and flagged as such. I don't dispute that blocking of experienced members of the community needs to be done with great sensitivity, but I'm not convinced that this is the right proposal to improve the quality of such admin decisions. Perhaps we should upbundle a few things from admins to crats, starting with civility blocks. ϢereSpielChequers 15:28, 13 March 2012 (UTC)
• I can see the point behind the general idea, but this particular implementation would have all sorts of problems. Chief amongst them is the use of edit count as a metric. Should minor edits be valued equally to major ones? Is someone who takes ten edits to do what others manage in one, thereby massively increasing his/her edit count, a better contributor than those who use preview more conscienciously? What about assessing quality of edits? I just don't see raw edit count with no analysis as a secure enough basis to judge this on. Then there's the issue of strict cutoff points. The range of editors that a particular admin wouldn't be allowed to block would in some cases change frequently over fairly short time intervals, especially where two editors edit at different times of day. The most likely outcome would probably be that the class of power-hungry admins who I'm assuming this proposal is mostly targeted at would just make a lot of semi-automated edits to increase the number of editors they can block, which probably wouldn't be a good thing. Call this a weak oppose of this precise proposal. Alzarian16 (talk) 01:03, 14 March 2012 (UTC)

Oppose Not that I have any desire to do this (I'd probably leave it to someone else anyway) but where would that leave admins like me with less than 10,000 edits? If necessary and if I thought it was worth the headaches it would bring me for days afterwords I don't think I would be incapable of making a good block of someone with a high edit count. Ks0stm ^{(T•C•G•E)} 17:17, 14 March 2012 (UTC)

Upon reading my comment further I should probably clarify. My issue with this proposal isn't necessarily how I would fare as an admin under the proposal, more that edit count doesn't equate with the ability or lack thereof to make well-reasoned, policy based blocks, and that includes of established users. I for one would take much more time and would be much more hesitant to block a very established editor, not doing so without double and triple checking the facts, my rationale, and what effects it would likely have, and in some ways this means any block I were to make of a very established user might very well be one of the more thought out blocks I would make; this is pretty much because I would have such a low edit count compared to the more established user I would be blocking. All in all, in my opinion, edit count differences should not preclude admins from making well-reasoned, policy based blocks of any user, including established users. Ks0stm ^{(T•C•G•E)} 17:44, 14 March 2012 (UTC)

• Possibly Illegal under current US law. There are some Wikipedia editors who are handicapped and can only edit with a mouthstick or a device that scrolls letters by to be selected with a mouth puff. These editors are physically incapable of making a large number of edits. Any policy that discriminates against editors based upon quantity of edits rather than quality of edits could be argued as being a violation of the Disabilities Act. --Guy Macon (talk) 12:18, 15 March 2012 (UTC)

  That's a pretty bizarre interpretation of US law, let's hope that you're not a lawyer. On the other hand, the US has so many more lawyers than any other country on Earth that I suppose they have to have something to argue about, to keep them busy. So long as someone else is paying, of course. Malleus Fatuorum 03:49, 21 March 2012 (UTC)

• Oppose as privileging editors who make many small edits in series rather than using preview and making multiple edits (or, as I often do, creating whole articles ([2],[3],[4],[5],etc.)) in a single edit. The number of edits made says little about the quality of the contributions, only the quantity. (And at #309 on WP:MOSTEDITS, I'd still be able to block all but the top 15 editors so this !vote is not about concern for my own personal ability to block an experienced editor run amok.) - Dravecky (talk) 13:20, 15 March 2012 (UTC)
• Oppose, "long-term editors" should never be granted special treatment of any type. Being a good editor is already far too much of a license for abuse, and that problem needs to be fixed, not made worse. If anything, longer-term editors should be held to a higher behavioral standard than others—they know the rules, so when they're breaking them, they're doing so intentionally. Seraphimblade ^{Talk to me} 17:56, 15 March 2012 (UTC)
• Oppose. Sensible admins have almost no incentives to block useful editors, and non-sensible admins would have perverse incentives to boost their edit count artificially. The problem of non-sensible admins blocking non-sensible but useful editors inappropriately needs the solution "knock heads together", not anything in the way of silly metrics as is being suggested here. Charles Matthews (talk) 19:02, 15 March 2012 (UTC)
• Oppose'. If anything, it should be easier to block problem users, and there are plenty of avenues to appeal a block and plenty of administrators willing to unblock. This would only further entrench long-term problem users. (For the record my comments don't refer to anyone in this discussion or under discussion here.) Gamaliel (talk) 21:39, 15 March 2012 (UTC)

• Oppose A high edit edit count is not a meaningful basis for protecting an editor from a block by an admin with less than 1/4 as many edits. Some editors boost their edit count by a profusion of small edits: add a comma, remove it, add a phrase, move it somewhere else, move it back. Or they chit-chat endless on other editor's talk pages. Or they chime in on every ANI issue or AFD with off-topic or repetitious comments. Or they ask silly trollish questions or make make silly joke responses to questions at Ref Desk. Or they generate thousands of low-value stub article new articles by basically robotically copying from some public-domain book they found online. Someone who hits the "Save" button a lot is not always someone who should be above the law, or who should be blockable only by some admin of similar editing habits. Edison (talk) 04:39, 16 March 2012 (UTC)
• Wikipedia:Don't feed the divas. Malleus, quit trolling. Fences&Windows 21:20, 19 March 2012 (UTC)

  Quit accusing me of trolling asshole. Malleus Fatuorum 21:29, 19 March 2012 (UTC)

  The lack of a comma in your sentence insinuates something else entirely. Killiondude (talk) 21:43, 19 March 2012 (UTC) Logan likes this.

  Only to an American. Malleus Fatuorum 00:41, 20 March 2012 (UTC)

  Reminds me of that Lynne Truss/Robert Sutton book, Eats Shoots and Assholes. 28bytes (talk) 02:49, 20 March 2012 (UTC)

I agree with what Edison says to an extent about the edit count not always being reflective of quality article and article work but I have experienced some situations where editors who have contributed practically nothing to the encyclopedia itself with tools who seem to relish blocking some of the heavy contributors who are not admins because they can do so. That is a problem and in certain situations, especially when it is a veteran editor with years of experience edit conflicting with a newbie, I believe the well established editor's perception on what or what is not appropriate for the article should be taken into consideration. I believe a lot of ANI reports would be avoided if veteran editors who are not necessarily admins at least have some element of trust in them to deal with content issues and stop what they believe is causing disruption to content.♦ Dr. Blofeld 21:39, 19 March 2012 (UTC)

• Oppose- What a silly proposal. I'm no authoritarian, but this is just plain stupid. This would cause even more disruption because it would encourage troublesome editors to dig themselves in by making a whole bunch of rapid crap edits. Reyk _YO! 06:08, 21 March 2012 (UTC)

Counter proposal

Established editors may not be blocked in non-emergency situations without prior discussion.

Ok, so we need to decide what an established editor is, but blocking an editor with more than a few thousand edits is something we should take more care over. If we put this mark at 10,000 edits, we're only talking about 5,000 editors, all of whom should know better. We can put in some safeguards if you like, 3RR, Sockpuppets etc. but I'm talking about the general case. Worm^TT · (talk) 08:56, 13 March 2012 (UTC)

Surely there must be other ways of restricting what administrators can do other than basing this on edit count? My fear is that such a proposal would encourage Wikipedia: Editcountitis. How about making it necessary for more than one editor to be called in for a discussion to decide whether an editor can be blocked? ACEOREVIVED (talk) 15:37, 13 March 2012 (UTC)

Bear in mind, that surely the main reason for blocking edits from users is that they have made a lot of rather stupid edits which would be counted as Wikipedia: Vandalism, which put up their edit count. As some said above, we should be basing decisions such as this on edit quality, not edit quantity. A lot of edits which are examples of Wikipedia: Vandalism would inflate some one's edit count. ACEOREVIVED (talk) 15:39, 13 March 2012 (UTC)

I doubt if we have many vandals who get near enough edits to get immunity under this proposal before they get blocked. Copyvio, plagiarism and running unauthorised bots on their main account, yes that all happens. But when did we last encounter an account committing vandalism after more than a thousand edits? ϢereSpielChequers 15:47, 13 March 2012 (UTC)

The only ways I've seen that happen is when someone wants to stop themselves ever coming back. Support Counter proposal. A vandal who makes a thousand, five thousand, ten-thousand edits before starting to vandalise happens basically never. They're much more likely to become a positive contributor on the way. Remember, we do have reformed vandals.--Gilderien Talk|Contribs 21:07, 13 March 2012 (UTC)

Support this matches well the spirit of consensus and seems free from problems of original proposal. Audriusa (talk) 15:13, 14 March 2012 (UTC)

Counter proposal II - upgrade block/unblock longstanding editors to crats

It is rare that longstanding editors get blocked or unblocked. Amongst our most active editors the two most common types of blocks are admins accidentally blocking themselves and admins accidentally blocking others. We could safely upbundle blocks and unblocks of logged in editors with more than 1,000 edits to our crats without causing them an excess workload, and it would certainly prevent some mistakes. This would mean that established editors could relax about RFA and not feel threatened by admins, at the same time it might reduce our problems at RFA. We do have a shortage of RFA candidates and are far too dependent on a very small number of very active admins, particularly at AIV and RFPP. Upbundling one of the most contentious parts of the admin toolkit makes sense to me, and should be quite easy for the devs to code. NB I'm assuming that this would work on a per account basis, so having half a dozen accounts with a couple of hundred edits each would not reach the 1,000 threshold. ϢereSpielChequers 16:01, 13 March 2012 (UTC)

• That would pretty much put an end to successful RfBs, I'd think. 28bytes (talk) 16:41, 13 March 2012 (UTC)

• And it's not that rare that longstanding editors get blocked or unblocked. All this talk about edit counts made me curious, so I took a look at my admin log. Turns out the last 14 accounts I blocked had edit counts of 158176, 318300, 260, 1, 3, 5, 5243, 6664, 19, 2, 3737, 191, 499 and 125630. 28bytes (talk) 16:43, 13 March 2012 (UTC)

I doubt if I've ever blocked someone with a thousand edits. Such blocks are probably not even a daily event, so I doubt that our current crats would be stretched by them. If they were then very few extra crats would be needed to cover the load. ϢereSpielChequers 16:53, 13 March 2012 (UTC)

If you'll excuse the sweeping generalization, any admin who's never blocked anyone with 1,000 edits probably tends to stay away from ANI drama. In my experience, plenty of established users do get blocked, but you wouldn't know it if you just patrol AIV etc. That's not a judgment -- I try to keep my distance from drama these days too. Equazcion ^(talk) 17:27, 13 Mar 2012 (UTC)

• The issue at hand is not so much with the ability of admins to block established editors, as if they do so for no reason. The issue is with established editors who might edit in ways that deserve a block, relying on their knowledge that someone will step in to unblock them if they do get blocked. The title of the thread ("get away with") already seems to establish a sort of bias about the contents. In general, it is not the admins who are "getting away with" things when these circumstances arise. — Carl (CBM · talk) 17:21, 13 March 2012 (UTC)
  • On the other hand, if only crats were able to reverse blocks that were made by crats, then allowing only crats to perform these blocks might provide some net benefit. The main issue is not really with the blocking, it's with blocking followed immediately by unblocking. The difficulty, of course, is that crats tend to be quite conservative and might always think there is "no consensus". So I still have far to go to be convinced, I'm afraid. — Carl (CBM · talk) 17:43, 13 March 2012 (UTC)
    • That's a key part of the proposal. Yes there will be a little more caution in blocking people and maybe some vested contributors will get warnings instead of blocks. But when a vested contributor is blocked then I'd be surprised if it didn't stick until either the block expired or the blocked editor agreed to make the requested change in their editing behaviour. ϢereSpielChequers 18:43, 13 March 2012 (UTC)
      • So if User:88edits and User:250000edits get in a stupid, disruptive edit war and continue to ignore warnings to stop, I can block User:44edits but have to go find a 'crat to block User:250000edits? 28bytes (talk) 19:06, 13 March 2012 (UTC)
        • Yup. But if the block is justified then I'm sure a crat will act and no other crat will overturn them. ϢereSpielChequers 21:09, 13 March 2012 (UTC)
          • Would I need to figure out which crats are currently online, or would there be an Established Editor Noticeboard manned by crats that I'd need to post to? 28bytes (talk) 21:21, 13 March 2012 (UTC)
• Oppose per editcountitis. --SarekOfVulcan (talk) 19:00, 13 March 2012 (UTC)
• Oppose. The underlying issue with restricting the block ability remains. Ironholds (talk) 21:48, 19 March 2012 (UTC)

Comment

All of these proposals really dance around the issue at hand: some editors feel that admins either have too much authority, or abuse said authority on a regular basis.

A single policy won't fix this. There's no overall measure that can assure an admin's competency, nor can we "protect" an editor from an improper block. Any hard rule will both make it more difficult for admins to block actual violators, and cause even more drama when an WP:IAR situation arises.

This is an issue of trust, and some editors will not trust admins in any capacity. Others want to give admins free reign. I think most of us fall in the middle. Regardless, this isn't something that can be fixed in a policy. However, maybe we can come to an agreement on what to do when it becomes clear someone was blocked improperly. (Reaching that conclusion is a whole 'nother ball game.) A desysop isn't necessarily the first thing that should be done, but at least some form of process to follow might help alleviate some of the concerns.

Note: I personally believe this is more something that needs to be done on a case-by-case basis, as it's an infrequent problem IMO. Given the timespan of this debate, though, it might be worthwhile to see if we can come up with a process of dealing with such issues. — The Hand That Feeds You:^Bite 18:23, 13 March 2012 (UTC)

The ironic part of the proposal is that admins have essentially no authority when it comes to blocking established editors, because some other admin will always come along and unblock the established editor. So in fact even a well-deserved block of an established editor is hard to keep in effect, much less an ill-advised one. Admins don't "get away" with anything under the current system, although it could be argued that some established editors do. — Carl (CBM · talk) 19:05, 13 March 2012 (UTC)

I'm basically with CBM: These proposals are based on the idea that some editors are so incredibly valuable that they shouldn't be subject to the same rules as everyone else. They want a special set of rules for the power users (usually called "experienced editors" or some such phrase), and then the regular rules for all those unimportant plebians.

And beyond the (IMO) inappropriateness of this, the proposals are poorly thought out. For example, these proposals would have prevented Guerillero from blocking Betacommand at ArbCom's direction last month.

NB that I oppose this, even though it could theoretically benefit me. Malleus, who started this discussion, could only be blocked by 30% of the admin corps, but if his proposal was approved, only 12% of it could block me, and less than 1% could block Rich Farmbrough. WhatamIdoing (talk) 19:41, 13 March 2012 (UTC)

I agree with both of you, actually. The current proposals are really just duct-tape over the actual issue at hand, which is mistrust of Admins. And there's very little we can do to assuage that.

However, putting in an actual guideline for what process to follow when you disagree with an admin action might be beneficial. Right now, it basically involves running straight to AN/I or ArbCom, which just tends to exacerbate things. As you say, CBM, established editors already get a lot more leeway, because Admins recognize their contributions to the 'pedia. Right now, though, if someone thinks they got a raw deal, there's no real process in place for them to act on. WP:DR isn't quite the right one for that, but dumping it on AN/I doesn't seem productive in most cases. — The Hand That Feeds You:^Bite 12:09, 14 March 2012 (UTC)

• Oppose totally un-needed. And with regards to non-admins having no power, I don't really think that's the case. -- Eraserhead1 <talk> 17:30, 14 March 2012 (UTC)
  • ... what? My post said nothing about "non-admins having no power," so I don't know precisely what you're opposing here. — The Hand That Feeds You:^Bite 20:30, 14 March 2012 (UTC)

Isn't it about time to end this discussion here? Obviously as a proposal it isn't flying. As a complaint it has much interest, and I hope another venue can be found for discussing it. Jim.henderson (talk) 13:24, 15 March 2012 (UTC)

• Oppose This is not necessary--if an admin exercises good judgement, then it should stay irrespective of edit count. If he doesn't, then it shouldn't. I don't understand why this needs to exist... —Justin (koavf)❤T☮C☺M☯ 19:55, 15 March 2012 (UTC)

Archive this?

I think this is one of those discussions that could go on forever if allowed, since it's so stupid that everyone who sees it feels they need to come comment on how stupid it is (I was admittedly one of them). There's clearly a consensus for rejection here and it's been up for nearly two weeks. Can we archive it? Equazcion^(talk) 06:51, 21 Mar 2012 (UTC)

Contribs tab

I was going to request this, but I eventually managed to script it myself. There used to be several scripts for this on Monobook, but since Vector I couldn't find a working one, and I figured people might want to know it exists now. User:Equazcion/ContribsTabVector. Equazcion ^(talk) 12:19, 13 Mar 2012 (UTC)

I'm sure Equazcion knows this but for people considering this script who might not, there's a "User contributions" item in the Toolbox menu on the left-hand sidebar when you are on a userpage. Jason Quinn (talk) 03:16, 21 March 2012 (UTC)

Yeah I do :) As evidenced by the three or so scripts that existed for this under Monobook though, many users like to have this in a tab. It feels like it should be one. Equazcion ^(talk) 03:23, 21 Mar 2012 (UTC)

Image or caption dispute tag?

I have a question regarding proper inline tagging of an article when there is a dispute about the accuracy of an image. This is of particular interest in the field of astronomy where speculative illustrations of unresolved objects are more commonplace. Would it be better to use a tag like {{Disputed-inline}}, {{Dubious}} or {{Or}}, or should a new inline template be generated specifically for image concerns? For example: ^{[Image disputed – Discuss]}. Regards, RJH (talk) 19:24, 13 March 2012 (UTC)

This presumably is related to the discussion at WT:NOR about whether images can be banned from Commons for violation the English Wikipedia's "No original research" policy. WhatamIdoing (talk) 00:04, 14 March 2012 (UTC)

Only indirectly. Regards, RJH (talk) 23:07, 14 March 2012 (UTC)

It's a complicated problem. I'd suggest tagging the image (rather than the article), except that most of our images are at Commons, and the English Wikipedia can't really go tag the image files over at Commons for non-compliance with our standards. Additionally, the image could be perfectly fine, but misused in a particular article. For example, you seem to object to using artistic illustrations of exoplanets (someone might be confused into thinking it's a real photograph rather than some artist's vision of the planeet), but I'm sure that we could agree that such an image would be a perfectly fine illustration for an article about Illustration of exoplanets.

I don't really know what the best way to tag such a problem is. I think I'd skip the tag and just head for the talk page. WhatamIdoing (talk) 00:56, 20 March 2012 (UTC)

Cool news, HighBeam Research to donate free, 1-year accounts for Wikipedians

I have just finished a discussion with some generous folks at HighBeam Research--an online, pay-for-use search engine for newspapers, magazines, academic journals, newswires, trade magazines and encyclopedias. The site has access to over 80 million articles from 6,500 publications, most of which are not available for free elsewhere on the internet. Aside from a free 7-day trial (credit card required), access to HighBeam costs $30 per month or $200 per year for the first year and $300 for subsequent years.

But...as of yesterday, HighBeam has agreed to give free, full-access, 1-year accounts for numerous Wikipedia editors to use, at the discretion of the community. They do not expect there to be a problem with the number of these free accounts; however, the plan is for editors to have a minimum 1 year-old account with 1000 edits in order to qualify.

This is a proposal/announcement of the project not the signup process, which should begin in early April and will be widely publicized. Details about the project are available at WP:Highbeam. Comments and assistance setting up the project are welcome. Cheers! Ocaasi ^{t | c} 09:27, 14 March 2012 (UTC)

Very welcome news; kudos to you and to HighBeam. --Tagishsimon (talk) 14:56, 14 March 2012 (UTC)

Indeed this is welcome news. Ditto on the kudos. Thanks for sharing this.--JayJasper (talk) 20:02, 19 March 2012 (UTC)

Proposal: allow anchors to lead paragraphs.

Wikipedia is the natural home for glossary information required by other websites. Rather than building their own glossaries, web authors should be able to link directly to Wikipedia. However, it is often the case that the item of information important to the referencing site is not the article as a whole, but a particular section, paragraph or even sentence, table or figure within the article. This is the Wikipedia counterpart of footnotes in print documents that refer to particular page of another document. Wikipedia already provides a certain amount of fine-grained access with its table of contents, which when used provide a URI that an author can use to link directly to a section.

This ability to link directly to specific information is not true of the lead paragraph, which contains essential definition of the subject of the article, and is precisely the information that would make a Wikipedia article for glossary footnotes. That omission may be unimportant when an author uses an endnotes style of glossary references: a link can take a reader to a Wikipedia page, which he can read and then return from; but it makes using Wikipedia difficult for authors to use frames or other techniques to provide footnotes that can be read simultaneously with the page using the defined term.

For example, if I am writing a page that discusses Aristotle's concept of causality, I can use the URI "http://en.wikipedia.org/wiki/Causality#Aristotle" in a link, with a target of MyFootnoteFrame and the Wikipedia article on causality will open in that frame directly at that section. But if I use the URI "http://en.wikipedia.org/wiki/Causality" the article opens at the top of the page with (today) three inches of page space before the lead sentence. For the purpose of putting footnotes in a compact frame, that effect is quite undesirable.

I tried adding ' {{anchor|Topic}}' tags to the lead sentence, but they are being removed by disapproving editors. Izno merely called them "unstandard". Johnuniq had more to say: "Articles at Wikipedia should not have obfuscating wikitext added simply for the convenience of external websites. I have removed your edit from Uniform resource identifier because it does not assist the article and has the potential to confuse editors (why is it there? what is it for?)."

I respond to Johnuniq by saying that anchors are obfuscating only to those who do not understand the interrelationships among information. Moreover, just as national boundaries have become moot relative to the global economic flow of goods and services, the boundary between what is internal and what is external to Wikipedia is moot relative to the noetic flow of information. Wikipedia is the perfect place to record, debate and refine common knowledge. But the uses to be put to that information vary with every story told by every author in the noösphere. Anchors are the technical mechanism that enables that multiplicity of usage. Wikipedia encourages its authors to build articles out of fine-grained, documented, reusable information. They should also be encouraged to anchor that information so that other authors, both inside and outside Wikipedia, can make effective use of it.

Far from prohibiting anchors, Wikipedia should encourage and standardize them. What should be the standard practice, to enable authors to point directly to the lead sentence or to other fine-grained information? What should be the standard anchor/URN for a lead or other sentence so that it can be referenced by a URI (URL + # + anchor) to that sentence? Should a shortcut template be added so that users can obtain the URI? Should some other link be added so that a reader of a Wikipedia footnote can open the full page in a new window? What instructions should be placed in this MOS article to guide Wikipedia editors in entering lead paragraph anchors? Is it possible that such anchors (and shortcuts) could be generated automatically? These are important technical questions that need to be addressed.

But policy must be set first. Is Wikipedia going to play a significant role in the commerce of information by being a broker of information by allowing fine-grain access to its contents, or is it going to insist that the Wikipedia page is the smallest unit of information that it will provide ready access to, in which case users of information will have to turn elsewhere.

Since I am in the process of building a website that requires a good glossary that I can present in a footnotes frame, I would appreciate some guidance. Should I put my efforts in upgrading Wikipedia to serve this need, or should I write my own glossary that simply links to Wikipedia?

[This is a modified version of the suggestion I put in the Talk section of Wikipedia_talk:Manual_of_Style/Lead_section.]DrFree (talk) 22:23, 18 March 2012 (UTC)

The built in #top links to the pagename, for example Causality#top. #mw-content-text links to the start of the article body, for example Causality#mw-content-text. As in this example, it will often be a hatnote. PrimeHunter (talk) 23:26, 18 March 2012 (UTC)

There's also Causality#firstHeading, which links to the title of the page (below the site notice, if any). In general, if you look at the page source any tag with id="foo" may be linked to with #foo in modern browsers. Anomie⚔ 01:43, 19 March 2012 (UTC)

Thank you for the suggestions but none have the require functionality: Causality#top and Causality#firstHeading open the page at the title, a wasted inch above the lead paragraph. Causality#firstHeading opens the page at the redirect paragraph, closer but still half an inch lead paragraph. Sorry to be picky, but a web page can only allocate a narrow frame for footnotes.DrFree (talk) 22:33, 19 March 2012 (UTC)

The topic caught my attention, but – WP:TLDR. ~ J. Johnson (JJ) (talk)

I didn't read it all either, but this use of {{anchor}} is inappropriate. If you want this functionality go get it done at mw:. Alarbus (talk) 01:16, 19 March 2012 (UTC)

Going to mw: seems inappropriate, for what I am questioning are Wikipedia standards applied within the Wiki software.DrFree (talk) 22:33, 19 March 2012 (UTC)

It appears from [6] and the long post that DrFree wants an anchor when the "main text" starts after any hatnotes, message boxes, infoboxes, images and whatever. That would be difficult to determine for mw. A possible combined editor/mw solution would be that editors could place an anchor with a standardized name like "lead", and if mw detects there is no such anchor on a page then mw automatically makes it at #mw-content-text right below the pagename and tagline. I don't know how much such a feature would be used in practice. PrimeHunter (talk) 02:39, 19 March 2012 (UTC)

All I am really asking is for a more permissive attitude towards anchors. In general it is difficult to anticipate where in an article an author might want to point. The only special place that perhaps needs an automatic anchor is the lead paragraph, which the MOS requires to have both the topic title and a concise definition or explanation.DrFree (talk) 22:33, 19 March 2012 (UTC)

No. While you may want anchors in articles at certain places for your website, other people may want anchors at different places for their websites. How would that benefit the encyclopedia? Articles are not formatted for the convenience of external websites without very good reason (I am unaware of any such cases, although there are some attempts to put some metadata, for example WP:Persondata, in articles). Anchors are for linking one Wikipedia article to another. Johnuniq (talk) 10:06, 20 March 2012 (UTC)

Such a slippery slope is far-fetched, but the benefits to the encyclopedia are obvious: the ability to reference particular items of information, rather than whole pages or just the predefined sections, would make Wikipedia the natural collection of background information to be referenced by web sites doing the original research that Wikipedia eschews. It would become an integral part of the world wide web of information, not a mere, self-contained island. DrFree (talk) 15:46, 20 March 2012 (UTC)

If there is value here, then the anchor should be applied to every article, not just a select few. I checked, but don't see this listed, so file a software enhancement. ---— Gadget850 (Ed) ^talk 10:54, 20 March 2012 (UTC)

Separating the general question of allowing editors to insert anchors where they find them useful, from the question of anchoring the lead paragraph, it would appear that this is not a software enhancement, because it is based on an internal Wikipedia standard which assigns special status to a particular sentence: MOS: Lead paragraph: First_sentence, which is precisely where external glossary references would normally want to point. If the software could be made to recognize and anchor that internal Wikipedia standard, that would be great, but such an enhancement is unlikely in the near term. Hence my current request is merely to be able to anchors to first sentences without their being removed by over-zealous editors.DrFree (talk) 15:46, 20 March 2012 (UTC)

I agree that random creation of anchors by editors at arbitrary points is different than a sistematic anchoring of the lead paragraph, and that creating an automatic anchor for all the leads is a good thing. That said, this should be created by modifying the software so that all pages (or none) get this enhancement. Manually creating anchors for the particular pages you want to reference from an outside site is a terrible idea, it would require a massive clean up work when/if a better way to link to the lead is ever implemented. Your better option is to submit the feature request, maybe recruiting the help of Wikipedia talk:Semantic Wikipedia or some other interested wikiproject. Diego (talk) 16:18, 20 March 2012 (UTC)

So the situation appears to be: (1) The first sentence of an article is important enough to have very special standards applied to it by the Manual of Style. (2) Those very standards make it an attractive point of reference to other web sites, both within and without Wikipedia. (3) There is no syntactic marker which designates the first sentence. (4) Because there is no syntactic marker, there is no way for software to create an automatic anchor. (5) Software magicians might someday overcome this insuperable difficulty. Therefore (6) anchors to the first sentence won't be allowed because they might interfere with some future magic trick. It appears that the much heralded "democratization" of information that was to be the hallmark of Wikipedia has devolved into a politburo of self-appointed bureaucrats intent on vetoing proposals that they themselves don't directly benefit from. Shades of the Soviet Union! DrFree (talk) 19:05, 20 March 2012 (UTC)

Facepalm

First, you're not helping your cause by being so insulting. This isn't something to be fixed here on en.wikipedia. Manually adding html anchors to specific pages is just bad form, and would lead to frustration & confusion when someone tries to link back to a page where they're not implemented. It would require a code-change to apply to all articles, which means you should file via the bug reports & feature requests system. — The Hand That Feeds You:^Bite 20:07, 20 March 2012 (UTC)

If you want those anchors so badly, why don't you just download your own copy of Wikipedia and edit it to your heart's content? It is free content after all as long as you comply with the license (you're showing proper attribution and licensing, right?), and it occupies only about 8Gbs (much less if you trim all articles to just their lead, and a trivial weight for the few articles that you could tag by hand). Why request -no, demand- that the whole project accommodate to your needs, when you already have been given permission to do as you please - at your private space, without interfering with others? ("Soviet Union", indeed). Your proposal here looks like an over-engineered solution to a non-existent problem. Diego (talk) 21:50, 20 March 2012 (UTC)

Proposed Removal of Article tab in Archived Talk pages.

I'd like to see a method of having the Article Tab removed on Archived Talk pages such as Talk:Muhammad/Archive 18, in this case it does not make sense to actually have the equivalent article Muhammad/Archive 18. While it is not always true that a talk page with a slash shouldn't link to its equivalent article (like Talk:Face/Off), is there some way that there could be a flag set (which could go in the Template:Automatic archive navigator as well as other appropriate places). (In fact can anyone think of a reason that a talk page that exists should have a link to a "article page for it" that doesn't exist yet?) Note, this is a "like to see"...Naraht (talk) 15:05, 19 March 2012 (UTC)

Or the article tab could like back to the main article, for example on Talk:FL Studio/Archive 1, the article tab would link to FL Studio, not FL Studio/Archive 1. Either way, this would be a useful feature. —danhash (talk) 15:15, 19 March 2012 (UTC)

Also a very valid idea, either would be much better, IMO, than the current situation.Naraht (talk) 15:26, 19 March 2012 (UTC)

A good idea; the current appearance is rather weird and potentially misleading. dci | TALK 22:28, 19 March 2012 (UTC)

This was also discussed at Wikipedia:Village pump (technical)/Archive 97#Can we get talk archives to point to the main? PrimeHunter (talk) 01:04, 20 March 2012 (UTC)

Adding a NOINDEX tag to unpatrolled articles

Hey guys

After suggestions on the New Page Triage discussion page, we've opened a Request for Comment on adding the NOINDEX tag to unpatrolled articles - basically ensuring they can't be syndicated by google. If you've got an opinion or any comments, head on over there and post your two cents :). Okeyes (WMF) (talk) 13:07, 20 March 2012 (UTC)

List of Internet phenomena

I noticed that several pages on the List of Internet phenomena do not have links to their own articles, while others do. Now don't get me wrong, I'm not the kind of guy who would request a Wikipedia article on every single tree, root, and blade of grass, (I'm not sure if I completely know the phrase) but these pages, in my opinion, (and I think that soon we will get the opinions of other fellow Wikipedians), should be redirects to their sections in List of Internet phenomena. Anyone support me?

--Walex03. Talking, working, friending. 00:47, 21 March 2012 (UTC)

You'd have to challenge each article one by one. If a discrete phenomena article meets notability then it is legitimate for the article to remain as is. There are many list pages that shell out into discrete articles. So no, no support from me for a blanket "should redirect to the list page". --Tagishsimon (talk) 00:55, 21 March 2012 (UTC)

(edit conflict) I support the addition of any article which meets our criteria for inclusion. If the articles not linked from the article you mentioned don't exist, and they meet our criteria, then I support their creation. If someone wants to create redirects for the items in the meantime, until the articles get created (if they do), and the redirects meet our criteria, then I support that too. Anyone who doesn't want to (or can't) create the articles themselves can, of course, use Wikipedia:Articles for Creation. I don't, however, really see what the "proposal" is here. All of these actions are standard, and possible already. Sorry if you meant something else, but if so, I'm afraid I don't understand. Begoon ^talk 01:00, 21 March 2012 (UTC)

Well, no, what you should be doing (or what the community should be doing), is analysing whether that article needs to be pruned. Some phenomena come and go, others remain. It's not for Wiki to record everything that gets posted on Reddit. Frankly, making geeks feel good about themselves is not how the project should continue. I'd be happy to cull almost everything in that article; we're not supposed to be a directory service, after all. doktorb _words^deeds 02:37, 21 March 2012 (UTC)

That's also a very fair point. I was trying to avoid the details of the article and respond in general, because I don't think this is the right place to discuss a specific article, but, in the context, yes, we are not a directory of internet memes, and, while they should be subject to the same sourcing and notability requirements as any other content, there are additional considerations, obviously. There do seem to be a number of doubtful entries in that list - which are certainly not things that are "memes" as I understand the term, in the sense of their not being in any way pervasive. I'll offer one thought that may or may not be useful - when judging these items for inclusion, notability, verifiability etc. are not, in themselves enough. The criterion which are being used to define something to be a "meme" are obviously crucial, and maybe some entries have not been subjected rigorously enough to that "test" - merely being notable and verifiable isn't enough. That's a discussion for the Article talk page, though. Begoon ^talk 03:15, 21 March 2012 (UTC)

By the way, would a more appropriate place to discuss this one than here be at the the talk page of List of Internet phenomena? Incidentally, I wonder whether the phrase that the initiator of this proposal was seeking was "paraphernalia". ACEOREVIVED (talk) 09:08, 21 March 2012 (UTC)

Yes, sorry, I should have been more clear - I linked my post now. Begoon ^talk 09:25, 21 March 2012 (UTC)

Time for new logo and default skin change

Wikipedia is in danger of growing stale. We need to take it in a new direction. NUMBER ONE) I propose we redesign the Wikipeia globe logo. The new logo should be of at best questionable improvement upon the current logo but should be rendered in full 4D. A panel of international editors should be formed and each letter nominated for inclusion should undergo a thorough review process. It shall be possible to find no fewer than 10 mistakes in the final set of letters. The new logo shall be colorful because color monitors and printers have now been developed since the last logo was made. NUMBER TWO) The Vector skin has started to feel soooo 2009. I propose we create a new skin that feels more modern and relies even more heavily upon recently introduced CSS elements. Almost the entire browser market now properly supports the CSS used in Vector and interactive elements are almost acceptably fast. Clearly, we are lagging behind. It's time to push Wikipedia into the next decade. Been too long since change occurred. who's with me? Jason Quinn (talk) 03:10, 21 March 2012 (UTC)

• For one thing, I think the best replacement for Vector would be something a lot more colorful. However, I don't know if the Wikimedia Foundation can afford the server resources necessary to serve up fancy CSS, etc.Jasper Deng (talk) 03:15, 21 March 2012 (UTC)
• Not me. Perhaps you have four dimensions in your universe, but I don't in mine. Malleus Fatuorum 03:41, 21 March 2012 (UTC)
• Even though this is clearly a joke, I'm totally on board. Equazcion ^(talk) 03:46, 21 Mar 2012 (UTC)

--Cybercobra (talk) 03:45, 21 March 2012 (UTC)

• 4D? If we're going to be making changes, I can't support anything less than 5D. 28bytes (talk) 03:51, 21 March 2012 (UTC)
• Call me a luddite, but I am a 2D man. – Allen4names 07:13, 21 March 2012 (UTC)
• Hmmm... Extra dimensions, with somewhat unsupported CSS? Sounds like a good idea to me......
  Is the original puzzle ball colorful enough? I can't imagine it would be too hard to add a couple extra dimensions to it, and more importantly, it has the advantage of having helpful mixed-Russian-Japanese redlinks. (By the way, it seems that the WMF actually does have plans to switch over to a new skin, called Athena, at some point.) --Yair rand (talk) 08:29, 21 March 2012 (UTC)

@Yair rand. Thanks for the heads up on this. Didn't know. I'm in the middle of watching the video conference about it. I was quite annoyed to hear it said that the future of the desktop is dead. So many projects seem to be taking this literally. At some level this "prophesy" will be self-fulfilling if vendors and organizations simply stop developing for the desktop and cause users to leave. This "let's bet the farm on mobile" type thinking is dangerous. Look at KDE 4 and GNOME 3, those are both projects where it is obvious that mobile and tablet-orientated thinking caused them to derail. I worry that mobile fever has infected the WMF. That said, I'm kind of liking Harris' design. I'll be anxious to see more. A good user interface tends to transfer from one platform to another with only minor tweaking. Maybe Harris' design your design (!) whoever's design will work well on the desktop too. We'll see. Jason Quinn (talk) 18:28, 21 March 2012 (UTC)

Um, what? It's not my design... --Yair rand (talk) 00:43, 22 March 2012 (UTC)

Sorry. I noticed your Athena Prototype while watching the video. I hastily edited the message thinking I had made a faux pas under the false assumption thinking you had something to do with it. I quickly realized I was in error again but got distracted and forgot to come back and fix the remark. Probably the work of many people, I guess, but maybe Harris is main designer. Don't know. Sorry for the confusion. Jason Quinn (talk) 00:50, 22 March 2012 (UTC)

The logo I can agree on, everything else no. Logos and identity have moved on a lot, things are much more streamlined and minimalist. So if there's going to be another year-long vote/debate/argument about the logo, count me in doktorb _words^deeds 18:49, 21 March 2012 (UTC)

Maintain a shortcut for User pages and User talk pages

Hi. I have been thinking of this for quite a few days. Why not maintain a shortcut for User and User talk pages? User talk pages should begin with UT:USERNAME, and user pages with UE:USERNAME. Dipankan says.. ^{("Be bold and edit!")} 05:48, 21 March 2012 (UTC)

Why UE? — Isarra (talk) 06:51, 21 March 2012 (UTC)

See also Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. —  HELLKNOWZ  ▎TALK 08:51, 21 March 2012 (UTC)

UT has been proposed and shot down before. Check the archives. I too wish we had UT. --Cybercobra (talk) 08:52, 21 March 2012 (UTC)

User pages should begin with UE as US:USERNAME makes me feel of a user coming from US and such. Dipankan says.. ^{("Be bold and edit!")} 10:34, 21 March 2012 (UTC)

UT might be useful, I agree. UE only saves 2 characters, which is not worth the trouble, in my opinion - I'm still a bit confused about the 'E' too… However, as HELLKNOWZ points out, this is in the Wikipedia:Perennial proposals which means it's been proposed and discussed several times before. That doesn't mean you can't propose it again, but it does mean you should check what the previous objections were, and preferably include rebuttals for the common objections in the proposal, so that the same objections don't need to be debated again. Begoon ^talk 10:48, 21 March 2012 (UTC)

Create an option to allow people to suggest a change

I don't know if this is the right place to submit this but I think it would be beneficial to add some way for people to submit a suggestion to change something. There is already a process for people to submit an article but not an individual change and I think this could be very useful. — Preceding unsigned comment added by 138.162.8.58 (talk) 18:59, 21 March 2012 (UTC)

You could either do it on your own; or you could suggest a change at the talk page of the article! mabdul 21:04, 21 March 2012 (UTC)

This is the encyclopedia that anyone can edit, in most cases, by clicking the "edit" tab at the top of the article or section you want to change. In some cases, however, you will find yourself unable to edit an article, since it may have been protected. In this case, do what Mabdul suggested and request a change on the article talk page, which you should be able to edit with no problem. dci | TALK 02:47, 22 March 2012 (UTC)

@138.162, You can use {{Request edit}} to request a change to an article you don't want to edit. You can use {{Edit protected}} to request a change to a protected article. Both of these are used on the article's talk page. 64.40.61.74 (talk) 10:35, 22 March 2012 (UTC)

Also, you can use the Wikipedia:Article Feedback Tool which contains the functionality requested (currently in testing, so it's not yet available at all pages). Diego (talk) 10:46, 22 March 2012 (UTC)

Wikipedia needs a training ground

One of the most pressing problems facing Wikipedia at the moment is declining editorship. This is largely due to the fact that Wikipedia has become an unwelcoming place for new editors unfamiliar with the rules and mores we've developed over the years. The "Article feedback tool" was one method tried to remedy this, but it has proven largely a joke, at least for the articles I edit. A better idea, I think, would simply be to make Wikipedia more welcoming to visitors. Right now, the "how to" sections on Wikipedia are faceless, intimidating blocks of text, hidden behind tiny search icons on the side of the page. What is needed is a user-friendly interactive website, complete with audio, video and its own cadre of dedicated users who will handhold new editors through their first attempts. I would also suggest a "training ground" be set up consisting of ~1000 duplicate articles on which new editors can be politely led through the dos and don'ts without getting their heads bitten off by irate editors. Serendi^podous 19:36, 21 March 2012 (UTC)

Wikipedia:Teahouse is one place for new editors. They might be interested in your ideas. Also see Wikipedia:Welcoming committee. Fences&Windows 19:41, 21 March 2012 (UTC)

Firstly, I dispute that declining editorship is a pressing issue. It's natural that we have fewer editors once the "easy" subjects already have articles.

Second, while some video "how to" lessions might be useful, it's impossible to "hand hold" every new person who decides to edit. For one thing, that would interfere with the "anyone can edit" philosophy that the WMF adheres to. People are encouraged to jump right in, and attempts to change this have been sharply turned down by the WMF, Jimbo in particular. As long as the WMF adheres to this philosophy, we cannot segregate new users into "the kiddie pool," as it were. — The Hand That Feeds You:^Bite 19:56, 21 March 2012 (UTC)

I'm not advocating segregation. People will still be allowed to edit as they see fit, but interested newbies who genuinely want to help should be given a place where they will feel secure and welcomed, rather than chased off by the usual crop of angry farmers. Serendi^podous 18:27, 24 March 2012 (UTC)

The problem is not all newbies are constructive or willing and lot of them make irritating little edits or refuse to listen to advice. I frequently welcome newbies to the project but if I offer them some tips on sourcing and categorization in my experience I'm usually blindly ignored and they rarely return anyway. The ones who want to edit and learn the ropes will happily take the advice and contribute so a "training ground" would not exactly change the situation. I'm not exactly seeing a declining editorship either. Obviously we've lost a lot of good eggs through petty bureacracy and bullying on here but I'm seeing quite a diversity of new articles coming in, even if we no longer have 1700 articles a day as we had in 2007.♦ Dr. Blofeld 19:59, 21 March 2012 (UTC)

I'm working at WP:AFC and in my experience most editors are now SPAs not wanting to do more than their "own" article and not even want to link this in other articles. It's - as Blofeld already said - not a problem of the system... mabdul 21:02, 21 March 2012 (UTC)

Hey Mabdul! I'm sure you'd agree, though, that's most editors there - not most new editors over the whole project. --Demiurge1000 (talk) 21:19, 21 March 2012 (UTC)

No, I think this is a problem that is getting more and more problematic: Many users are only SPAs and simply don't want to care about related/other articles. mabdul 22:19, 21 March 2012 (UTC)

That's my impression as well, and goes some way to accounting for the diminishing number of editors willing to review the work of others. Malleus Fatuorum 22:26, 21 March 2012 (UTC)

@Serendipodous, I think this is a grand idea, but I would make it a seperate project. Perhaps something like WikiTraining. IMHO, Wikipedia has become user-un-friedly to good faith new users. And that means the only ones that are persistant are the SPAs, COIs and vandals, which is not a good position for Wikipedia to be in. 64.40.61.74 (talk) 10:53, 22 March 2012 (UTC)

UNINDENT

I think the original poster idea has some context to it, take me for example i am dsylexic and struggle to learn new rules that might be affecting a article i am doing or new code like for example cite book i recently used but had never used it before. So i say a training ground even for established editors would be a good thing as no editor here can stay they know Wikipedia inside out so at one point they will come across something and then need to use Wikipedia pages on that thing to learn it, have a training ground with video etc not just for new editors but existing editors would be very welcomed by me. Although some will say there sandbox, sandbox will only help to make a new article without affecting a current one but a training ground would help with the coding of the article as well--Andrewcrawford (talk - contrib) 12:23, 22 March 2012 (UTC)

Thinking in terms of radical solutions and Thinking Outside the WikiBox, I think one thing which would work superbly well would be a kind of video game where people can "play" picking up "treasures" (WikiPoints) by going from room to room, answering puzzles, typing in text in wikimarkup, p[roving that they can understand one policy before moving on to the next "level", and things like that. A lot of people who really enjoy video games would learn huge amounts about Wikipedia that way, and those who can;t stand video games would still have the trad. route to go. I also really like the idea of interactive video tutorials, with screenshots, try-it-yourself sections, and all that stuff. If we have anyone on board who can code such stuff, it would be very interesting to try it. Pesky (talk) 12:47, 22 March 2012 (UTC)

@Serendipodous: I am currently working on Wikipedia:The Wikipedia Adventure (see also User:Dcoetzee/The Wikipedia Adventure) now as a class project. It is an interactive website, although somewhat different from what you envision. I'll post about it when it's ready to start testing. Dcoetzee 21:07, 22 March 2012 (UTC)

One thing that might help would be to require new accounts to take a short, simple, and easy quiz (no more than a dozen questions, with the answers given right next to the question). IP editors wouldn't be affected, but anyone who registers would have to at least read a paragraph (no more than twenty sentences) summarizing WP:FIVE and a few other relevant policies and guidelines like WP:TALK, WP:RS, WP:OWN, and WP:GNG.

This way, regular and experienced editors would have to spend less time explaining these things to new accounts, and it would be clearer who is a bad-faith SPA and who isn't.

The problem with videos or text is that someone can just skip them or avoid them entirely. If they have to actually pay attention to a concise summary of site policies and guidelines to make an usable account, there is no excuse for not knowing not to call someone an asshole for reverting an uncited edit.

Dcoetzee's Wikipedia Adventure is also a great idea, though it seems a bit large for a mandatory intro. Perhaps use that as another means of determining autoconfirmed users? Ian.thomson (talk) 19:01, 24 March 2012 (UTC)

I'm a little wary of "mandatory"; the whole point of the idea in the first place was not to scare GF users off; I think an initiation ceremony, partiucularly one that excluded anonymous editors, would go a long way towards doing just that. At the very least, Wikipedia's main page should have a well-placed message that says, New to editing? Click here. Serendi^podous 19:07, 24 March 2012 (UTC)

Agree w/ Serendi on the "New to editing? click here" idea, as opposed to a mandatory intro. Much more user-friendly. Also note WP:THEEND, not a "training ground" per se, but targeted at users (new or somewhat experienced) who feel overwhelmed at the seemingly "endless" array of policies & guidelines. Designed to give an overview of the WP editing philosophy in simple and concise language.--JayJasper (talk) 19:33, 24 March 2012 (UTC)

Share button

Hey, just a suggestion. I personally would like to have a Share button so that I can directly share articles or photos on Wikipedia on Facebook or whatever. Especially like the photo of the day, but really on everything would be cool. Kag427 (talk) 22:28, 22 March 2012 (UTC)

• Oppose: Wikipedia isn't a social network.Jasper Deng (talk) 22:27, 22 March 2012 (UTC)
• See User:TheDJ/Sharebox. This is a perennial proposal, and nonsensical opposition like Jasper's is the norm. Of course Wikipedia is not a social network - but why should that stop us facilitating the sharing of the knowledge of Wikipedia on social networks? Fences&Windows 22:33, 22 March 2012 (UTC)
• This has been proposed several times and shot down every time. --Cybercobra (talk) 22:55, 22 March 2012 (UTC)
• Support per Fences. The more perennial a proposal, the more evidence that it could be worth revisiting. Wikipedia is not a social network, but facilitating sharing of our content through those sites doesn't somehow turn us into one. Plenty of other news sites and other info sources do this without themselves turning into social networking sites. Social networking is a prominent tool that other sites can and should make use of. The resistance to it is based on a stale and archaic feeling that association with social networking means catering to a teen trend, but if that ever were true, it certainly isn't anymore. Equazcion ^(talk) 13:27, 23 Mar 2012 (UTC)
• Oppose The ability to copy and paste URLs is already built into everyone's browsers. Wikipedia must not host any of the tracking code that comes from any of those socially sites. Ntsimp (talk) 14:26, 23 March 2012 (UTC)
  • Agreed, let's not host tracking code. Should it be decided that there's consensus for a share button, we can then discuss possible ways of implementing it without any such tracking. Equazcion ^(talk) 14:38, 23 Mar 2012 (UTC)
• Support : What's the point of having all this information if it can't be accessed easily? Paper encyclopedias were made obsolete by (desktop/server) CDs, CDs were made obsolete by the Internet (and... Wikipedia), but now social media and smartphones/tablets are becoming a large player in the way that information is accessed and shared. It's a question of "evolve or die". Best, Markvs88 (talk) 15:08, 23 March 2012 (UTC)

• Support if it's easy to disable in preferences and doesn't have share options to Wikimedia projects or other sites where it's probably unwanted. Wikipedia is not a social network but why make it harder for users to share Wikipedia on actual social networks? Copy-pasting a url may seem trivial to us but many of our readers have asked for a share feature which can be simpler and prettier. Many people today are used to share features and it will make more users give us free "advertising" whether or not we are elitist enough to claim that it shouldn't make a difference. Copy-pasting also has potential traps. http:// is sometimes omitted, and many link-parsing programs will ignore a trailing ')' as used in our disambiguations. PrimeHunter (talk) 15:24, 23 March 2012 (UTC)
• Comment Before we go any further with this, what buttons do we intend to put on the new "feature". As noted in the last discussion, there are hundred of social networking sites. It wouldn't be feasible to list all of them, as it would render the tool useless. We would have to leave some of them out. In doing so, we would be breaking our position as a neutral encyclopedia. Having a limited number of buttons is no better than having a big social networking ad on all articles. Both would result in many editors leaving the project. If you want the tool for just yourself, then install the .js script, but before installing it sitewide it might be worth considering the consequences. Alpha_Quadrant (talk) 15:37, 23 March 2012 (UTC)
  • As noted below, there are 330 services. I am not sure what order AddThis presents them in initially, but as you use them, the most used move to the top of the list. ---— Gadget850 (Ed) ^talk 15:42, 23 March 2012 (UTC)
  • It would be easy enough to have a Preferences tab to choose the ones registered users want. For initial display and anonymous users, we'd need to figure out a method of choosing, sure; but I don't think that's something we need to decide "before we go any further". Ie. the POV issue shouldn't be a block to this proposal. We'll deal with the caveats once we've established consensus that the community is in favor of the feature in general. As for scripts, they're great if you know how to use them, but I'd go out on a limb and say the majority of users who would need a share button to share an article are generally not the ones who would easily find out about the script, or even know how to install scripts. Equazcion ^(talk) 16:00, 23 Mar 2012 (UTC)
  • You often have to make choices, also when creating articles, adding entries to lists, adding references and external links, and so on. I assume a new share feature would be similar to User:TheDJ/Sharebox which places a "Share" link in the toolbox. You have to click that to see any of the available options. If you click an ISBN number in an article then you get a page like Special:BookSources/0-596-51516-2 with many options. If you enable "Add a selector to the Wikipedia search page allowing the use of external search engines" at Special:Preferences#mw-prefsection-gadgets then you get 5 external options at Special:Search. I don't think we should be so afraid of making choices that it prevents useful features for those who want to use them. PrimeHunter (talk) 16:12, 23 March 2012 (UTC)
• Support This is a total no brainer. Claiming that social networks have nothing to do with a collaborative wiki is exagerated to say the least. It overlooks our talk pages which are one giant social network without face pics dedicated to spreading information). Nit picking about which social network to use is just nit picking and can be constructively dealt with in the process of implementing the feature. --Shabidoo | Talk 16:47, 23 March 2012 (UTC)
• Support, but please allow individual users to disable it for themselves: (edit conflict) I am proud to not be a user of Facebook or Twitter (or any social networking site) and thus not be infected with the disease/plague that has enslaved the world in the past few years. But the fact remains that there really isn't any good reason to not implement a share button. We could make it a gadget for registered users that is turned off by default, but where does that leave the countless unregistered readers who are infected with the plague and would like to share Wikipedia content on their social networking site of choice? I don't want to be forced to have the share button looking at me when I browse Wikipedia, so I believe that individual users should be able to disable it for themselves.

Adding a share button does not make Wikipedia a social networking site; it simply makes it easier for people who may not be technically savvy enough to know how to copy URLs to share Wikipedia content on their social networking site of choice. The reasoning that some opposing !votes use, that "Wikipedia is not a social network", are so baseless that they should be struck out or ignored. There is NO rule that I see at WP:NOTSOCIAL that would forbid a share button.

There are some privacy concerns above on having a share button. If the share button can be implemented without it tracking users, etc., then there is no good reason that I can think of to oppose having a share button.

—{|Retro00064|☎talk|✍contribs|} 17:08, 23 March 2012 (UTC).

• Conditional Support/Strong Oppose I would support under the following conditions: (1) There are zero privacy issues (not even what is mentioned below as point 1 under #Sharebox privacy) when nothing is shared, and it can be disabled in preferences; or (2) it is not enabled by default, and the privacy issues are clearly mentioned next to the "enable" checkbox. Otherwise, I strongly oppose. I also note that something not meeting these conditions would most likely violate m:Privacy policy by leaking IP addresses and page view statistics to a third party without the consent of the user involved. Note that my condition #1 effectively requires that no scripts or images are loaded from non-Wikimedia urls, at least until a share is actually initiated. #2 could be done now by making Sharebox into a non-enabled-by-default gadget. Anomie⚔ 17:16, 23 March 2012 (UTC)
• Strong Oppose, no benefit is obtained by making canvassing easier nor to send free traffic to one commercial website over another. Also, the WMF is working, afaik, on a well made extension to do this and discussion should be delayed until such a tool is available. Snowolf ^{How can I help?} 23:01, 23 March 2012 (UTC)
• Conditional Support per the two provisions proposed by Anomie. Just because WP is not a social network does not mean that its content cannot or should not be shared on social media venues. On the contrary, it would be great promotional tool. Besides, I see WP content posted on FB fairly often as it is. That said, as Anomie notes, privacy issues are of vital importance and must be adequately addressed. Also, the feature should be optional for users as it may viewed by some "as a privacy threat (even if these concerns are properly and effectively addressed) or as an attempt to "social media-ize" Wikipedia. I also agree with Anomie (and others who have voiced similar concerns) that if these stipulations are not met, the proposal should not be implemented.--JayJasper (talk) 20:04, 24 March 2012 (UTC)
• Strongest ever oppose I'd personally be discouraging these things. OK, social networking is good. But there has to some limit. Never ever. WP:NOTFACEBOOK clearly states that WP is not a social network. Those who want can use User:The DJ's sharebox. Remember, privacy is also concerned. AddThis is still collecting a lot of statistics, but less then when they actually track your browser. Dipankan says.. ^{("Be bold and edit!")} 09:54, 26 March 2012 (UTC)
• Oppose. Share buttons can be useful on pages with dynamic URLs, but since any link to a Wikipedia article will always work (barring deletion or modification to a redirect), there's no need. You can simply copy the URL of the page you're looking at and paste it into the email or whatever other type of message or document you're writing. Nyttend (talk) 14:36, 26 March 2012 (UTC)
• Strong oppose - solution without a problem, perennially offered by social-media advocates who don't understand the concept of "encyclopedia". None of these services lack a facility to simply post the URL of any Wikipedia article you wish to "share"! Besides, this is impossible to do without adding privacy-invading code, favoring one service over another, etc. --Orange Mike | Talk 15:34, 26 March 2012 (UTC)
  • No one claimed it was a solution to a problem. It's merely a proposed improvement, and one that's been requested by many people who might not find copy/pasting as intuitive as we do. To claim that it's only suggested by "social media advocates" would be unfair. I'm no social media advocate. Those share buttons seem entirely superfluous to me. Nevertheless my support for this is based on my stance that we should be vigilante in not surrendering to our own dorky pedantic techie asperger club tendencies by saying that them there sharing buttons those kids are using these days are totally unnecessary, when everyone else seems to think they are. There should be some limited accommodation for something the audience seems to want, even if we the providers don't see the need. Equazcion ^(talk) 17:30, 26 Mar 2012 (UTC)
• Oppose—share buttons are not, on balance, in our interest. There are 4 main parties to consider: readers, editors, Wikipedia as a whole, and social media sites. Social media sites would love it if we added share buttons, because it sends them traffic—that's the whole reason those annoying buttons exist: to reduce the effort of being active on a site by embedding external opportunities to visit it. Most sites use these mini advertisements for social networks because there's a symmetric effect: if someone shares a link to their site, then they, in effect, receive free advertising to that person's friends through the social network. Since Wikipedia as a whole gets a lot of traffic anyway, the benefit here to Wikipedia is minimal. There is a good argument that it helps technophobe readers, but I don't think that that's a strong enough point to counter the fact that it might introduce tracking of Wikipedia users to some degree, or that it's inherently non-neutral because any reasonable interface will highlight the most-used networks first. I would support some sharing functionality, but only on the conditions that it a) benefit editors somehow (they get little to no benefit from standard "sharing" as editors) b) be strictly opt-in, and c) strictly avoid introducing users to more tracking than is expected in our Privacy policy. I'm not sure how those conditions could be fulfilled. {{Nihiltres|talk|edits|⚡}} 18:30, 26 March 2012 (UTC)
  • Although the explicit arguments you provide here have to do with privacy and neutrality, they seem to be an incidental excuse to back up your revulsion to giving free advertising to social networks, which overshadows most of this comment. I think this is a good example of the general feeling here. I join everyone in that feeling, I just don't think my personal disgust is a good reason to block a feature that objectively is useful to everyone outside our inner sanctum. As much as we shouldn't seek to advertise other sites, we also shouldn't explicitly seek to avoid doing it incidentally at the cost of a feature readers will find useful. As for NPOV and ensuring privacy, I think it's already understood that supporters of this feature have those as prerequisites. Equazcion ^(talk) 18:52, 26 Mar 2012 (UTC)
    • I won't hide my distaste; I don't want Wikipedia to give social networks (specifically, big social networks) free advertising. However, I think that the "objectively" useful feature of bypassing a bit of copy-pasting is trivial enough that it is balanced by concerns of privacy and neutrality, and I don't see that it benefits Wikipedia itself to add "share" buttons. Since I don't see a net benefit, I don't think it's a good idea. {{Nihiltres|talk|edits|⚡}} 20:08, 26 March 2012 (UTC)

Previous discussions

• Wikipedia:Village pump (proposals)/Archive 81#Does Wikipedia need a “share” button?
• Wikipedia:Village pump (proposals)/Archive 73#Let 'em like 'em
• Wikipedia:Village pump (proposals)/Archive 74#Link to Facebook
• Wikipedia:Help desk/Archives/2011 February 24#Sharing using twitter
• Wikipedia:Help desk/Archives/2011 March 10#How do you share, or link, an article? Can you? Do I have to copy the URL?
• Wikipedia:Help desk/Archives/2011 April 7#Please Integrate Wikipedia with Social Media Sites such as Facebook, Twitter etc
• Wikipedia:Help desk/Archives/2011 April 20#Sharing Wikipedia Articles With Facebook Friends
• Wikipedia:Help desk/Archives/2011 April 21#Clickable Facebook icons on your pages, so my Facebook friends can click on the heading and read the Wikipedia page.
• Wikipedia:Help desk/Archives/2011 September 15#sharing with social sites?
• Wikipedia:Help desk/Archives/2011 July 28#Sharing
• Wikipedia:Help desk/Archives/2011 October 11#Printing suggestion
• Wikipedia:Help desk/Archives/2011 December 16#email
• Wikipedia:Village pump (miscellaneous)/Archive 36#I just donated...
• Wikipedia:Help desk/Archives/2011 December 22#Forwarding an article.

Each of these has gotten bogged down in "Wikipedia is not a social media site." While that statement is quite true, it has nothing to do with giving users the tools to share on other sites. ---— Gadget850 (Ed) ^talk 14:18, 23 March 2012 (UTC)

I removed the thread for changing the size of PDF downloads; except for the final (irrelevant, as far as I can see) comment on the thread, it was completely unrelated to social media. Nyttend (talk) 14:39, 26 March 2012 (UTC)

Sharebox services

The Sharebox user script uses the AddThis bookmarking service to add e-mail and share buttons to the Wikipedia toolbar. As of March 20120, AddThis supports 330 services. A few highlights:

• • Blogging platforms— LiveJournal, Twitter, TypePad and WordPress
  • Bookmarking sites— including the reference management sites CiteULike and Connotea
  • Email— generic, AOL Mail, Gmail, Hotmail and Yahoo! Mail
  • Social news— Digg, Fark and Slashdot
  • Social networks— Facebook, Google+, Myspace, orkut, LinkedIn and Plaxo
  • Shopping— Amazon.com and Kaboodle
  • Tools— Google Reader, Google Translate, W3C HTML Validator, print tools, PDF tools, screen capture tools and Whois

---— Gadget850 (Ed) ^talk 14:18, 23 March 2012 (UTC)

Sharebox privacy

From User:TheDJ/Sharebox:

1. This tool tells AddThis not to track you. I'm not guaranteeing that they don't track you. AddThis is still collecting a lot of statistics, but less then when they actually track your browser.
2. If you are concerned, just don't use this, or write a new tool that has all the AddThis functionality. I looked around, it does not seem there are any usable open source alternatives that have the amount of share options of AddThis.
3. The Facebook and Twitter icons used by AddThis, are simply share links. They do not have the privacy issues of Facebook's own Share and Like buttons. Yes these major sharing websites know a lot about you, but that doesn't mean that this is automatic. By not using the official buttons of these websites, but simple links, you are in control about what the site knows about you. In practice this means they know what you share, not what you read. If you don't want them to know what you share, don't share.

— Preceding unsigned comment added by Gadget850 (talk • contribs) 15:39, 23 March 2012 (UTC)

Feature request: Toggle all images

Per NOTCENSORED, Wikipedia articles will always contain images that are NFSW (or more to the point, Not Safe For Public Transit).

A few people know how to browse without images, but most people don't even know it's possible. Attempts to explain it to them have generally failed-- too many browsers, too many OSes, and too many native languages. New readers have no idea how to read Wikipedia without images.

The solution is to add an "Image Toggle" button the User Interface. When clicked, it would temporarily disable the images on the page. Each image would be replaced with an offer to "Show All Images". Re-showing all images should be near-instantaneous.

This was originally proposed at an ongoing RFC. A proof-of-concept javascript has been created, you can view example screenshots.

There's appears to be substantial support for adding such a button to the Muhammad article. There is also substantial opposition-- opposers cite a need to treat all articles equally under NPOV/NOTCENSORED. But even among people who oppose adding Image Toggle to one specific article (Muhammad), there seems to be a lot of support for adding the feature to the main Wikipedia user interface, as a feature available on all articles (since we don't want to single any one article out as 'special' or 'controversial').

We know our tech-saavy users routinely browse without images during public browsing. We should let all users have that same ability. would there be support for such a UI tweak? HectorMoffet (talk) 08:46, 23 March 2012 (UTC)

Perhaps wait for that discussion to come to an end first? It doesn't have much chance if it fails there and really I wouldn't want that discussion spilling over to here before it is finished. Dmcq (talk) 11:33, 23 March 2012 (UTC)

Actually, this should be less controversial than adding it just to a single article. I believe it will fail as an article-specific hatnote, but will succeed when applied to all articles. --HectorMoffet (talk) 23:00, 23 March 2012 (UTC)

We could also wait until image filtering is implemented. —  HELLKNOWZ  ▎TALK 11:55, 23 March 2012 (UTC)

I'm glad to see the baseline support there, I thought I was in a minority with the way I got almost universal opposition elsewhere when discussing anything like that. Dmcq (talk) 13:08, 23 March 2012 (UTC)

If I understand things, the image filter is not under active development, I assume because it was too controversial / dev intensive. "Image Toggle" would be far less controversial than Image Filter, because it would be content neutral-- all images on an article treated identically, all articles treated identically. --HectorMoffet (talk) 23:09, 23 March 2012 (UTC)

Support though this might not be the most relevant forum. It's a pleasant and easy feature in Wikipedia:Mobile access where it serves to restrict the number of kilobytes that must be downloaded to see a page, but if a reader prefers to use it to censor, no problem. Jim.henderson (talk) 14:36, 23 March 2012 (UTC)

• "There seems to be substantial support to adding such a button to the Muhammad article" is a decidedly misleading statement. As of right now, support is well below 40% and barring a major change in opinion, that proposal is doomed to failure. However, I am one of the opposers who sees this as a potentially useful widget that could be added to the sidebar toolbox, but only on two conditions: First, that it applies to all articles, not just the ones that are subjectively considered controversial. Second, that the default state is all images shown. Any option other than that would be fiercely condemned as a censorship position. Resolute 20:35, 23 March 2012 (UTC)

+1 to everything Resolute said, especially his characterization of RFC. There is "substantial support" but there is no consensus for adding the feature to just one article. I don't anticipate that will change. --HectorMoffet (talk) 23:02, 23 March 2012 (UTC)

Wikipedia official skype account

Hello,

Can we create an official wikipedia skype account ?

Pro:

- audio conference

- discuss, interact

- wikiprojects coordination

- task force coordination --Tegra3 (talk) 05:36, 24 March 2012 (UTC)

Nope. Prodego ^talk 05:38, 24 March 2012 (UTC)

• Oppose - Something makes me think you proposed this before. Wikipedia won't get itself closer to being a social network. Besides, Skype does not work that way.Jasper Deng (talk) 05:40, 24 March 2012 (UTC)
• Have a look at WP:MUMBLE. Peachey88 ^{(T · C)} 06:07, 24 March 2012 (UTC)

Only show the V • T • E links in navboxes to editors

When we added the "V • T • E" links to the {{navbar}} template, we broke a cardinal rule of interface design: Only show interface elements to the people who need them. For the vast majority of Wikipedia readers, the mysterious "V • T • E" letters in the corner of every navbox are nothing more than confusing clutter. Not only that, but the links also display incorrectly on some browsers and versions of MediaWiki due to how they are implemented.[7][8] We don't display such editor-centric links on other templates, so I think we can live without them in navboxes as well. What I would like to do is remove the links from the {{navbar}} template and instead create a gadget that adds the "V • T • E" links to navboxes for the people that really want them. That way editors can still have the links, but we don't have to confuse our readers with them. Thoughts? Kaldari (talk) 21:21, 24 March 2012 (UTC)

Since everybody (whether or not they have an account, or they are logged on) is a potential editor, then everybody needs to see the VTE links - otherwise, how can people edit the template or talk pages?Nigel Ish (talk) 21:43, 24 March 2012 (UTC)

The same way they edit every other template and talk page. Kaldari (talk) 22:02, 24 March 2012 (UTC)

IPs do edit navboxes, so I think there is merit for those links. It certainly is easier to get to navboxes' markup this way. —  HELLKNOWZ  ▎TALK 21:45, 24 March 2012 (UTC)

Removing the links and adding a gadget to re-add them sounds like a solution in search of a problem. The links are helpful for inexperienced editors to find and edit the templates, and the clutter is minimal. Hiding them on the mobile version might be fine (but there may be some technical hurdles that need working out first). --CapitalR (talk) 21:53, 24 March 2012 (UTC)

Sure, if they happen to guess that "E" is a link to edit the template. So maybe half of people who want to edit the template would actually use the links, and the percentage of people who want to edit the template is maybe 0.001% of the people who read the article. So for half of 0.001% of our users, it is useful, for everyone else it's just mysterious clutter. Kaldari (talk) 22:02, 24 March 2012 (UTC)

Eh, by those stats, we could also get rid of section 'edit' links and especially interwiki links. I have no idea what most of the languages are by looking at them, so perhaps we should get rid of all interwikis and use a gadget to re-add them for those who want a particular language? And very few people actually use a particular section edit link compared to how many read the article, but they're still useful to have. More seriously though, I think the benefit of the VTE links outweighs the cost (access vs. 'clutter'), and it's not hard to find out what they do (click or mouse over). And when a user does click or mouse over one, they can see how easy it is to access and edit such pages. --CapitalR (talk) 22:25, 24 March 2012 (UTC)

This is just food for thought, but maybe hide them from IP editors, and let them display by default to registered users (no gadget required)? Navboxes are UI elements, rather than article content or discussion that should be considered as part of the "anyone can edit" principle applied elsewhere. Just throwing that out there, I'd be interested to hear why or why not, though I can predict some of the responses. Equazcion ^(talk) 22:01, 24 Mar 2012 (UTC)

(Coming here from Template talk:Navbar#Getting rid of the V T E links, which has the question We don't include edit links in other templates like infoboxes, so why do we have them in navboxes?): The main reason for having v-t-e links in navboxes is because navboxes are virtually always in a separate template, and they provide the means for accessing that template's talk page or for editing it. There are rarely v-t-e links in infoboxes because the infobox is almost always in the page itself, so you use the normal edit links for the page.

Regarding if they happen to guess that "E" is a link to edit the template - the {{navbar}} template generates tooltips "View this template", "Discuss this template" and "Edit this template" shown when you mouseover the links. --Redrose64 (talk) 22:36, 24 March 2012 (UTC)

It's precisely because they aren't contained in the current page that I'm thinking there's reason to consider this (not inviting navbox edits from "just anyone"). It's relatively easy to make a mistake, intentional disruption, or controversial change affecting lots of articles. And those changes won't be detected as easily, since generally they won't be showing up in watchlists for people who edit articles where they're transcluded. Relatively few people actually have navboxes watchlisted, and the rest would need to catch errors visually. Equazcion ^(talk) 22:46, 24 Mar 2012 (UTC)

What your proposing would have the same effect as semi-protecting the whole of template space, with the downside that experienced vandals can circumvent it easily by going to the template page directly. We already protect way too many templates because they are "high risk", I would definitely oppose something like this. Yoenit (talk) 15:08, 25 March 2012 (UTC)

This proposal relies on two flawed assumptions: That all non registered people are not interested in editing, and that all non registered people don't understand how the templates work. Both are obviously incorrect. There are many non-registered editors who make use of the ability to edit templates (eg: {{Colorado Avalanche roster}}). I see this proposal as a solution that lacks a problem. Resolute 15:41, 25 March 2012 (UTC)

I concur with Resolute, this is the encyclopedia that anybody can edit. We already discriminate against anonymous users enough, no need to take it further, especially given there's no pressing reason to do so. Snowolf ^{How can I help?} 19:16, 25 March 2012 (UTC)

I likewise oppose. I occasionally edit templates when logged out (when on public computers, and I don't have the time to log into my account for use on public computers), and removing these links would make it rather inconvenient. In reality, this proposal is backward: if we remove the links from anyone, it would be better to remove them for logged-in users, since they're more likely to know how to find the template page before editing it, while non-logged-in people are more likely to be unable to find the template and consequently be confused why they see a big box when the code is simply {{template}}. Nyttend (talk) 14:43, 26 March 2012 (UTC)

User scripts cleanup project

The user scripts listing page at Wikipedia:WikiProject User scripts/Scripts is in dire need of cleanup. To facilitate this, I created a new draft listing at Wikipedia:WikiProject User scripts/Scripts cleanup. All are invited to list scripts known to be currently working and relevant. If/when the list seems reasonably complete, we can deprecate the old listing and move this one in (though keeping and linking to the old one as a more exhaustive list of all existing scripts). Please share any thoughts on this. Thanks. Equazcion ^(talk) 00:35, 25 Mar 2012 (UTC)

Initiative to get us ready for World IPv6 Launch

While World IPv6 Launch day, 06 June 2012, is still far away, we have bazillions of scripts that need re-writing and numerous policies to update before we could be ready. The WMF is more likely to prioritize it if we, the community, actively pursue it.

I don't know whether this should qualify as a WikiProject or not (since it's not a content project), but I think it's important that we start now so unexpected events don't make us late again.Jasper Deng (talk) 18:47, 25 March 2012 (UTC)

Are there a lot of user scripts that are dependent on IP addresses? Or did you mean a different type of script? Equazcion ^(talk) 19:00, 25 Mar 2012 (UTC)

Specifically, Toolserver scripts (many), Twinkle, pop-ups (major), Huggle (though it's not a script), some bots like TorNodeBot and ProcseeBot, and custom user warning scripts.Jasper Deng (talk) 19:27, 25 March 2012 (UTC)

Good idea then. I create Wikipedia:WikiProject IPv6. It's currently just a skeleton based on {{wikiproject}}. Anyone should feel free to fill in the blanks and get stuff going. Equazcion ^(talk) 19:47, 25 Mar 2012 (UTC)

Got some of those fields ready.Jasper Deng (talk) 20:06, 25 March 2012 (UTC)

• Those would be awesome :). If anyone has the technical knowledge necessary, btw; one of the early tasks that would free up our devs to work on other things is to puppetise NfSen. Okeyes (WMF) (talk) 23:49, 26 March 2012 (UTC)

Make suppress redirect available to auto-confirmed users

Hi. Why not make the suppress redirect option available for auto-confirmed users? First of all, it is of great help to all users working in WP:RM. Secondly, that is going to make the names simpler. Consider on a bad name of a article; written professionally. Like: "Example is a bad guy" is the article title; but the article's content refers to the apple iPad, written brilliantly, without bias, etc. This would be of great help to all auto-confirmed users. Thanks. Dipankan says.. ^{("Be bold and edit!")} 10:20, 26 March 2012 (UTC)

Misuse of the suppress redirect function will leave the editors who created the page confused and lost. Also, the potential for misuse by vandals, who have no trouble getting autoconfirmed would be substantial. Snowolf ^{How can I help?} 11:31, 26 March 2012 (UTC)

Then make it available for editors with 6 months and 1000+ edit's experience or something like that. Whatever, it's going to very useful for all workers in areas which requires moving of pages. Dipankan says.. ^{("Be bold and edit!")} 12:37, 26 March 2012 (UTC)

A better way might be to give the option to everyone when there are no links to or transclusion of the page. (May need some development work though.) -- WOSlinker (talk) 13:08, 26 March 2012 (UTC)

• Oppose. This will, for all intents and purposes give autoconfirmed users the power to delete articles. What's to keep someone from moving an article into their userspace, waiting a while, and then CSD U1ing a "userspace draft"? (or just leaving it there to rot) --Ron Ritzman (talk) 13:24, 26 March 2012 (UTC)

Wouldn't move log still be there? Can't users abuse this approach already, or are incoming redirects checked when U1 is requested? Even if they are, the user can replace original article with a non-redirect. Isn't that why history/move log should always be checked regardless? Just wondering. —  HELLKNOWZ  ▎TALK 13:31, 26 March 2012 (UTC)

As an admin, I can assure you that it's easy to overlook single entries when looking over a page history for a U1 speedy; I've made mistakes of this sort more than once. I've recently seen lots of pages get speedy deleted that didn't qualify even for regular deletion — they had been moved and then tagged, and there were so many of these pages that the deleting admin didn't realise that there was a substantial problem. That's the biggest reason I oppose this idea, but even beside that, I think it's a solution in search of a problem. Seeing how I almost never see any type of {{db-move}} situations at CAT:CSD, I believe that Dipankan greatly overestimates the number of times that this ability would be used. Finally, if just about anyone can suppress a redirect, we'd likely see lots of redirects getting deleted needlessly — I often see redirects up for deletion despite points 4 and 5 of WP:RFD#KEEP; if this proposal passes, we'd run the risk of breaking tons of incoming links and links in page histories. Nyttend (talk) 14:50, 26 March 2012 (UTC)