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

Allow watchlisting of Special:Contributions/[User] pages

[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)

• 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)

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)

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)

UID interface to Wikipedia

This is a proposal to come up with a systematic means by which members of subsets of Wikipedia articles (chemicals, protiens, railway stations, etc etc) can be accessed by means of Universal IDs.

The subjects of many wikipedia article have unique IDs assigned to them. Chemicals are identified by their CAS registry number, for instance; protein sequences are identified by a range of UIDs such as UniProt; nucleotide sequences and their protein translations by GenBank ... UK railway stations by NaPTAN, etc. As you'd expect, UIDs are used to provide access to all sort of database repositories. Techniques include web service interfaces, APIs, etc. UIDs make information available on a systematic basis.

UID are already widely used on wikipedia, notably in infoboxes of articles. But right now, any info wikipedia has about a subject is (as far as I know) mostly inaccessible by the UID. Searching for the Ensembl UID for Rhodopsin, ENSG00000163914, brings a pretty useless result.

Equally, right now, any number of software products exist to search third party databases for information by UID. Other than by article name, wikipedia will tend not to feature as a source.

The proposal, then, is make such changes as are sensible to make wikipedia articles accessible by UID through the normal web interface. There are a number of ways this could be done; I come here for thoughts and direction both about the general idea and also the specific implementation. A low-tech example implementation is to create a redirect for each UID - e.g. Ensembl-ENSG00000163914 - and expect it to redirect to the article, Rhodopsin. A better approach would be to reuse the data already in infoboxes to seed the interface, so that we're not double entering data.

If it needs answering, the "why do this", "what use will be made of this" questions resolve to "because we can", "who knows", "until we do we'll not find out" and "if we don't, then we prevent these things from being realised". Those seem good enough reasons to me. Grateful for proposal and implementation detail feedback. thanks --Tagishsimon (talk) 21:25, 13 February 2012 (UTC)

I absolutely endorse this proposal - I'd be happy to be considered a co-proponent - which accords with moves to increase Wikipedia's metadata and machine readability; as well as interoperability with other websites and apps. Alternative formats (and there will be others) would be Ensembl:ENSG00000163914 or to set up a UID namespace, for example: UID/Ensembl/ENSG00000163914. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:39, 13 February 2012 (UTC)

Support redirect system. Redirects are cheap, and I can't see how the it would interfere. If other commenters have a negative outcome in mind, then I may need to re-evaluate. At the moment I can't see it. Not sure what "A better approach would be to reuse the data already in infoboxes to seed the interface, so that we're not double entering data." means. Automatically creating (or even maintaining) redirects based on infoboxes could be suitably trialled and implemented, I would think, if that's the sort of thing you meant. Grandiose (me, talk, contribs) 21:45, 13 February 2012 (UTC)

I'm not convinced that "who knows" is a sufficient reason to spend the time & resources of the WikiMedia on fixing a problem which does not yet exist, when they could be used to fix problems that we do know exist. If I've just not fully understood the proposal (which may well be the case), just let me know. ItsZippy ^{(talk • contributions)} 21:48, 13 February 2012 (UTC)

It's hard to say, ItsZippy. Who knows what's in your head? What I know is this: right now anyone who has an app which uses UIDs finds wikipedia inaccessible. If we re-use UIDs to enable access to article text, it becomes utterly trivial for any third party dealing in UIDs to access our content. --Tagishsimon (talk) 21:53, 13 February 2012 (UTC)

To be honest, I don't know a great deal about UIDs. If you think it's beneficial, then I won't be opposed. ItsZippy ^{(talk • contributions)} 22:15, 13 February 2012 (UTC)

Rather than onwiki namespaces, it might be possible to do something using a simple lookup database - toolserver.org/UID/Ensembl/ENSG00000163914 spits out the relevant article, with the option of adding /en or /de to the URL to select the desired language, etc. I do like the idea very much - I can see an obvious application involving LCSH headings resolving to specific Wikipedia articles, for one thing! Please let me know if you go ahead with this...

One other approach would be to increase our use of hidden infobox fields, and make sure they search properly. It's not much help to prominently display relatively technical identifiers in an article, but if we used something like persondata - a hidden metadata template - this would be a great use for it. Including this alongside the referrer database or redirect would also help ensure we don't get errors creeping in due to page moves (which is likely if we start using geographical or personal identifiers); we can have a script patrolling for mismatches and flagging them. Shimgray | talk | 22:40, 13 February 2012 (UTC)

Why would we put something on the toolserver, when Wikipedia itself can host it adequately? Also, I'm not in favour of hidden fields. We should be displaying UIDs in infoboxes; but that's a separate issue and should not be conflated with this one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 13 February 2012 (UTC)

I'm certainly not wedded to the idea of an off-wiki solution (and toolserver was just an arbitrary suggestion), but I think it's worth considering the benefits. The model I'm thinking of here is the very successful QRpedia, which does a similar trick of going through an intermediate layer before resolving a specific Wikipedia article, rather than leaping straight to an enwiki address.

Firstly, in the short term, it's simpler. We can set up a test database of these links elsewhere as a demo without approval, since it doesn't have to tie directly into the wiki; going straight for onwiki namespaces involves getting consensus before being able to do a practical demonstration, which risks becoming a vicious circle... (Transferring a proof-of-concept database to the wiki should be relatively simple, if the namespaces are later enabled - it'd be a matter of running a script to populate the redirects. The converse is true, as well, of course!)

Secondly, it has greater potential for future development. Using an intermediate layer makes it a lot easier to expand the functionality with things like:

• adding alternate-language capacity via the same URL, without having to seperately query xx.wp and xy.wp and xz.wp to see if there are entries in the preferred languages. (I can imagine a case where a database would say "We need results in Polish, alternatively falling back to German or Russian, and if all else fails use English.")
• more versatility in what we send back - some users might want microformat metadata, some might want full articles, some might want mobile ones, some might want us to spit out a copy of just the lead or the infobox image, etc.

...to take a couple of examples. Shimgray | talk | 12:47, 14 February 2012 (UTC)

This seems desirable, but probably needs a project page somewhere so ideas can be worked through. Is it wanted that a Google search for "ENSG00000163914" would include Wikipedia in its results? And/or a normal (article namespace) Wikipedia search? (Currently, a Wikipedia search finds nothing unless searching in the template namespace.) Roughly how many articles might end up with a UID? How would they be maintained? While a bot might happily create thousands of redirects, there should be some planning for how the results could be maintained. For example, there could be a master list somewhere, and a bot would make the redirects from that list, and would periodically report any changes to the redirects that disagree with what is in the list. Johnuniq (talk) 10:08, 14 February 2012 (UTC)

Yes; a project would be a good idea. Google searching would be one benefit, but the primary purpose would be so that other websites (online databases) and apps could programmatically create URLs like, say, http://en.wikipedia.org/wiki/UID/Ensembl/Foo, where "Foo" is a UID, and be redirected to the relevant article. Hopefully, this would also, eventually, be possible through the API, too. The use of categories would serve to provide lists of such articles. A bot could create the redirects, by scanning, for example, sub-templates of {{PBB}}; like {{PBB/6010}} for Rhodopsin. I like your ideas of a bot reporting suspicious changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 14 February 2012 (UTC)

Tagishsimon, POTW, ... will you please stop having good ideas before I have them! .... :-) I'm currently talking to Library catalogue folks in Sheffield. I think we have an agenda! (ItsZippy - our resources are volunteers - the resource is infinite! We just need discussions about where the value and the enthusiasm best match. This might be one of them Victuallers (talk) 10:56, 14 February 2012 (UTC)

I have created WikiProject Unique Identifiers for discussion and coordination of all UID related matters. Please join! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 14 February 2012 (UTC)

A google search for ENSG00000163914 within the en.wikipedia.org domain gives {{PBB/6010}} and Rhodopsin as the top two hits. It is also worth noting that at least one external database can be search for ENSG00000163914 (see for example GeneCards) that leads to a link that points back the the Wikipedia Rhodopsin article. I don't see any harm in adding these types of redirects, but at the same time I do not see any particular advantages either, especially considering that search engines can rapidly locate the desired article. For the rhodopsin article alone, there would be an almost endless list of possible redirects starting the rhodopsin ensemble accession numbers for a half dozen additional species, the refseq RNA and protein IDs, UniProt IDs, etc. Boghog (talk) 20:50, 20 February 2012 (UTC)

The particular claimed advantage is that a third party database using UIDs can link to wikipedia articles at something like nil marginal cost. Given that we have UIDs in articles, leveraging them to create redirects is also pretty much nil marginal cost. There may be many redirects to a single article, agreed, but I don't see that as a problem. --Tagishsimon (talk) 21:03, 20 February 2012 (UTC)

You don't see any cost to adding millions of redirects? --MZMcBride (talk) 14:15, 1 March 2012 (UTC)

That's why bots were invented. When we have large numbers of articles with specific unique identifiers, a bot will not have difficulty figuring out the one that's applicable to each article. This is a simple enough task that I doubt we'll see false positives except for occasional vandalism and typos. Nyttend (talk) 14:35, 9 March 2012 (UTC)

I am still confused as to why we would want all this in the first place? Could someone explain the idea in simple language. (Don't assume people understand what you are talking about). Start with explaining what a "Unique Identifier" is and does. Then go on to explain why and how you think Wikipedia would benefit from having these "Unique identifiers". Thanks. Blueboar (talk) 15:05, 9 March 2012 (UTC)

THere are standard codes for train stations. THere are standard codes for Proteins. I run a web site or database dealing with train stations. And another dealing with proteins. I use these standard codes in my website. Right now, I cannot use these codes to link to wikipedia.

Wikipedia has standard codes for train stations in its train station articles. Wikipedia has standard codes for proteins in its protein articles.

If wikipedia uses the codes it already has, to crate redirects to the appropriate train station or protein page, then by making one simple change in my website code, I can link all of my train station entries to wikipedia: my users can navigate from my website record to the apropriate wikipedia record. Ditto proteins.

That's it in a nutshell. And yes, there are a number of train station and protein web services out there; and ditto the very many other database systems dealing in entities which have UIDs. Does that help? --Tagishsimon (talk) 15:16, 9 March 2012 (UTC)

"My contributions" link for anonymous IP editors

There should be a "my contributions" link visible somewhere to anonymous IP editors, like there is for registered users. It should probably be called "contributions from this IP" or something similar, though, because the contributions may not be those of the current user of the address.

It has always bothered me that I have to jump through some hoops to see the contributions from this address, either by going to Special:Contributions and then having to figure out the IP address to type in, or to look at the history of an article I know I've edited, find one of my edits, and click on my address to see the contribution history. If there's an easier way, I don't know what it is. 66.159.220.134 (talk) 21:54, 15 February 2012 (UTC)

If you want to see your own contributions quickly, just use Special:MyContributions. Due to dynamic IP-addresses, I'm not sure how useful the link would be. --He to Hecuba (talk) 22:13, 15 February 2012 (UTC)

Thanks. In that case, I amend this suggestion to ask that Special:MyContributions appear on the list at Special:SpecialPages. Currently it doesn't.

Some IP addresses are static, and some dynamic ones persist with the same customer for months, depending on the ISP. Such is the case with me. It wouldn't be useful for AOL users, who get a different address on each HTTP request. 66.159.220.134 (talk) 22:41, 15 February 2012 (UTC)

For an easier way to see your contributions, simply click edit on any unprotected Wikipedia page, type four tildes (~~~~), which can be done automatically using the edit pane button, click on show preview, and then click your linked IP address.--Fuhghettaboutit (talk) 13:26, 16 February 2012 (UTC)

• Strongest possible oppose: there is already a mechanism for watching one's contributions: create an account. The my contributions thing is guaranteed to be abused by bad-faith dynamic IP users, who would only add select contributions to their lists and then pretend that this is all they did. — Dmitrij D. Czarkoff (talk) 13:53, 16 February 2012 (UTC)
  • What would stop them from doing this right now, consider several easy workarounds are available? Why would they suddenly start doing so with this change? Yoenit (talk) 14:14, 16 February 2012 (UTC)
    • Nothing. They do this, and I see no reason why we should facilitate such behaviour. — Dmitrij D. Czarkoff (talk) 11:03, 19 February 2012 (UTC)
  • Thanks Czarkoff, I have rarely seen a more blatant example of disregarding WP:AGF. There is NO requirement to create an account on Wikipedia to participate here.

    Going to a page and typing four tildes to see my IP address, or hunting for one of my contributions in an article history, or looking up my own IP address to type it into Special:Contributions, are all unnecessary hoops to jump through.

    There is no valid reason I can see to make the anonymous IP experience deliberately more difficult. Anons don't get a watchlist, and that makes sense from a technical standpoint. However, an anon who wants to perform maintenance to some articles should have a way to see past articles of involvement. Special:MyContributions is the way to do that, but currently there is NO way for that link to be found. All I'm asking is that Special:MyContributions appear on the big list of other special pages at Special:SpecialPages, which is supposed to be a comprehensive list. 66.159.220.134 (talk) 15:06, 16 February 2012 (UTC)

    • Er, I'm not following. Yes, there's no requirement to EDIT Wikipedia, and there never will be. But people ARE "strongly encouraged" to get an account. I'm not opposed per se to making it easier for IPs to see their contributions, but to say that "There is no valid reason I can see to make the anonymous IP experience deliberately more difficult" is silly. There's a VERY valid reason -- the whole POINT of making an account is to make things easier, on everyone. You might have a static IP but for even so it's not your account. If you ever move, you'll change your IP and someone else will potentially use it. It's not "you" any more. Not to mention editing from elsewhere. So yes, if you want an easy way to find all your contribs, register an account. If you refuse, well there's other ways of keeping track what pages you edited -- your broswer's bookmarks for instance. ♫ Melodia Chaconne ♫ (talk) 16:51, 16 February 2012 (UTC)
      • Pardon, but where is the argument to exclude Special:MyContributions from Special:SpecialPages? Where is the argument that a comprehensive list of special pages must omit this particular link? 66.159.220.134 (talk) 19:02, 16 February 2012 (UTC)
        • There seems absolutely no reason why it should be omitted from the list. I'll post a request on the administrator's noticeboard asking for it to be done. --He to Hecuba (talk) 13:53, 18 February 2012 (UTC)
          • The only way to do this is to change the MediaWiki software, as these special pages are marked in the code as "unlisted" and this cannot be overridden; to request such a change, file a request on Wikimedia's bugzilla. Anomie⚔ 19:17, 18 February 2012 (UTC)
    • Your reading of WP:AGF is plain wrong: nobody is supposed to assume the good faith of each and every human being. This policy is the editing policy, it is applicable on individual talk pages. Still, anonymous IP edits are not difficult at all, and there was a good way provided to facilitate tuning of the editors' experience: registering the account. You are not obliged to state your personal details if you don't want to, but re-inventing accounts just to save the ability to indicate your IP instead of random word just doesn't make sense at all. — Dmitrij D. Czarkoff (talk) 11:03, 19 February 2012 (UTC)
      • • • • • I believe what 66.159.220.134 is proposing the implementation of a link to Special:Contributions. Accounts already have it through a button called "my contributions" in the top right corner. It is technically feasible to add such a link to an IP editor. For example, if 66.159.220.134 clicked the link, it would lead to Special:Contributions/66.159.220.134. I don't see how that could be abused, it would merely be adding a helpful feature that accounts currently enjoy. Alpha_Quadrant (talk) 20:00, 19 February 2012 (UTC)

I have the Firefox search pulldown set to Wikipedia and generally just type "special:my" into it, so it auto-finds MyTalk and MyContributions, and that's how I usually get to my contributions page. Browsers also have a feature called "bookmarks", so overall I think the proposed new feature is of minor benefit as best. 67.117.145.9 (talk) 21:40, 18 February 2012 (UTC)

• Oppopse: This would remove a big reason to create an account and could be as a tool for sockpuppetry: just hop to a new IP and there's all the articles edited by the last one. Best, Markvs88 (talk) 14:53, 19 February 2012 (UTC)

Yes, it is a reason to create an account, but it is technically possible to add an IP editor as well. With that said, the second part of your comment is plain wrong. IP editors already have a Special:Contributions page, it is just hard to find because it isn't in a prominent location. Sockpuppets already know the process, and they know how to get to IP contribution pages. Alpha_Quadrant (talk) 19:55, 19 February 2012 (UTC)

Well, some socks already know the process. I get where you're coming from, but I still feel there's no reason to make it easier. Best, Markvs88 (talk) 12:35, 20 February 2012 (UTC)

There aren't any serial sockpuppeteers that don't know how to get to a contributions page. This change will only make it easier for IP editors to find out what edits came from their IP. How on earth is that a bad thing. The page is already generated, it can't be abused, so what is the problem here? Alpha_Quadrant (talk) 15:39, 20 February 2012 (UTC)

• Support it is quite sensible to have a tab for IPs to see their contributions. Although they don't have an account, they may want to check back on a page they previously edited. Before creating an account, I edited as an IP, and it was very annoying trying to check back on edits I previously made. There is no requirement whatsoever for users to create accounts. Providing a link to an IP's contributions page would be extremely beneficial for IP editors. Alpha_Quadrant (talk) 19:55, 19 February 2012 (UTC)
• Support - None of the oppose rationales seem to make sense. Yes, it would be possible for an IP user to abuse this feature, but that is already possible. If a committed vandal or sock-puppeteer is going to abuse the fact that they can see their IP's contributions, they will do so regardless of whether there is an easy link for them to use. Preventing such a link will not deter those who actually want to abuse it. Despite what people have said, there is not requirement to create an account; users only encouraged to create an account insofar as some pages describe the benefits. Nowhere does it say that IP users ought to create an account, just that they can and that there are benefits to it. IPs are human too expresses most of my feelings nicely. ItsZippy ^{(talk • contributions)} 20:28, 19 February 2012 (UTC)
• Oppose per Wikipedia:Role accounts. Where is the page showing the Foundation supports such a feature?.Switched to Conditional support below. Toshio Yamaguchi (talk) 09:22, 20 February 2012 (UTC)

This oppose doesn't make any sense. IP editors are not role accounts. Alpha_Quadrant (talk) 15:37, 20 February 2012 (UTC)

Strictly speaking they are not. Yet no editor owns a specific IP address and there is nothing prohibiting another user from making edits under the same IP (see WP:SHARE). Furthermore anyone wishing to have the benefit of having all their contributions shown in one place should simply register an account. I don't see the net benefit of this proposal. Toshio Yamaguchi (talk) 16:00, 20 February 2012 (UTC)

IP editors are already capable of editing. They already have a contributions page. This proposal is about making it easier for IP editors to actually find their contributions page. Presently, they have to figure out what their IP address is, visit Special:Contributions, and enter their IP. Either that, or they have to edit a page and use the contributions link on the history tab. There are many, many IP editors that are more active than some logged in users. For example, User:220.101.28.25, an IP editor has almost 12,000 edit. Account registration isn't required. It is an option open to allow IP editors extra tools (i.e. rollback, adminship, scripts, edit protected pages, etc.). What is the harm in adding a link to their contributions page in the top right corner near the login button. The page already exists, so how can a simple link be abused. All it will do is make it easier for IPs to find their contributions page. Alpha_Quadrant (talk) 16:10, 20 February 2012 (UTC)

You say "Account registration isn't required.", but neither is editing under an IP. It seems reasonable to me to require anyone wishing to have the benefits of an account to register an account. Toshio Yamaguchi (talk) 16:22, 20 February 2012 (UTC)

• Conditional support under the caveat that it is called All contributions from this IP or something similar and with a note saying something like This is the contribution page listing the edits performed from this IP address. Please note that the edits might be attributable to several distinct individuals. Toshio Yamaguchi (talk) 21:42, 21 February 2012 (UTC)
• Support per Alpha Quadrant. None of the opposes make sense to me, how can one abuse a Special:Contributions page? It's a page no one has control over and it already exists since it is dynamically generated; linking it would be useful for many unregistered contributors just like it is useful for registered contributors. CharlieEchoTango (contact) 09:30, 20 February 2012 (UTC)
• Support I can't give a better rationale than CharlieEchoTango or Alpha Quadrant, so this support is per their comments. I too, fail to understand what "abuse" this virtual, dynamic list of contributions is likely to cause. There are many very productive IP editors to whom this would be a boon, and I can't see any reason to deny them what appears to be merely a convenience link to a page that already exists, unless there are technical issues. Begoon ^talk 04:23, 21 February 2012 (UTC)

• Support at Special:SpecialPages but oppose on every page. Most unregistered visitors are only readers and many would be confused by a link for edits made by "their" IP address. In most cases there will be no edits anyway, but checking this and only displaying the link if there are edits would probably be too expensive. PrimeHunter (talk) 04:33, 21 February 2012 (UTC)

  Logout and type Special:MyContributions into the search bar. IPs already have this page. I don't think it would be that difficult for the devs to work something out so that it only displays for IPs with actual edits. Alpha_Quadrant (talk) 04:39, 21 February 2012 (UTC)

  That's an interesting idea, to make the link visible only if the IP has edits. Another idea would be to have Special:Contributions default to have the username field pre-filled with the username or IP address as appropriate. 66.159.220.134 (talk) 23:06, 21 February 2012 (UTC)

  I doubt devs will add any "conditional" link because of caching issues, for the same reason mw:Manual:$wgShowIPinHeader is disabled here (I think you can see the result of that option here: http://wikitech.wikimedia.org/view/Main_Page in the right top corner). — AlexSm 02:40, 22 February 2012 (UTC)

• Strong support. This is a simple matter of making an existing, useful feature more accessible to users who edit while logged out. Being able to review their own edits allows new users to reflect on their work, learn from their experiences, and grow as an editor. Even registered users usually have some edits they made before registration that they would like to review, but if they can't figure out how, they won't be able to learn from it. It shouldn't be interpreted as endorsing editing while logged out. Dcoetzee 20:34, 23 February 2012 (UTC)
• Support. It seems pretty uncontroversial to make a link that's already available from the search bar a little more accessible. 28bytes (talk) 02:54, 24 February 2012 (UTC)
• The easiest way to find your "My contributions" link is to get this warning. Sole Soul (talk) 05:57, 29 February 2012 (UTC)
• Support per Alpha Quadrant Nobody Ent 11:51, 1 March 2012 (UTC)
• Just add to Special:SpecialPages, no need for any new UI features such as a tab, since the UI is cluttered enough already (or at most, "meh"). Adding to Special:SpecialPages seems to satisfy the original proposer who first asked for the feature. I've been editing from IP addresses for ages and have never had trouble using Special:MyContributions and I don't see any comments from anyone in this thread saying they have ever personally had such a problem. 67.117.145.9 (talk) 04:09, 4 March 2012 (UTC)

• Support I revert a lot of vandalism, and a lot of this is from unregistered IPs (and lets drop the "anon" part - IPs make more identity visible than disposable accounts). I would find it enormously useful to have this link, and having it would allow me one-click access to a page that I need to read, rather than the current hoopla through intermediate pages to find it. In fact I needed this so much that I wrote some JavaScript to provide it as a hack, just for myself (this is only a hack - I'm not going to release or maintain it). Andy Dingley (talk) 10:42, 7 March 2012 (UTC)
  • As an IP address contributor, I support this idea. Perhaps, on the side toolbox instead, "User contributions", rather than uptop and an obstruction to non-contributive IPs. 184.146.126.165 (talk) 01:42, 8 March 2012 (UTC)

• Support. I often edit via IP when on public PCs and I must agree, this can be quite helpful by easing the way to keep track of what's done. At the same time, for those who have occasional cashe issues like myself; it would help to keep track of what edits have accidentally been saved as IP, when you get automatically signed off. All these are little issues, but would overall increase the editing experience. I don't suggest placing those links where the signed-in user's links are (that would confuse a lot of folks), but instead in one of those dropdowns, or a new one all together. Rehman 08:59, 8 March 2012 (UTC)

• Support: should be made accessible ... more preferably alongside the "login/create account" option. --lTopGunl (talk) 13:14, 10 March 2012 (UTC)

Persondata backlog done by bot

Roaming around Wikipedia, I found Wikipedia's biggest backlog. Category:Persondata templates without short description parameter has 620,000 pages in need of a description parameter. Basically what this is, for those who are new to this category, is a few words that summarizes what a person did for a living for statistical purposes. Now, the few words, like "rock musician" for example, can be predicted through a number of ways. One example is by infobox. An article can only have one infobox, obviously. So, that infobox would describe the thing the person was most famous for. An idea that 1ForTheMoney developed in the idea lab was that a bot lists articles with infoboxes and missing short description. Then, the bot suggests a short description and all an editor has to do is to click an "okay" button which would trigger the bot to ammend the persondata. Other ideas thrown around at the idea lab were using stubs, titles, WikiProjects, and categories.
Vote below with Support or Oppose or suggest using something instead of infoboxes. Thank you, BCS (Talk) 02:45, 24 February 2012 (UTC)

• As per Wikipedia:Persondata#Short_description, disambiguation text should trump infobox text, or both could be used. Stuartyeates (talk) 02:56, 24 February 2012 (UTC)
• I could possibly write this up if there's consensus. My initial thought was a user script, but my second thought was a Web page that just rotates through articles, shows the article title, lead, maybe an infobox if there is one, some automatically-suggested short descriptions, then lets the user enter one and press Enter to move on. If two or three people agree on the short description, it's removed from the rotation and assigned to the bot. — madman 03:50, 24 February 2012 (UTC)
• The remainder of the first sentence after the Forename, surname (19xx-19yy) is another likely contender. Stuartyeates (talk) 06:35, 24 February 2012 (UTC)
• I would guess that this is too difficult for a bot to do accurately. See Wikipedia:Persondata-o-matic for a tool to assist human editors. -- John of Reading (talk) 09:20, 24 February 2012 (UTC)
• I've seen articles with multiple infoboxes, for example both Aussie Rules and NFL players. Categories might work. Josh Parris 11:49, 24 February 2012 (UTC)
• I think what makes more sense is to develop a script that can make a good guess at what the short description should be, then incorporate it into Persondata-o-matic, so that a human can view it and approve it very quickly. I already do this for names, and doing it for short descriptions is an obvious next feature. Dcoetzee 19:50, 24 February 2012 (UTC)

I would suggest starting with the big win categories, Actors, Athletes, politicians and military persons. Depending on how detailed you want the description (can you say American politician or does it need to be Arizona governor) could depend on how easy or difficult the logic need be. Frankly I don't think it would be that hard to kock them out and it should be rather easy to write a script that could be done by a bot. --Kumioko (talk) 20:01, 24 February 2012 (UTC)

Both examples would be okay according WP:DATA. I like your idea. Would you like to volunteer to program the bot? Or will you leave soon? (I saw your userpage) BCS (Talk) 21:03, 24 February 2012 (UTC)

Sorry I'm not really interested in doing any bot work. There are plenty of other folks that can do that though if you take it to the Bot requests page someone may volunteer to do it. --Kumioko (talk) 00:14, 25 February 2012 (UTC)

Here is a small snip-it of AWB code that will add Footballer if the SHORT DESCRIPTION field is blank. This will probably be all you need if you are getting a list of articles based off of a category. I agree with Kumioko, that the big ones should be knocked out first and sportspeople is the #1 big one. I could run this as a bot or if somebody else wants to have some fun, go for it.Bgwhite (talk) 01:15, 25 February 2012 (UTC)

If you have the code ready, then by all means use it. Knock a big one out. WikiProject Football has 37,000 articles missing the short description. Infobox footballer could be a football player or manager if you use that, by the way. So, sometimes a manager who has never played football will have Infobox footballer. @Kumioko It's okay, I wasn't forcing you to make a bot. BCS (Talk) 04:15, 25 February 2012 (UTC)

I would do it by category and not infobox. I can do those that have both footballer and manager categories and then do just the individual categories. The same procedure can then be done for other sports. I think things would be more complicated for politicians, arts and the other groups. Bgwhite (talk) 05:41, 25 February 2012 (UTC)

Sounds good to me. BCS (Talk) 16:25, 25 February 2012 (UTC)

• BCS refers to my idea of adding descriptions based on infoboxes/categories/project banners, and requesting human confirmation (using Madman's idea on the Toolserver or somewhere else) on the ones it doesn't like. Though I was just jotting ideas down at the time, it was made to address the problem of articles with no defining features, and those with multiple infoboxes. (In fact I remember participating in a similar thing with interlanguage links a few year ago, where editors compared articles in different languages and pressed a button to say if the articles were about the same subject or not. If enough people agreed a bot automatically added the links, and if they disagreed that pairing was taken off the database.) 1ForTheMoney (talk) 00:05, 25 February 2012 (UTC)

FYI. Rcsprinter (orate) (Contribs)
(Not Rcs) 20:50, 26 February 2012 (UTC)

• What about using PersonData from interwikis? We could just steal the values from other wikis. Josh Parris 11:43, 28 February 2012 (UTC)

German wiki is the only other wiki to use persondata. Persondata actually started there. How do you steal German language words to put in the short description parameter? Bgwhite (talk) 21:13, 29 February 2012 (UTC)

• Two bot tasks have had BRFAs raised, and they look likely to fail due to unacceptable error rates. I now believe that crowdsourcing is the only viable solution, and encourage development in that area. Josh Parris 11:06, 29 February 2012 (UTC)

Yeah, they shot it down because any bot would produce an error, therefore a bot can't work on it. It sounded like they didn't even like "normal" people working on it because of the errors a normal human would produce. As the number of articles missing the description parameter has gone up every year since persondata was started, this categroy will never be empty. Bgwhite (talk) 21:13, 29 February 2012 (UTC)

That's a reasonable summation. A crowdsourced solution ought to address both problems, by waiting until enough humans agree on what the short description ought to be. I think someone pointed out earlier that the backlog was getting smaller, but I haven't sighted any data one way or the other. Josh Parris 02:27, 1 March 2012 (UTC)

I feel compelled to point out that a crowdsourced solution might seem like a good idea in theory but in reality Wikipedia is the modal of crowdsourcing and these entries have been empty for years (and apparently will be empty for years to come) so if you have a good idea then please present it. You are both very good programmers so I imagine you both have some really good ideas about how to solve this problem other than writing it off to crowdsourcing that you know won't work. 71.163.243.232 (talk) 04:41, 1 March 2012 (UTC)

@Josh: That would be me. I keep a record of the number of templates missing descriptions that I update once a week, though I admit it's more for my own purposes than anything else. And no, I don't think that bots are the best answer to this one - slightly ironically, persondata was made so that biographies could be made accessible to machines, and bots are in fact the cause of this backlog thanks to mass automated additions that should have been reined in before they started. At the moment, the best move is for more people to get involved with the backlog - tools such as Persondata-o-matic allow for semi-automatic additions but with human intervention. 1ForTheMoney (talk) 15:17, 1 March 2012 (UTC)

What about this? Could that be replicated? -- BCS (t · c · !) 19:06, 3 March 2012 (UTC)

Getting people to pay more attention to talk pages

This is only a suggestion, and arguably, it might have been better in Wikipedia:Village_pump_(idea_lab),but I guess that more people look at this page of Wikipedia. My proposal is as follows. It is sometimes said that people will get more out of Wikipedia if they did not merely read the article, but the talk pages (indeed, I am sure I once read a magazine which said that). Can we therefore have a template at the top of at least some articles, encouraging readers to read the talk pages of articles? ACEOREVIVED (talk) 20:35, 28 February 2012 (UTC)

Oppose. Talk pages are for discussing improvements to the article. If we did this then some talk pages would be considered quasi-articles by many readers – and by some editors who would start speculating in spreading their crap on talk pages when it's kept out of articles. All sorts of unverifiable nonsense and rude discussions are already on talk pages. If people want to learn more about the subject than the article and they aren't studying Wikipedia culture then they are better off searching elsewhere on the Internet. Talk pages are also treated less strictly than articles concerning legal issues like BLP violations and copyvios - especially when it's discussed whether something in the article is exactly that. We shouldn't give the impression that we want readers to read talk pages. They are for editors. PrimeHunter (talk) 00:02, 29 February 2012 (UTC)

I'm inclined to agree with PrimeHunter. I will note, however, that many of the article cleanup templates that flag content disputes or biased articles (e.g. {{POV}}) already link to a given article's talk page. While these template messages are principally aimed at editors, other readers are certainly able to discern the presence of a dispute and view any related discussion. TenOfAllTrades(talk) 00:26, 29 February 2012 (UTC)

• Its just more clutter theres a tab at the top of the page already for the talk page, adding a template at the top is just going to detract from a persons ability to read the article Gnangarra 01:50, 29 February 2012 (UTC)

• Comment: Hi ACEOREVIVED, it goes without saying that talk is used to settle disputes, improve the article, etc. However, sometimes it goes... well, way beyond. Please check out talk:Gustave Whitehead... is that what you're trying to engender? Best, Markvs88 (talk) 15:24, 29 February 2012 (UTC)

• Oppose: Yes, readers should read more deeply. I meet people and brag about being a Wikipedia editor, one of millions, and tell them it's one of those iceberg things, 90% underwater. I advise them to use the tabs at the top of the page, and the "About Wikipedia" on the left edge, and the "Help" also on the left, all of which lead them to read the highly informative underwater parts. It's all there; just have to point, click and read though perhaps "Help" ought to be made more immediately helpful to readers and less focused on editors. Jim.henderson (talk) 19:31, 29 February 2012 (UTC)

Support - if we encourage users to actually go on talk pages, there would be a more social and collaborative aspect to the encyclopedia. By encouraging people to use the talk pages, we encourage new WikiProjects to actively improve a certain subject on Wikipedia, and improve the existing and mostly moribund ones. This will also aid in editor retention (our number 1 priority now), as it will allow a forum for discussion of articles. I understand that Wikipedia is not a forum or message board, but discussion on articles does contribute to their quality. Wer900 (talk) 03:36, 6 March 2012 (UTC)

Many thanks to all the people who responded to this proposal. The comments in response are well taken. I should also say that I was very impressed with how polite and civil people who responded to this discussion were, even if the general consensus appeared to be oppose the original proposal. It goes without saying that that is exactly the good manners that, one hopes, will characterise Wikipedia discussions. ACEOREVIVED (talk) 21:12, 29 February 2012 (UTC)

What I wouldn't mind seeing is a count on the 'Talk' tab of the number of recent discussion sections added or updated. (For example: '| Talk (2 updates) |'.) That way I can tell at a glance whether discussions are taking place. Regards, RJH (talk) 23:17, 29 February 2012 (UTC)

RJH's idea sounds interesting, but I would think like the above proposal, it doesn't totally jive with WP as an encyclopedia. All of the behind-the-scenes work should be accessible, but probably shouldn't be to prominent. Aslbsl (talk) 14:17, 1 March 2012 (UTC)

Make it possible to have several watchlists

It would be really helpful to be able to create several separate watchlists. I watch pages where my interest is the article itself but I also often watch pages where I only do wikignoming and only need to check whether someone else undoes those edits. It would be cool to be able to maintain separate watchlists for those two types of pages. Therefore I propose to give all editors the ability to maintain more than one watchlist. Toshio Yamaguchi (talk) 19:58, 1 March 2012 (UTC)

I had a similar idea, but I did not mention it outside my talk page (User talk:Wavelength/Archive 1#Watchlist folders).

—Wavelength (talk) 20:11, 1 March 2012 (UTC)

Try Special:RecentChangesLinked - it lists changes to any page linked to from a given page. You populate a page with the pages you want to watchlist, and tada you're done. Josh Parris 20:15, 1 March 2012 (UTC)

I am not sure this works for me. What I need would be the following watchlist categories:

• Articles I am interested in
• Village pumps and help desk
• Specific policy pages
• User talk pages
• Pages where I perform NFCC enforcement

This is only a rough outline to get an idea of what I have in mind. Additional options for "fine tuning" your watchlist might be desirable. Toshio Yamaguchi (talk) 20:37, 1 March 2012 (UTC)

See Wikipedia:Help desk/Archives/2010 October 30#Multiple personal watchlists.

—Wavelength (talk) 21:02, 1 March 2012 (UTC)

Try User:UncleDouggie/smart watchlist.js. --Yair rand (talk) 22:13, 1 March 2012 (UTC)

This one is excellent, been using it since quite some time.. but it saves its settings to your browser, so you won't have the same settings on another computer. Some thing like this should be rolled out in general instead. There was also a consensus for recent watchlist changes... what ever happened to that? --lTopGunl (talk) 11:50, 4 March 2012 (UTC)

Special:EditCount

I've come up with a idea: Why not create a special page called Special:EditCount? I agree that luxo's, X!'s, tparis's ; etc are not bad, but when replication lag is high, problems occur. There is a sample here. It is used in Wikia, also run by MediaWiki, so it's technically possible. There is a consensus for creating this at TestWiki. Dipankan ^{Meet me here!} 14:44, 3 March 2012 (UTC)

• What benefit would such a page bring to this encyclopedia? Phil Bridger (talk) 22:54, 3 March 2012 (UTC)

• It is as accurate as your preferences. Dipankan ^{Meet me here!} 05:03, 4 March 2012 (UTC)

• I didn't ask whether it was accurate, but what benefit it would bring to an encyclopedia. Phil Bridger (talk) 08:42, 4 March 2012 (UTC)

• That consensus is on another website. Historically, the consensus at en.wiki has been that too much attention to one's number of edits may lead to editcountitis, the symptoms of which make for a very unhappy editing environment. — Huntster (t @ c) 05:49, 4 March 2012 (UTC)
• What would be the benefit of letting everyone see everyone else's edit counts so easily? This should stay in preferences where it is not being broadcast. ▫ JohnnyMrNinja 06:07, 4 March 2012 (UTC)
• The example that you linked to uses the Editcount extension. I agree with Huntster, though, that in order to enable it here you would need to show a good reason and how it would be used to improve the encyclopedia, to overcome the concerns described. Incidentally, if you want to see Users' edit counts while browsing talk and contribution pages, Navigation Popups includes that functionality (using the API) when you hover a user name. Begoon ^talk 06:10, 4 March 2012 (UTC)
• OK. I have developed my own script which adds a Edit Count link in your personal toolbar. That is of X!'s, but that will help. Dipankan ^{Meet me here!} 09:39, 4 March 2012 (UTC)

  I'm sure that may be useful for some people, thanks for sharing it. You can list scripts like that which you've created at WikiProject User scripts, to make them easier for other users to find. There are already a couple listed there which do something similar, like User tabs. As I mentioned, the API result from WP:NAVPOP is enough for me. Begoon ^talk 09:43, 4 March 2012 (UTC)

Thanks for giving the feedback. I will continue to develop simple tools using JavaScript when I get time...! Dipankan says.. ^{("Edit count do not matter")} 05:13, 6 March 2012 (UTC)

People who have contributed to this discussion may be interested in the Wikipedia article Wikipedia: Editcountitis, although since I just saw a quote "Edit count (sic) do not matter" perhaps some of them will not! ACEOREVIVED (talk) 22:17, 8 March 2012 (UTC)

Comment I've always thought it doesn't make any sense why our edit count is under "my preferences" instead of "my contributions". Jason Quinn (talk) 04:15, 9 March 2012 (UTC)

It is under "my contributions". If you click on "My contributions", you can go to "Edit count" at the bottom of the screen. ACEOREVIVED (talk) 08:44, 9 March 2012 (UTC)

I was wondering if it is possible to have an EdiCount that has, as an additional argumen,t a minimum contribution size (eg. 1000 bytes) , either fixed or entered by the user. I know editcountitis is spread among some of the top contributors and that all contributions and contributors matter, however it is be good to recognize who the top contributors are. But, in my opinion, we shall not recognize ones that have thousand of contributions only adding lines between paragraphs, brackets in dates and adding unnecessary categories. Perhaps some filter (eg. contribution size) would help. Lgtrapp (talk) 18:31, 11 March 2012 (UTC)

Categories for discussion nomination of Category:Eponymous categories

Category:Eponymous categories and all other cats beginning with "Category:Categories named after" , have been nominated for being turned into hidden categories. On the Categories for Discussion page there has been a debate about the appropriate venue for this discussion so I am linking it here to try and establish a censensus on venue. If you would like to participate in the discussion, you are invited to add your comments at these categories' entry on the Categories for discussion page. Thank you. RevelationDirect (talk) 04:48, 4 March 2012 (UTC)

Note there is a complementary request to rename such categories to "Category:Wikipedia categories named after...". SFB 17:29, 4 March 2012 (UTC)

Citation Style templates- centralizing talk pages

See Help talk:Citation Style 1#Centralized talk page.

A week ago, I made a proposal to centralize the talk pages of the Citation Style 1 templates, making an announcement on all 25 talk pages. The response has been minimal, which rather proves my point that these pages are underwatched. Since these templates are so well-used, I thought it best to open this to a broader audience. ---— Gadget850 (Ed) ^talk 14:02, 4 March 2012 (UTC)

Go be bold, imo. --Izno (talk) 14:17, 4 March 2012 (UTC)

Maintenance Category Reorganization

The maintenance categories on Wikipedia are poorly organized, and as a result, users are turned off by the massive walls of text which link to them. Category:Wikipedia maintenance categories sorted by month says it all. This is especially damaging to the base of new editors, which will be at best confused and will not be able to target their efforts on where the encyclopedia requires the most work, and at worst will be turned off by the large number of categories and simply become inactive or leave, feeling that there is no way they can help. For anyone, the place is visually unappealing in addition, and difficult to navigate. It is for this reason that I propose organizing the numerous categories into various categories superior to them but inferior to the category of all articles requiring maintenance, which shall give the general area of what must be done with these articles:

• Cleanup and Grammar - this should deal with various aspects such as the prose of the pages, its grammar and spelling, the formatting of its contents, whether they use neologisms, etc.
• Accuracy - this category should specifically deal with pages which have accuracy issues, or have some issue with regard to the style and placement of their references.
• Comprehensiveness - self-explanatory. This category should deal with pages which have issues in the amount of content they have, if articles are stubs, and whether the article explains in depth and with many examples the topic that it covers. This section will also deal with whether lists comprehensively cover what they are supposed to and have basic properties of all of their subjects
• Suitability for Inclusion - this includes articles that are cruft of any kind, non-encyclopedic, example farms, promotional, tl;dr self-shrines, libelous, etc.

In addition, within these categories, the dates they are sorted by should also be subcategorized by year, again so that new users are more invited to edit them and navigation is easier generally. I am not proposing the demolition of any existing category, merely that they be moved into the appropriate supercategory listed above so that the page is more elegant and easier to navigate for new users and old alike. Nothing else will change with regard to the categorical structure.

Also, in order to ensure that the backlog of bad articles is eliminated in the quickest fashion possible, a link should be placed to the maintenance categories sorted by month in a prominent place, perhaps on the left sidebar, or to the left of the "feedback about editing" link. This will ensure that a larger percentage of new and experienced editors alike notice the existence of a backlog, and that more resources will consequently be available to the related WikiProjects to help clear up this backlog, as opposed to merely a small dedicated group (though this group is not in any way harmful, just too small to clear up the backlog without serious firepower). That way, more editors will feel a purpose of being on Wikipedia, more new editors will be retained, and the community can grow back.

Wer900 (talk) 23:56, 5 March 2012 (UTC)

The new, redundant automatic edit summary on page moves should be reverted

Apparently as of about March 1, 2012, the automatic edit summary on page moves became the stunningly redundant "User name (without the user: prefix) moved page X to page Y". In an article's edit history what is thus seen is a person linked username, followed by their name again, listed as making the move. Here's a screenshot from the article history of a move I made last night to illustrate:

When looking at a person's contributions, or your own watchlist, a person's username is not linked and listed, but since you're looking at that person's contributions or your own watchlist, you know whose contributions you're looking at, so it's just as redundant to see this edit summary. I also imagine this now shortens the number of characters one can add to a page move summary in the Reason: field, which was already pretty short because of the automatic move text (a person with a long name might find any reason they add just gets swallowed when they save because of the character limit). I have no idea where this change was discussed at all, or what would need to be done to change it back but I'm sure responders will illuminate me.--Fuhghettaboutit (talk) 13:04, 6 March 2012 (UTC)

• Support. As you say, it's redundant and it bloats diffs, logs, contribs, etc. Jenks24 (talk) 13:18, 6 March 2012 (UTC)
• Support, redundant. --SarekOfVulcan (talk) 13:44, 6 March 2012 (UTC)
• Comment See WP:VPT#Moving saves username in edit summary for technical details. In short, it will require a code change which will require filing a bug. This comment isn't intended to discourage discussion, as gaining consensus here may help in convincing the devs to make this change. Anomie⚔ 18:34, 6 March 2012 (UTC)
• Support; blatantly redundant. Does anyone know what happens if the user changes name? Could we end up with lists displaying two different names? Favonian (talk) 20:13, 6 March 2012 (UTC)
• Support - You can vote for the bug fix here. Jojalozzo 20:38, 6 March 2012 (UTC)

• Thanks for providing this information. I have voted and apparently a developer has been "assigned" the bug (I assume that means the fix has been greenlighted and put in a queue for that person to take care of?)--Fuhghettaboutit (talk) 15:37, 7 March 2012 (UTC)

• Support, I have voted there as well, and left some comments for the very defensive (and incorrect) developer. Let's hope they leave their rather entrenched position and actually listen to what we are suggesting, or that they at least provide some good examples of where this change is beneficial. Fram (talk) 09:52, 9 March 2012 (UTC)
• Support the removal of this redundancy. ItsZippy ^{(talk • contributions)} 19:44, 9 March 2012 (UTC)
• Support overly redundant, and there was no consensus for the change in the first place. While we are at it, the two periods around the page size should also be removed. For example
  00:00, March 9, 2012 Alpha Quadrant (talk · contribs) . . 2,000 bytes (+200) . . (Edit summary) would take up much less space as
  00:00, March 9, 2012 Alpha Quadrant (talk · contribs) 2,000 bytes (+200) (Edit summary). I have no idea why the devs added the extra periods, but I can't thing of any reason for having those four extra periods on either side of the page size count. It just takes up extra page space. Alpha_Quadrant (talk) 19:50, 9 March 2012 (UTC)

No, they add some much needed breathing room. We don't need to design for 640x480 anymore. - ʄɭoʏɗiaɲ ^τ _¢ 20:09, 9 March 2012 (UTC)

• Support - Marcus Qwertyus supports the removal of this redundancy. Marcus Qwertyus 03:09, 10 March 2012 (UTC)

Request for comment: Adoption of new unblock appeals tool

Hello, all; an RFC has been opened at Wikipedia_talk:Guide_to_appealing_blocks#Adoption_of_new_unblock_appeals_tool to seek input regarding the implementation of the Unblock Ticket Request System as a replacement for the unblock-en-llists.wikimedia.org mailing list. Comments from all users, especially those who have experience in reviewing blocks, would be greatly appreciated. Hersfold non-admin^(t/a/c) 21:13, 6 March 2012 (UTC)

Adding another disclaimer page about Accessibility

In Wikipedia talk:General disclaimer#For or not for dyslexic and blind people?, I requested an addition about dyslexic and blind people. However, the user suggested that adding a disclaimer about people with difficult accessibility is too good for WP:General disclaimer. There is already WP:WikiProject Accessibility, but it is not itself a disclaimer, I'm afraid. I don't know if WP:NOT addresses accessibility for handicapped people. Should there be another Disclaimer page about Accessibility for people with difficult diagnosis, such as deafness, blindness, dyslexia, and other diagnosis? --George Ho (talk) 02:01, 7 March 2012 (UTC)

I think you misunderstood what I was suggesting. I didn't mean another disclaimer page, because I don't think this is something to be "disclaimed" rather something along the lines of a page with advice on using Wikipedia for the differently-abled, much like Microsoft Windows has an accessibility section with things such as page zoom and speech etc--Jac16888 ^Talk 02:06, 7 March 2012 (UTC)

Shortcomings in the medium are not things to be disclaimed. Note how no other site has disclaimers for these. --Cybercobra (talk) 07:02, 7 March 2012 (UTC)

Sometimes government organizations have to put in some sort of disclaimer where they have not been able to cater properly for people with a disability because of requirements on them to deal with such problems. However the only requirement on Wikipedia is a moral one so no disclaimer is needed just an effort to deal with such problems. Dmcq (talk) 11:48, 7 March 2012 (UTC)

Can you elaborate a "moral one", please? --George Ho (talk) 12:15, 7 March 2012 (UTC)

As in the very first definition in athe first dictionary I googled 'of, pertaining to, or concerned with the principles or rules ofright conduct or the distinction between right and wrong;ethical: moral attitudes.' Dmcq (talk) 12:38, 7 March 2012 (UTC)

As a totally blind person (who happens to have Wikipedia:General disclaimer on their watchlist), I don't understand why a new disclaimer page is needed at all. It'd be very difficult to write a page about using Wikipedia for people with disabilities because users' needs vary enormously. The closest we have is Wikipedia:Using JAWS. Graham87 15:49, 7 March 2012 (UTC)

Village pump official irc channel

Hello

can we create an official irc channel to discuss the proposals each other ?

I think it's useful. What do you think ? --Tegra3 (talk) 12:13, 7 March 2012 (UTC)

With the creation of any new IRC channel there is the danger it will remain underpopulated and die due to lack of interest. I think it's better to discuss proposals in existing channels like #wikipedia-en. Dcoetzee 22:21, 8 March 2012 (UTC)

General discussion of occupational categorization

Please Wikipedia talk:Categories for discussion#On the categorization of biographies by (perhaps) incidental occupation. Mangoe (talk) 19:56, 7 March 2012 (UTC)

editing references

Moved from WP:VPP (Policy) because of letter "P" mistake. [2] -DePiep (talk) 10:48, 8 March 2012 (UTC)

I propose to add a link to every cite template, added to the reference content and so to be shown in the reference section. The link shows "[Edit]" on the page, and when opened it allows editing the reference (template), as entered on that page. Much like one can edit a Section now. -DePiep (talk) 10:12, 8 March 2012 (UTC)

. Can you explain what are the benefits of this change? Diego (talk) 10:32, 8 March 2012 (UTC)

It isolates, for editing, the single reference code input (template usage on the page) from other code. Especially since the code is in line, it is complex when editing the full page. -DePiep (talk) 10:42, 8 March 2012 (UTC)

{{Cite doi}} has that feature, but it only works because each reference is a subtemplate. ---— Gadget850 (Ed) ^talk 10:52, 8 March 2012 (UTC)

Spot on. We could limit it to cite templates, I have cast the net a bit wide. -DePiep (talk) 11:01, 8 March 2012 (UTC)

• Have you tried ProveIt? You can activate it in your Preferences->Gadgets. It doesn't work exactly as you describe, but it's somewhat similar, I think, and worth a look if you've never tried it. Begoon ^talk 10:57, 8 March 2012 (UTC)

• I just tried the demo. Very, very good. But hey, I do AWB once a month. I really need to learn HotCat, to use it once a month. Maybe I am a TWinkle-editor, once a month. You get my point? I am a serious editor, with many edits, but having to (learn to) use an App is not good. Just give me an [Edit] click, please. -DePiep (talk) 22:29, 9 March 2012 (UTC)

1) Wouldn't WP:Citing sources (or such) be a more appropriate place to discuss this?

2) The proposal is unclear as to where this edit link is to appear. You mention a "reference" section: does this mean specifically a section titled "References"? Or some other section? Or is the edit link to follow the citation (reference) wherever it is displayed? Or do you propose that these edit links be collected in some special section?

3) If the core problem is the difficulty of template coding being mixed in with article text (and I agree that is a problem), then there is a much easier solution: gather all the templates together in one section (e.g., "References") and link to them using Harv.

~ J. Johnson (JJ) (talk) 17:45, 8 March 2012 (UTC)

Not everyone like Harvard referencing. --Cybercobra (talk) 05:25, 9 March 2012 (UTC)

re JJ: 1) Indeed, "(or such)" is where I ended up. 2) As for where the [edit] is to appear: I think I described that in the first sentence. A more exact location can be decided later, and is not essential for the proposal. {{cite doi}} is a good example. 3) Reducing cite options to just harv is no way forward, and not "easier" (more simple it is, as in "choose any black color for your T-Ford"). I must say, you got the issue right when acknowledging it. -DePiep (talk) 16:57, 9 March 2012 (UTC) Struck my arrogance -DePiep (talk) 22:18, 9 March 2012 (UTC)

You have not explained why this venue is more appropriate than (say) Wikipedia talk:Citing sources. I think that exactly where this edit tab is to appear is a key part of the proposal, and not something that can be "decided later"; the lack of that detail suggests that the proposal has not been adequately worked out. (Could you provide us with a mockup?)

And I find it quite inexplicable how you find "Reducing cite options to just harv is no way forward". I certainly have not suggested "reducing cite options" – I suggested an available option that is likely more useful, and certainly easier, than what you are proposing. That many editors are prejudiced against it is unfortunate, as it does not suffer from the problem you apparently want to address. ~ J. Johnson (JJ) (talk) 00:33, 10 March 2012 (UTC)

Latest ep of a TV series

My proposal is that at the top of the page of a tv series, such as glee, or family, or house etc, it has one those those italicised sentences that says something like "for the latest episode of _____, which is currently in season _____, see _________." It will save a heck of a lot of time in finding the latest aired episode on a series instead of typing in the name of the series, then scrolling down to click on the latest season article, then scroll down and clock on the latest ep article.--Coin945 (talk) 09:05, 9 March 2012 (UTC)

Those italicised sentences are called Wikipedia:Hatnote but this isn't really what they are for. It would also require frequent updates and often be out of date. And many countries air foreign shows with a delay of weeks or months. I don't support going down this road but if we do then I think it should be a field in Template:Infobox television with both episode name and original air date. PrimeHunter (talk) 15:36, 9 March 2012 (UTC)

What's the view against going down this road? It seems like a logical, helpful thing to do from my perspective...--Coin945 (talk) 10:31, 10 March 2012 (UTC)

Opposing view would be something like... wikipedia is an encyclopedia? --lTopGunl (talk) 12:53, 10 March 2012 (UTC)

.....I've thought about this quite a lot and I've come to the conclusion that we can't actually use that as an excuse anymore. Wikipedia is not an "encyclopedia". It is a hub for all knowledge. When people want to know something, they will always to go Wikipedia - not to Wiktionary, or to Wikinews, or Wikicommons etc. Wikipedia is the be all and end all. That's the same reason why I oppose transwikiing. By all means have a wiktionary article as well, but keep the Wikipedia article as if its not on Wikipedia, it doesn't exist [at least that's the way many people see it]. And it naturally follows that I'm starting to think that just as Urban Dictionary is creating new memes and popular culture that even the media haven't picked up on, maybe it is our job to document them.... screw notability!!! [rant over :P] My point is that people go onto Wikipedia to have easy access to things they find interesting. Yes, the info they get can often be sub-quality, but I for one sure as hell love it when the Wikipedia article is a Simple-English style article that has all the basic facts in simple sentences/paragraphs instead of massive articles that i have to skim through to find what I'm looking for.... and I'm sure for others it's the same. In the same way, making life slightly easier for our readers will be of such great use to them. I don't see how fear of skewing from the "encyclopedic" format is a valid argument. All I am saying is that this might be a very useful little shortcut for people.--Coin945 (talk) 15:31, 10 March 2012 (UTC)

To put it simply: Just because people may use a resource for something doesn't mean that's what the resource is for. ♫ Melodia Chaconne ♫ (talk) 16:40, 10 March 2012 (UTC)

I don't think you'll get much traction for trying to revoke WP:N. I really don't want Wikipedia to become haven for all the fancruft that would allow, as well as minor bands, trivial locations, etc. Just because you can do a thing, it does not follow you should do it. — The Hand That Feeds You:^Bite 18:46, 10 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)

  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)

• 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)

You don't make any sense Mark. I think you might be lost. :-) ShmuckatellieJoe (talk) 08:39, 12 March 2012 (UTC)(formerly Kumioko)

• 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)

  Ultra you know as well as anyone that its even harder to get an admin desysopped than it is to become one and frankly the RFA process is legendary in its difficulty so to say its easier is saying something. Whenever I see an admin desysopped I always buy a lottery ticket because the odds of winning are better. Using myself as an example here. If an editor has at or in excess of 1000 edits in almost every namespace that might be an indication of trust and sound judgement. You can certainly slide by in Userspace but namespaces like template, category and Wikipedia (not even counting the talk pages) tend to be watched. ShmuckatellieJoe (talk) 08:39, 12 March 2012 (UTC)(formerly Kumioko)

• 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)

• 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)

Umm actually I would say this essay suggests that not all Wikipedians are equal.ShmuckatellieJoe (talk) 08:39, 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)
• Comment - I am a little troubled by a few of the comments that I see in this discussion. Several editors have made it sound as though being an admin should make one more trustworthy than an editor that is not. This is not, nor should it be the case. Many editors, such as myself, do not wish to be an admin. There are many tools that admins have that I thought would be useful, but not that would make me want to endure RFA to get them. Just because an editor is not an admin, does not mean they shouldn't be a trusted member of the community and I find the notion otherwise to be a tell as to why we are losing so many editors. ShmuckatellieJoe (talk) 08:39, 12 March 2012 (UTC)(Formerly Kumioko)

Exporting table data as CSV file

Just a small suggestion for added utility on pages containing table structured data.

The short version: Data contained in table format should have an option of exporting in various formats such as: CSV, XLS, XLSX, Tab Delimited, etc... This would allow for a quick way to manipulate and/or translate the data and the respective format of that data.

+++++++++++++++++++++++++++

The longer version/explanation and example use case: I'm a programmer working on a project that requires the storage of SMS/MMS gateways in order to formulate cell phone "email" addresses depending on the carrier the program is sending messages to.

I found the data I was looking for on this "List of SMS gateways" page on your site. The relevant data is contained in an ordered table on this page, but there is no way to export that data in a structured way. The print/export link in the margin of the website allows for PDF exports, but to extract data from a PDF file programatically requires a separate layer of case-specific coding that usually isn't worth the time invested.

My workaround was to use Microsoft Excel's Web Query feature in order to obtain this data in a structured way so that it can be easily manipulated and exported for various purposes.

In my specific case, the table data found on the list of SMS/MMS gateways page needed to be translated into a format compatible for importing into a database table. If the tables on Wikipedia had the option to export the data in various formats, I feel that many people would benefit from this utility.

+++++++++++++++++++++++++++

I imagine there might already be an API available for accessing & obtaining information from Wikipedia. If this is the case, my suggestion shouldn't be ignored completely, because using an API to obtain information requires special knowledge that I presume most visitors of this site do not possess. On the other hand, if my suggestion can be implemented, it would allow for a wider audience to participate in bulk data exports of table data.

Also, if by any small chance, there isn't an API established for Wikipedia yet, you should really look into developing one!

++++++++++++++++++++++++++++

Thanks for your time reading this... and thanks for providing an excellent means of providing and sharing knowledge to the general public. — Preceding unsigned comment added by CheeseConQueso (talk • contribs)

Of course there's an API. It's available at <https://en.wikipedia.org/w/api.php>. :-)

This is a very good feature request. I completely agree that having a little widget next to every table allowing easy export would be great. You should file a bug at Bugzilla. (Or I will shortly.) --MZMcBride (talk) 19:06, 10 March 2012 (UTC)

Why not just copy the table data and paste it into MS Excel or any other spreadsheet, then save it in whatever format you want? That's worked for the last decade... Franamax (talk) 19:34, 10 March 2012 (UTC)

Subtle notification of Article Talk page changes

As a user and editor, I would like to be able to easily distinguish whether an articles talk page has been changed since my last visit and or edit to it. Some of us have a lot on our watch list, and the chances of me missing an updated talk page is high. I don't think a big banner with flashing lights is necessary, but something subtle yet noticable, such as bolding the 'talk' button, or changing the font color could be useful. Mr.weedle (talk) 03:30, 11 March 2012 (UTC)

Just above the actual content of the watchlist is a dropbox that says "Namespace". If you select "Talk" from that and click the "Go" button, it will show you only the recent changes to talk pages. Slightly less convenient that having them highlighted amongst all the others, yes, but it should help a little. Keep in mind you'll have to switch back to "all" to get the non-Talk pages to show back up. —Scott5114↗ [EXACT CHANGE ONLY] 06:01, 11 March 2012 (UTC)

Gentry

I think that the Gentry article needs a major Gallery cleanup. For each country there is a gallery with people that are examples of its gentry. The people from each gallery are COMPLETELY RANDOMLY CHOSEN and this leads to two things:

1)The article becomes ridiculous and

2)Some old computers cannot afford such a large amount of images.--188.4.233.216 (talk) 13:46, 11 March 2012 (UTC)

It is kind of odd, especially given the fact that every section has been split to subarticles. The galleries should either be moved to the subarticles or removed completely.

That said, this isn't the place to bring it up. Talk:Gentry would have been more appropriate. :) --Izno (talk) 16:51, 11 March 2012 (UTC)

No one looks at talk pages. Especially in this talk page there is a proposal that has not been answered sonce March 2010...--188.4.233.216 (talk) 19:02, 11 March 2012 (UTC)

If you're getting no responses at the article's talk page, try Rfc. Per Izno, this isn't the appropriate venue. Thanks. --JayJasper (talk) 19:11, 11 March 2012 (UTC)

I tried what you said

So what if I try it the other way? It seems like I wouldn't get the same results... Thanks though.— Preceding unsigned comment added by 109.230.251.33 (talk)

Your comment has no context. What is it you are talking about? --Onorem♠Dil 17:00, 11 March 2012 (UTC)

Bot to notify admins of backlogs

We have 1500+ admins (several hundred of which are pretty active), yet we still incur large backlogs, especially at WP:RPP. Does this mean that we should have a bot to notify admins at AN (or, possibly, ANI) about backlogs?Jasper Deng (talk) 02:57, 12 March 2012 (UTC)

The script generally used to archive WP:RFPP will put up an admin backlog notice on that page when the queue reaches 10. An example of the notice may be seen in this version, just below the TOC. EdJohnston (talk) 03:19, 12 March 2012 (UTC)

Yeah, but admins do not see it unless they manually navigate to RPP.Jasper Deng (talk) 03:21, 12 March 2012 (UTC)