Jump to content

Wikipedia:Village pump (proposals)/Archive 60

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Pure wiki deletion, redux

I have created an extension, mw:Extension:PWD, that implements the pure wiki deletion proposal that was mentioned at m:Pure wiki deletion. Here is the PWD demonstration wiki. There were some early concerns about cross-site scripting vulnerabilities but I think I have cleared those up by adding code to send data through htmlentities before outputting it. Please let me know if you have any enhancement suggestions or bug reports.

In my opinion, there are four main arguments for implementing PWD. First, it enables non-sysops to verify for themselves that deletions were justified by policy; this can be of help at deletion review, where too often non-sysops are having to rely on outdated google caches. Second, it enables users to obtain deleted content without having to ask an admin for assistance; this is helpful not only for the author but for anyone who might want to port the content elsewhere (e.g. to another wiki) or to try to rehabilitate the article to meet Wikipedia standards (e.g. by adding reliable sources to demonstrate notability). Third, because it allows users to see the exact content community consensus saw fit to blank, it helps them to avoid inadvertently re-creating a similar article. Fourth, it improves the quality of the encyclopedia by allowing non-sysops to blank unacceptable articles. This is in accordance with the fundamental philosophy of a wiki, which is to make bad edits easy to correct rather than hard to make.

Of course, regular deletion and oversighting remain available for pages we are legally required to remove from view of non-sysops or non-oversight users, respectively. Therefore, a lot of the arguments raised at Wikipedia:Viewing of deleted articles by non-administrators and Wikipedia:Perennial proposals#Deleted pages should be visible are probably moot in reference to this proposal. Tisane (talk) 01:59, 14 March 2010 (UTC)

Please see Wikipedia:Perennial proposals#Deleted pages should be visible, and especially this comment by the Wikimedia Foundation legal counsel. -- Black Falcon (talk) 07:39, 15 March 2010 (UTC)
If you look at the specifics of the extension, user deletion and admin deletion are treated separately, so the legal aspect does not come into play here.--Father Goose (talk) 08:10, 15 March 2010 (UTC)

PWD allows regular users to "delete" a page non-destructively, extends or supersedes PROD, reduces the load on AFD, allows for a softer touch towards not-yet-notable articles (we can PWD them until someone comes with a notable source), etc. Seems like a useful and sensible tool for our toolkit, allowing us to reserve AFD and OVERSIGHT for the more hardcore cases. --Kim Bruning (talk) 13:34, 15 March 2010 (UTC)

Plus, this obviously addresses a number of admin accountability issues, by mooting them. ;-) --Kim Bruning (talk) 13:38, 15 March 2010 (UTC)

It's quiet, too quiet. Surely this can't be a "no opposition" shoo-in? <crosses fingers> --Kim Bruning (talk) 11:15, 16 March 2010 (UTC)

This is interesting. Is there any further opposition to implementing PWD at all? Else I'm going to make a nice page for it, get 7 days review, and if no opposition, will request it be installed. I'm a no-nonsense, no-big-noise kind of person. Here's your chance to yell before "those other people" implement something you didn't want. ;-) --Kim Bruning (talk) 15:38, 17 March 2010 (UTC)
I wouldn't put too much effort into this. Once it is advertised a little better and I'm sure the opposition will come rolling in. –xenotalk 16:01, 17 March 2010 (UTC)
The extension needs a huge amount of technical work before it can be enabled; Tim will take one look at the raw mysql_* functions and give up security review in dispair. Happy‑melon 16:08, 17 March 2010 (UTC)
Bear with me, I had some hardware issues (namely, a hard drive failure) that I had to deal with, but I expect to implement all the changes that were suggested by Mr. Z-Man within the next few days, including substituting the wrapper functions for the raw mysql functions, as you suggest. Tisane (talk) 18:49, 17 March 2010 (UTC)
An idea does not earn a spot at WP:PEREN without there being significant opposition to it. I do not deny that it could be tempting to shoo-in the proposal based on this thread—<wide-eyed expression of innocence>"Well, no one said we couldn't..."</halo> —but I hope no one will actually activate the extension on any Wikimedia project without a clear consensus to do so reached through a publicized and active community discussion at that project. -- Black Falcon (talk) 18:09, 24 March 2010 (UTC)
I think that there has been perennial confusion about what this proposal consists of. People have lumped it in the same category as WP:Viewing of deleted articles by non-administrators (including in the former WP:PEREN listing) when really it is something entirely different - i.e. a proposal to switch from an inadequately nuanced two-tier hierarchy of deletions to a three-tier hierarchy, with different gradations depending on who really needs to be barred from access to the content: Oversight via RevisionDelete for stuff that presents such a grave danger of legal action that it needs to be barred from viewing by practically everyone; regular deletion for illegal stuff that is not important enough to bother the Oversighters about, or as a temporary measure taken by sysops while awaiting oversighting; and then pure wiki deletion for everything else we delete (e.g. everyday Vanispamcruftisement).
It should be noted too that PWD will not necessarily lead to a change in processes. True, every user will have the power to blank or unblank. But the authority to do so remains in the hands of community consensus. A blanking or unblanking contrary to consensus will be treated like any other edit that is contrary to consensus, and pages subject to blank/unblank wars will be treated in the same way as pages that are subject to edit wars.
Looking at the !vote tallies at WT:PWD, it doesn't look like the opposition had the upper hand numerically, and in any case, I think the stronger arguments are on the side of the PWD crowd. The side with the stronger arguments is supposed to prevail. I think this proposal didn't go anywhere in the past because writing the implementing code was not considered a high priority, but progress is being made on the code now. Where would we advertise the PWD discussion if not at the village pump? I guess we could post a notice on everyone's watchlist, as we did for BLP. Tisane (talk) 18:50, 24 March 2010 (UTC)
(edit conflict) I don't think there is any confusion: the three-tier system you describe ultimately has the effect of allowing the viewing and restoration of pages by any registered user (perhaps with some minimal requirements) that, under the current two-tier system, would be deleted.
I expected that you would consider the "stronger arguments [to be] on the side of the PWD crowd", else why would you work on the PWD extension? I disagree, of course, and think that this proposal didn't go anywhere in the past not because the code didn't exist but because concerns about problems inherent to PWD were not addressed.
I did not mean to suggest that the village pump is not an appropriate place to advertise PWD, but I think that a much more publicized process (RfC, lasting 30 days, advertised here, on policy talk pages, at {{cent}}, and via a watchlist notice) is needed to determine whether consensus has changed in favor of implementing PWD. Implementing PWD is a change on the scale of implementing FlaggedRevs for all articles (which I now support, incidentally), and it is a more significant change than both Wikipedia:Community de-adminship and "BLP deletion", and those topics have involved weeks or months of discussion by hundreds of editors; the level and prominence of the needed discussion should reflect the significance of the proposed change. -- Black Falcon (talk) 19:10, 24 March 2010 (UTC)
  • Question. Is this extension used anywhere other than the demonstration wiki? The concept is interesting, but I (and I'm sure many others) would have a serious concern about implementing an experimental extension on en-wiki, particularly one that still has a big security warning on its mediawiki page. English Wikipedia is a huge, high-profile, high-traffic site. Getting the extension into live use on a lower-traffic wiki (whether a Wikimedia project or not) would be a better first step. --RL0919 (talk) 16:08, 17 March 2010 (UTC)
    Is there another wiki you would like to suggest? (After all the technical issues mentioned above are addressed, of course) Actually, isn't that what the test wikipedia is for? Tisane (talk) 18:49, 17 March 2010 (UTC)
    I don't have a particular one in mind, but I mean a live, used-in-the-wild wiki, not a test or development wiki. Among Wikimedia Foundation projects, there are many, such English Wikiquote and English Wikinews, that are a tiny fraction of the size of English Wikipedia. There are also many non-WMF sites using MediaWiki software. Or depending on language skills, you might be able to get a non-English Wikipedia project to explore this. Any way you go, starting with the world's largest wiki as your first non-test deployment seems unwise. All policy and legal arguments aside, I don't think you'll get much traction here without some other site going first. --RL0919 (talk) 14:27, 18 March 2010 (UTC)
    Meh, I'm not even that worried about that. But it does need to pass code review, of course. :-) --Kim Bruning (talk) 18:38, 18 March 2010 (UTC)

The extension appears to be nearing the end of the first stage of code review; most of Mr. Z-Man's suggestions, including use of the database wrappers, have been implemented in v1.0.0. Does anyone have further input on the PWD concept? Tisane (talk) 20:42, 20 March 2010 (UTC)

I'd like to echo xeno's comment: PWD was rejected every time that it was proposed (and it has been proposed, in one form or another, many, many, many times), and nothing short of a major change in consensus (or imposition by the Foundation) will result in its implementation on en.wikipedia. -- Black Falcon (talk) 17:17, 24 March 2010 (UTC)
  • Things are deleted for a reason. If they are still widely visable they are not deleted. Unless the extension can prevent offsight linking it cannot be considered deletion by any reasonable standard.©Geni 18:39, 24 March 2010 (UTC)
Agreed. I doubt that the Foundation's legal opinion is different for this proposal than it was for "view deleted" and before further discussion occurs, those in favor of PWD should first request the Foundation's legal advice because there is nothing more pointless than to discuss something that the Foundation will not allow to be implemented anyway. Regards SoWhy 19:00, 24 March 2010 (UTC)
An interesting proposal, I wouldn't mind supporting it. Prodego talk 19:54, 24 March 2010 (UTC)

@Geni: "Things are deleted for a reason." Consider, though, that an article deletion is just a deletion of revisions (it just happens to be a deletion of all the revisions in the article). From that view, where is the consistency in our regular practice of leaving spam and such in the history of a page, where anyone can access it and link to it from external sites, but deleting all the revisions of other articles for the same infraction, just because there were no good revisions in the article alongside the bad ones? Consider this permalink: http://wiki.eso.workers.dev/w/index.php?title=Portable_Document_Format&action=historysubmit&diff=351826562&oldid=350421875 . The revision as of 20:33 (GMT) 24 March 2010, including the linkspam, will remain in the history and anyone can link to it externally, but no admin feels a need to delete that revision. Indeed, even if the whole page had been replaced with spam, that revision would have been reverted, not deleted. Why? It's the same concept.

Also, as Jimbo put it, "Wikipedia's success to date is entirely a function of our open community." Deleted articles are one of the few aspects of Wikipedia that are not open to the public, and the encyclopedia is the worse for allowing that exception. An article's non-notability or non-verifiability or spamminess or whatever, absent libelousness or copyvio or confidential information or whatnot, simply is not a good enough reason to compromise one of our most important principles. Tisane (talk) 20:58, 24 March 2010 (UTC)

The problem of people linking to past revisions is a known issue and has resulted in revisions being pulled when the problem has become significant (someone used a past revision on de to try and spread malwarea few years back for a rather extreme example). There is the broader issue that wikipedia is not a free webhost. Past revisions of wikipedia articles are an extemely poor webhost. PWD stuff not so much. If you want to know what is being deleted see CAT:CSD or Special:NewPages (admins are not that fast).©Geni 23:15, 24 March 2010 (UTC)

Having now tested it on the supplied wiki, I should note that PWD deleted articles are far different than admin deleted articles - admin deleted articles are not visible to intrepid lookers, while PWD deleted articles are. We should continue to use old-wiki-deletion for libel, disputes and problematic articles. PWD would appear to be prod-lite. I don't see how it's a bad thing. I wonder if it could be a user-right like rollbacker - PWDer - who could pure-wiki-delete something, while blanking by non-PWDers would instead result in a blanked article. Hipocrite (talk) 20:52, 24 March 2010 (UTC)

Or the non-PWDers could simply be forbidden from blanking articles. Although I think a better solution is to use our existing semi-protection and protection tools to guard articles that are under a lot of attack from people inappropriately blanking or unblanking them. And of course, people can scrutinize the blank log to make sure that everything's kosher. Tisane (talk) 21:00, 24 March 2010 (UTC)
  • Strong oppose:
  • Nearly half of the articles I come across tagged for deletion as advertisements (whether prodded or G11ed) are copyvios but no one has looked, or they didn't look hard enough, or didn't think they needed to look because a G11 was already in the offing and pretty clearly applied. A significant percentage of articles deleted on other bases are also copyvios. Every article in that boat that is blanked through this process leaves a copyvio publicly accessible and persisting. That pernicious result alone would make me oppose. Say I'm wrong on the numbers by an order of magnitude, say 1/32 are copyvios, and only 1/4 of total articles deleted were through this process. At 2,000 articles per day, in five years we'd still have 28,515 blanked copyvios through this process.
  • There is no well thought out process and mechanism, or at least I've not seen any discussed here, for reviewing these articles as they are undeleted/unblanked. If you told me that articles "deleted" through this process would automatically go through newpages upon undeletion, that would blunt my concern on this score. But unless that's the case, this is a backdoor to creating articles without going through newpages, which is the only centralized winnowing method we have for article creation. As I said, tell me this is not the case, but if it is, it would be even more of a disaster than I already foresee.
  • What methodology is proposed for making sure the person deleting through this process, instead of the existing "unviewable deletion" processes, has the discrimination to choose between this method and another? I think we can all agree that, at the least, copyvios, controversial or negative unsourced BLPS and pure attack pages should not be deleted through this process. It is not unusual to come across a brand new user tagging numerous articles at newpages with little understanding of the criteria. Same for prod and AfD. Well, now we get that type of helper blanking pages through this process without understanding what it should and what it should not be used for. There's no review process proposed. At CSD a highly experienced admin inevitably reviews beause that's the only way an article is deleted. Same for prod. At Afd a whole crew reviews. Here, the new user blanks and that's the end of it. Into the 'blanked catalogue' goes a page that should never have been deleted through this process and thereby stays publicly available. Oh, informally, someone might review but that's catch as catch can.
  • The legal issues inherent especially in attack pages and negative BLPs slipping into this roster (per above) is obvious. Once the number of the blanked articles grows to a huge number, it will become more and more likely that someone digging through will find they, or someone they know or someone they will inform for whatever reason, has been defamed because the publication (as that term is used in its legal sense for libel and slander claims) remains, or that there will be a later publication outside of Wikipedia of defamatory content that could not have occurred if the content was deleted in a regular way that hides it from view. There's no way to predict or stop that unless we can guarantee none would slip through.
  • More of a perennial objection to these types of proposal but I simply do not think we should have a vast viewable catalogue of what wasn't suitable when first posted, which will also make it far easier to recreate that unacceptable content. Where a user wishes to see or use deleted content they can request it, and if it isn't problematic, they get it. Yet, we are not flooded with such requests. Yes, there are some good results that would come from this but I see them as as a feather weighing against a mountain of bad potential.--Fuhghettaboutit (talk) 01:51, 25 March 2010 (UTC)
    • I believe one could make exactly the same criticisms toward deleted content (i.e., old revisions) in articles that are not themselves deleted. I agree with your suggestion that copyvios and other legally unacceptable material should be admin-deleted, not user-deleted -- what ideas do you have to make sure this is done more rigorously in articles that won't be deleted, as distinct from articles deleted via PWD?--Father Goose (talk) 05:33, 25 March 2010 (UTC)
      • It would be great if all prior copyvios and attack text in page histories was permanently removed. In other words, the fact that we don't do this presently is no good reason to create another repository where inappropriate content can be accessed. This content is also different for a number of reasons. Yes, we don't always act to permanently remove bad (possibly actionable) content (and sometimes we do, which would not happen here mind you) but it enters the system far more randomly. Here we will be focusing the bad content in one place; we will be blanking articles because they are inappropriate for some reason, so the archive it creates is a repository for what wasn't acceptable. The most critical difference between this content and deleted revision, however, is the ease and likelihood of discovery. These articles will for the most part be just a few revisions, if not just one, and because we're blanking, probably the most recent revision will contain the bad content, whatever its nature. This is apples and oranges to a copyvio or attack buried somewhere two or three hundred revisions ago. Think about it from the perspective of a person who finds they have an article on them or someone they know. The person goes to their article and reads it. Are they likely to look at every revision? They will have to stumble across the "bad version" and are vanishingly unlikely to do so often. Here the person sees an article on them was blanked, goes to look at it, and the version they will see when they unblank is the inappropriate version. It's night and day.--Fuhghettaboutit (talk) 02:26, 26 March 2010 (UTC)

A lot of so-called copyvios are self-promotional materials that the contributor owns the copyright on, and thus they become copylefted as soon as he hits the "Save page" button. But even when it is a legitimate copyvio, there are several things that tend to diminish the odds of our getting sued for having it buried somewhere in a page history. First, a lot of the copyright owners, e.g. advocacy organizations and such, don't mind having their content widely distributed, even if they didn't give permission. Second, most people come across Wikipedia articles through Google, which only caches pages for awhile after they're blanked. Third, most readers don't hit the History tab, much less go digging around for copyvios or other objectionable content. Fourth, most people, when they find objectionable content, don't sue; usually they remove it themselves or report it so that someone else can remove it.

It is highly doubtful that John Seigenthaler ever would have stumbled across his erroneous biography if it had been buried in the page history. And if it had gone undetected, and he had lived his whole life without ever having known about it or been harmed by it, what would have been the harm? Yet, even if he had known that it was buried in the history somewhere, would he have cared, given the small chances of anyone else, much less anyone important, stumbling across it? How often do we get complaints about stuff that's buried in page histories?

There is always going to be some tension between keeping old revisions around and preventing copyvios and other seriously objectionable content. If we wanted to take an extreme preventative stance toward copyvios, we could avoid keeping any old revisions at all, or schedule them for deletion when they reach a certain age. Surely there are a lot of cases in which someone, perhaps a newbie, uses their non-sysop editing power to revert a copyvio rather than seeking its deletion, but we accept that possibility as part of the cost of doing business, so to speak. We have countermeasures against such problems; e.g. if we catch someone doing a bad job patrolling, we can check their other contributions to see what they have been overlooking and correct their mistakes.

To some extent, those who oppose PWD because of the potential for illegal content that needs to be removed to be left in the revision history are caught in a Catch-22. If the content is in such an obscure place that no one will find it, then its obscurity will also tend to lessen the harm that it is likely to cause. If, on the other hand, the content is in a place where it will readily be found, then it is more likely to be spotted and admin-deleted. So the problem takes care of itself.

There is already a log of blankings and unblankings, but functionality can also be added to cause unblanked articles to show up in NewPages. Functionality can also be added to put a checkbox in Special:Preferences to automatically watchlist any pages that the user blanks or unblanks; that would help guard against re-creation of bad articles. If anyone wants to make a conditional statement of support, e.g. "I support PWD, provided that unblanked articles show up on NewPages," that is fine. Part of the purpose of this process is to generate ideas for enhancements that will be needed to make the idea palatable to the community. I think this reform is important enough that it is worth developing whatever other tools are needed to make it work well for us.

I think there is somewhat of a culture gap on Wikipedia, in that there are some users who spend most of their time adding content to the encyclopedia, and there are others who spend most of their time patrolling for bad content that needs to be eliminated; and it colors people's perspectives. People in the former group tend to have had bad experiences with their articles getting inappropriately speedily deleted and such, and have dealt more frequently with the frustrations caused by not being able to view articles that were deleted for notability reasons and whatnot. People in the latter group probably feel deluged by all the vandalism, spam, copyvios, etc. coming in, and want to avoid changes that will cause it to get worse. I hope that we can find creative solutions that will satisfy the concerns of both sides. Maybe something like CorenSearchBot can be developed to search revision histories for copyvios, for instance. Again, feel free to make conditional statements of support, which will make it possible to focus on those areas of concern that need to be addressed in order to achieve a rough consensus of support. Tisane (talk) 05:34, 25 March 2010 (UTC)

  • Strong oppose as a solution in search of a problem. What kind of articles would be eligible for this kind of deletion (and I expect the "Pure Wiki Deletion" name needs to be changed asap - it's a form of page blanking distinct from the random vandalism that is being proposed here) and based on what are they supposed to be subjected to a different process?

Currently, deletion is clearly defined in three groups and we have many control mechanisms in place to ensure deletion remains, as much as possible, a controlled process. We have speedy deletions for entirely uncontroversial deletions, and the so-called PWD would, at best, only be able to supersede some of the A7/A9 cases. I'll get back to why I see replacing those with PWD as a bad idea a bit below. We have PROD, which comes with a deadline to contest or (ideally) address the issues presented. And we have AfD where deletion only occurs after a policy-based consensus is established and a deadline. These are relatively strong safeguard against wanton removal of content, performed by people that have been vetted by their fellow editors as having (most likely) enough good sense to only delete what is required. And we have DRV to review any deletion decision.

Still, deletion even under the above conditions has been cause for strife time and time again. What is proposed here, presently, is to give vast numbers of people the ability to shotgun delete pretty much anything without framework nor delay. Reducing the workload at AfD? How so? Even under the best conditions, a significant portion of the arguments played out at AfD would suddenly be shifted over to ANI, with considerably more drama and WP:BITE potential.

So what would be deleted through "PWD"? Replacing the CSD A7 / A9 deletions? There's perennial debate about what constitutes a statement of importance over at WT:CSD for what are, already, the more contentious CSD criteria.

Copyvios? No way. The qualification of "corporations are OK with their content being reused if it makes them good publicity" is completely naive and ill-informed. Yes, corporation XYZ is definitely fine if random employee alpha reposts the content of their website on Wikipedia, even without explicit permission to do so. It can be verified often enough through the application of WP:NLT that your average corporation is a lot less happy when the same information gets subsequently modified and the article suddenly starts echoing negative press about them. That's when the legal threats start flowing in, and when copyrighted material that was posted without verifiable permission is present, it poses an immediate and additional threat to Wikipedia. I don't see how PWD could help for any of that.

Automatically deleting old revisions over time is a proposal that immediately infringes upon our own licensing terms with our contributors, who retain the right of having their work attributed to them through the article's history. I again cannot help but see that as an ill-informed and extremely naive attempt at defending at all cost a code snippet that has no practical reason to exist. Feature creep at its best.

Anything else? I don't know. As I said above, this is a solution in search of a problem. It's also one that has a huge potential to increase drama tied to "deletion"-type activities by several orders of magnitude. MLauba (talk) 09:59, 25 March 2010 (UTC)

Actually, I expect that, in addition to PROD and AFD, PWD would be useful for:
  • G1 (patent nonsense), G2 (test pages), G3 (pure vandalism and blatant hoaxes), G4 (recreation of a page that was deleted per a deletion discussion), G5 (creations by a banned or blocked user(s)), G8 (pages dependent on a non-existent or deleted page) although this CSD should probably be abolished, G11 (unambiguous advertising or promotion);
  • A1 (no context), A2 (foreign language articles that exist on another Wikimedia project), A3 (no content), A5 (transwikied articles), A7 (no indication of importance (individuals, animals, organizations, web content), A9 (no indication of importance (musical recordings)), A10 (recently created article that duplicates an existing topic);
  • R2 (redirects from the article namespace), R3 (implausible typos);
  • C1 (unpopulated categories);
  • U2 (nonexistent user);
  • T2 (misrepresentation of policy), T3 (duplication and hardcoded instances); and
  • P2 (underpopulated portal).
I expect that PWD would be inapplicable for:
  • G6 (technical deletion), G7 (author requests deletion) although some authors might be content to just blank their content, G9 (office actions), G10 (pages that disparage or threaten their subject), G12 (unambiguous copyright infringement);
  • F1-F11;
  • C2 (renaming or merging) which should be handled through redirects;
  • U1 (user request) although some authors might be content to just blank their content; U3 (non-free galleries); and
  • P1 (any portal that would be subject to speedy deletion as an article).
The mention of "automatically deleting old revisions over time" or otherwise deleting old revisions was an attempt to show the consequences of taking the idea of minimizing the potential for copyvios to its logical extreme. I am not saying either that copyvios should be condoned; but I think their occasional unnoticed presence on an open wiki is inevitable, and that built-in factors do, steps can be taken to, reduce their presence and mitigate their impact on the project. For instance, edits by anons and new accounts should and do draw more scrutiny than edits by established users, and when we catch an established user introducing copyvios, we usually check his other contributions for copyvios. I don't see convincing evidence to indicate that this is going to be as big a problem as people think, but it is true that I don't hang around Special:NewPages very much. When I have hung around there, it seemed that the copyvios were usually pretty blatant and easy to detect and verify by a Google search. Tisane (talk) 18:05, 25 March 2010 (UTC)

As happened in previous PWD debates, there seem to be about half in favor and half against. Perhaps the best course of action would be to try PWD at a smaller wiki, perhaps one with about a dozen active contributors. Then it could be tried at larger wikis, and eventually at one of the smaller Wikimedia projects, and then this proposal could be raised again at enwiki if the results have been good elsewhere. That would allow for experience to make clearer what other anti-copyvio, anti-libel, etc. measures need to be introduced along with PWD to make it work well, and it might dispel some of the concern about various "what-if" scenarios by showing what happens in practice. Tisane (talk) 20:39, 25 March 2010 (UTC)

It would have to be tested in a smaller wiki first anyway. You don't know that it would even work without blowing up the site. Reach Out to the Truth 03:03, 28 March 2010 (UTC)
Don't worry about performance. Any code will be reviewed by a sysadmin for security and performance before it is deployed. All the community needs to worry about is the policy aspect unless told otherwise. Mr.Z-man 04:11, 28 March 2010 (UTC)
While I don't think that anyone should (or can, for that matter) prevent a test of PWD in a small wiki whose members consent to the test, the results of such a test will not be readily generalizable to larger projects. Many of the problems with PWD will not be present on a wiki with only a dozen contributors and a few hundred pages, as opposed to thousands of contributors and millions of pages. -- Black Falcon (talk) 20:00, 28 March 2010 (UTC)
Indeed. I think that pure wiki deletion here would lead to newbie biting, edit warring, and bad blood all around. The processes in place generally work fine. The first three arguments proffered are essentially non-issues: there is a whole category of admins willing to provide users with deleted content. –xenotalk 21:22, 28 March 2010 (UTC)
By that same logic, couldn't we say that it's a non-issue that FlaggedRevs would not allow a user to singlehandedly cause an edit to go live? After all, he can still make it go live; he just needs the assistance of an admin or reviewer. The problem with requiring admin assistance in situations where it shouldn't be necessary is that the extra step is a hindrance. In practice, most users at a DRV will not ask an admin for a copy of a deleted article; they will just vote based on what they see in the cache, which may or may not be a good snapshot of what was deleted. And what matters is not what works in theory but what works in practice. We can deduce what happens when one introduces hindrances to the open wiki editing process by seeing the fate of projects like Nupedia and Citizendium that imposed too many restrictions. Our own recent statistics don't bode well either, but that ties into some larger issues than just PWD or the lack thereof.
By the way, which is more BITEy to newbies — a page being blanked or being tagged for speedy deletion and then deleted before they have a chance to figure out how to respond? With PWD, a blanking user, or a bot, might post a notice on the newbie's talk page saying something to the effect of, "Thank you for contributing to Wikipedia. The article x that you recently created has been blanked because of y, but a copy of it is still available here [provide link]. If you can address the concerns, feel free to unblank." Tisane (talk) 12:47, 30 March 2010 (UTC)

As part of the testing process, PWD has been implemented on Libertapedia. Tisane (talk) 06:54, 29 March 2010 (UTC)

Technically this looks like a good thing to me; it's very tempting. But if this is implemented we will have to change a lot in our processes. Since the English Wikipedia is so mature, this will result in additional rules and processes on top of the existing ones and make things more complicated. There will be rules about who is allowed to blank in what kind of situation. Blank-warring will be considered more serious than normal edit warring. Maybe there will be a new rule that for some types of AfD the article is blanked before the discussion, leaving a link to the AfD in the edit summary. Then more people than usual will participate without even looking at the article, so a link to a previous version will be added. This link will go either to the secure version or the normal one, which is bad for several reasons including that normally you are only logged in on one of them. I know it's silly, but I predict that there will be a new possible outcome "blank" in AfDs, making them more complicated.
For these reasons I reluctantly oppose [changed my mind, see discussion with Kim Bruning below] PWD for this particular wiki – unless and until we get some kind of reform or revolution in which we scrap most of our rules and processes and restart. I think this would be a good thing, but it's unlikely to happen in the near future. Hans Adler 08:25, 29 March 2010 (UTC)
I think that blank would replace delete as an option in debates, rather than being an additional option. Notice that you never see people voting for oversight in deletion debates on enwiki, despite the fact that we have that second tier of deletion. The reason is that oversighting is reserved for cases meeting very specific criteria, much like deletion on a wiki using PWD. Those criteria (copyvio, libel, etc.) are less subjective than, say, notability or WP:NOT, and therefore debate is not needed in those cases. Tisane (talk) 09:05, 29 March 2010 (UTC)
No, I disagree. If all AfDs were automatically about blanking rather than deleting, then non-admin closures of AfDs would become the norm after a while. I don't want to see the resulting battles between inclusionists and deletionists. We already have occasional problems with admins closing debates controversially, closing them half a day early, and sometimes even both at the same time. If the two of us can't even agree about this basic point, it's clear that there will be a lot of long discussions about all the details of the required changes after the extension is in place. I just don't believe it's worth it. Hans Adler 09:16, 29 March 2010 (UTC)
Hans, we can either scrap all our rules at once, or we can place new rules alongside, and obsolete the old system piece-wise. My preference is for the latter, and it has worked quite well several times. (Fixes for MEDCOM, AMA, AFD, etc were all implemented this way )
If you oppose my preference, and I oppose your preference, then we are deadlocked and cannot fix the rules at all. ;-) Can we resolve? :-) --Kim Bruning (talk) 11:42, 30 March 2010 (UTC)
OK, you comment suggests that what you have in mind is basically abolishing the deleting altogether and replacing it by blanking, which everybody can do. Of course someone will still have to be able to delete, perhaps still the admins. But it will become more like hiding revisions. Is that what you have in mind?
If that's what you mean, then I agree. The problem is that while there seems to be something like a consensus for introducing PWD, I can't see how much of it is only the normal enthusiasm for cool new features and how much of it actually agrees with your vision of how to reform our policies once we have it. What I have described is what's going to happen if we get PWD and there is no consensus to make standard deletions obsolete, and I don't like it because it implies massive policy creep rather than replacing the existing rules by new ones. I am not familiar with your three examples, but it appears that AMA was "fixed" by just abolishing it, and MEDCOM and AFD were fixed by replacing existing process with new process. I can support PWD if it comes in a package that ensures that something similar will happen.
This would require a big RfC proposing a package deal to (1) add the PWD feature, (2) reform AfD by removing the "delete" option and replacing it with a "blank" option, (3) reform the Speedy system by removing criteria that will be required by BRD-style blanking, (4) creating a consistent policy (or set of policies) for oversight, revision hiding and deletion. Perhaps we can leave out one of the points and do it later. What is crucial IMO opinion is combatting our natural (collective) inclination to simply stack new rules on top of existing ones. Hans Adler 11:59, 30 March 2010 (UTC)
I agree. While I believe that this proposal could make things a lot simpler and more natural to our wiki-ways, a lot of thinking and discussion will be needed about how the policies and guidelines would need to adapt to it. Just enabling it might lead to chaos (or it might not). — Martin (MSGJ · talk) 12:24, 30 March 2010 (UTC)
FYI, WP:AMA was replaced by WP:EA
As I already implied earlier, I am opposed to RFC's, proposals, package deals, and Big Process in general. People bite off more than they can chew, babies get thrown out with bathwater, there's lots of drama, it is hideously inefficient, and it's very much an all-or-nothing affair. I have not and will not ever submit a policy proposal, RFC, or perform a vote [1]. These fail >90% of the time, and therefore I do not consider these methods to be germane to wikipedia.
Analogous to agile process and the wiki-way, it's simpler, quicker, easier to put small nimble processes in place step by step and piecemeal, and let people flock to them naturally. Sometimes this doesn't get you 100% of what you want; and you may need to bend to consensus a little; but worst case you will always get at least a couple of steps closer to your objectives. Sometimes people might even come up with better ideas than the one you started with. ;-)
--Kim Bruning (talk) 13:06, 30 March 2010 (UTC) [1] Disclaimer: "Use the right tool for the right job" applies here. This is my position on process for on-wiki. For IRC or for other communities or systems you might see me at, I might advocate other approaches as is relevant for those communities.
I agree with this approach in general, but it can lead to ever more complicated structures when we simply pile new processes on top of the existing ones. When I joined this wiki 2 1/2 years ago it was already so complicated that it took me rather long to understand most of it. Since then several features and processes have been added, and not much has been removed or simplified. We are soon going to get some form of sighted or checked revisions (I hope), which will lead to a new level of bureaucracy. PWD would lead to yet another level of bureaucracy. I am very pessimistic w.r.t. any form of streamlining. The German Wikipedia recently managed to merge GA, FA and FAC into a single system that is working quite well, easy to understand, keeps the FA and GA communities together, and ensures that the gap between FA and GA quality remains. If I was aware of any similar reforms here that reduced bureaucracy, then it would be much easier for me to support this new feature. But it appears to me that this wiki has so many full-time busybodies that the introduction of any new piece of bureaucracy becomes essentially irreversible. Hans Adler 15:27, 30 March 2010 (UTC)
PS: Immediately after pressing "Save page" I remembered WP:SPI. Perhaps it is possible, after all. Hans Adler 15:27, 30 March 2010 (UTC)
At one point, I wanted to replace all of policy with WP:5P (to make a long story short), that didn't quite work out either.
I think we're not agressive enough about retiring old processes, perhaps. I would really like to replace PROD with PWD (PROD is really PWD lite, as we couldn't get the technical issues fixed previously), and then gut CSD, which has somehow devolved from its origins a means to apply WP:COMMON sense to a bureaucratic nightmare.
I think the only way to prevent bureaucracy is to constantly churn through "dead" processes. (By dead process I mean a process that has stopped growing and learning, and instead has built a fort and is fighting off anyone who tries to change it. "This process is non-negotiable" is a good clue there... ) --Kim Bruning (talk) 16:04, 30 March 2010 (UTC)
OK, blanking replacing PROD is a good point, and with some luck it will work as an unrest cure for some of the more ossified processes. I am still not entirely convinced (perhaps I just need to sleep over it), but for the moment I don't see a reason to oppose. Hans Adler 16:13, 30 March 2010 (UTC)

It would appear that thus far there is a slight majority opposed to PWD, and that the discussion has slowed down/stopped. Should this be taken to Wikipedia:Centralized discussion/WP:RFC; or is it better to do what I proposed above, which is wait until other wikis have had a chance to demonstrate how well PWD works; or should we try to figure out some way to proceed in the wiki way, as Kim Bruning suggests? Tisane (talk) 13:47, 1 April 2010 (UTC)

Marking reverts

I worry about reverts sometimes in my watchlist whether they are real reverts of vandals just changing the count of changed character back to zero and putting in a deceptive message. What I think I'd like is for the system to actually put in a database marker where it is certain it is a revert and the start of the message would be fixed by the system. That way the watchlist could automatically cut out or dim the intervening edits or otherwise make it obvious I could ignore them unless I really was interested in seeing what a reverted edit was about. Anybody else feel this would be a very worthwhile improvement to watchlists? Dmcq (talk) 17:52, 28 March 2010 (UTC)

Are you asking for some new type of edit filter? Airplaneman ✈ 20:51, 28 March 2010 (UTC)
It could be used to drastically cut down on the number of edits to check if that's what you mean. Dmcq (talk) 08:14, 29 March 2010 (UTC)
Remember that sometimes, a vandal will actually do a real revert to an earlier, vandalized version, so this would not be fool-proof. PleaseStand (talk) 23:30, 28 March 2010 (UTC)
You wouldn't lose anything either. What you are saying is that people editing would point out an article and you might then vandalism in it. If you had more time free from checking fo vcandalism you'd have more time for spotting vandalism in the first place. I guess what you are saying is that if one completely hid the reverted edits you mightn't spot there is an edit war that a vandal is winning. If one dimmed or put in a count of the intermediate edits in the list of edits instead of completely suppressing them it would be obvious who did the edit that is currently live and whether there was a war on. Dmcq (talk) 08:14, 29 March 2010 (UTC)
I think this could be useful, but unless somebody implements this in JavaScript, it would require software change and I think that flagged revisions (particulary patrolled revisions) will be actually implemented sooner than this would and they are able to do something even better, although not automatically. Svick (talk) 21:08, 29 March 2010 (UTC)
In JavaScript? That wouldn't solve the problem. As to flagged revisions: it is a misconception that under the flagged revisions system, users propose changes to the published version of the article. All changes would in fact be immediately applied to the latest (unstable) version (which subsequently is reviewed and approved for publication) and therefore the situation would be no different for editors reverting vandalism (it is just that it is hidden from readers). In contrast, patrolled revisions (which have nothing to do with the revision shown to readers), as long as all patrollers can be trusted, might be helpful to prevent wasted effort in RC patrol. PleaseStand (talk) 22:30, 31 March 2010 (UTC)
I had been thinking it would be implemented in the database support for the wiki. It sounds very expensive to do automatically on all watchlists and thats what you want for better vandalism checking. It this was in the database and done when pages are saved it might be possible to stop saving about a quarter or so of all the pages I guess, it would be particularly cheap for revert wars. For all I know they might already have all the information there because of this saving. Dmcq (talk) 22:04, 1 April 2010 (UTC)

Suggestion for a new user talk template message

I was thinking that there should be a user-talk page template message to warn users who do not finish the AFD process properly, as I see this kind of thing all the time. I have drafted up a proposed template message here. Tell me what you think. Ten Pound Hammer, his otters and a clue-bat • (Many otters • One bat • One hammer) 16:34, 31 March 2010 (UTC)

Looks good, though I would suggest that you expand on the "ask someone to help you" bit, as it might not be especially obvious how they can ask someone for help, if they're a new user. --Deskana (talk) 16:42, 31 March 2010 (UTC)
Looks very good now! :-) --Deskana (talk) 16:44, 31 March 2010 (UTC)
Good one, but should be made clear it is a "notice" and not a "warning". I do believe this belongs at WT:UW, though (ironic-I know). –xenotalk 16:46, 31 March 2010 (UTC)
Looks good; definitely would be useful. Airplaneman ✈ 23:09, 1 April 2010 (UTC)
I like it. BTW, I added as it is featured in a lot of other notices. NERDYSCIENCEDUDE (✉ message • changes) 23:15, 1 April 2010 (UTC)

The Unfinished Puzzle Globe

It seems obvious to me that Wikipedia should have an article about its logo, The Unfinished Puzzle Globe. Come on Wikipedia it shouldn't be hard to find information about this unique and thought invoking logo. — Preceding unsigned comment added by 128.157.160.13 (talk) 23:48, 31 March 2010 (UTC)

There is Wikipedia:Wikipedia logos, but it's not an actual (encyclopedic) article. And there is also meta:Wikipedia/Logo. Svick (talk) 00:15, 1 April 2010 (UTC)
Shouldn't someone get around to finishing that thing? I mean, it looks to me like there's only a few pieces missing. It shouldn't be that hard. Tisane (talk) 00:25, 1 April 2010 (UTC)
They're working on filling in the unseen back pieces, for an official 3d version...
The errors might even get fixed some day... meta:Errors in the Wikipedia logo and meta:Talk:Wikipedia/Logo, etc.
The last time I asked, in October, someone was doing something about it. I've heard nothing since then. -- Quiddity (talk) 00:27, 1 April 2010 (UTC)
You should read the current Signpost then. --Cybercobra (talk) 01:00, 1 April 2010 (UTC)
Woohoo! ty. -- Quiddity (talk) 02:25, 1 April 2010 (UTC)
I just tried to create the article and found that it was deleted in 2006 and is now protected from recreation. It is obviously a worthwhile and notable subject. There is no reason why it should not exist. The matter seems to be stuck in bureaucracy. So, I wrote to Jimbo in hopes of getting things done. I am just wondering if there is an admin who can simply undo the protection so that I can start Wikipedia logo? I would be very interested to see what arguments can be made for speedy deletion once it is made. Best, Anna Frodesiak (talk) 03:37, 1 April 2010 (UTC)
Do you have any reliable sources for it? The article that was deleted was mainly original research and content from various projectspace and meta pages. It had only one real secondary source that discussed the logo for 2 sentences. Mr.Z-man 04:35, 1 April 2010 (UTC)

Wikipedia:Wikipedia_logos is a fine source with refs. Really, I think this is all just about moving it to the mainspace so that visitors can get there directly. Anna Frodesiak (talk) 08:25, 1 April 2010 (UTC)

Please see Wikipedia:Deletion_review/Log/2010_April_1 Anna Frodesiak (talk) 21:14, 1 April 2010 (UTC)

Create a sanitized oversight log for general consumption

I propose that when WP:OVERSIGHT is exercised, that a publicly-viewable log entry be entered describing who suppressed content from what article and, in general terms, why, e.g. "User:Cool Knight Fozzie removed libelous content from John Seigenthaler per oversight team consensus." This would increase the transparency of the process without providing the actual content that oversight is designed to remove from view. Presently, when oversight is done in controversial cases, people sometimes end up speculating "Why did the content go away? Who did it? Was it an office action?" This would at least answer a few questions and let people know who to ask if they still have concerns.

The counter-argument might be raised, "But this will draw attention to it and make people look at Google caches and other sources for it." Possibly, but would any court find fault in us for merely noting the removal of content that was against our policy to begin with and is no longer on our site? I doubt it. Some stuff we have to remove, but if we get paranoid about legal threats to the point that we allow them to hinder our openness and transparency more than is necessary, then "the terrorists have won," so to speak.

It might also be argued, "This is a solution in search of a problem; can you cite any cases of oversight abuse?" Well, that would be hard, wouldn't it, given that I'm not an oversighter. That is the whole problem; the community elects the ArbCom to oversee oversight, but we as the community, in our capacity as voters, are not in a good position to exercise effective oversight over the overseers of oversight themselves, partly because, whether deliberately or by oversight, no one made it possible for us to view even a sanitized oversight log. (And I'm beginning to see why people want to rename it "suppression.") Tisane (talk) 15:33, 1 April 2010 (UTC)

SUPPORT. Cleanliness is something we should strive for, and any oversight log deserves to have the same cleanliness. One thing though, what should we sanitize the log with? Draconiator (talk) 16:12, 1 April 2010 (UTC)

  • Oppose—it creates needless work. Every oversight for which it is deemed appropriate to leave some sort of record already has one (like this edit, for example); for those oversights which are more subtle and don't have anywhere obvious to be logged "in situ", there is a clear reason not to publicise them. I trust the oversight/audit teams to act responsibly and to keep a decent check on each other. ╟─TreasuryTag►assemblyman─╢ 16:16, 1 April 2010 (UTC)

There is no need for this; there are reasons the supression log is private. You can see if content has been oversighted or not anyway. If it has been admin-level revision deleted, the oversighter and the reason are displayed in the deletion log. If it has been oversighted, it must follow one of the criteria in WP:OVERSIGHT, so the number of reasons is limited anyway. We have the audit subcommittee to make judgements on the use of oversight. I fear that if this is implemented, there will be unnecessary discussion about the legitimacy of an action for content that most users can't even see. All concerns should be sent to oversight-l or the subcommittee for review. PeterSymonds (talk) 16:21, 1 April 2010 (UTC)

Sorry, but no. This is not one of the areas of Wikipedia where transparency is needed. EVula // talk // ☯ // 16:31, 1 April 2010 (UTC)

Also no. Your first counter argument implies that the only reason we oversight things is to protect ourselves legally. While this may be the case, we also do so to protect the privacy of the individuals involved, which is more important IMO--Jac16888Talk 16:44, 1 April 2010 (UTC)
Does the log entry harm privacy, if it just says "So-and-so removed content from x for user privacy reasons"? Tisane (talk) 16:47, 1 April 2010 (UTC)
No, but as you said "this will draw attention to it and make people look at Google caches and other sources for it." So while this isn't technically down to us, it goes against the spirit of wikipedia--Jac16888Talk 16:56, 1 April 2010 (UTC)
If you just want to be able to see a list solely comprising entries which read, "So-and-so removed content from x for user privacy reasons" then you can make your own using any word processing software. But such a list would be of no use whatsoever! ╟─TreasuryTag►First Secretary of State─╢ 16:59, 1 April 2010 (UTC)
Indeed; my last five suppressions all have the exact same summary: "Non-public identifying or personal information". Oversighters generally don't add a whole lot of context to suppression summaries because it doesn't matter. EVula // talk // ☯ // 21:05, 1 April 2010 (UTC)

Notify of proposal to automatically include a unreferenced template

There is a discussion at WP:FOOTY to automatically include an unreferenced template if {{Fs start}} is not referenced. Currently there is support for the change but WP:BAG wants a support consensus. PLease have a look Gnevin (talk) 18:09, 19 March 2010 (UTC)

Time to become a democracy?

Maybe it's time for WP to become a democracy. Maybe WP:CONSENSUS and WP:IAR do not scale to this size. Maurreen (talk) 08:52, 7 March 2010 (UTC)

What makes you say that? I don't know about you but I'm not ready to give up on WP:CONSENSUS. -- Ϫ 09:59, 7 March 2010 (UTC)
Exhibit A. Maurreen (talk) 10:08, 7 March 2010 (UTC) Mainly the BLP mess -- Exhibit A -- Exhibit B, including the archive and talk page. -- Maurreen (talk) 10:19, 7 March 2010 (UTC)
Heh, point taken. But maybe democratizing would bring it's own new set of problems. Including splitting us up into warring factions. United we stand, I say. :) -- œ™ 10:27, 7 March 2010 (UTC)
Only if we can trade our votes. Representative democracy is not an improvement over WP:CONSENSUS. Paradoctor (talk) 10:57, 7 March 2010 (UTC)
There's also the issue of socks voting... Anyways, Consensus is quite effective. WP is an organization anyways, so its more of a constitutional monarchyManishEarthTalk • Stalk 12:38, 7 March 2010 (UTC)
And Jimbo is the monarch? :P No, it is a direct democracy with decision by consensus and not by majority, which I think works better. It also helps from avoiding problems mentioned above. --JokerXtreme (talk) 12:52, 7 March 2010 (UTC)
I tend to think of him more as Citizen J. ;) Paradoctor (talk) 13:13, 7 March 2010 (UTC)

Consensus is the best way to reach a decision. Unfortunately it can't apply to countries as reviewing stuff would be a headache. But it works fine here. Mindless voting without reason doesn't have much merit. Here, The better your reason for voting, the more strength your vote has. ManishEarthTalk • Stalk 12:54, 7 March 2010 (UTC)

Direct democracy was in use in ancient Athens, but I guess it became impossible as population and administrative regions grew larger. Well, internet now provides the means to do that, at least for a project such as wikipedia. As for countries, I don't see that happening any time soon, but I think we're slowly moving to that direction. --JokerXtreme (talk) 13:20, 7 March 2010 (UTC)
While I agree that consensus is often hard to form and often controversial in WHAT it is, the problem with direct votes comes from the fact very often people will just completely misunderstand just what they are 'voting' on (how many times has someone opposed flagged revisions, for instance, because they think it'd take away people's right to edit which is the exact opposite of what it does?), and also many people using WP:ILIKEIT and WP:OTHERSTUFFEXISTS. This is even before any socks issues, as mentioned above. ♫ Melodia Chaconne ♫ (talk) 14:45, 7 March 2010 (UTC)
Then maybe representative democracy? It beats tyranny. Maurreen (talk) 15:02, 7 March 2010 (UTC)
Are we still talking about wikipedia? :P BTW, will anyone take a look at the section below? --JokerXtreme (talk) 15:07, 7 March 2010 (UTC)

All other issues aside, democracy requires an electorate verified to a reasonable standard. WP has nothing like that. Rd232 talk 22:43, 7 March 2010 (UTC)

Why would we want a democracy? Consensus is much better as people can't blindly vote. ManishEarthTalk • Stalk 01:18, 8 March 2010 (UTC)
For the second time, this is a democracy. It's just not majority rule and yeah, consensus is better. --JokerXtreme (talk) 08:40, 8 March 2010 (UTC)

How would you establish who has a right to vote? Anybody coming to an AfD without ever having done anything on Wikipedia before gets a vote equal to that of someone who has been here for years? Woogee (talk) 00:13, 9 March 2010 (UTC)

Nobody has a right to vote in here. You may get to !vote, though. I'd say that makes Wikipedia a !democracy. ;) Paradoctor (talk) 00:30, 9 March 2010 (UTC)
You cant vote! Wikipedia is based on consensus. This:
  • Support blah blah long description
has more power over:
  • Support good idea

Yes, people tend to listen more to admins than new users, but decisions are made on the power of descriptions. 10 descriptive supports has more power over 50 undescribed opposes. We're more like a big (I mean BIG) family... in a demented sorta way...ManishEarthTalk • Stalk 01:21, 9 March 2010 (UTC)

My advise: No political system was intended to work at a project like this, they are intended to work at societies at large, which are sooo different. They have many topics to adress: civil rights, social care, the economic system, military forces and foreign threats, crime, stir between political groups, relations between national and local governments, and a long etc. which can not be applied here, or the relation with a wiki phenomenon would be too much broad to even consider it seriously. Better yet, we should craft our own "system of government", based on our own needs, purposes and contexts. For example, among other things we need to keep it friendly for newcomers, to have new users, and to keep it as simple and bureaucracy-free to avoid this side of the project from diverting us too much from the purpose of writing an encyclopedia. Yes, we can borrow specific aspects from government system to aid us at specific areas, or employ real life knowledge when considering proposals, but only to the extent it aids our own purposes MBelgrano (talk) 01:54, 9 March 2010 (UTC)

We are indeed in quite uncharted territory. --Cybercobra (talk) 02:15, 9 March 2010 (UTC)

Proposals for governance reform have been made, and rejected. But don't worry — the market will sort everything out in the end. If Wikipedia fails to provide what its customers (editors and readers) want, a competitor will eventually come along and drive it out of the market. All it takes is one entrepreneur with a good idea and the tenacity and ingenuity to make it work. I personally think that Wikipedia's current governance system is moribund; as Murray Rothbard pointed out:

We see that in action here in the Wikimedia Foundation's unwillingness to raise revenue through even the most unobtrusive and context-relevant advertisements, which could have raised quite a bit of money for technical enhancements to the Mediawiki software by now. Tisane (talk) 12:31, 9 March 2010 (UTC)

You seem to be confusing the governance of the Foundation with that of the community. --Cybercobra (talk) 12:39, 9 March 2010 (UTC)
It is the Foundation that chose to leave decisions in the hands of the community rather than taking action to maximize profitability of the site. Most sites will disregard users' expressed preferences if necessary to make a profit; for instance, most users of the urbandictionary.com or Gmail, etc. would probably say that they prefer not to see ads. Nonetheless, the site will never get rid of those ads, because they are needed in order to generate the profitability that enables them to continue offering the site and improving its quality. Wikipedians likewise express preferences that are not in the site's best interests or even in their own best interests. An example would be notability policy, which has caused a great deal of strife, bad blood, frustration, wasted time and missed opportunities to offer useful information. Another example would be the current userpage restrictions, which in many cases lack any persuasive logic; see for instance my essay User:Tisane/Don't delete users' résumés. I think if these policies were reformed, site traffic and user satisfaction could be increased without sacrificing quality. I can't prove it (yet), but I suspect it, and when I gather together the necessary resources to start my own wiki and implement the functionality I need, I intend to prove it. If anyone thinks I'm being elitist in saying that users can't be trusted to govern the project, I am to some extent; but I also think that public choice dilemmas such as rational ignorance come into play in any kind of democracy, especially a large democracy. The free market is the only mechanism that has proven effectiveness in fulfilling people's needs; democracy has failed, both in government and on Wikipedia. Tisane (talk) 03:34, 10 March 2010 (UTC)
Free market is a farce. No such thing ever existed, at least not on this planet. The economic system we have, whatever that is, has proven deeply flawed and probably is at death's door, at least in its current form. Maybe some reforms will save it for now. As for Wikipedia, this would never work if it was a private project. At least not on the magnitude it does now. No one knows better than you, what is better for you. That is one of the reasons that make Wikipedia so successful. The other is that people actually love what they do, and don't instead work for some corporate fucker, that would exploit them for pennies. That is actually the driving force of WP, its free tireless workforce, that actually enjoys what it does. --JokerXtreme (talk) 23:37, 13 March 2010 (UTC)
People spend hours writing/maintaining their MySpace, Facebook, Blogspot, etc. pages, and have fun doing it, and those are all for-profit sites. And collaboration goes on at all kinds of for-profit sites, e.g. Yahoo Groups. Plus of course there is Wikia, another for-profit project, albeit one that probably needs to be bought out by Google or something. Tisane (talk) 01:43, 14 March 2010 (UTC)
So, how are for-profit projects any better? Did I mention the millions of dollars donations? WP is not just a project run by people, but it is also funded by them. --JokerXtreme (talk) 10:28, 14 March 2010 (UTC)
Because certain mechanisms of providing better governance, such as the threat of falling share prices and ensuing shareholder revolt and/or hostile takeovers in the event of mismanagement, do not exist. There are no big shareholders who have an incentive to invest much time and effort in ensuring policy is meeting the needs of the customers. Plus, election of board members is complicated by the issue of sockpuppetry. If it were a share corporation, all the shareholders would be on record as owning x shares, and sockpuppetry would be impossible. It makes sense that people should have influence over the organization in proportion to how much money they invest in it, but our donors get nothing but a nice warm feeling and a tax deduction for donating. Granted, it may be a gift economy. Nonetheless, I personally wouldn't mind seeing Google buy Wikipedia and Googlify the software (i.e. experiment with various nifty enhancements, switch to a faster-loading format, integrate it with the rest of Google tools, and make it easier to learn and use.) Tisane (talk) 22:10, 14 March 2010 (UTC)
Was that truly a serious proposal to make an editor's "influence" or "vote" proportional to their donation? In that case let me get my check book, there are certain editors I'd like to go around banning and being uncivil to without consequences. If Google were to buy Wikipedia then I'm sure many who currently donate will not anymore, and of course to make money (which is their goal in everything they do) Google will bring in ads; the integrity and goal of this endeavour as a serious encyclopedia will be compromised.Camelbinky (talk) 22:21, 14 March 2010 (UTC)
Tisane, you seem to be advocating some kind of commercialization of Wikimedia, something which is not only basically impossible, but is also something that the community would do anything to stop. Wikimedia is free, non-profit, community-run, and based upon a mission to collaboratively give information to the world. Nobody can "buy" Wikimedia. The content can be duplicated by anyone, for free, without permission. The community is in charge of everything. Money is irrelevant. The community would not allow anything to be compromised just for some cool software.
The point is irrelevant. As this is not some kind of political forum for debating what's the best way to run a volunteer community, can this side-discussion end? If someone wants to bring up a formal proposal to do something, go ahead. This thread was about eliminating WP:CONSENSUS and WP:IAR and replacing them with votes, so that's what gets discussed under this heading. --Yair rand (talk) 23:19, 14 March 2010 (UTC)
Just to clarify, when I started this, I didn't necessarily intend to eliminate consensus or even IAR. I think what I was hoping for was recognition that consensus is not always achievable, and deliberation about what to do in those cases. Maurreen (talk) 23:25, 14 March 2010 (UTC)
Well a 3/4 majority usually suffices. As for more even splits, I don't think that voting is a good idea. I'm not sure what works in those cases. --JokerXtreme (talk) 23:32, 14 March 2010 (UTC)

I think this discussion has missed some important features of Wikipedia that make it undemocratic, and that won't be discarded. Office actions, and Mike Godwin's ability to veto proposals that would cause legal issues for Wikipedia. RadManCF ☢ open frequency 17:37, 20 March 2010 (UTC)

Doesn't the Wikimedia Board of Trustees have the power to overrule anything the office or Mike Godwin does, and to even have such people fired? And the Board is democratically elected. And so it seems that if there hasn't been effective oversight of staff, that is evidence of democracy's failure, and not of our need for democracy. Tisane (talk) 21:05, 20 March 2010 (UTC)

Unreferenced BLP tracking by WikiProject

Thanks to User:Okip's persistance and User:Tim1357/User:DASHBot, coding, the automated updating of the unreferenced BLPs is now running, creating pages like this: Wikipedia:WikiProject Australian television/Unreferenced BLPs. After the issue and drama that this has caused over the past two months, I propose that enrolling your project in this automated system should be publicised to all projects and enrolment made compulsory so that each and every project has no excuse not to assist with clearing the uBLP backlog. I've listed a bunch of projects tonight, but there are still many more.The-Pope (talk) 16:35, 15 March 2010 (UTC)

every project has no excuse - They would still have an excuse, no one is required to do anything. Just listing projects won't help if the project is inactive or the members aren't interested in helping; it would just be a waste of edits and Toolserver resources. Mr.Z-man 17:04, 15 March 2010 (UTC)
Don't you know? WP isn't a volunteer effort any more. If you're an editor of any sort, you HAVE to do stuff like this, even if you don't want to. ♫ Melodia Chaconne ♫ (talk) 18:05, 15 March 2010 (UTC)
  • I really wish people would quit beating the BLP dead horse already. Not everyone shares the ultra-liberal, bleeding heart, strident viewpoint that "we must prevent any damage to real people at all cost!" If you're that concerned about the problem, I'd be more convinced if you'd all STFU and actually start taking care of the real problem content.
    — V = IR (Talk • Contribs) 20:09, 15 March 2010 (UTC)
    • Not everyone who considers himself an "ultra-liberal, bleeding heart" in general shares it, either. I generaly so identify myself, and i don't. DES (talk) 00:30, 16 March 2010 (UTC)
      • I also consider that using real life political analogies isn't helpful here. Though I suspect there is a divide between those who aren't particularly concerned about BLP matters, and those like me who are concerned about BLPs and regret the way the deletion spree and its aftermath distracted attention from more serious BLP problem areas and instead focussed it on an area of largely uncontentious content. ϢereSpielChequers 12:00, 16 March 2010 (UTC)
        • Don't worry too much about that. The zealots who don't care how much damage they do to the project overall so long as their pet interest is given primacy will eventually turn their attention to other areas. Resolute 14:41, 16 March 2010 (UTC)

There's no need to be so aggresive about this. It is a good tool, now we simply make it known, and let every project discuss on their own if they will use it or not. For some projects like Wikipedia:WikiProject Mountains there would be very little use for this, for others that include living people among their scope it shouldn't be a problem as long as at least a part of the users seem interested in it. After all, all projects intend to make their related articles of good quality, in the long run that means getting as many good and featured articles as possible, but in the short run it means fixing as much articles with problem tags as posible, so that they don't need to keep such tags. Either if it is critical or of low importance, an unreferenced BLP is an article with a problem, a problem that may be fixed by someone with knowledge on the topic MBelgrano (talk) 00:56, 16 March 2010 (UTC)

Wow. Guess I should have stated it a bit differently. As for the STFU and taking care of the problem - I have personally referenced close to 200 articles (and found problems in about 10 of them) and facilitated the referencing of over 1000 articles in the past two months through the generation and maintaining of Wikipedia:WikiProject Australia/Unreferenced BLPs. This bot makes that task so much simpler. My viewpoint is that a list of 40,000 uBLP articles is useless and impossible to try to actually reference - or check for "problem content". A list of 1000 articles that were nominated in July 2008 isn't much better. A list of 100 sportsmen from Australia is useful as I might know something about them, or where to find references, and I might find their pages more interesting than one about a pianist from Russia. This bot allows for EVERY project to at least run it once, see what's on their list, and then it's up to them , whether everyone in the project or just a couple of people, to try to clear the backlog - and then they can remove themselves from the list and save that precious edit count and toolserver resources. I agree that simply referencing articles isn't the end of the BLP issues, but guess what - this bot could be easily tweaked to report any other cleanup cat - especially now that WolterBot seems to be dead. And as much as I despise the way in which this issue came to a head (the deletion spree) and ArbCom/Jimbo's responses to it, I agree that we need to do better on BLPs. Referencing all BLP articles (and having a read/check for truly contentious material) is the first step to comply with the do no harm policy. This bot makes that task easier. I quite like the idea that I'm helping to do less damage to real people, but each to your own.The-Pope (talk) 11:34, 16 March 2010 (UTC)
Also its quite surprising how many projects have BLPs issues. I don't know if mountaineers or vulcanologists are of interest to Wikiproject Mountains, but there are some very early historical and archaeological projects who have BLPs of living historians and archaeologists within their remit. ϢereSpielChequers 11:54, 16 March 2010 (UTC)
The word "compulsory" is enough to gain an oppose for a proposal from a lot of people (including me). People don't come here to follow strict rules. Those who want to do this can do it (it is an important and valuable task, of course), but trying to force others into it is never going to end up well. Those who don't want to do it should be left to do whatever they do want to do. If you need help with it, what you have to do is get them informed and interested, not force them. ≈ Chamal talk ¤ 12:07, 16 March 2010 (UTC)
To calm the unneeded stir, I have removed the word "compulsory" from the thread title, so people can focus their attention over the tool itself. MBelgrano (talk) 12:35, 16 March 2010 (UTC)
I only ever proposed that every project should have one of these pages, not every editor. Once each project has the page, it's then up to each and every editor whether or not they use it to help reduce the backlog or just ignore it. Whilst it would be great if 10,000 editors each sourced 4 articles, or 1,000 editors do 40 articles, so that we can move onto some other issue, that will never be compulsory. I'm talking about enabling this on a project scale.The-Pope (talk) 14:40, 16 March 2010 (UTC)
As I said above, unless the project actually intends to use it, doing it would be little more than a waste of resources. Mr.Z-man 14:52, 16 March 2010 (UTC)
WP:BLPRFC was a waste of resources. This might actually achieve something. I'll qualify my suggestion though, if a project has unreferenced BLPs tagged with it's project tags, then this page should exist and it should be publicised to that project that they need to do something about them - or they will be deleted. I generally lean towards the inclusionist side, but if a project doesn't take responsibility for articles that they have tagged, after being offered/given simple tools like this, then invite Doc, Lar and Kevin over and start deleting. The-Pope (talk) 16:52, 16 March 2010 (UTC)
Inviting zealots to damage the encyclopedia will never be the proper way to encourage compliance. Resolute 17:02, 16 March 2010 (UTC)

I've added a mention of this to Wikipedia:WikiProject_Council/Guide#Use_bots_to_save_work and to Wikipedia:Article alerts/News. Could maybe stick a mention in the WikiProject section of WP:SIGNPOST too. Rd232 talk 17:25, 16 March 2010 (UTC)

Mr Z Man, The bot does not use too many of the toolserver's resources. It takes around 5 seconds for each query. Tim1357 (talk) 05:25, 21 March 2010 (UTC)
5 seconds per query times 200 or so projects every day and a few hundred bytes for each edit. It might not be a lot, but if the project doesn't use it, then its all wasted. Mr.Z-man 05:55, 21 March 2010 (UTC)

Flagged Protection: ready for more testing

Wikipedia:Village pump (policy)#Flagged Protection: ready for more testing --MZMcBride (talk) 00:46, 21 March 2010 (UTC)

"This user is currently blocked" message

When a user or IP address is blocked, and you open the contributions list for that user (at Special:Contributions), it will state in a light red box "This user is currently blocked. The latest block log entry is provided below for reference:". I would like to propose that if it is an IP address, it should read "This IP address is currently blocked. The latest block log entry is provided below for reference:". The reason behind this proposal is due to the fact that IP addresses are often shared, where the word "user" (which implies only one person) would not make sense. Please post in the appropriate place below, depending upon your position. -- IRP ☎ 21:00, 14 March 2010 (UTC), modified 21:01, 14 March 2010 (UTC)

Polling is evil, and totally unnecessary at this stage. I think this is a great idea. Happy‑melon 21:24, 14 March 2010 (UTC)
Support this and see it as uncontroversial enough to warrant skipping the on-wiki discussion and going straight to bugzilla. Equazcion (talk) 21:27, 14 Mar 2010 (UTC)
Is there a MediaWiki page for this notice? If that's the case, then this would be as simple as making a request to an administrator. -- IRP ☎ 22:00, 14 March 2010 (UTC)
This page? MediaWiki:Sp-contributions-blocked-notice. ManishEarthTalk • Stalk 04:04, 15 March 2010 (UTC)
I doubt we could use parser functions on that page to automatically change the wording. Why not just substitute "user" with "account"? — Martin (MSGJ · talk) 17:31, 15 March 2010 (UTC)
That would remain inaccurate in the case of an IP address (the identifier used when someone is not logged in to an account).
Pending a MediaWiki improvement, how about "account or IP address"? —David Levy 17:38, 15 March 2010 (UTC)
We could probably use a magic word for this. -- IRP ☎ 18:54, 15 March 2010 (UTC)
I went ahead and added "or IP address". It may make sens to also change "user" to "account" as proposed above, since technically it is the account. –xenotalk 18:57, 15 March 2010 (UTC)
Good temporary solution, however, we need to find a permanent solution soon, probably using a magic word. -- IRP ☎ 19:11, 15 March 2010 (UTC)
Why? –xenotalk 19:13, 15 March 2010 (UTC)
Don't you agree that it is far more professional to have a fully accurate message rather than one which refers to both? -- IRP ☎ 20:37, 15 March 2010 (UTC)
Not if it takes developer time away from other more salient concerns (like flagged revisions, liquidThreads, default alt text being taken at the file page, etc.) –xenotalk 20:39, 15 March 2010 (UTC)

I was only saying that we would do so if we can find a magic word as a solution. Hey, if anybody thinks of something, please speak up. -- IRP ☎ 20:44, 15 March 2010 (UTC)

A clever parserFunction using strLen might be able to determine if it's an IP (or a user with only numbers and dots in their name), but it might be too expensive to be worthwhile. I don't see the big deal leaving it as "user or IP address". –xenotalk 20:45, 15 March 2010 (UTC)
OK, well that's worth looking into. -- IRP ☎ 21:01, 15 March 2010 (UTC)
It would be fairly trivial to write it; MediaWiki already has regexes for determining if a string is an IP address. The issue would be usage. Adding extra features that add little value is generally discouraged. Outside of a handful of system messages like this (but I agree that "user or IP address" is fine there), what's the use? Mr.Z-man 23:04, 15 March 2010 (UTC)
{{#iferror: {{#expr: {{PAGENAME}}.123 }} | IsUser | IsIP }}
Will fail on users with wholly-numeric usernames, or ones which for whatever reason are valid inputs to #expr. But works in general. Happy‑melon 23:06, 15 March 2010 (UTC)
I was about to suggest just changing the sentence to avoid the use of "user" or "IP address." Something like "A block is currently in place." Useight (talk) 23:09, 15 March 2010 (UTC)
The problem with your code is that the notice is shown on Special:Contributions/..... So the final parser code will be: {{#iferror: {{#expr: Special:Contributions/192.168.1.1.123 }} | IsUser | IsIP }}, resulting in: IsUser. So it won't work. ManishEarthTalk • Stalk 01:42, 16 March 2010 (UTC)
Solved it! {{#iferror: {{#expr: {{#titleparts: {{PAGENAME}}|1|2}}.123}} | IsUser | IsIP }}. It returns IsIP for this: {{#iferror: {{#expr: {{#titleparts: Special:Contributions/192.168.1.1|1|2 }}.123}} | IsUser | IsIP }} ManishEarthTalk • Stalk 02:03, 16 March 2010 (UTC)
Assuming that this code works, is it worth the added overhead? The current wording seems more than adequate. —David Levy 03:15, 16 March 2010 (UTC)
Wouldn't it just be easier to use {{BASEPAGENAME}} ? =) –xenotalk 20:28, 16 March 2010 (UTC)
Its a trivial admin change which really doesn't require much consultation. I'm not sure if it'll actually work as Mediawiki: transclusions might be a bit different. Try editing the message at testwiki first (you'll need to be able to edit it on testwiki, see a list of people who have edited the MW namespace here and see the effect on a blocked IP and on a blocked user. ManishEarthTalk • Stalk 05:10, 16 March 2010 (UTC)
Obviously, I disagree with your opinion that this doesn't require much consultation. That the visible effect would be trivial is why I'm not certain that it would justify the added overhead (which you haven't addressed). —David Levy 05:27, 16 March 2010 (UTC)

Overhead? This is a nonexpensive parser, and there won't be any extra load on the server when the change is made as Special pages always require the server to build them and send them back, unlike normal pages, which are just sent directly from the hard drive. In other words, this change will not require the server to update every single blocked contribs page (unlike how the server updates all transclusions when you edit a template). For example, Xeno's change didn't have to go through the job queue. It went live on all contribs pages immediately as the server builds a contribs page every time you request it. So I don't think there's any overhead. Unless you meant something else...ManishEarthTalk • Stalk 06:04, 16 March 2010 (UTC)

No, that's what I meant. Thank you for answering the question. If your explanation is correct, it addresses my concern. —David Levy 06:15, 16 March 2010 (UTC)
  • One more question is, are we willing to put up with the message being inaccurate when, for example, User:7, and the like are blocked? –xenotalk 20:33, 16 March 2010 (UTC)
    To me, the status quo seems preferable. —David Levy 01:01, 17 March 2010 (UTC)
    Would tend to agree. –xenotalk 01:02, 17 March 2010 (UTC)
    This technical discussion should really go to Bugzilla and/or MediaWiki.org, should it not? It sounds as though this issue applies to all MediaWiki installations, not just Wikipedia. Tisane (talk) 22:12, 20 March 2010 (UTC)
    I agree. Though to me its a tiny change which isn't even a bug which will probably bug the buggers at bugzilla. Plus the change will have to be translated into quite a few languages. That will make a small change into a BIG project. Still, we can atleast change it here...ManishEarthTalk • Stalk 02:04, 21 March 2010 (UTC)
    It seems to me that the way Bugzilla works is that if no one feels like devoting the time needed to fix something, then the proposal dies a natural death. Kind of like how in the marketplace, the real test of whether a product is worth producing is whether customers are willing to shoulder the cost of production by buying it, often the best test of whether an enhancement is worth implementing is whether anyone cares enough to actually sit down and write the code. If they don't, then nothing we say here can implement it. On the other hand, if someone wants to implement it, and they don't mind putting in the time to do so, and it's not a harmful change, then who are we to say that it's a waste of time? Tisane (talk) 05:23, 21 March 2010 (UTC)
    Nothing ever "dies" on Bugzilla because a bug is always open until someone closes it. If nobody fixes it right away, that's usually because its seen as very low priority or very difficult. There would be nothing wrong with reporting this on Bugzilla, it exists for all MediaWiki bug reports and feature requests no matter how trivial. Otherwise, how would things like this ever get fixed? As for translations, translatewiki.net is very efficient. Mr.Z-man 17:02, 21 March 2010 (UTC)
    And indeed that's evident just by looking at the RELEASE-NOTES. There's quite the range of bugs being fixed and features being added based on Bugzilla reports, some old and some new. As long as the bug remains open there is the potential that it will be fixed. Maybe not right away, but eventually. Reach Out to the Truth 03:15, 23 March 2010 (UTC)

Yeah, but the buggers at bugzilla will be least bugged to fix this bug-which-isnt, and it will fall to the bottom of the priority list. We get more and more bugs there, so this bug won't even be looked at until about 2020. ManishEarthTalk • Stalk 03:23, 23 March 2010 (UTC)

If it's never filed at all, you can pretty much guarantee that it will never be fixed. Having it in Bugzilla is a lot better than in a village pump archive somewhere. Mr.Z-man 03:55, 23 March 2010 (UTC)
Okey dokey ManishEarthTalk • Stalk 05:49, 23 March 2010 (UTC)

Improving security of site-wide JS

Since site-wide JS files could be exploited for malware distribution, I propose that all changes to site-wide JS must be approved by at least three admins before going live (enforced by the software in a special form of flagged revisions, or manually by the m:System administrators). This would hopefully make it harder to affect site-wide JS using a compromised admin account, since three accounts would need to be compromised. Perhaps this should apply to the entire MediaWiki namespace as well, to avoid disruption by a single rogue admin. PleaseStand (talk) 13:42, 20 March 2010 (UTC)

Are there any occasions where this has been problematic in the past? ╟─TreasuryTag►stannator─╢ 13:46, 20 March 2010 (UTC)
Maybe someone should make a list of things that would have catastrophic effect if a rogue admin were to do them. E.g., just to take a random example that I'm sure would never happen in real life, there is a theoretical possibility that a sysop could edit MediaWiki:Tagline to say "From Wikipedia, the free encyclopedia administer by people with a stick up their lavender passageway," a startling admission that would potentially shock millions of readers. Or to take another absurdly improbable example, a sysop might inadvertently delete the main page. Once this list is completed, then the special flagged revisions can be applied to those items. Tisane (talk) 16:35, 20 March 2010 (UTC)
The complete list is here. — Gavia immer (talk) 16:50, 20 March 2010 (UTC)
The imagery on that page makes me hungry for gourmet jellybeans. Tisane (talk) 19:15, 20 March 2010 (UTC)
OK, seriously. Let's not forget that it is unwise to entirely depend upon security by obscurity. The press will find out when Wikipedia becomes the latest hacked site. To let such a thing happen is unwise. PleaseStand (talk) 00:45, 21 March 2010 (UTC)
Do we have any meaningful security by obscurity, considering that our code is open source? I really think some public-spirited individual such as yourself should create a list of particularly damaging sysop-generated incidents waiting to happen, so those issues can be addressed, through Bugzilla if necessary. WP:BEANS is an essay and not a particularly cogent one, because as you say, it does rely on security through nonexistent obscurity. Tisane (talk) 03:37, 21 March 2010 (UTC)
Relying on security by obscurity is about as bad as publishing a list of possible, but unlikely, attack vectors, then using an appeal to fear to get a bunch of volunteers to fix them. Mr.Z-man 05:17, 21 March 2010 (UTC)
I'm sure you recall when MZMcBride compiled such a list. Prodego talk 05:20, 21 March 2010 (UTC)

I see that Encyclopedia Dramatica has his list at MZMcBride/Going Rogue. Anyway, it might not be hard to fix the security issues, since some of them are probably similar to one another, and therefore some of the same code could be reused/adapted. The alternative is to wait until something happens, which will put immediate pressure on management to do something. But in those situations, the emergency measures may not be well-thought-out, and could be hard to repeal. Better to plan ahead.

On the other hand, I acknowledge that all FlaggedRevs-type measures are contrary to the spirit of a wiki, in that they try to make problems harder to create rather than easier to correct. So I wonder if there is a better approach. I say, in accordance with the (newly-coined) Bugzilla principle, this should just go to Bugzilla. We can always WONTFIX it if need be. Tisane (talk) 06:23, 21 March 2010 (UTC)

The easiest solution would be to restrict the 'editinterface' right to a smaller group than admins, create some stricter requirements for the group, then have it assignable only by stewards. Mr.Z-man 06:40, 21 March 2010 (UTC)
So would we need some process of WP:Requests for editinterface? Tisane (talk) 07:01, 21 March 2010 (UTC)
When I saw bugzilla principle, I thought it would be 'be slow' or something like that. Cenarium (talk) 00:22, 29 March 2010 (UTC)

I think that it's generally a good idea to split off various functions from the "moderator" side of administration, and leave the more specialised functions for other user groups. — Werdna • talk 07:43, 22 March 2010 (UTC)

That's a good principle, and is especially applicable to this kind of function. The editing of temporarily protected pages has some relation to moderation. But the editing of permanently protected pages, especially system messages and such, is unrelated to moderation, and therefore can/should be split off from the other admin rights. Tisane (talk) 10:39, 22 March 2010 (UTC)
Is this another solution in search of a problem? Ruslik_Zero 11:11, 22 March 2010 (UTC)
Moderation is a very small part of my admin work though, and this is true for many admins. I often need to edit the interface. It would be an inconvenience if it were hard to get. Cenarium (talk) 00:13, 29 March 2010 (UTC)

Yes, the scenario you describe could happen, but has it ever? This sounds like a pointless layer of bureaucracy. We have plenty of competent admins who don't need two others to hold their hand while they make important changes. Aiken ♫ 14:05, 22 March 2010 (UTC)

The question is not one of how competent our admins are; it is whether to require that a certain number of admins (or an admin in a smaller, more tightly controlled group) approve of changes to site-wide JS (and other interface messages), and technically enforce that in the software to make it harder to hijack the Wikipedia site for a nefarious purpose. I proposed the former method since if a malicious change were to make its way onto Wikipedia, it might be easier to find three admins to revert it than quickly locate a member of a special, "privileged" group. Having many members in such a group of which only one member needs to approve a change defeats its purpose. PleaseStand (talk) 01:04, 23 March 2010 (UTC)
FWIW, less than half of current admins (695 out of 1,718) have ever actually edited a page in the MediaWiki namespace and only 136 (8%) have ever edited a .js page. As for locating a member of a special group, experience shows that it isn't that hard. Finding a steward in an emergency is usually rather easy (and all stewards will be in the group or could add themselves to it in an emergency). In any case, the whole purpose of these proposals is to reduce the risk of it happening from its already extremely low probability. It doesn't make a whole lot of sense to design your security system based on how easy it is to recover after it gets breached. If ease of recovery is the main consideration, then the current system is best. Mr.Z-man 02:58, 23 March 2010 (UTC)

If we're going to protect system messages from rogue admins, now is probably the time to do it, because April 1 is just around the corner. Tisane (talk) 17:18, 23 March 2010 (UTC)

WP:Ideabox

How about creating a WP:Ideabox - a "safe zone" sandbox for ideas. In the Ideabox, there is no such thing as a bad idea -every idea, however unimplementable, might inspire some useful thought. There is no voting (or !voting); only discussion on the merits, and maybe branching off variations of the idea. There may be smiles about how unimplementable an idea is, or how much the downside exceeds the upside; but creativity appreciated and positive aspects acknowledged. If at some point discussion points towards an idea as potentially being able to fly, it can be chucked out of the nest to some appropriate location (eg WP:VPR) to see what happens.

The motivation for this is that too often on Wikipedia people are scared of bad ideas being implemented - so jump on negative aspects of ideas they're opposed to or ambivalent about. Let's encourage a bit more creativity, and a bit less judgemental shooting down of ideas before they can either be fixed or inspire something useful. Rd232 talk 01:18, 22 March 2010 (UTC)

In person, there are benefits to brainstorming - i.e., innovating in a two-step process in which, in the first step, people share new ideas without any criticism; and in the second step, the ideas are judged. On a wiki, I'm not sure it's as necessary, since we can process an unlimited number of ideas in parallel. Tisane (talk) 01:52, 22 March 2010 (UTC)
But that's exactly the point: on WP ideas get processed too quickly, and aren't given enough time to develop. Rd232 talk 02:23, 22 March 2010 (UTC)
I'm concerned about vandalism. Does it not serve the same purpose as the talk page? Airplaneman talk 02:15, 22 March 2010 (UTC)
? Vandalism there will be handled same as anywhere. And no, it's not the same as the talk page of this article - there would only be one Ideabox, at WP:Ideabox. Rd232 talk 02:23, 22 March 2010 (UTC)
Oh, I see. I misread the proposal the first time around. Airplaneman talk 02:32, 22 March 2010 (UTC)
This is the third proposal that I can think of in the past year or so in which an editor has hoped to improve the ability of ideas to get flushed out instead of getting knee-jerk reactions of opposing because something is different or as Rd232 pointed out there may just be a negative aspect that could be rectified but because there is the negative reactions from the outstart little is ever pursued to make a final proposal that can be implemented. Unfortunately none of the proposals I've seen have ever been implemented to make this process here at the VP less judgmental and I believe the reason is people as human beings inherently love the ability to shoot things down, be judgmental, attack, etc. and thats why this place functions the way it is. There should literally be a ban on statements like "oppose per user:x" which is the most stupid comment anyone can say, along with somewhat more constructive but still bad statements that point out the bad of a proposal but dont ever say what can be done to rectify the concern and make a good proposal. Basically if you cant help and work to make a proposal work good then you shouldnt be commenting at all should be the "rule" around here. This would eliminate the need for an ideabox and therefore has the benefit of not increasing the process. Process should be streamlined for new ideas not further steps invented.Camelbinky (talk) 02:30, 22 March 2010 (UTC)
Why is "per user:y" such a bad thing if you actually agree with them? Airplaneman talk 02:34, 22 March 2010 (UTC)
Exactly. Even I hate that statement (it turns consensus into vote), but you have to use it at times. If you don't use it, you have to give a pretty much similar reason, and everyone will then call you a copycat. Though I do feel that "per nom" should be banned (I think it is, i've seen it on a policy page, but no one follows it) ManishEarthTalk • Stalk 09:08, 22 March 2010 (UTC)

The Wikipedia community is decidedly conservative when it comes to proposed reforms. I think people view it as safer to stick with what we have than to experiment with the unknown, even though the nature of a wiki is that anything can be reverted. Plus people who are dissatisfied with our current system are less likely to continue participating in the project, and with their departure the community becomes even more conservative.

The views of the community are, however, no bar to entrepreneurialism; you are welcome to create your own wiki implementing whatever you want. And if you are successful, then Wikipedians may well say, "Hey, looky over there... that seems to be working well for them!" That's why it's so good to create new extensions; you're not forcing any functionality on Wikipedia, but if you can show it works well, Wikipedia can easily adopt it. Plus some extensions, such as the forthcoming RPED, promise to make it easier to operate an independent wiki that integrates Wikipedia's data and thus piggybacks off its content to some extent, making such wikis more viable and less duplicative of effort. Tisane (talk) 03:26, 22 March 2010 (UTC)

Ok, I'll concede that while not perfect "per userx" isnt completely bad, but I think it does show that if you cant come up with a reason not already mentioned some are perhaps trying to bolster their side with a vote and it isnt a good thing to do and we could come up with something better than "per userx" since discussions are supposed to be judged on the merit of the argument and not on a vote of who agrees with which side. Getting back to topic however- I understand Wikipedia in the village pumps is conservative (I disagree that it is everywhere, by definition all wikis are quite liberal, and Wikipedia seems to be very liberal with things like IAR and in arguments at other noticeboards such as the NO/R and RS.). Being conservative does limit our ability to implement new procedures that are proposed. However, can we perhaps figure out ways to increase dialogue here and allow new ideas to be fleshed out and the negative comments kept out of here? For a place where discussions about ettiquette and civility are constantly being discussed Wikipedians sure are downright rude about new ideas and shutting them down and no one complains, and if they do those who complain are told in an even ruder way to stop complaining. If you have the majority on your side you can be rude seems to be the message. Anyone willing to have constructive discussions on things that CAN be implemented successfully? Not calling for a full renovation of the VP, new procedures, or new noticeboards, just easy new simple small things that most could agree with.Camelbinky (talk) 23:56, 22 March 2010 (UTC)
This sounds like a very good idea, but it would be best if it didn't just become another layer of bureaucracy. Ideas should still be able to be placed in Wikipedia:Village pump (proposals) without first having to go through the ideabox. --Yair rand (talk) 19:38, 23 March 2010 (UTC)
I agree. I think it would better serve as a resource for people who have an idea but need to get feedback on it before making a proposal. I see a lot of things go through the proposals page that would be much more constructive if they had received some discussion before being set down as a full-blown proposal. Just like a peer review serves to improve an article without judging it as a GA or FA or whatever, the ideabox would do the same for "proposals" without being judged on whether they should be implemented as-is. —Akrabbimtalk 20:26, 23 March 2010 (UTC)
Anyone want to just be bold and go ahead and make the page? --Yair rand (talk) 00:15, 26 March 2010 (UTC)

This is a good idea, I had thought of something similar. It may benefit from a better name though. What about making this a subpage of VPR, or a VP on its own ? Cenarium (talk) 02:03, 27 March 2010 (UTC)

Suggestion: Wikipedia:Village pump (development). For considering new ideas and suggestions and develop proposals, and for considering general issues then find ideas and suggestions for improvement. Cenarium (talk) 12:54, 27 March 2010 (UTC)
I have been bold and created the page, please give your thoughts on the talk page. Cenarium (talk) 23:45, 28 March 2010 (UTC)

Proposal to ban users from commenting on their own deletion/move discussions

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
We all know that this proposal doesn't have a leg to stand on. Closing it as further discussion isn't necessary. —Farix (t | c) 21:25, 28 March 2010 (UTC)

I have some issues with XfD and RM discussions that merit a policy change. Simply put, the proposer of a deletion request or move request should not respond to comments and !votes made by other people. This is for multiple reasons:

  • Responding to every single argument with the same counter argument, or worse, following opposing users to their talk pages, creates a chilling effect discouraging people from posting their opinions and inflames the dispute. Most people just want to say their piece; they don't want to be drawn into a fight
  • Proposers have a conflict of interest. Right now, there is nothing preventing them from smearing people who disagree with their proposal and posting accusations that all users !voting against them are all part of a conspiracy to hide the truth from the public--and, yes, I've seen such discussions.

My proposal is this: anyone who proposes a deletion request or a page move is to be automatically banned from the discussion for the duration of the discussion as soon as the first person comments on it. It is not just a ban from the discussion page, but from any discussion of the issue: taking the discussion to a user's talk page is just as forbidden as replying on the discussion page, and editing your own proposal is permissible as long as it consists of content-free spelling and/or formatting corrections. There will be one exception to the ban: you may withdraw your own proposal. Users who violate the ban are to be indefblocked until the discussion is closed and then unblocked. This policy could also be easily extended to other disputed proposals.

Now, for the FAQ:

What if somebody's argument is wrong?

Their argument will stand or fall on its own merits with or without your involvement. These discussions are not closed by robots but by intelligent human beings trusted by the community to understand Wikipedia's policies and guidelines; it is up to the closing administrator and only the closing administrator to determine whether other users' counterarguments are stronger than your proposal. Furthermore, consensus applies: if their argument is truly wrong, the rest of the community will offer their own arguments that agree with yours and disagree with the counterarguments; if not, then it's you against the community, and repeating the same faulty arguments over and over again does nothing but inflame the dispute.

What if I forgot an argument when I wrote up the discussion?

You are not special. There are plenty of intelligent people who read such discussions and weigh in. If nobody else is willing to post the same argument, your argument will not get consensus if you post it yourself.

What if I think people are socking?

Again, you are not special. If people are socking, somebody else will notice. Furthermore, you have a conflict of interest: what better way to save a proposal opposed by 90% of the community than to accuse the opposing 90% of being one person using several identities?

What if I think the opposition is in cahoots with one another?

It is not for you to decide, as you have a conflict of interest: what better way to save a proposal opposed by 90% of the community than to accuse the opposing 90% of being part of a conspiracy to hide the truth from the public? Remember that the strength of arguments matters, not the intention behind them. Again these discussions are not closed by robots: if the opposing arguments are demonstrably absurd, the closing administrator is expected to reject those arguments, and if their arguments are stronger than yours, the discussion won't be closed in your favor regardless of the intention of the participants.

jgpTC 19:26, 27 March 2010 (UTC)

No, I don't think this is a good idea. –xenotalk 19:30, 27 March 2010 (UTC)
(ec)Blocking the submitter of the AFD is bad - very bad. Discouraging the same users from repeating the same practice of responses over and over against multiple times per AFD and over several AFDs (regardless of a submitter or not) should be pushed more, ideally with repeat offenders being pointed to WQA for mostly of the other arguments stated. But the submitter has no other special privileges or restrictions than anyone else that can respond. --MASEM (t) 19:38, 27 March 2010 (UTC)
You claim there are "chilling effects" from allowing a proposer to rebut arguments. I claim there are chilling effects from banning the user from doing so. I think banning people from even commenting away from the discussion will put people off proposing unsuitable material for deletion. A bad idea; this will not fly. Aiken ♫ 19:36, 27 March 2010 (UTC)
That is a very harsh proposal you just came up with! I thought the banning policy was about numerous blocks which can effectively force a ban. Agree with Xeno & Aiken drum here. Minimac (talk) 19:44, 27 March 2010 (UTC)
Much too extreme. You underestimate how low participation in some discussions is; if the proposer doesn't respond/rebut, no one might, and yet the proposer is the most likely proponent to do serious research/reasoning. --Cybercobra (talk) 19:57, 27 March 2010 (UTC)
This is one of most anti-wiki proposals I've seen on here. ♫ Melodia Chaconne ♫ (talk) 20:08, 27 March 2010 (UTC)
Hell no.--Cube lurker (talk) 20:13, 27 March 2010 (UTC)
This proposal is based upon the incorrect assumption that there is a material distinction between a nominator and any other discussion participant. There isn't.
As Aiken drum noted, this would discourage people from making good-faith proposals. Instead, they would wait for or ask someone else to do it (thereby shifting the arbitrary and illogical discussion ban).
As Cybercobra noted, a nominator is among the participants most likely to possess relevant knowledge (and the ability to address questions and comments that arise). Your claim that "if nobody else is willing to post the same argument, your argument will not get consensus if you post it yourself" is flat-out wrong. It's not uncommon for a single editor (the nominator or someone else) to sway other respondants' opinions (and influence the closing administrator's determination of consensus) via the strength of his/her arguments. This open interaction is essential.
Furthermore, anyone (not just the nominator) can engage in the type of behavior that you say "creates a chilling effect discouraging people from posting their opinions and inflames the dispute," so this proposal would do nothing to address the actual problem. —David Levy 20:50, 27 March 2010 (UTC)
Does not meet with the spirit of "the encyclopedia that anyone can edit". At least jgp having proposed the case is not responding to us in the spirit of the proposal! Graeme Bartlett (talk) 21:07, 27 March 2010 (UTC)
AFDs are suppose to be an open discussion. Banning the initiator of the AfD from participating in the discussion is the height of absurdity. And if you limit everyone to just one comment per discussion, which is completely unworkable, than the AfD becomes nothing more than a WP:VOTE. —Farix (t | c) 22:05, 27 March 2010 (UTC)
You forgot the most important FAQ - What if I want to engage in a civil discussion about the article? Mr.Z-man 22:14, 27 March 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal for creation of Village pump (development)

Please give your thoughts on the creation of a village pump development at the talk page. Cenarium (talk) 23:47, 28 March 2010 (UTC)

Effectively warning school IPs

My concern is that if there are many IP users, for example, from a high school, that a vandal using a school computer will never get the warning. Large high schools typically have hundreds of computers NATted behind a single IP address, and chances are, since Wikipedia is a widely used (although discouraged by schools) resource of information, that the likelihood that the vandal would receive his warning is extremely small.

I propose that a token be set upon the first IP edit for the purpose of tracking the specific IP user to warn. The value of this cookie would be automatically included in the edit summary for all edits from that user. Including that same token in the edit summary when warning the user through the talk page would cause the site to show the "You have new messages" banner even though the banner has already been shown to that IP. Concerning privacy, the token safely can be removed one hour after the last edit, since many common vandalisms are reverted quickly, providing the vandal with instant feedback to stop vandalizing. Such expiration would also prevent edits on different days from being linked together to the same user on that IP (everyone has to sleep).

I understand that IP users are seen by some as a real problem on Wikipedia and this is my proposal to attempt to address that concern. PleaseStand (talk) 22:52, 17 March 2010 (UTC)

This seems like a good idea. Much the same situation also applies with public library IPs.--Pharos (talk) 16:12, 20 March 2010 (UTC)

I think there are better ways of doing it. — Werdna • talk 12:13, 23 March 2010 (UTC)

How? PleaseStand (talk) 22:50, 23 March 2010 (UTC)
Please, MiszaBot II, don't archive this yet. PleaseStand (talk) 06:50, 30 March 2010 (UTC)

Edit summaries and Twinkle

Moved to Wikipedia talk:Twinkle#Edit summaries and Twinkle. PleaseStand (talk) 07:00, 30 March 2010 (UTC)

User review

This stems from the Norwegian Wikipedia, where I suggested this to some limited enthusiasm. The suggestion is to enable new Wikipedians who have gone beyond the first fumbling steps of editing and are beginning to feel confident in their adherance to basic WP standards, to get an experienced Wikipedian to go through their edits and created articles, and give constructive criticism and pointers to the user. This is similar to the 'peer review' concept, but doesn't apply directly to one specific article, but the specific user's efforts as a whole. This could be done through the user adding a template or metacategory on their user discussion page, and thus being listed for reviewers to pick up on and go through. Kenneaal (talk) 07:39, 29 March 2010 (UTC)

Like Editor Review?--Jac16888Talk 17:00, 29 March 2010 (UTC)
...or adopt-a-user? Airplaneman ✈ 23:58, 29 March 2010 (UTC)

I suggest that the date part of the ~~~~ template was turned into a permanent link to the current article's version, for example:

Stpasha (talk) 18:54, 16 March 2010 (UTC)

The reason for this would be that too often when you go to a talk page of some article to see if there are any concerns raised or suggestions for further improvements, you'll find comments like

“I find section XXX very confusing ...”, or
“I think there is an error in the first formula in section YYY ...”, or
“Section ZZZ requires expansion ...”, or

All of these responses would be much easier to investigate if it were possible to immediately jump to that version of the article which was in place at the time the comment was written. Otherwise you have to list through countless revision history pages until you find the date closest to the date of the post, which is of course quite inconvenient. // stpasha » 18:54, 16 March 2010 (UTC)

An interesting idea! I'm not entirely sure if it's even possible for the software to generate such links. One problem I see is that such discussion would happen on the talk page, hence the links would be to talk, and not the article making it pointless. Aiken ♫ 20:18, 16 March 2010 (UTC)
Neat idea for a script but I think this would bloat the wikitext unnecessarily if it were done by default. –xenotalk 20:26, 16 March 2010 (UTC)
Well, fancy signatures (such as mine >.<) already bloat the wikitext. However the overall effect of adding a link to each signature will be minimal assuming that the pages are stored and transferred in a compressed mode, since each link is essentially the same string, with only difference in page's id.
The fact that signatures are on talk pages, while they should be anchored to the main article — makes the issue more complicated, but certainly not impossible to implement. // stpasha » 20:57, 16 March 2010 (UTC)
I was more talking about the bloat in the on screen wikitext. –xenotalk 21:21, 16 March 2010 (UTC)
Or there could be a special function made to automatically link dates like those in the sig to the version of the page. Airplaneman talk 21:30, 18 March 2010 (UTC)
I suggest using &offset=YYYYMMDDHHmmss00 to jump around the history. Per Xeno, a script (or manual permanent link) could grab the latest revision ID from the referenced page. A template could be easily written to use Help:Magic words, although I'm not sure of the most compact form – fullurl and SUBJECTPAGENAME may not be necessary. Flatscan (talk) 05:37, 19 March 2010 (UTC)
Side comment and proposal extension: Whoa that exists? I never knew that. Thats gonna be pretty useful, and will solve my pet peeve that old revisions of pages link to current revisions, instead of linking to the revision at that time. I propose to extend this proposal to also use offset parameters in all wikilinks on all "old revision" pages. Shouldn't be a big change, as old revisions are generated by the server anyways...ManishEarthTalk • Stalk 08:48, 19 March 2010 (UTC)
There may be a misunderstanding here: my comment about &offset only helps with Stpasha's problem of browsing through many history pages. I don't know whether a page revision ID can be easily retrieved from a timestamp. Flatscan (talk) 05:22, 20 March 2010 (UTC)
On that page you linked they say there is a template {{REVISIONID}} to get the revision id for the current page. However it doesn't seem to accept parameters. That is, what we really need is to write something like {{REVISIONID|page={{SUBJECTPAGENAME}}}}. // stpasha » 19:48, 20 March 2010 (UTC)
This is T8092 that has already been implemented, but that change was reverted. Svick (talk) 20:01, 20 March 2010 (UTC)
We'd need an edit filter which stopped users from changing the dates (but allowed them to overwrite their own signature). ManishEarthTalk • Stalk 02:08, 21 March 2010 (UTC)

Objective measures of Wikipedia

More and more specialized concepts accumulate over time as our knowledge and research progress, and this rate is amplified in Wikipedia as recognition of its power grows.

It might be good to have some objective measure(s) of the significance and authority of concepts in Wikipedia. For example, for each article / link, some published measures of authority/mainstream/accuracy/links in-out count/popularity/attention growth/etc measures/statistics.

Measures that might be useful:

  • Wikipedia has a unique record of concept search and usage and concept-concept link usage (from and to). The number of times a link is used could be regarded as some form of significance of that link and also of the coupling strength between the two concepts. The time profile of this might allow some prediction of rapidly developing concepts and ones that were possibly historic or obsolete.
  • The number of edits and article has had give some idea as to it's veracity, surely if it has been modified by more than one editor then it has more "veracity".
  • In addition some other useful statistical information may be derived from existing records, such as editor competence and authority, which could then possibly be used as a factor in rating article authority / quality.
  • Average editor experience/acceptance scores (based on their prior edits (inc new articles) and following modification history and rapidity of re-edits by other editors, longevity of their edits, etc
  • More might be achieved by collecting a little more information about editors, such as what the consider to be their fields of competence, but that might be unacceptable.

Also Wikipedia could start to look upon itself as a massive database of linked concepts rather than a set of linked articles.

The Concept structure is probably more useful and general in the long run, and might promote more systematic representation of knowledge, generalized coherent standards for concept definition, including maybe formal concept definition notations. The hyperlink is one such useful notation, but others could be introduced gradually.

In the end perhaps article texts might be automatically produced from the core language-independent concept definition.

Also automated access to concept definitions could provide knowledge engineering support for various AI systems.

Thanks so much to all of you for this fabulous aid to co-operation and learning. —Preceding unsigned comment added by Jjalexand (talk • contribs) 23:49, 20 March 2010

This is an interesting proposal, it sounds like what Google would do if it ran Wikipedia. Automatic metrics such as those you suggest would be useful. Fences&Windows 16:22, 22 March 2010 (UTC)
Roger Dingledine, inventor of TOR, has said that if Wikipedia implemented a trust metric, this would effectively solve the problem of proxies. We should flesh out this proposal so that it can be submitted to Bugzilla as a proposed extension. Any thoughts on the specifics of the algorithm that would be needed? Tisane (talk) 18:36, 22 March 2010 (UTC)
I refer you to #Reader feedback tool above. --Ravpapa (talk) 20:04, 22 March 2010 (UTC)

Discuss page protection/unprotection on the article talk page

Instead of posting a request on Wikipedia:Requests for page protection, a proposal could be made on the article's talk page. If the proposal gains support, a template (similar to {{editprotected}}) can be used to gain an administrator's attention. This would have the following possible benefits:

  • It would allow other people who are involved with editing the article to have a say on whether the protection or unprotection is warranted.
  • It would also give the admin an indication of whether the request has consensus or not, rather than making the decision on their own.

WP:RFPP could still be used in parallel for the time being. What do people think? — Martin (MSGJ · talk) 13:13, 23 March 2010 (UTC)

What if the article is getting heavily vandalized or there are BLP concerns? Waiting for consensus to form on a talk page is going to take a while, to the article detriment. –xenotalk 13:16, 23 March 2010 (UTC)
If admin attention is needed rapidly, then the {{protection requested}} template (I think this might be a good name for it) could be placed immediately. — Martin (MSGJ · talk) 17:53, 23 March 2010 (UTC)
What is wrong with the current system? (...that allows admins to simply watch a single page for requests to come in?) –xenotalk 17:55, 23 March 2010 (UTC)
The current system is quite well, but this could be an improvement for the reasons I have outlined above. It strikes me that the talk page is the natural place to decide whether an article needs protection or not. — Martin (MSGJ · talk) 18:00, 23 March 2010 (UTC)
I just think that having it centralized helps quickly get many eyes and opinions on the matter and there hasn't really been an issue with doing it that way. –xenotalk 18:07, 23 March 2010 (UTC)
Why are there so many people trying to mess with protection policy all the sudden? I don't get it, it's always struck me as one of the more smoothly functioning areas of admin work. Most protections do not require a discussion, just one user to notice a problem and one admin who understands the policy and can make a decision whether it meets the conditions to be protected or not. If anyone objects to a protection they already have avenues to appeal by either contacting the protecting admin or asking at RPP for unprotection. I don't see what problem would be solved by making it a more complicated a time consuming process. Beeblebrox (talk) 18:11, 23 March 2010 (UTC)

Because unfortunately some admins are abusing the policy. As a particularly extreme example take the Army of the Republic of Vietnam it was semi-protected indefinitely (its now been challenged and unprotected) because someone had done a test edit which they then reverted themselves. -- Eraserhead1 <talk> 18:16, 23 March 2010 (UTC)

If administrators are not following policy/guidelines then that should be taken up with the administrator, and failing that, at the administrators' noticeboard. –xenotalk 18:18, 23 March 2010 (UTC)
Which I've already explained twice in almost the exact same words at the other current discussion over at Wikipedia talk:Protection policy. Beeblebrox (talk) 18:41, 23 March 2010 (UTC)
Yeah sorry, my bad. I misinterpreted that before :o. -- Eraserhead1 <talk> 20:28, 23 March 2010 (UTC)

Suggestion - Wikipedia is not a comparison guide

This kind of goes with not an indiscriminate collection of information but there are possibly hundreds of these articles in existence. Examples:Comparison of Canadian and American health care systems, Comparison of the AK-47 and M16, Comparison of smartphones, etc. Obviously merging these articles could take years so an incremental approach, might be necessary. In the meantime it might be necessary to set-up an edit-filter to block creation of comparison articles. Marcus Aurelius Antoninus (talk) 19:50, 23 March 2010 (UTC)

According to a cursory search of intitle:"comparison of", there are 345 currently. Some of them are prose articles, but most are table-based lists. The majority are in software eg. Template:Layout engines, but there's everything from Comparison of karate styles, to Comparison of heavy lift launch systems, to Comparison of birth control methods, to Comparison of fighter aircraft, to the "Comparison/Difference" articles in Category:Language comparison.
If after looking through all that, you still think they need to be eradicated, that's a discussion for the village pump. However, if you just have concerns with individual pages, then taking the matter to WikiProject talkpages, or AfDs, are the way to go. There would be wide opposition to any mass-deletion.
HTH. :) -- Quiddity (talk) 00:47, 24 March 2010 (UTC)
I'd strongly disagree. There are many of these articles, they are quite useful, and they're mostly verifiable. I see no reason to exclude them. --Cybercobra (talk) 01:14, 24 March 2010 (UTC)
If the comparison itself is already a topic found in bibliography, and it isn't needed to make synthesis of unrelated information from here and there, then we can make an article about the comparison, under the same rules than any other one. I know for sure that some books that explain some complicated software concepts, such as operative systems or programming languages, rely heavily on comparisons.
For example, Comparison of Windows and Linux are a classic. MBelgrano (talk) 02:10, 24 March 2010 (UTC)
(edit conflict) The vast majority of comparison Wikipedia articles don't draw any conclusions, so they couldn't be synthesis anyway. --Cybercobra (talk) 02:17, 24 March 2010 (UTC)

What makes comparison articles any worse than list articles? The only difference is that the former provide more information and are in a tabular format. I personally use these comparison articles all the time. Being able to sort by different criteria beats having separate articles for various attributes, e.g. List of open source text editors written in C++. If anything, we need more comparison articles. Tisane (talk) 06:14, 24 March 2010 (UTC)

On the question of appropriateness, I agree with MBelgrano: as long as the comparison is not original, but has been done by reliable sources, then I don't see how WP:NOT#INDISCRIMINATE would apply. On the question of utility, I agree with Tisane: a single well-organized comparison article can provide more information in a more accessible format than multiple separate lists. -- Black Falcon (talk) 17:52, 24 March 2010 (UTC)

Wikipedia:Administrator inactivity

Hello all, I've just posted the proposal above. I know it's one of the "perennial proposals", but comments there would nonetheless be appreciated. Thanks! Hersfold (t/a/c) 02:49, 9 March 2010 (UTC)

Comments moved to Wikipedia talk:Administrator inactivity - discussion should continue there. –xenotalk 16:52, 25 March 2010 (UTC)
The following discussion has been closed. Please do not modify it.

Strong oppose. And this will solve what problem? People take wikibreaks. You want to penalize someone for returning? You want to set up new bureaucratic procedures for a non-problem? alteripse (talk) 19:53, 9 March 2010 (UTC)

That idea is really stupid. We prefer to have admins for life. That's a much better idea. Angryapathy (talk) 19:58, 9 March 2010 (UTC)
Please note that the proposal has nothing to do with the issue of "admins for life". It is about temporary removal of the sysop tools due to inactivity, to be reinstated without question upon an admin's return. -- Black Falcon (talk) 20:01, 9 March 2010 (UTC)

It seems a good idea, unfortunately phrased. The start does indeed seem to tut-tut over admins who don't pull their weight, and one has to read through this to realize that the proposal is actually about something else.

I'm still not sure that there is any problem, but I'm willing to believe that there is one, or the potential for one. If so (and even if not), then there's nothing obviously wrong with removing a user's admin bit if its later restoration can be automatic.

Admin for life, eh? No chance of a reduction for good behavior? -- Hoary (talk) 16:19, 10 March 2010 (UTC)

As I have stated on similar proposals, this idea institutes unecessary new policies and creates new workloads to solve a problem that has not been demonstrated to exist, ie. a solution in search of a problem. New rules and processes for their own sake do not an efficient Wikipedia make; WP:CREEP is relevant here. I cannot support this sort of proposal. Shereth 16:47, 10 March 2010 (UTC)

Support I believe this is a necessary step to minimize the problem of compromised admin accounts. If the bureaucrat unchecking proposal passes, we wouldnt even need to bother the stewards (which I think would be a good thing, as theyre pretty busy as it is). —Soap— 15:58, 13 March 2010 (UTC)

And how often have we had compromised admin accounts that occurred after long inactivity? Judging from WP:AN/I it is a rare occurrence. Are you aware of any count or record? The whole community should be answering proposals like this with WE NEED CONTENT IMPROVEMENT, NOT MORE ADMINISTRATIVE PROCEDURES! Can I propose that editors must make 50 constructive, non-trivial article improvements to earn the right to engage in a single administrative discussion? I will adhere to that myself. alteripse (talk) 11:51, 15 March 2010 (UTC

Support Since admins have the power to edit site-wide JS (and other system messages), a compromised admin account is valuable to hackers. Since Wikipedia is an extremely high-trafficked website, such a compromise has the potential to infect thousands of readers with malware (the security of web browsers and their plugins is far from perfect, with new exploits announced daily). Blocking the compromised account after the fact would not stop the malware infections. Reducing the number of admin accounts to only those who really need admin access is one way to lower the risk of a compromise. I'm actually surprised that AFAIK, the MediaWiki:Common.js file hasn't been exploited by the cybercriminals. Yet. PleaseStand (talk) 02:33, 20 March 2010 (UTC)

The proposal of course does absolutely nothing to resolve that security issue. All someone would have to do is hijack the account after desysopping, make an edit to ask for the tools back, then its like they got the admin account directly, or they can just hijack it after 89 days; so this lowers the risk by about 0%. Additionally, the only real way to hijack an account that's been inactive for months would be a brute force attack on the password. Active accounts are much more vulnerable; vandals have even gotten admin accounts "legitimately" by creating an account, making a few thousand good edits, then running for RFA. Mr.Z-man 04:25, 20 March 2010 (UTC)
Either way, any admin account with a keylogged password, active or inactive, can be used to compromise the site. In particular, would an inactive admin even notice that his account is compromised (not necessarily even an active admin)? I have posted a new proposal below specifically addressing the security risk of the immense amount of technical power granted to admins. PleaseStand (talk) 13:48, 20 March 2010 (UTC)
How do you use a keylogger to capture someone's password if they never log in (since they've been inactive for months)? It would only take a few minutes and a single edit to add some script to the sitewide JS, I doubt an active user would notice immediately and even if they did, they wouldn't be able to notice until after the edit was made. Mr.Z-man 16:54, 20 March 2010 (UTC)
There have been instances (Very rare instances) where an admin account (which in this case has been inactive) has been compromised by someone guessing the password (See User:RickK event). That aside this is a rare and extreme event requiring considerable patince by someone and could just as easily happened to an active admin account (Which has also supposeofly occured with some admins). At any rate in all cases this has been dealt with the current systems in place and damage has been minimized. Basically its more a matter of password security through watching out for malware or behavioural patterns in your edits that can identify your pws. That in itself i think is sperate from inactivity of accounts and more to do with the security of an individuals password and their computing habits (active or not). Just some stray thoughst on thisOttawa4ever (talk) 18:03, 20 March 2010 (UTC)

Oppose. All admins are aware of the possible security issues with their own accounts. In fact, it's on the Administrators' reading list. "...Privileged editors are required to use strong passwords and are informed that the developers will occasionally try to crack their passwords and disable those that can be cracked." This alone should be all the security that is needed. Compromised admin accounts do not seem to be a common problem at all, looking over ANI. If it ain't broke, don't fix it. I trust all the admins here to have complete security over their accounts. The issue of keylogging has been brought up and discussed above. (You can't log what is not typed in.) Also, in my experience at least, almost all malicious activity, regardless of where it comes from, is quickly caught and dealt with. All events are logged, and there is an undo button for everything. Any person who is aware of which admin accounts may be inactive and what can be done with them will surely be aware of how easily their actions can be undone. It is far more likely that any unauthorized use would come from an admin leaving their account logged in somewhere, at a library for example, or in a college dorm room/workplace where a disgruntled colleague may be able to access. There really are few reasons to try and hack an admin account anyway. There is no secret information to be gained, no money to be wired to a Swiss bank account, no claim to fame as long as we deny recognition... All this policy will do (in my opinion) is add unnecessary bureaucracy to prevent a very rare occurrence. Admins may feel like they cannot take a break, lest they get "demoted" or "punished" by having their tools removed. Even if it is not considered punishment per policy, it may feel like that to the admin that has this happen to them. Not to mention the fact that the proposed policy states: "If, after a period of one week, the inactive administrator has not made any edits or logged actions, or has not in some other way acknowledged receipt of the notices given in step 1, the user who left the notices may make a request at m:Steward requests/Permissions for the removal of the administrator's sysop flag." So, any "inactive" admin just has to log in for 5 minutes a week and block a vandal at ANV or semi-protect one page at RPP. If this were a common occurrence, I would agree with the proposal. As of right now, it is simply unneeded. Avicennasis @ 11:31, 21 March 2010 (UTC)

Oppose I agree with Avicennasis. I feel like I would be spitting his words back out if I launched into a lengthy explanation. Don't think this is needed right now, Airplaneman talk 16:35, 21 March 2010 (UTC)

Comment. I should point out that this exact policy is listed at perennial proposals, which is a list of things that are frequently proposed on Wikipedia, and have been rejected by the community several times in the past. Also see Wikipedia:Requests for adminship/desysop poll. Like I said, if the admin has passed a RfA and gained the community's trust, then that tust should remain; (mis)use or (ab)use of tools is one thing - (non)use of tools is quite another. Also, the propsed policy would need drastic re-writting if it were to become actual policy. In the example listed about, it is far too easy for an "inactive" admin to violate the spirit of the policy, while not violating the letter of the policy. As is, there are too many loopholes. Also, the policy seems to be based off of users taking action, rather than a standard or automatic process. This would easily allow for for "targeted" de-sysop request; an admin who regularly blocks 3RR editors, for example, may get a warning (and following de-sysop) much sooner that an admin who helps at DRV. Even though an admin can easily request their rights back, this allows for users to make admins "jump though hoops" on their return to get those rights back. Avicennasis @ 20:36, 21 March 2010 (UTC)

Strong oppose. It is the responsibility of any user Administrator or not to make sure their account is used only by themselves. Just because a user has not been active for some time does not mean that their account will be compromised that is a separate issue entirely. Administrators are picked in a process that is not taken lightly judging from reading some of the RfA past succeeded and failed archives. I believe then the process that a user has gone through to become an administrator should allow them and only them (unless they are abusing their powers) decide when they are no longer able to be administrators anymore. Now perhaps if there was a way to temporary "disable" a administrator's account if he is inactive for a long period of time...by say ..having to resend an auto confirm email to the email they used to sign up..or some such manner. that could be an option. I would suggest somthing temporary if needed that the user himself can reactivate...or something. But... otherwise you would have to open up a whole new can of worms to figure out ...ok how long does the user have to not be active to be diasbled from being an administrator? How active do they have to be?

I don't think it is our job to police administrators in that fashion as long as they are doing what they should be doing without abusing power i think they should be active for as long as they see fit. They earned it.

Evenios (talk) 07:32, 22 March 2010 (UTC)

Strong Oppose - What I don't understand is this; how does it hurt to have inactive administrators? Honestly, these are the "most trusted" members of the community. Why should their tools be removed from them? Opposing per this and above reasons. Ajraddatz (Talk) 16:40, 25 March 2010 (UTC)

Implementation of bureaucrat removal of admin and crat flags

Following from the two discussions on giving bureaucrats the technical ability to remove admin and bureaucrat flags, in February 2009 and then January 2010, and the more recent discussion on implementation; a clear conclusion is that a concrete policy governing bureaucrats' use of this tool is desired. Accordingly, there is now a policy proposal at Wikipedia:Administrators#Bureaucrat removal, which mandates bureaucrats to remove rights only in the uncontroversial instances. Please come and share any thoughts on the proposal at the associated discussion. Happy‑melon 12:34, 18 March 2010 (UTC)

This is already being discussed (and opposed) above. Ajraddatz (Talk) 16:45, 25 March 2010 (UTC)

Futher as Above

Do the same (and I do assume they do)foundations areas as above Wikipedia:Village pump (proposals)#Deletion of 1yr old vandalism-only inactive accounts cover the same grounds for a soft block for K-12 schools. They can research till there harts content, but no editing. Mlpearc MESSAGE 00:00, 23 March 2010 (UTC)

Since I'm an age where we didnt have computers in school like they do now Im not as sure if this applies to all schools or not- wouldnt a soft block on schools also block the teacher's access, so teachers cant edit either? Do we want to block teachers? And why block all students? Shouldnt we be encouraging students to edit responsibly? Imagine how much better Wikipedia could become if we actively encouraged school teachers to have their students to real research in order to edit the article on their hometown, or on some history subject they are studying, or something like that. Tiny towns and hamlets and villages that are currently stubs could turn into great articles with multi-paragraph long sections on history, geography, transportation, education, architecture, etc. Instead of blocking schools maybe have Wikipedia actively reach out to teachers and offer support on our policies so they can be aware of our editing style and have a course plan established for this type of student project. Plus it allows us the opportunity to have at least one of those students turn into a regular editor because he/she decides to go on (and of course we might have some vandals as well, but I think that the good outweighs the bad).Camelbinky (talk) 00:10, 23 March 2010 (UTC)
This was not written with Teachers in mind, ( my mistake for not clarifying this) and of course we should encourage all young minds to excel, and contribute. But in the real editing world where do 80% of vandalism come from ? Mlpearc MESSAGE 00:30, 23 March 2010 (UTC)
Why not instead put more effort into working with schools to help get younger people to edit responsibly. That always seems better to me than a autoblock policy. Ajraddatz (Talk) 16:58, 25 March 2010 (UTC)
Oppose blanket preemptive blocks. –xenotalk 13:18, 23 March 2010 (UTC)
Oppose How can someone be pre-emptively blocked and in the same way be encouraged at improving their editing? Sorry but I have to oppose this proposal. Ottawa4ever (talk) 15:46, 23 March 2010 (UTC)

If I take the URL of a page and put it into an RSS feedreader, I get the RecentChanges feed. Now, no one (except bots) in their right mind would want to subscribe to our RC feed (The RC feed is only useful on sites like usability:, which have an edit every two days). Instead, subscribint to a page on Wikipedia should subscribe to the page history. The change is a small one: 

<!--Change this in the <head> of the HTML for User_talk:Manishearth (example)-->
<link rel="alternate" type="application/rss+xml" title="Wikipedia RSS Feed" href="/w/index.php?title=Special:RecentChanges&feed=rss">
<link rel="alternate" type="application/atom+xml" title="Wikipedia Atom Feed" href="/w/index.php?title=Special:RecentChanges&feed=atom">
<!-- to this (present in User_talk:Manishearth?action=history): -->
<link rel="alternate" type="application/rss+xml" title="User talk:Manishearth RSS Feed" href="/w/index.php?title=User_talk:Manishearth&amp;feed=rss&amp;action=history">
<link rel="alternate" type="application/atom+xml" title="User talk:Manishearth Atom Feed" href="/w/index.php?title=User_talk:Manishearth&amp;feed=atom&amp;action=history">

Comments? ManishEarthTalk • Stalk 04:54, 25 March 2010 (UTC)

That's the global site feed and should rightly be available from every page. Just because it's not helpful on enwiki doesn't make it any less helpful on the majority of other MediaWiki installations. If you goto the history page, you get the links for the feeds for an article. I *believe* there's an open bug requesting the feeds be available when action=view (I'm too lazy to go searching for it at the moment). Also, RSS is going away on the next scap, we're only serving Atom now (by default). ^demon[omg plz] 13:04, 25 March 2010 (UTC)
Couldn't we disable it on enwiki? I'm not sure if its possible to modify stuff in the <head> of a page through js... ManishEarthTalk • Stalk 15:14, 25 March 2010 (UTC)

protecting WP: namespace

I propose that the WP: namespace be creation protected. I came across Wikipedia:Rogerguerin, which was made about a year ago and was lying there since. (I tagged it with a nonspecific CSD template as it's a unique case.) If someone wants to make a new page, they can easily request it. We also need to purge the WP namespace of such pages. If there's one, there are probably more. We can probably filter out wikiprojects anyways (Though we should crosscheck if all Wikiproject pages are in WP:PROJDIR using a toolserver script), and stuff listed at WP:POLICY, but we really need to creation-protect the WP: namespace and purge it of all unwanted pages. ManishEarthTalk • Stalk 10:37, 22 March 2010 (UTC)

I do not see anything unique. It was just G11. Ruslik_Zero 10:48, 22 March 2010 (UTC)
No it wasn't. Roger Guerin already exists. Looks like the user just got confused. ManishEarthTalk • Stalk 11:34, 22 March 2010 (UTC)
It was an obvious spam (And more to come ...). Ruslik_Zero 14:21, 22 March 2010 (UTC)
So even new essays would require admin assistance in order to be posted in WP namespace? And new proposals as well? That could have a chilling effect on metapedian speech, especially efforts at Wikipedia reform, which is an uphill battle as it is. Why wouldn't the usual procedures, such as New Page Patrol, work just as well in the WP namespace as elsewhere? Tisane (talk) 10:52, 22 March 2010 (UTC)
Ooh good point about essays. I forgot about them. ManishEarthTalk • Stalk 11:34, 22 March 2010 (UTC)
And archivebots such as MiszaBot and ClueBot III should get the admin bit, solely to make the archive pages? (X! · talk)  · @540  ·  11:56, 22 March 2010 (UTC)
Allow bots. Anyways, I've changed the proposal, see below. ManishEarthTalk • Stalk 12:47, 22 March 2010 (UTC)
Oppose. Users can already put spam in their user spaces. So would we need to creation protect those as well? Plus, the protection would need to have one exception for each of the deletion discussion processes, which do not currently use the Wikipedia talk namespace. PleaseStand (talk) 11:11, 22 March 2010 (UTC)
Well, the code could be changed to apply only for new top-level pages (pages which aren't subpages/are subpages without parents) ManishEarthTalk • Stalk 11:34, 22 March 2010 (UTC)

Well, we should atleast sweep the namespace for once, and have a tool which monitors all non-subpage new pages, which people should check on every now and then, maybe via RSS (Any devs?) ManishEarthTalk • Stalk 11:34, 22 March 2010 (UTC)

I think the problem is rare enough that you can tag pages as you see them. No point in preventing people needlessly. Aiken ♫ 13:58, 22 March 2010 (UTC)
Yes. Thats why I've changed the proposal to just "scan the WP namespace for unwanted articles" using a tool which filters out subpages. Another tool should generate an rss page of new WP pages which aren't subpages. ManishEarthTalk • Stalk 15:16, 22 March 2010 (UTC)
If someone wants to make such a tool, they're free to do so. You don't even need to file a BRFA for a read-only tool. I don't think it would be an especially good use of Wikimedia's paid developers' time though, if that's what you're suggesting. Mr.Z-man 16:45, 22 March 2010 (UTC)
Not paid devs. Toolserver ones.
I did an analysis of the namespace and it seems it's one big unstructured and uncategorized mess: User:Svick/Wikipedia namespace. Svick (talk) 17:53, 23 March 2010 (UTC)
We need to MfD those AfDs... I thought that they were deleted after a month or so of being an archived ManishEarthTalk • Stalk 03:36, 25 March 2010 (UTC)

If you are interested in cleaning up the Wikipedia namespace, check for example Wikipedia:Database reports/Orphaned single-author project pages or Wikipedia:Database reports/Orphaned article deletion discussions; for other interesting reports see Wikipedia:Database reports. Cenarium (talk) 18:53, 23 March 2010 (UTC)

Editprotecting?

Atleast editprotect the WP: pages from IPs (maybe autoconfirmed, too) WP:VAND gets vandalised every day (so does the talk page, but we can't help that) Most people filter out WP: pages when RCpatrolling, which is evident through the fact that this edit wasn't reverted until I saw it in my watchlist (Yes, its only an 8 minute difference, but after 8 minutes, you can consider the edit permanent). ManishEarthTalk • Stalk 03:00, 24 March 2010 (UTC)
What? WP:VAND has been semiprotected since 2007, and AFACT has been vandalized only twice since January. The talk page isn't protected, but gets vandalized only about 5 times per month. Neither are even close to "every day." Mr.Z-man 03:19, 24 March 2010 (UTC)
Really? I must be mixing up the talk pages with the actual page. But I'm quite sure that there's a lot of vandalism there, just right now there was a heated debate going on, so the vandalism was buried. Many times my watchlist has a reverted edit in it. Anyways, what's the need of letting IPs edit WP: pages. WT: is OK, but even I don't edit WP: pages except the pumps and the sandbox. All WP: pages should be IP protected except discussion pages and the sandbox. ManishEarthTalk • Stalk 03:51, 24 March 2010 (UTC)
Why must we protect the entire namespace, and not just the articles infected? I r confused. Ajraddatz (Talk) 16:51, 25 March 2010 (UTC)
Be cause RCpatrollers and Huggle users by default filter out the WP: pages. Scenario: A vandal receives a message telling him to stop vandalizing. There are links to policy pages there. He follows a link, and sees the "edit" tab. He thinks "Wow! I can edit this", and he edits it. The edit goes unnoticed, except by watchers of the page (And most policy pages aren't watched by people...The ones which are watched are for the discussion pages). This is exhibited by my example above of WP:Rogerguerin. ManishEarthTalk • Stalk 02:51, 26 March 2010 (UTC)
If someone has to vandalize something, I would rather it be something in the WP: namespace or userspace than an article (i.e. something that matters). Note that you cannot watch just a discussion page. When you watch a page, you watch the page itself and its corresponding talk page (or vice versa). Mr.Z-man 03:04, 26 March 2010 (UTC)

Thats what I meant. The only policy pages watched are those with active discussions. ManishEarthTalk • Stalk 12:37, 26 March 2010 (UTC)

Article subtitles

I'd like a mechanism for adding a secondary title to articles that could be optionally listed in categories. For many types of articles, for example legal cases (Smith v. Jones), technical standards (ANSI Z535) and so on, the title tells you nothing about the subject. A short subtitle added using a tag similar to the default sort tag would make the category listings more intelligible. The reader should be able to toggle the subtitles on and off as they saw fit to deal with over-full categories.--agr (talk) 00:01, 25 March 2010 (UTC)

Can you explain how you contemplate this would work a little more completely? I think I know what you mean in a vague way, but I'm not at all sure I know what you mean. What I got is that for "Smith v. Jones" say, the subtitle would be something like U.S. legal case, or even more detail like U.S. legal case, abortion rights and that subtitle would only appear in the category listing and would not be visible in the article except when viewing the code, possibly taking the form of a second parameter in default sort such as {{DEFAULTSORT:Life of Brian|Monty Python comedy film}}. Is that anything like what you mean?--Fuhghettaboutit (talk) 04:59, 25 March 2010 (UTC)
Interesting idea - could certainly make category listings less cryptic. But if the text is only visible in category listings, maintenance on low-visibility pages would be a nightmare - god only knows what vandalism could stay there for how long. Rd232 talk 12:13, 25 March 2010 (UTC)
I envision pithy, non-controversial subtitles that would aid a reader in deciding whether to click on the article link, like Fuhghettaboutit's Life of Brian example. They shouldn't merely duplicate category names. So for Gideon v. Wainwright the subtitle might read "State courts must provide indigent defendants with counsel." The fact that it was a US Supreme Court ruling could be left out of the subtitle on the theory that the reader is most likely to encounter it in a category of US Supreme Court rulings. ANSI Z535 might be subtitled "Standards for safety markings." I was thinking about their utility category listings, but the subtitle could also appear in smaller print under or next to the article title, as a user option perhaps. That would deal with the maintenance problem. Software resources permitting, subtitles could also be shown in link mouse-overs and spoken by assistive readers on request when a link is encountered. We might disallow them for living persons at first to avoid creating new BLP issues. Using a second parameter in DEFAULTSORT:Life or creating a new tag seems to me an implementation judgement call.--agr (talk) 17:29, 25 March 2010 (UTC)
Sounds more like a keyword or keyphrase rather then a subtitle. ---— Gadget850 (Ed) talk 17:42, 25 March 2010 (UTC)
Popups show you the lead of an article, this accomplishes most of what you're aiming for. Fences&Windows 23:34, 25 March 2010 (UTC)
It's a nice tool—I wasn't aware of it before—but it don't give readers a guide to opaque category listings like Category:ANSI standards or Category:United States Supreme Court cases of the Rehnquist Court. Also it requires a user to have an account, so it's not available to the vast majority of our readers.--agr (talk) 03:21, 26 March 2010 (UTC)

Re-enabling JavaScript access to the API

I'll keep this as technically low as possible, so apologies in advance to anybody who thinks I'm giving too much background info about this proposal.

The WikiMedia API is the piece of the software that allows automated browsing and editing (e.g. for bots, tools, helper scripts, etc.). The API was designed to be accessible by JavaScript, a scripting language that runs inside webpages. However, since the time of the development of the MediaWiki API, browser manufacturers have placed increasingly greater restrictions on the abililty of JavaScript running on one page on the internet to communicate with other pages elsewhere on the internet. This was to protect internet users from malicious uses of JavaScript. Unfortunately, it also meant that access to non-malicious uses, such as the WikiMedia API, were restricted also.

Last year, the standards body for the internet published a solution for this issue and, over the last few months, this standard has been implemented by all the major browser manufacturers. As a consequence, in the new releases of all popular browsers, cross-domain JavaScript is completely disabled by default and check boxes, which previously allowed users to enable it for certain pages, have been removed from preferences dialog. The new standard is that websites that have content that they want to be accessible by JavaScript running on another webpage need to explicity state so in the HTTP headers of the relevant pages.

There are many flavours of approaches that we might take in doing so. My conservative proposal (for now at least) is that we:

  • Enable JavaScript running on the toolserver.org to browse, log in and edit pages.

Such scripts were previously able to do this for all browsers and, if you have a browser older than a few months, still can.

For us to do this would require a code change to the api.php file on the Wikipedia servers: 

header("Access-Control-Allow-Origin: http://toolserver.org");
header("Access-Control-Allow-Credentials: true");

I have described two other approaches we could take on a sub page of my user page. These are:

  • Enable JavaScript running on any website to browse, log in and edit pages.
  • Enable JavaScript running on any website to browse and edit pages - but only JavaScript running on the toolserver.org to log in.

The first of these is how the API was originally designed to run (and, my conservative proposal side, my preferred approach). The second is the restricted manner in which it was possible to access the API until the last few updates to the major web browsers.

These changes, particularly the "conservative" proposal, don't constitute an increased security risk since malicious users can still trivially bypass the restrictions on cross-domain JavaScript should they wish to do so. Rather they lift the restrictions placed on ordinary users, allow JavaScript-based tools to continue to function as normal and mean that script writers don't have to resort to work-arounds that are of benefit to noone.

They do not affect other technologies that use the MediaWiki API, such as PHP or C# applications, or JavaScript that is run on from wiki.eso.workers.dev. Tools written using other technologies continue to have full access to the API (as do malicious users of JavaScript). --RA (talk) 14:36, 25 March 2010 (UTC)

This is already implemented for the API. See bugzilla:19907. Though I think it might not yet be deployed, and if it is, toolserver probably isn't included in the whitelist yet. See also bugzilla:20298. —TheDJ (talk • contribs) 20:33, 25 March 2010 (UTC)
LOL! I could have saved myself a lot of typing if I had checked the SVN! The implementation is real nice too. Here's r62546 and we are running r64051. So it looks like it is deployed and ready to go.
The question then is, are we in consensus to add '*.toolserver.org' to the wgCrossSiteAJAXdomains array in includes/DefaultSettings.php (if its not done already)? If so, who can do that? --RA (talk) 22:46, 25 March 2010 (UTC)
I don't think anyone would object, though perhaps it might be a good idea to limit to stable.toolserver.org at first. Any such requests should be filed at bugzilla: under Wikimedia site requests. —TheDJ (talk • contribs) 22:54, 25 March 2010 (UTC)
You are an oracle of knowledge, DJ. It looks like the stable.toolserver.org is no more. (Follow any link in this Google search). I'll open a request for all of toolserver and see how it goes. --RA (talk) 23:45, 25 March 2010 (UTC)
Request submitted. Thanks for your help. --RA (talk) 00:05, 26 March 2010 (UTC)
Update: Tim Starling says no for reasons of account security. I suggested to set Access-Control-Allow-Credentials to false, but I guess it ain't gonna happen. --RA (talk) 11:08, 26 March 2010 (UTC)

Deletion of 1yr old vandalism-only inactive accounts

I propose to delete all vandalism-only accounts which are more than a year old without any activity. The deletion should free up the user name for account creation. All of the users edits must have been reverted, and the edit and its revert should also be removed from the database so the new user can start with a clean slate. I'm not sure if this is possible, but it seemed like a good idea... Comments? ManishEarthTalk • Stalk 13:13, 22 March 2010 (UTC)

The edits will not be removed from the database, but the username could be renamed to "Renamed user xxxx". –xenotalk 13:15, 22 March 2010 (UTC)
This is already done occasionally through WP:USURP, but I can't see the benefit of doing it for every account. Besides, if its done by bot/automated it would also release thousands of offensive user names and to do by hand would take years. --Jac16888Talk 13:20, 22 March 2010 (UTC)
Indeed - most vandals don't use desirable names anyway. –xenotalk 13:22, 22 March 2010 (UTC)
  • Oppose because I don't know what real benefit this will serve. If someone desires a name that a vandal had, they can usurp it. Aiken ♫ 13:56, 22 March 2010 (UTC)
  • Oppose Fundamentally I see the point that there are user names that would be desirable that are taken up by inactive accounts that are a few years old. In addition, for a new comer it might be a bit difficult to undertsand the whole usurp thing (though once you know about it its simple) However, I think this isnt the best idea mostly due to what was mentioned above about tracking socks. Alot of vandals Ive seen return with simillar account names longer than a year and its easier to keep a long term abuse record with the previous existing accounts. They could also in theory just re-create their blocked account and continue to harass individuals (an extreme) but nether the less a reason which i oppose the general rule. I think the usurp process is just fine in order to get an account name thats inactive orr only used for that single purpose. Though its a good issue and point that you bring up. Ottawa4ever (talk) 15:14, 22 March 2010 (UTC)
  • Strong Oppose Per Ottawa4ever (talk · contribs). Immunize (talk) 15:23, 22 March 2010 (UTC)
  • Not possible Our copyright licenses requires attribution of all edits—yes even edits that are the written equivalent of fart noises at the back of the auditorium. Even if the opposes above were all supports it would not matter: We cannot do this. You'll note that the threshold requirements of username usurpation is that the target username have "no edits or significant log entries"; same reason.--Fuhghettaboutit (talk) 23:30, 22 March 2010 (UTC)
    • I fear this is a bit overstated. If the user has no edits that actually form part of the encyclopedia, there is no legal impediment to renaming or deleting the account. Even if the user did have a vanishingly small number of edits, there would be no serious legal impediment, though there might be a policy and practice issue. Newyorkbrad (talk) 23:57, 22 March 2010 (UTC)
      • Even if it were true of those who just added pure vandalism to articles, how would we ever separate out the numerous vandalism only accounts who made a few good edits as a false flag or even edited for a few days to get autoconfirmed before launching into their rampages.--Fuhghettaboutit (talk) 02:30, 23 March 2010 (UTC)
        • Just because we don't like the vandalism and get rid of it (rollback/undoing/os'ing) doesn't mean its not part of the encyclopedia.... if the user makes a edit and its available in the article history it is my understanding that we must attribute them. Peachey88 (Talk Page · Contribs) 12:33, 23 March 2010 (UTC)
          • Even if this were true, attribution is still available even if the account is renamed. Just follow the breadcrumbs. Bureaucrats will and have been vacating vandalism-only accounts for usurp requests as not GFDL(and now cc-by-sa)-significant. –xenotalk 13:20, 23 March 2010 (UTC)
          • If its rolled back or deleted, that's exactly what it means. All we need to give credit to are the people who actually contributed something to the current version of the page. Our attribution requirements are still based on copyright law, and I don't think you can claim copyright on something that you didn't contribute to. Mr.Z-man 14:07, 23 March 2010 (UTC)

Alternative idea: What about deletion of accounts that have never made a single action other than the account creation entry and is N days/months/years old? If they've made no edits or other work to attribute, we hardly have to retain the creation log for licensing. I don't really have any strong opinions either way, but it would address the issue of "freeing up usernames" without the licensing issues. ^demon[omg plz] 02:04, 25 March 2010 (UTC)

And if the user logs in, and uses the Special:Preferences to modify the interface, would we be able to know? It would be wrong to prevent those users from using their preferred skin, having all times in histories/logs be according to their time zone, etc. עוד מישהו Od Mishehu 05:31, 25 March 2010 (UTC)
Then exclude people who've set preferences as well. My point remains the same. ^demon[omg plz] 01:17, 26 March 2010 (UTC)
I would support this for accounts over 1000 days old. –xenotalk 01:21, 26 March 2010 (UTC)
This takes care of the licensing issue entirely. I'm still not seeing a good reason to do this though. I have no objection, just not sure it has much utility. Under this version, any account we delete would have been usurpable. So we are preemptively freeing up the names, and some who might not have discovered or bothered with usurpation will be able to sign up without ever realizing the name they choose was once taken. Is that such a boon that we need bother? I'm actually asking.--Fuhghettaboutit (talk) 02:32, 26 March 2010 (UTC)
I agree, I see no reason to do this. In addition, I can't see how it could be done. As far as I know there is no way currently for any person to remove an account all together, with perhaps the exception of developers. Sure, they can be renamed to User:Usurped 666 or hidden from view, but the account is still there, this isn't going to change anytime soon. Or does this alternative suggestion involve moving old accounts to something different aka usurp. If so, who'se going to do it? Do you want the few crats we have to go through the hundreds of thousands of unused accounts we have, renaming them all to User:Unused 1, 2, 3 etc, all on the offchance some newbie wants the name, which considering the relatively low number of requests at Usurp isn't that common? Or should a bot should do it? Which would mean giving a bot a crat flag, something never done before afaik, and considering the masses of debate before we started giving bots sysop flags, its not likely to happen anytime soon? --Jac16888Talk 02:45, 26 March 2010 (UTC)
I was saying to have a developer run the "removedUnusedAccounts" script, which physically deletes unused accounts from the database. Right now the script doesn't take preferences into account like I suggested (it will ignore based on user_touched, which is more greedy, iirc). Right now the command would be php removeUnusedAccounts.php --delete --ignore-groups=sysop,bureaucrat --ignore-touched=1000. ^demon[omg plz] 17:16, 26 March 2010 (UTC)
Unused accounts could be alternative accounts (usually declared on user or talk pages), doppelgänger accounts (not necessarily declared), or SUL accounts. snigbrook (talk) 20:14, 26 March 2010 (UTC)

Proposal for preemptive protection of BLPs at risk

There is a proposal for an amendment of the protection policy to allow preemptive protection of BLPs at risk (currently, the policy states that protection should not be used as a pre-emptive measure). Cenarium (talk) 19:00, 23 March 2010 (UTC)

I oppose. Dg-reg-fd-1971 (talk) 15:42, 25 March 2010 (UTC)

Please comment on the linked page, this is jut an announcement. Thank you, Cenarium (talk) 13:45, 26 March 2010 (UTC)

What is a jut? Dg-reg-fd-1971 (talk) 21:09, 26 March 2010 (UTC)

Add a new word to the dictionary

"Googleable: (adv) describing someone or something that can be retrieved directly via a search using the Google internet search engine. Google is a multinational public cloud computing and Internet search technologies corporation."

e.g. Question "I hear that you're on google" Answer " Yes, I'm googleable, aren't you?"

—Preceding unsigned comment added by 204.40.1.129 (talk) 19:32, 26 March 2010 (UTC)

Better icons for user warnings

I was thinking that we can use better-looking icons (at least these look better to me) for user warnings. Below, I have placed my proposals. Please edit the appropriate subsection below, depending upon your position. -- IRP ☎ 14:59, 9 March 2010 (UTC)

Icon Replacements
→

→

→ [I am not sure what to replace this with]

→

Support
  1. I support the change to the first icon (looks friendlier IMO) but not the rest. --Yair rand (talk) 22:28, 9 March 2010 (UTC)
  2. They do stand out more, which might prevent a vandal from not reading the messages...ManishEarthTalk • Stalk 01:44, 10 March 2010 (UTC)
Neutral

  1. I fear change. –xenotalk 20:23, 9 March 2010 (UTC)
  2. When comparing the two sets, Crystal Clear and Nuvola it's hard to decide. There's good icons in both, we should use some from each. -- Ϫ 08:51, 10 March 2010 (UTC)
  3. I have no particular opinion on the first two suggested changes. As for the third and fourth, there should be no icon. In the spirit of "PDFTT", such messages should look boring, in order not to provide any satisfaction for attention-seeking nitwits. -- Hoary (talk) 16:23, 10 March 2010 (UTC) ... very slightly rephrased, and moved from "oppose" to "neutral" -- Hoary (talk) 03:01, 11 March 2010 (UTC)
  4. eh... if we're going to go to the trouble of changing icons, let's at least make a real improvement. the new icons are marginally better, at best. --Ludwigs2 15:45, 11 March 2010 (UTC)
  5. There is a point to improving them, but this change is cosmetic. We need the icons to show the escalation of importance in a specific and transparent manner. So I am positively and conspicuously neutral on this change Fiddle Faddle (talk) 15:51, 11 March 2010 (UTC)
  6. There should be no "wrong" icons to use; I've used custom warning templates in the past and I think that variation within reason should be permitted. So long as the user understands the message and it is neither too weak nor too strong, I don't the icons should matter. —Soap— 17:47, 13 March 2010 (UTC)
  7. Rather trivial, and I do not think the new images are any better or worse than the old ones. As Soap mentioned, if a user doesn't like the generic templates, custom ones are always an option. Airplaneman talk 17:54, 21 March 2010 (UTC)
  8. I dunno, I kinda like the old ones... Ajraddatz (Talk) 16:43, 25 March 2010 (UTC)
Oppose

  1. What's the point of changing anything? In what way are your proposals better than the current set? You've not explained this very well... ╟─TreasuryTag►cabinet─╢ 16:33, 9 March 2010 (UTC)
    In my view, they look more appealing to the eye. They draw more attention. -- IRP ☎ 18:49, 9 March 2010 (UTC)
  2. The initial icons are clearer than the proposed replacements, if not as shiny. :/ {{Nihiltres|talk|edits|⚡}} 17:07, 9 March 2010 (UTC) (iPod edit)
    To me, the proposed replacements look better. -- IRP ☎ 18:49, 9 March 2010 (UTC)
    Well, to us, they don't... ╟─TreasuryTag►ballotbox─╢ 19:21, 9 March 2010 (UTC)
  3. I like the existing ones, the replacements are blurry. Fences&Windows 20:19, 9 March 2010 (UTC)
  4. The second icon, especially, is harder to view. Also, I'm not sure the new set would scale well. —C.Fred (talk) 20:32, 9 March 2010 (UTC)
  5. A resounding meh. Concur about blurriness. --Cybercobra (talk) 20:36, 9 March 2010 (UTC)
  6. I'm all for change, even just for the sake of looking cooler, but the proposed replacements don't really seem like an improvement. Equazcion (talk) 21:23, 9 Mar 2010 (UTC)
  7. Looks like a step backwards to me. – ukexpat (talk) 21:58, 9 March 2010 (UTC)
  8. (edit conflict) Agree, don't see the new icons as that much of an improvement. Mo ainm~Talk 21:59, 9 March 2010 (UTC)
  9. We should be removing the icons entirely. --Carnildo (talk) 22:49, 9 March 2010 (UTC)
  10. Bad idea. The icons catch the eye of a vandal and he actually reads the stuff. Actually it would be better to replace the icons with some faces, like smiling, then sad, then angry, then furious. THat will sum up the message pictorally.
  11. The suggested alternatives are not an improvement IMHO. Mjroots (talk) 09:40, 10 March 2010 (UTC)
  12. No way - big waste of time and I prefer the old ones. Kayau Voting IS evil 09:53, 10 March 2010 (UTC)
  13. The original icons are directly face on and easy to see, where as the suggested replacements seem to be angled and have light effects/blurs on them making them a tad harder to see, as well as the blue/white and yellow/brownish colour schemes seem to clash on the information and exclamation signs respectively (See: Wikipedia:ACCESSIBILTY#Color). If anything I would probably prefer replacements that were front on with minimal solid colours that didn't include and effects (such as shading)...... Peachey88 (Talk Page · Contribs) 09:57, 11 March 2010 (UTC)
  14. Proposed icons are not significantly better than the current ones. The 3D effects are a bit kitsch, and makes them less clear. However I like the idea of the middle strenght warning (triangle sign) being yellow instead of red. Elekhh (talk) 00:56, 12 March 2010 (UTC)
    In that case, why not use ? --Yair rand (talk) 01:15, 12 March 2010 (UTC)
    Yes, I would support this one. --Elekhh (talk) 05:51, 27 March 2010 (UTC)
  15. I oppose the replacement of the current icons with the proposed icons, as it feel (to me) like a massive step backwards. I agree that the proposed icons are blurry, and (to me)look far worse than the current ones. Immunize (talk) 17:36, 13 March 2010 (UTC)
  16. Yeah, I actually just wanted to use this :D I strongly oppose, whatsoever. --JokerXtreme (talk) 23:39, 13 March 2010 (UTC)
  17. Picking the equivalent icon in a nearly-equivalent icon set is not enough change to bother. Ikluft (talk) 12:32, 14 March 2010 (UTC)
  18. Hate those 3D effects. —TheDJ (talk • contribs) 13:19, 14 March 2010 (UTC)
  19. I don't like the new graphics, and why fix what's not broken? SchuminWeb (Talk) 23:52, 15 March 2010 (UTC)
  20. Contrast is better on the current ones. Mr.Z-man 23:56, 15 March 2010 (UTC)
  21. Above reasons (contrast, not face-on, no improvement, etc.), plus there is no proposed, matching replacement for File:Stop hand nuvola.svg, the icon most commonly used in vandalism warnings. PleaseStand (talk) 13:51, 20 March 2010 (UTC)
  22. Not enough difference between current and proposed sets, proposed set is friendlier looking, which will probably be counterproductive when warning vandals. RadManCF ☢ open frequency 17:41, 20 March 2010 (UTC)
  23. I just believe that a strong degree of directness in the warnings is required to halt the damage being done and it shouldnt be made more graphically 'spiffy' they are fairly direct the way they are. I do however like the first warning change. Just not the subsequent ones. Ottawa4ever (talk) 17:53, 20 March 2010 (UTC)
  24. To me it seems the current icons serve just fine. I dont see any major need for changes at this time. Evenios (talk) 07:35, 22 March 2010 (UTC)

Rename the move function to... rename

Hello,

Was just "moving" a page and it occurred to me that a more accurate name for the function would be "rename". What are people's opinions on this? Aiken ♫ 15:36, 13 March 2010 (UTC)

Technically the Mediawiki software "moves" the page, leaving a redirect behind in the old location. Well, kind of. I have a genuine "don't care either way" over this. It's just a bit of software, after all. Fiddle Faddle (talk) 15:49, 13 March 2010 (UTC)
Technically schmechnically... there's a case that "rename" might be clearer to newbies. This might be an issue for the Usability Initiative guys to look into. Rd232 talk 22:00, 13 March 2010 (UTC)
We have a Usability Initiative? Wow, does that mean we'll throw Mediawiki software away? Fiddle Faddle (talk) 22:36, 13 March 2010 (UTC)
I doubt it, but you could ask them: usability.wikimedia.org. Rd232 talk 23:56, 14 March 2010 (UTC)
Already told them about the renaming idea: usability:Talk:Main_Page#Suggestion_from_Pump:_.22Move.22_-.3E_.22Rename.22 --Cybercobra (talk) 00:04, 15 March 2010 (UTC)
We don't want newbies to move pages. Do you want another Willy on wheels? Newbies don't need to move pages. They can request a move if they want to. They will discover the "move" button sooner or later and find out what it means (No, they won't do any damage, as they will see MediaWiki:Movepagetext at the top of the page before they move).

If you still want to go ahead with this, ask an admin to change the text here to "rename". ManishEarthTalk • Stalk 03:43, 15 March 2010 (UTC)

Reply to Fiddle Faddle (User:Timtrent): The Usability initiative is just making the interface look better, it still uses MW. Basically, the "Try Beta" link next to your username/talkpage/prefs/contribs at the top of the page (the personal portlet) takes you to beta mode, which has a sleeker interface and a better edit box (If you don't wanna try beta, but are curious what it looks like, The Usability wiki has the same interface as beta. Or you can just enter and exit beta at your will).ManishEarthTalk • Stalk 03:24, 15 March 2010 (UTC)

Don't see why not. "Rename" sounds better, IMO. Airplaneman talk 19:15, 18 March 2010 (UTC)
But "Requested renames" doesn't flow off the tongue like "Requested moves". –xenotalk 19:19, 18 March 2010 (UTC)
True. I think I'll stay neutral for the time being. Airplaneman talk 19:55, 18 March 2010 (UTC)

I also support the idea of renaming move to rename. Immunize (talk) 19:18, 18 March 2010 (UTC)

"Move" makes more sense to me, especially with things like userfying, where a page is moved to one namespace to another place, with different rules, etc. I wouldn't really care either way or the other, but they aren't complete synonyms in my mind. —Akrabbimtalk 19:20, 18 March 2010 (UTC)
I'm not a big fan of this. It's come up often and as much as "rename" does make some sense, neither word is really completely technically accurate, and I'd rather go with the one that gives newbies some pause before clicking. I don't think newbies should be encouraged to do it before they're fully aware of what happens, and needs to happen, when a page is renamed/moved (ie. the ramifications). Equazcion (talk) 19:25, 18 Mar 2010 (UTC)

Reconsidering myself, mainly because "move" seems better than "rename" when referring to moves across namespaces. "Rename" really is not the best way of talking about these moves. And, why fix something that is not broken in the beginning. Immunize (talk) 19:32, 18 March 2010 (UTC)

I wonder whether changing the "move" function to "rename" might encourage what we know now as page move vandalism, as the function will be more obvious to casual users. For example, imagine a Green Bay Packers fan reading the article on Brad Childress. He sees the rename tab, and decides to rename the article to "Brad Childress that !@#$%#@@#$" It would definitely be worth remembering WP:BEANS. RadManCF ☢ open frequency 17:46, 20 March 2010 (UTC)

FYI, fr.wikipedia uses the term "rename", see fr:Special:Log/move. I believe this term to be easier understandable, but it really doesn't always accurately describe what's happening. Another reason not to do this change would be that we couldn't rename Special:MovePage/Foo. I wouldn't mind a change to "rename", this might make it easier to understand for some people and I don't think that this will give much more vandalism, but I don't think that the term "move" is so bad that we immediately need to change it. After all, I understood what it meant quite well when I was still a wiki newbie. --The Evil IP address (talk) 13:00, 27 March 2010 (UTC)

Proposal to treat IP addresses and vandalism-only accounts equally.

I am proposing that we treat IP addresses and registered vandalism only accounts equally-that is, we indefinitely block all vandalism only IP's, just as we indefinitely block all (or at least most) vandalism-only accounts, as I feel that our current method of dealing with IP vandals (giving a very short block initially) discourages registration and increases vandalism. [[User:Immunize|Immunize]] ([[User talk:Immunize#top|talk]]) (talk) 22:53, 25 March 2010 (UTC)

  • Strong oppose - Just because an IP is vandalism-only now doesn't mean it won't one day net a constructive contributor. –xenotalk 23:04, 25 March 2010 (UTC)
  • Oppose: IPs are dynamic, so if you indefinitely block an IP, it may only take a couple of weeks for the user of that IP to rotate to a new one, at which point you now have a redundant block; that may at some point end up blocking a potentially constructive user. SpitfireTally-ho! 23:07, 25 March 2010 (UTC)

If they are really that constructive, I would expect to see them create and account. Immunize (talk) 23:22, 25 March 2010 (UTC)

I take it you haven't read the study that showed significant amounts of content is/was contributed by IP editors? --Cybercobra (talk) 23:28, 25 March 2010 (UTC)
So you would then suggest we leave account creation enabled - so a steady flow of vandalism-only accounts can be created from the IP? –xenotalk 23:31, 25 March 2010 (UTC)
  • Oppose IPs do not necessarily belong to one person; accounts do. No point in banning an IP if it causes collateral damage. And, by the way, there are plenty of very constructive editors who don't create an account. Aiken ♫ 23:26, 25 March 2010 (UTC)

For example, a large number of disruptive edits could have been prevented if User talk:203.38.60.32 had received a indefinite block initially. Immunize (talk) 23:29, 25 March 2010 (UTC)

Possibly. But that's just one IP. Your suggestion is that every IP that ever got blocked for vandalizing should be blocked indef, which is a bad idea. Aiken ♫ 23:47, 25 March 2010 (UTC)
  • Oppose - Our current method of dealing with IPs is because almost every IP that edits the site is either dynamic or shared. If its dynamic, it might have a new user in days or weeks. If its shared, it might have a new user in minutes or hours. Blocking them for longer will just lead to collateral damage. Mr.Z-man 00:03, 26 March 2010 (UTC)
  • Oppose. Looking at the contrib history of an IP who is currently vandalizing, I often see a series of productive edits made in the past. --NeilN talk to me 14:07, 26 March 2010 (UTC)
Only if the IP adress makes vandal or incompetent edits. Dg-reg-fd-1971 (talk) 20:57, 26 March 2010 (UTC)
Huh? I don't understand the point you're trying to make. --NeilN talk to me 15:12, 27 March 2010 (UTC)

I don't either. Immunize (talk) 18:10, 27 March 2010 (UTC)

  • Oppose IP's rotate, like mine. If a vandal edits from my IP rotation range and is blocked, I won't be able to login (without propogating the block). Even softblocking is bad because the IP rotates. Fixed IPs are also transacted continuously (When the person moves, etc.). We can't indef block IPs. ManishEarthTalk • Stalk 01:33, 27 March 2010 (UTC)
  • Oppose unless it can be proven the IP in question is static. HalfShadow 18:12, 27 March 2010 (UTC)

Is there any way to prove an IP is static? Immunize (talk) 18:21, 27 March 2010 (UTC)

Doubt it. I edit from what can be considered a "static IP" but it still changes about once a year. --NeilN talk to me 18:28, 27 March 2010 (UTC)
Nonstatic (rotate-every few hours) IPs have a status "ALLOCATED PORTABLE", like [[1]] ManishEarthTalk • Stalk 02:25, 28 March 2010 (UTC)
  • Oppose it is reasonable to assume that an account belongs to an individual, but you can't make the same assumption of an IP. Even if an IP is static that doesn't mean that every future editor from that network or household will behave the same as the vandal who provoked the block. ϢereSpielChequers 18:27, 27 March 2010 (UTC)

Wikipedia:Village pump (proposals)/Persistent proposals

It has not been used since April 2009, is there still a point in it ? Otherwise, we should mark it as historical. Cenarium (talk) 01:16, 27 March 2010 (UTC)

It appears to me that it's completely redundant to Wikipedia:Perennial proposals. So long as there's a pointer to the more active page, I think we can mark it historical. — Gavia immer (talk) 01:23, 27 March 2010 (UTC)
Persistent proposals, if I recall correctly, is a dumping ground for threads-that-never-end on a pump. It appears we don't have any now (obligatory <high five>).
Perennial proposals is slightly different. –xenotalk 02:17, 27 March 2010 (UTC)
There are a few threads which stay for quite some time, like NOTNEWS at the top. In practice they remain on VPR. Hence it seems they're no need for /persistent. Cenarium (talk) 02:25, 27 March 2010 (UTC)
What do you mean by "not used"? Have you confused "not edited" with "not read"? WhatamIdoing (talk) 04:32, 29 March 2010 (UTC)
  • I created "persistent proposals" as a place where proposals could go that actually have consensus, but that aren't likely to be implemented soon due to developer time constraints, so that consensus proposals aren't lost to auto-archiving. This was in the midst of the development of global login, which seemed to be taking forever and put any other development on hold. Looking at the page now it seems to have been misunderstood and misused. The closures with vote counts seem entirely inappropriate for what the page is supposed to be. Maybe the instructions at the top could use some tweaking; or maybe no one's even reading them. I'll bow to whatever the consensus is, if people the think the page should be retired, reworked, or whatever. Equazcion (talk) 04:41, 29 Mar 2010 (UTC)

"Talkback bot" proposal

I have an idea for a bot that could potentially simplify communication on Wikipedia. Before I potentially waste my time coding it now, I have posted a specification so that the Wikipedia community can offer input on the proposal. Is it a good idea or not, and how can it be improved on? Please respond on the talk page. PleaseStand (talk) 06:02, 29 March 2010 (UTC)

Proposal to enable AbuseFilter blocking

I am continuing discussion this ANI thread, as it was archived prematurely, and wasn't the correct place for the discussion anyway. When AbuseFilter was introduced months ago, consensus was achieved for enabling it without the block option. Since then, there has been a proposal to enable it, citing multiple cases where it would be beneficial. I initially opposed this, as there are non-admins who have access to the tool, and that would allow them to block without having to pass RfA. Having done more research, I have determined two different options.

  1. The first option is the previously proposed one: allow blocking for everyone who has the abuse filter editor right, including non-admins.
  2. The second is only allowing admins to create/edit filters that do not block users.

Most people who commented in the previous thread were in support of this proposal, but there wasn't enough to garner consensus, nor was option #2 raised. As such, I'm asking you all: What do others think about this proposal?

  • Support option 2 - (X! · talk)  · @319  ·  06:39, 21 March 2010 (UTC)
  • Support option 1, neutral on option 2 - To avoid any potential conflict of interest, I should point out that I am one of the (extremely few) non-admin edit filter managers, so my thoughts should be taken with a grain of salt. However, as I stated at WP:ANI, I have full trust in all (approximately 4 active) non-admin filter managers that this tool would not be abused. Removal of this privilege is as simple as is for rollback and other such permissions, and edit filters are constantly monitored. The problem with option #2 is, as of right now, it would require developers to intervene and add additional levels of restriction in the edit filter, whereas enabling it for all that can edit filters is a simple configuration change. If it eases minds, I support option #1 with the added restriction that no filter enable block on hit without review by an actual administrator. And of course, naturally, any filter that is set up as such must go through rigorous testing to ensure it incurs no false positives. There is no room for error. --Shirik (Questions or Comments?) 06:45, 21 March 2010 (UTC)

There should be some sort of system in place for reviewing, identifying and dealing with incorrect blocks. Regardless of how hard we try, sooner or later an innocent user will be blocked. There needs to be something in place to make sure that this is identified and fixed as quickly as possible. --Chris 06:52, 21 March 2010 (UTC)

A valid point. It would be trivial for me (or anyone) to write a bot that monitors blocks and reports them in, say, an IRC channel for review. As far as I know we aren't talking about any high-rate block filters right now. The only one we've even considered is 278 which has only had 58 hits in about 3 months. The reason for the block is not because of high rate of blocks needed, but rather to stop the detected user before they find a way around the filter. Reviewing every individual block should be trivial. --Shirik (Questions or Comments?) 07:08, 21 March 2010 (UTC)
I wish I could remember which one, but at one point there was a +sysop bot that could block users, but would always then immediately post a stock unblock request on their talk page to make sure human eyes would, at some point in the process, review the automated decision. Such blocks could and probably should be mentioned somewhere with a real-time emphasis, too (you mentioned IRC). Many people viewed this as an essential component of the system, and rightly so.

With that in mind, I'd think that any blocking filter should be capable of leaving a talk page message for the blocked user (which, for our policy purposes, would more than likely be a block template and one of the above-mentioned stock unblock requests for human review). – Luna Santin (talk) 01:42, 23 March 2010 (UTC)

  • oppose both-- as a general rule, allowing for very rare exceptions. We admins need work to keep us from getting lazy! More seriously, there will very very rarely be a situation so utterly unequivocal that a human being should not look at it. There is enough of a tendency for a admin to fall into a bot-like mode, especially when dealing with a large number of problems in a row, but there always remains some degree of human non-AI functioning that will be on alert for special cases. That's what humans do best--what bots to best, is carefully without error or sleepiness check everything systematically following fixed rules to make a list for the humans to look at--humans, being human, tend to slip up on things like that. But there will be exceptions. Wallflowers is quite possibly one of them. I think the individual exceptions should get wide notice, and be proposed not just on the edit filter page, but on a highly watched admin board before individually implementing. This will keep this to where we really need it. Many of us who approved the edit filter project at the first did so on the condition that this function would never be implemented--I do not think it would have got the necessary initial approval otherwise. With experience, I've learned to trust it more than I thought I would. So I admit it's worth considering--something I had not thought I would ever admit--and I'm willing to go case by case, since we do have here an appropriate one to start with. DGG ( talk ) 07:11, 21 March 2010 (UTC)
  • Comment when I supported the idea at ANI I had not realized that it would require new functionality to be enabled on the edit filter system or that any non-admins had been given access to the filters. These make this a bigger deal than I had thought. However, I still feel that in certain cases when a filter has been successfully deployed without false positives it may be appropriate. My preference would be that any flipping of the block functionality on a specific filter only take place after a specific discussion has determined consensus for it. I'm not sure where the best place to have such discussions might be; maybe WP:AN with a notice at Wikipedia talk:Edit filter? Thus I'm not actually too far from DGG though we are coming at it from different angles. On the other hand, if no consensus for enabling blocking functionality is forthcoming, could the filter be rigged to make an automatic report to ANI or otherwise flag accounts as needing rapid administrative scrutiny? Eluchil404 (talk) 07:33, 21 March 2010 (UTC)
  • Oppose Both (as general rule per DGG) I would likely support rare exceptions but in general I'd say no and have to agree with DGG. I am hesitant of blocking bots too except for specific exceptions like proxies etc (and I think this falls under the same category as a bot for these types of things). I think editfilters reporting to things like AIV could be a great option if possible (or a bot reading and reporting to the page) but I just see to many opportunities for false positives and generally want a human hand involved in a block (and not just looking over them later, they will invariably miss some). James (T|C) 07:38, 21 March 2010 (UTC)
I believe we already have a bot for that. Perhaps it's underused? –MuZemike 16:21, 21 March 2010 (UTC)

(edit conflict) Since two three have said "oppose in general, but potentially support approved, announced exceptions" so far, I'd like to raise a potential flaw with this and a proposed resolution. The problem is, regardless of our policies on exactly how this is enacted, if we want even a single filter to be able to perform a block, then we need to gain consensus for the configuration change. So, I propose option three:

Option 3. Enable abuse filter blocking configuration. No individual, admin or otherwise, is to enable a filter to perform blocks without first announcing the filter on WP:AN and WT:EF proposing that blocking be enabled and establishing consensus for the filter.

I believe this addresses the concerns while focusing on the technical problem itself. --Shirik (Questions or Comments?) 07:47, 21 March 2010 (UTC)

In this case any change to a blocking filter must be approved by consensus too—unworkable, in my opinion. Ruslik_Zero 09:55, 21 March 2010 (UTC)
  • oppose mostly per the above (false positives). Providing theres 100% garantee of avoiding this in any option, I am opposed to any mechanism that automatically blocks. I think a human hand as said above is essential like at AIV. Thats just my thought on this the way i interpretted it. Though it is worth thinking about Ottawa4ever (talk) 15:05, 21 March 2010 (UTC)
  • Oppose pretty much per the other opposers. I think humans would do a better job. I like the idea of the edit filters somehow notifying admins of potential blocks, though. I think an "editfilter reported" section would be a nice addition to AIV. Airplaneman talk 16:25, 21 March 2010 (UTC)
  • I think a good idea would be to have the edit filter trigger an AIV report (if this is at all possible). This would be a similar approach to how Cluebot treats vandalism. An admin would be able to look over the report and then pull the trigger. ThemFromSpace 16:42, 21 March 2010 (UTC)
  • Oppose It would be impractical and the risk of false positives too high. There is a bot, User:Mr.Z-bot, which reports to AIV users hitting the specified filters (I had proposed this bot because we need to identify and block immediately users matching certain filters, but filters with blocking would be unwieldy and a bot allows more customization, for example those in vandalism are reported after several matches, 10 I think). If you think certain filters should be added, it can be done by admins. Cenarium (talk) 19:13, 21 March 2010 (UTC)
  • Oppose - At this point, I think it would be counterproductive. For every blocking filter, we might need to maintain 2 versions: the blocking one designed for minimization of false positives and a non-blocking one to catch the stuff the blocking one misses. One of the main benefits of the abuse filter is that its easily adaptable. If changes to blocking filters require a discussion, then it loses that benefit. Mr.Z-man 21:31, 21 March 2010 (UTC)
  • Oppose due to the risk of false positives. There's a person on the other end, and getting blocked by a bot by mistake should be avoided at all costs. Aiken ♫ 14:02, 22 March 2010 (UTC)
  • Oppose automated blocking. SilkTork *YES! 18:35, 23 March 2010 (UTC)
  • Oppose If existing processes for blocking vandals get saturated, maybe. Not now. RayTalk 19:10, 23 March 2010 (UTC)
  • String support for option 3 - and have a bot actively monitor all such blocks to bring them to further human review (an unblock request such as {{unblock-bot}} is probably the best). עוד מישהו Od Mishehu 05:23, 25 March 2010 (UTC)
  • Oppose All No . . just no, there's a non trivial *hand-waiving statistic* false-positives, so now we're wanting to add users wrongly getting blocked into the mix? Q T C 05:27, 25 March 2010 (UTC)
  • Oppose Both - Per opositions above, which basically sum up my thoughts on the matter. Ajraddatz (Talk) 16:49, 25 March 2010 (UTC)
  • Oppose entire proposal — as noted by Aiken, unintentional blocking is a significant enough problem that blocking should never be done except by a human who has been approved by community consensus to have that ability. Nice idea, but I can't imagine how the filter could have as small a chance of errors as a human can. Nyttend (talk) 04:02, 31 March 2010 (UTC)
  • Oppose - Currently there seems to be no lack of capacity to handle blocks trough WP:AIAV. A direct block by the filter is prone to false positives, and if each block has to be reviewed by an admin, what is the point of a direct block? (Except being a minute or two faster). If any, the filter should follow the same procedure as bots and regular users, and drop a report at WP:AIAV. I would have no objection if that could be done. Excirial (Contact me,Contribs) 15:42, 31 March 2010 (UTC)

Hi, i constantly bump into files like this File:Nobslogo.png that suffer from source link rot, commons has a partial solution in the form of flickr review where administrators check the source and marked it as verified so even if the link goes dead or the license changes there is still the admin review that proves it was ok at some point. I propose the creation of a policy and process say "Media source review", so the files don't end-up in source limbo.--IngerAlHaosului (talk) 15:21, 30 March 2010 (UTC)

Ability to delete one's own user pages

Why not give the ability to users to delete their own test pages or whatever, without having to ask admins to do that? --JokerXtreme (talk) 11:56, 23 March 2010 (UTC)

This is covered in Wikipedia:Perennial proposals#Grant non-admins admin functions within their user space. The problem with this specific request is that it is possible for any autoconfirmed user to move practically any page in the project to their userspace. If they are then allowed to delete that article, the combination of these two abilities is equivalent to the ability to delete any page. --Allen3 talk 12:15, 23 March 2010 (UTC)
There isn't much process or protocol involved in this either: a user can tag his own user page with {{Db-u1}} and it will be speedily deleted. There's no even need to have a "good" reason for it, even a simple "I don't like my userpage anymore" would be enough MBelgrano (talk) 12:36, 23 March 2010 (UTC)
How about restricting the ability to move in userspace for non-admins? Hm, I see there's also the ownership thing. Well, anyway, I can live without it. --JokerXtreme (talk) 12:47, 23 March 2010 (UTC)
On a technical level, we should ask first if this is technically feasible at all. As far as I know, each tipe of user has a defined set of user rights of things that can or can't be done, but those rights apply everywhere, beyond namespaces, which are actually a convention we use to keep some order, but without any actual effect on the technical level. Is there any example of an action that is or isn't available for a certain type of user at a certain namespaces and not others? MBelgrano (talk) 13:17, 23 March 2010 (UTC)

The solution is to let users delete pages which they are the sole author of. Why they would want to do that, rather than just abandoning unwanted pages (perhaps in a conveniently out-of-the-way location, e.g. moved to a subpage of User:Joeblow/Sandbox), I don't know, unless the user posted personal information and now wants to expunge it. To be consistent, we should either let users delete pages they are the sole authors of, or else not honor their requests to have such pages deleted. The current policy doesn't really make much logical sense. Tisane (talk) 15:00, 23 March 2010 (UTC)

What Tisane proposes would work nicely, if it can be done. --JokerXtreme (talk) 15:04, 23 March 2010 (UTC)
It would have to be restricted to pages that the user is the sole author of, and had never been outside their own userspace. Otherwise it could be abused to do things like revoke good-faith article contributions without review. — Gavia immer (talk) 15:32, 23 March 2010 (UTC)
Why would anyone do that? --JokerXtreme (talk) 15:34, 23 March 2010 (UTC)
Editors do do that sort of thing, if they get in a spat with someone, or they disagree with the idea that WP:OWN applies to themselves as well as others, and they try to withdraw contributions that they made in accordance with Wikipedia's license. We shouldn't allow that to be done unilaterally. — Gavia immer (talk) 15:51, 23 March 2010 (UTC)
There's not much of a problem with the current system. I can U1 a page and it'll be deleted in a day. Js subpages have to be moved first and then U1'd. Plus this proposal will let users delete their talk pages, to wipe their slate cleanManishEarthTalk • Stalk 15:43, 23 March 2010 (UTC)
{{db-u1}} does work on .js pages, actually. It doesn't look like it works, but it will still list the page at CAT:CSD even though the template rendering is broken. — Gavia immer (talk) 15:51, 23 March 2010 (UTC)
Wow. ManishEarthTalk • Stalk 02:57, 24 March 2010 (UTC)
  • I believe the programming effort needed to ensure that the ability was not abused would outweigh the negligible time saved on teh part of admins patrolling the u1 category. Not to mention we're now having non-admins with admin actions in their log summaries for potential added confusion. Perhaps a db-u1 bot could be written on the 7seriesBot's framework. –xenotalk 18:10, 23 March 2010 (UTC)
I understand that it may just be negligible in the amount of time it saves janitors, oops I mean admins; but how about the fact that it gives the average editor the ability to do things him/herself and feel better about being able to do things without templates and having others do things for them. Are admins that worried about the normal editor that they cant trust them? We're all just a bunch of misfits and potential trouble makers and vandals if we dont aspire to become an admin has been the growing vibe from the admin community towards this perennial proposal, discussions to which I was a party of at least twice. I know most admins are great individuals, unfortunately as a group you tend to be quite arrogant and sure its just a handful of bad apples, but allowing us mere lil guys to have this gesture and symbol of controlling our own destiny would go a long way to creating some good will. And I know this isnt just me, there's been LOTS of comments in many different places from regular editors not liking how admins have tried to make themselves a class separate from us, we are ALL equal, show us that you believe the same.Camelbinky (talk) 23:40, 23 March 2010 (UTC)
Well, Mediawiki is open source, write the code, and the sysadmins will consider enabling it. Prodego talk 23:44, 23 March 2010 (UTC)
Or to put it another way: Seriously, write up the software or propose it at Bugzilla. The granularity of rights you request doesn't exist in the current software, so far as I can tell. If you have a solution that can be committed to the software build, let's have a look. If it's a suggestion, well, build a little more support until some dev or other writes it. Those are the only realistic options I can think of. Franamax (talk) 02:50, 24 March 2010 (UTC)
Rephrase: MediaWiki is open source, write the code, try to find a developer willing to commit it (I for one will not), and then you can get a sysadmin to enable it. ^demon[omg plz] 10:26, 24 March 2010 (UTC)

I think that in most cases, deletions of pages with only one author will be unopposed. However, these deletions will appear on watchlists, so that will attract the notice of anyone who cared enough to watch the page. If someone has an objection to deletion, he can request that an admin undelete it; or perhaps we would even allow for non-sysops to undelete pages deleted by non-sysops. And of course, if a user is in bad standing, he will probably be blocked from deleting his own pages. The fact that bots are always making edits to pages will probably create a de facto time limit on deletion of one's own pages. See also my remarks at Bug 14325, though, about how WP:PWD essentially moots this whole proposal. Tisane (talk) 05:05, 24 March 2010 (UTC)

There's a fairly easy way to do this, we just need a continuously running admin bot that does certain types of non-contentious u1 and G7 deletions. It is indeed a perennial, but in my view that's because with appropriate safeguards, it is such a good idea. The last big discussion that I'm aware of was at Wikipedia_talk:Criteria_for_speedy_deletion/Archive_36#possible_botting_of_speedy_deletes. I think we were able to identify tests such as the article not having been moved that resolved all the concerns about misuse, the only outstanding issue was concern by some that a bot to do a few thousand speedy deletions a year would user more development time than it would save admin resource. However as the number of active admins continues to decline we need to do this sort of automation, and this topic gets raised so often in so many different forums that I think there would be an additional benefit in that we'd no longer need to keep debating it. ϢereSpielChequers 06:35, 25 March 2010 (UTC)
User:7SeriesBOT seems to be chugging along nicely, so there's certainly a precedent for a bot carrying out uncontroversial deletions and at least some framework in place. –xenotalk 23:06, 25 March 2010 (UTC)
I guess a bot could do the job, yes. I think this move would be a good "investment". The development would be done once, but the benefits would be...erm...perennial :) --JokerXtreme (talk) 08:15, 26 March 2010 (UTC)
I added the request to add this type of task to User:7SeriesBOT at WP:BRFA. Your comments are welcome there. (talk→ BWilkins ←track) 14:00, 27 March 2010 (UTC)

Strong Support I strongly support the idea of an autoconfirmed user having the ability to delete pages within his own userspace, as it does not impact the status of the encyclopedia, and it would simplify the process of userspace deletion. Immunize (talk) 15:32, 27 March 2010 (UTC)

I would oppose the proposal if all users, not just autoconfirmed users, would be able to delete their userspace, as I feel there is a potential for abuse. Immunize (talk) 17:00, 29 March 2010 (UTC)

The discussion is here:Wikipedia:BRFA#7SeriesBOT_2. Maybe we should archive this? --JokerXtreme (talk) 15:22, 1 April 2010 (UTC)

Linking to other languages in search results

  • There are many articles written in a few languages but not others. If I search, for example, for the Israeli folk singer Ruhama Raz in English Wikipedia no articles show up - only a red linked reference in another article. However such a page exists in Hebrew Wikipedia. I think it would be a useful Wikipedia tool to be able to know such a page exists when searching in English. It could appear in the search results and be generated by users of the respective Wikipedia that contains the written article. Does this seem like a good and feasible idea? I don't know anything about the technical aspects of such an endeavor. Has it been tried? THEMlCK (talk) 03:11, 1 April 2010 (UTC)
  • Falling back to searching Wikipedias in other languages would be useful sometimes. --Cybercobra (talk) 05:20, 1 April 2010 (UTC)
  • Just to play devil's advocate, I'd say for a good 99.9% of searchers, an article on Ruhama Raz in Hebrew would be completely useless. I don't think your idea is technically feasible; interwiki links are updated manually (either by editors or by bots) and do not always have the exact same name across multiple languages. For example, Earth is also Земя, Země, Γη, כדור הארץ, An Domhan, Планета Земја, Ziemia, Земля, Daigdig, โลก, and Terre (and that's just a small sampling). I don't think there's a decent way for the search system to know what to look for on other language editions (yes, sometimes articles on people will have the same name across multiple languages, but that's not a guaranteed case; can you tell me who Μπαράκ Ομπάμα or ジョージ・ワシントン are without checking those links?). EVula // talk // ☯ // 15:42, 1 April 2010 (UTC)
  • I think that with the automatic translating resources available on the web, ie. google translator, any article, even in a foreign language, is more useful than no article at all. Also in terms of the problems of associating a foreign language page with the relevent english search term, I think it would probably have to be done manually through some type of method that allows people to tag certain search terms with foreign language links. It seems like it may be too complicated to do, but I still think it would be fairly useful.THEMlCK (talk) 03:13, 2 April 2010 (UTC)

Another potencial problem are the false positives, terms written the same way in different languages but with different meanings in each one. Consider for example Ave and es:Ave MBelgrano (talk) 02:14, 5 April 2010 (UTC)

As long as it's implemented as a fallback only, that shouldn't be a big problem. --Cybercobra (talk) 02:38, 5 April 2010 (UTC)
Wikimedia Commons has media related to Village pump (proposals)/Archive 60.

Hello. I would like your comments and thoughts. I find that the little "Wikimedia at Commons" box very easily overlooked, even if one is looking for further images. The vast majority of non-Wikipedians don't know what Wikicommons is, and have no idea that clicking that box will lead to further images. Galleries are often replaced with this box, and the images are never seen. Probably hundreds of thousands of visitors a day come to an article seeking images, see what is displayed, and go away thinking that is all there is.

Wouldn't it be better to have a wee graphic image within that box indicating more pictures? After all, that is exactly what the eye is searching for. Anna Frodesiak (talk) 00:10, 31 March 2010 (UTC)

Agree. The idea is to convey information not to show off a pretty logo. Dmcq (talk) 08:18, 31 March 2010 (UTC)
Have to agree that there needs to be some improvement here to draw people to explore further and to be obvious what the link is for. Keith D (talk) 10:07, 31 March 2010 (UTC)
What about replacing "media" with "images and other media"? Let's face it, only a very tiny part of Commons are sounds or videos. MBelgrano (talk) 16:04, 31 March 2010 (UTC)
Support switching "media" with "images and other media". --Yair rand (talk) 21:23, 1 April 2010 (UTC)
Nice but most commons categories have only images, and no other media. Some have other media and no images. Some bot must regularly verify presence of images and other media, drilling down into commons subcategories, and update appearance of the template. NVO (talk) 10:13, 8 April 2010 (UTC)

Maybe there could be some way to pull a couple of random images from the relevant category and make small thumbnails in the Commons box. That would increase visual impact a lot. Rd232 talk 17:37, 31 March 2010 (UTC)

Maybe something like the external image icon as in Fish trap. Anna Frodesiak (talk) 23:17, 2 April 2010 (UTC)

Support switching media to images and other media. Pretty obvious, just easier to read and understand. Ajraddatz (Talk) 00:49, 9 April 2010 (UTC)

With those templates, we should have Usability in mind: being user-friendly and easy to understand is more important than being "accurate". "Media" may be a very technical word, and some users may not be aware that images are media (some may think that "media" is the mass media, or the variety of hardware that may be pluged into the computer). "Images", on the other hand, are a clear word that anyone can understand. Even so, by stating "Images and other media" and not just "Images", we are not only considering the chance of having sounds or videos, but also educating those users: the part "and other" subtly teachs that images are a kind of media MBelgrano (talk) 02:22, 9 April 2010 (UTC)

Is versus was

  • I think we need some policy guidelines on when articles should use "is" in the lead and when they should use "was". For example former TV shows use is, even if the show no longer produces new episodes, because it still is a TV show. Obviously past events should use was, because the event is over. But what about other things such as Ford Mustang (first generation), it still is a car, but they don't produce them anymore, so should it be is or was? I think is, but there is no guidelines to point users to this. CTJF83 chat 17:49, 6 April 2010 (UTC)
  • A lot depends on context of that lede sentence. You are right that certain things will always "be" (is) something even if it is no longer made; an old TV show "is" still a tv show; that property did not change. On the other hand, the property of some things do change, such as people that pass away, "John Smith was an actor..who passed away in 2010", since there is no way for that person to be an actor ever again. The Ford Mustange example can be read two ways. The car "is" still the original pony car (that property can't change), but "was" manufactured by Ford (that property can).
So the easy way to say this is to consider how you are defining that topic in relationship to a property.
  • If that property can never be taken away from that topic, then that topic "is" that property
  • If the property depends on some time factor otherwise (death, no longer manufactured), then use "is" if it is currently true, otherwise "was" if it wasn't.
Note that one also needs to consider that a property may not yet be set; I don't have a good example but take a video game that has been stated to be in development but yet to be released; it "is" an upcoming video game. But if that game gets canceled, then the language changes to "was" a planned video game. But when you consider "upcoming" and "planned" as properties that are not permanent, these fall into the second point above.
Note this also means "is" and "was" can be mixed and matched in the lede sentence if both types of aspects are critical there. --MASEM (t) 18:05, 6 April 2010 (UTC)

User Access Groups and Block/Unblocking

I have a few ideas about changes User Access Groups, my ideas are:

  • Rollbackers being able to give users the Rollbacker flag
  • Sysops being able to give users the Sysop flag

The reason for this is that members of a particular user group should be able to make other people a member of that group too.

A another idea I have is that any Sysop that is blocked would immediately lose access to the blocking/unblocking tool to prevent them fom unblocking themselves thus evading a block alternatively they could be automatically desysopped thus disabling all admin related tools to prevent further abuse. Paul2387 11:30, 26 March 2010 (UTC)

It is kinda dumb that sysops can be blocked by other sysops from editing but not from unblocking themselves. The only purpose that could serve, that I can think of, would be stopping an out-of-control adminbot. I think we should allow bureaucrats to both promote and demote admins, and enable mw:Extension:EmergencyDeSysop. Tisane (talk) 11:49, 26 March 2010 (UTC)
Under what circumstances do you see it as appropriate that an admin promotes another editor to admin? (This isn't sarcastic or rhetorical, I'm seriously trying to see where you're coming from.)--Cube lurker (talk) 12:20, 26 March 2010 (UTC)
Background reading: T17810 and discussion on EmergencyDeSysop. Happy‑melon 12:38, 26 March 2010 (UTC)
I understand the block/emergency de-sysop concept. (Not a bad idea except you'd be desysoped for using it.) It's the part on Sysops being able to give users the Sysop flag that i'm having trouble coming up with an example of when it'd be a good idea.--Cube lurker (talk) 12:47, 26 March 2010 (UTC)
  • Oppose the first two points (admins&rollbackers being able to self-replicate) as opening the door to potential mass-organizated disruption. –xenotalk 13:21, 26 March 2010 (UTC)

Yeah, EmergencyDeSysop, as currently written, unnecessarily requires the sysop who uses it to surrender his bit. It would be better to modify it per my suggestion: Give each sysop one credit, which he can "spend" to desysop another admin. A bureaucrat can later give him another credit (presumably after determining that the desysoping was justified) for future use, but no sysop can ever have more than one credit at any given time.

In reference to the common arguments against prohibiting sysops from unblocking themselves: It is unlikely that a situation would arise in which a wiki's sole sysop blocks himself and then can't unblock himself, because usually in that situation the sole sysop is also the site owner and therefore a bureaucrat. But it could happen if the site owner goes AWOL and there is only one other sysop. Therefore, sysops should simply not be allowed to block themselves.

I have actually seen the situation of two dueling sysops with no one else to intervene. I am a sysop on a small wiki with only three sysops, one of whom is the site owner and sole bureaucrat. The site owner has been AWOL for months now; who knows if/when he's coming back, but evidently he's paying the bills. Anyway, the other sysop, who is kinda young and impulsive and zealous about certain religious/scientific subject matters that were under dispute, went around deleting a bunch of articles, threatening unjustified bans, etc. I reverted everything and he eventually admitted he was in the wrong, and things settled down to normal. I'm not sure how things would have gone if a "nuclear option" like EmergencyDeSysop had been in place. Perhaps each of us would have gotten itchy trigger fingers and been inclined to launch a preemptive desysoping strike on the other, since potential would have existed to disarm the other from retaliating. Then again, he probably shouldn't be an admin; he's never really used his powers except abusively. So maybe the itchy trigger finger thing isn't so bad, as long as the good admin shoots first.

You have to apply a bit of game theory to these matters. When you're developing a board game, you don't sit around and speculate endlessly about what might happen if you implement a certain rule or game mechanic. Instead, you play-test to see what happens in practice. Same thing with these types of changes. They probably should be tested on smaller wikis rather than introduced here first, because this community is pretty conservative about untested ideas. Sometimes that conservatism is beneficial, as when stuff like mw:FlaggedRevs gets rejected. I think that if we test it on dewiki or something, we'll probably find that FlaggedRevs is more of a hindrance than a help. It definitely is in need of further play-testing before implementation on enwiki.

On a large wiki like this, EmergencyDeSysop is perhaps both safer and less necessary, given the large number of stewards. You have to admit, though, the concept is pretty badass. I might try it out on the next small wiki I become site owner of, just for fun. Tisane (talk) 13:43, 26 March 2010 (UTC)

  • Oppose Its easy to become a rollbacker, so you can't tell if a rollbacker will go bad. And anyways, We have ~63 'crats, which is more than enough for making admins. I for one, don't see why we need so many crats. We have very few RfA's which can be taken care of by 10 crats. Bot status management requires a few tech savvy ones (we don' have that many botrequests), and also around 10 to handle username changes. So we have more than enough people who can make admins. As for the rollbacker stuff, I strongly oppose it. The entire point of the usergroup hierarchy is that higher users can check the lower users. ManishEarthTalk • Stalk 05:25, 27 March 2010 (UTC)
    There are 36 crats, not 63. Happy‑melon 14:40, 27 March 2010 (UTC)

Is it really that easy to become a rolbacker? Immunize (talk) 14:11, 27 March 2010 (UTC)

Its a hell of a lot easier than becoming a 'crat. All a user needs to do is have some experience with vandalism and show they are sensible and most admins will grant it--Jac16888Talk 15:01, 27 March 2010 (UTC)
  • Support I disagree. I feel it would be reasonable for rollbackers and sysops to be able to grant other users the same rights that they have. Immunize (talk) 18:40, 3 April 2010 (UTC)
  • Oppose. One person with bad intent uses a good hand sock to become an admin and then uses it to make a few more admin accounts. Probably during a time when it's late in the evening in the US and early in the morning in Europe. Those newly-sysopped accounts become meatpuppets that sysop more accounts. This would become a problem in a hurry. WP:BEANS, of course. Useight (talk) 20:20, 3 April 2010 (UTC)
  • Oppose - The only reason given is circular logic (people should be able to do it because they should be able to do it). Mr.Z-man 21:55, 3 April 2010 (UTC)
  • Oppose - I'm sorry, but allowing rollbackers to assign the rollback flag? You just lost my support with that. Ajraddatz (Talk) 00:39, 9 April 2010 (UTC)
  • Oppose - Ive got a bad feeling about this one. Its not that hard to get rollback rights to begin with, imagine the damage that could be caused by one bad seed. Worse imagine the damage caused by a rogue sysop making multiple disruptive editors sysop. I see both proposals causing alot of trouble. Sorry but I have to oppose this, but thanks for bringing up the thought, its still worth while to brainstorm wasy to improve the system. Ottawa4ever (talk) 10:54, 9 April 2010 (UTC)

If this system was put into effect, I feel we would need to more carefully select rollbackers and admins, because yes, there is some risk for abuse, though at this time I feel it is fairly small. Another option that could possibly decrease abuse of this system would be to not allow rollbackers and admins to grant other users these rights until they themselves have had the rights for at least 90 days. Immunize (talk) 14:20, 9 April 2010 (UTC)

Or we could just not do it at all, since no one has yet provided a logical reason why we should do this. Mr.Z-man 14:26, 9 April 2010 (UTC)
I know we're typically not supposed to close discussions on the pump, but in this case we should have closed it on Apr 3. The new comments from today (while entirely in good faith) are simply extending the amount of time this unsuitable proposal stays on the pump. –xenotalk 14:52, 9 April 2010 (UTC)

So yopu feel this proposdal is completely unsuitable, and has no place on Wikipedia? Immunize (talk) 17:06, 10 April 2010

I think that at this time, it's not necessary (in the case of rollbackers, a solution in search of problem, and admins, an unsuitable solution to something not everyone agrees is a problem) and clearly has not been well-received. It is a wasted effort to attempt to tweak a proposal that has been so handily rejected. –xenotalk 16:25, 12 April 2010

Edit Statistics

I was thinking if we looked at Good Edits vs Bad Edits made by different User groups we would be able to see where most of the vandalism is being made, which in turn will allow us to find a solution to reducing it. Finding the cause helps to eliminate the problem is the saying we need to use otherwise Wikipedia will soon be a trash-heap or a Junkyard.
. Paul2387 14:21, 6 April 2010 (UTC)

I don't think sorting by user group is going to give much useful information. There really shouldn't be any vandalism from groups that have to be manually granted (which is most of them). User group doesn't give you much information about things like motive for vandalism (bored schoolkid, determined troll, etc.) or type of vandalism (childish vandalism, subtle vandalism, attacks on users, etc.). Looking at the user group is like looking at car accidents by type of vehicle. If you're an insurance company, it might help you determine rates, but if you want to actually reduce accidents, knowing whether the driver was in a sedan or a truck is less useful than knowing the location of the accident or whether the driver was distracted by something. I really can't see more than 3 possible conclusions from user group vs. vandalism rate data: 1) Everything is fine. 2) We need to ban IPs from editing. 3) We need more data. Mr.Z-man 17:03, 6 April 2010 (UTC)
So is there anything else we could do to collect more helpful data on this issue? Rd232 talk 21:21, 6 April 2010 (UTC)
I suppose one step would be to start a campaign to get people to not just revert but also flag vandalism revisions, and aggregate those bad revisions into a database table. A metadata field could be added to keep track of revisions flagged as vandalism. We could populate it partly by editors doing the flagging manually. And we can also looking at edit histories for, e.g., Twinkle-added comments stating that an edit has been identified as vandalism. We could also look for transclusions of {{test}} and such to help track down those edits; if a user has that template on their talk page but none of their edits has been flagged as vandalism, we would know that someone probably forgot to flag their edit as vandalism. We can also look at page semi-protection patterns. Once the bad revisions are flagged, we can use the data to identify patterns more readily. Then of course there is the STiki project. Tisane (talk) 06:28, 10 April 2010 (UTC)

Commemoration of Service

Let me say first of all that I edit wikipedia because I feel an obligation to contribute to the extremely worthy goal of creating a universal, free content compendium of knowledge. I also enjoy the sense of satisfaction that I feel when I know that my contribution to pages like Presidency of Jimmy Carter, Henry Clay, and Supreme Court of the United States, among others, will help me and my fellow students look for information. I imagine that as we enter the 1970s in my US History Class, many of my students will use the references I have provided. That is why I edit wikipedia. However, I, and many like me, whether they're job applicants, other students at many different levels, and so forth, who are required to show that they are the kind of civic minded person who cares about improving their community, are totally unable to point to the good work they do improving wikipedia as examples of this service. Also, I think that alot of serious editors would appreciate commemoration for their services.

My proposal:

  • Some mechanism for verifying the amount of hours someone has spent improving wikipedia. (I'm required to do this for local civic organizations and my schools honor society, but I'm aware that it's a fairly common practice.) Of course, ensuring that the contribution are helpful is a must. I think that it is far more helpful to be a wikipedian, whose editing can benefit hundreds of others in one day than it is to be part of the "safety patrol" at local football games that accomplishes nothing. Yet one task allows me community service hours and the other doesn't.
  • Some title to commemorate service. I will say that the above conversation and its theme is one with which I agree: this website is at its best when it maximizes editor equality. We should not have ranks that put some editors over others, dissuading some from participating and driving others to work for the irrelevant distinctions rather than the good of this project and the promotion of it's goal of enriching human knowledge. Therefore, these titles should in no way, shape, or form enhance the ability of an editor to do anything on wikipedia. Still, if I could call myself a "senior editor" or "distinguished contributor" on my college/job applications, that would help. I would also feel thanked for my contributions. I think many admin hopefuls are admin hopefuls simply because they want some kind of commemoration for their service. We could base these titles on some simple algorithm, like overall edits, overall content added, overall activity, and so forth.
  • We should have a "thank you bot" that automatically places awards, barnstars, or something like that, on the talk pages of users when ever they do something good, which we could calculate with an algorithm. (Congratulation on your 1000th page edit or something)

In conclusion, I edit because I think that it's a good way to serve my community. I will continue to edit for that reason. However, I would appreciate being thanked for my contributions and having some way of showing organizations looking for public service that I serve my community in one of the best ways possible: I edit wikipedia.

Thanks. In.Lumine.Tuo.Videbimus.Lumen (talk) 17:22, 11 April 2010 (UTC)

I have thought of this as well, but counting how many hours spent on here is an extremely flawed way to calculate value of contributions. There are just too many variables. I personally would have been able to submit thousands (yikes!) of community service hours to my school. Try taking a look at WP:Service awards, which you can award yourself. Personally, I edit for the fun of it. There are also specific barnstars for it (see WP:BARNSTAR). Other than that, editing is a rather thankless job. My motivations to edit, as I said earlier, are fun and the prospect of learning countless things. Info it interesting. Therfore, I edit. Organizations may look at your service on Wikipedia regardless of how many "awards" you have earned for "number of hours" or "number of edits" (see WP:EDITCOUNTITIS). Remember, it's quality of contributions, not quantity. Regards, Airplaneman ✈ 18:50, 11 April 2010 (UTC)
It would be good to have something to show for our work here. I'd separate your proposal into two parts, one for recognition for the sake of recognition, and one for proof that can be shown on job/organization applications. The latter is what I'm more intrigued by. The former is really already handled by barnstars etc, and I don't think a bot or the like is really necessary. It would be nice to have something to show a potential employer or the like for time, effort, and skill demonstrated in editing here. Contributing to any other publication the way many of us do here would usually be resumé material. I'm not sure how that could be accomplished in any objective and verifiable way though. Maybe DYK credits? Or maybe a "committee" could be established, that an editor or group of editors wanting to establish credit for improving an article could appeal to? Equazcion (talk) 19:18, 11 Apr 2010 (UTC)
I think that if you were to try to put your Wikipedia editing on a résumé, you'd need to have some kind of "real-world" sounding title. "Senior Editor" was mentioned above; something to that effect. If I put Wikipedia Bureaucrat on mine, I don't think that'd be real impressive, but Wikipedia System Operator sounds like it has more weight. Although I must add that I'm not a big fan of the proposal. I already see a myriad of editors plastering the top of their userpage with icons representing the GAs, FAs, and DYKs they've made. Seems kind of pretentious to me, especially if we start adding official titles. Useight (talk) 19:26, 11 April 2010 (UTC)
I find it strange that the originator of this proposal actually uses the word "compendium", since that actually is the name of a "rival" of Wikipedia which actually does have pretty much what this editor is proposing... is this a coincidence or is this proposal specifically designed to make Wikipedia have something similar to Compendium? As I understand Compendium has specific titles and requires you to provide proof of your identity and any education, degrees, etc that can lend itself to being used for future references. I'm not saying we should automatically reject proposals because a competitor already has this idea, I applaud the idea of taking good ideas from competitors and appropriating them for ourselves so as to crush them easier (and so does Bill Gates). Perhaps someone with more knowledge of Compendium could illuminate how they work and see what would be good for us to copy and what wouldnt be.Camelbinky (talk) 19:56, 11 April 2010 (UTC)
I was wrong, the competitor is actually called Citizendium, not Compendium. I apologize! But they do have a similar system to what is being proposed, perhaps we could learn something from them.Camelbinky (talk) 01:07, 12 April 2010 (UTC)

Automatic signature when adding new section to talk pages

Hi! I suggest that, when clicking the tab "new section" or "+" to add a message to a talk page, if the user has not signed the message, that the four tildes are automatically added to the end of the message. Anna Lincoln 10:46, 13 April 2010 (UTC)

User:SineBot already does this, except when you're an experienced editor. ManishEarthTalk • Stalk 17:00, 13 April 2010 (UTC)
Plus it would be of limited use if it only works with the new section button, and LiquidThreads is going to do this anyway. -- Nx / talk 17:05, 13 April 2010 (UTC)

Should the underscore be used as mark-up for non-breaking spaces?

A concern which once in a while pops at WT:MOS is that the HTML entity for the non-breaking space &nbsp; clutters the edit window. So I suggest that all underscores in the rendered article text, except in URLs and within <source> and <code> tags, be automatically replaced by non-breaking spaces in the rendering engines. (Non-displayed underscores in template parameters, HTML elements, etc. would be unaffected.)

The use of underscores actually displayed in articles in very rare, anyway: I searched for _ using my browser's Find feature in the last four days' TFA and in ten random articles, and I found none except in URLs. If such a functionality were implemented, before turning it on, a bot could be set up to put <nowiki> tags around any underscore actually displayed. ― ___A._di_M. (formerly Army1987) 14:52, 12 April 2010 (UTC)

I'd like to see some more data over-and-above "10 random articles" before supporting this. –xenotalk 14:59, 12 April 2010 (UTC)
The use of &nbsp; is relatively rare in articles too, mind you. Wouldn't this just serve to make the raw wikitext marginally more confusing for a fairly limited benefit? Shimgray | talk | 15:03, 12 April 2010 (UTC)
There are eleven &nbsp; in Today's Featured Article alone, more than thirty in yesterday's, more than thirty in last Saturday's, and twenty-seven in last Friday's. (And do you really mean that 2_+_2_=_4 is more confusing than 2&nbsp;+&nbsp;2&nbsp;=&nbsp;4 or was that a typo? Consider that not everyone is familiar with HTML entities; the former is easier to input, too.) ― ___A._di_M. (formerly Army1987) 15:24, 12 April 2010 (UTC)
To be honest, I think they're about equally odd to a novice user - they're both characters that don't do what they immediately seem to - so that wouldn't change much. However, it would produce a marginal extra bit of confusion for everyone who already knows how to use wikitext - it's worth considering this before implementing any such change.
I'm quite surprised as to the usage figures for FAs, though I suppose I should have expected a higher use rate when we're looking at fancier articles. I'd previously done a quick check using special:random, and after two dozen articles still hadn't found any using nbsp; I wonder if the absolute number of articles this affects is very low, but those articles are quite concentrated? Shimgray | talk | 15:57, 12 April 2010 (UTC)
To a good first approximation, everyone who knows about the existence of the non-breaking space is "familiar with HTML entities". Because it would be defining something brand-new, the underscore idea would be marginally more confusing. Ntsimp (talk) 16:04, 12 April 2010 (UTC)
A while ago the same discussion took place with conclusion that ,, (a double comma) would be the best choice to represent a non-breaking space in the edit window. It is more similar to the several other double-characters for special wiki items and more unlikely to be happen naturally. A very detailed proposal was worked out, still available at User:Noetica/ActionMOSVP/StableWholeProposal including gathering of opinions, which can be found in User:Noetica/ActionMOSVP/Archive2. It did not happen. −Woodstone (talk) 16:33, 12 April 2010 (UTC)
Agreed. I don't think I'd support a single underscore as a wikimarkup for a non-breaking space. A double comma, or even double underscore would be more appropriate.—NMajdan•talk 17:19, 12 April 2010 (UTC)
Isn't there a template which automatically applies non-breaking spaces to any text wrapped inside the template? -- Black Falcon (talk) 17:58, 12 April 2010 (UTC)
Not quite, but there is {{nowrap}} which is used sometimes, especially in scientific articles. However, it takes eleven keystrokes, as against six for a simple &nbsp;, so it is only used for fairly long chunks of text or stuff containing thinspaces. Physchim62 (talk) 18:03, 12 April 2010 (UTC)
That's the one I had in mind. Thanks, -- Black Falcon (talk) 18:15, 12 April 2010 (UTC)
Non-breaking spaces are, in principle, allowed in page titles (they are prohibited only by our title blacklist, not by MediaWiki). Where, in this proposed system, should [[Foo_bar]] lead? What is the expected meaning of Foo__NOTOC__bar? The underscore is a highly unsuitable character for this function. Happy‑melon 18:24, 12 April 2010 (UTC)
What I think [[Foo_bar]] should do is basically the same as what {{nowrap|[[Foo bar]]}} does now: make the same link as before, and display as a space rather than as an underscore, but prevent line breaks within the link. This would be especially useful when linking personal names, as it is bad typographic style to allow line breaks between the first name and middle initial but currently too much hassle to prevent. —David Eppstein (talk) 18:52, 12 April 2010 (UTC)
What about [[Talk:Foo_bar#use of __NOINDEX__]]?? Or [[Template talk:Foo#Deprecate some_parameter parameter]]?? [[Talk:Foo#Discussion about links to www.some_website.com]]? The latter two are problematic mainly because a header ==Deprecate some_parameter parameter== will no longer be successfully linked to by a section link which copies the same wikitext, which is unhelpful. Happy‑melon 19:04, 12 April 2010 (UTC)
I had in mind the same as Eppstein about what [[Foo_bar]] should do. (BTW, someone on WT:MOS pointed out that unpiped [[Foo&nbsp;bar]] also goes to Foo bar.) Anyway, the magic words are something I had not thought about, but also ,, would work for me. (BTW, TeX uses ~, but that character is too widely used (e.g. to mean "approximately") so doing that here wouldn't be worth the trouble.) ― ___A._di_M. (formerly Army1987) 19:32, 12 April 2010 (UTC)
I like the concept. I suspect most editors do not use non-breaking spaces as often as WP:MOS recommends (e.g., in measurements), partly because the &nbsp; entity is a bit cumbersome, and {{nowrap}} even more so. As to implementation: we already have the convention where underscores represent spaces in file names. As to the relatively few cases when an underscore per se is desired, could we use doubled underscores in the markup? - J. Johnson (JJ) (talk) 20:42, 12 April 2010 (UTC)
Oh please can we have something like this? Please please please. We desperately need better markup for hard spaces. Ozob (talk) 02:36, 13 April 2010 (UTC)
I'm for this in the form of double underscores interpreted as non-breaking spaces (and single underscores interpreted as bare underscores). Double underscores aren't used for anything in normal prose, so they will stand out properly as markup. However, we had better make certain that they are interpreted as a literal double underscore in <code> tags, because double underscores are quite common in encyclopedic code listings. — Gavia immer (talk) 03:00, 13 April 2010 (UTC)
In LaTeX they use the tilde for this (~). Considering how rarely this character is used in articles (except for URLs) this seems viable. Dcoetzee 07:45, 13 April 2010 (UTC)
We quite often have people writing things like "there's ~30 cases of this" in non-article space, mind you. And the system would get horribly confused if you wanted three of them in a row ;-) Shimgray | talk | 08:49, 13 April 2010 (UTC)
The Citron beta (Beta version 3--At the moment we're on Babaco) changes the editor box into an iframe, and collapses templlates, among other things. It could be proposed to collapse nbsps at usability:Talk:Prototype. ManishEarthTalk • Stalk 17:06, 13 April 2010 (UTC)
The {{s}} template adds spaces, which is not the same as marking a space as "non-breaking". As to the tilde ('~'), it has an ordinary usage that I suspect is almost as common as exclamation marks. Not a good idea to mess with that. Of the proposals made so far, I'd say the underscore, or double-underscore, are best. Alternately, could some completely different character be used? Something that could be "composed" on the keyboard? It would need to be non-blank, so it would be visible in the markup, but would be converted like any other markup. - J. Johnson (JJ) (talk) 20:59, 13 April 2010 (UTC)
It adds non-breaking spaces... –xenotalk 21:01, 13 April 2010 (UTC)
The problem with {{s}} or {{nowrap}} or whatever is that they are no easier to type than &nbsp; and they clutter the source text just as much. The underscore is easy to type and occurs very rarely in actual running text (except in certain situations, like code examples, for which there needs to be a rather easy way to get a real underscore; <code> or <nowiki> is probably easy enough). It has the added bonus that it looks enough like a space so that it doesn't interfere with reading the source text, while looking distinct enough that it won't be confused for a normal space. There's a reason TeX reserves a single uncommon character (the tilde) for non-breaking spaces—such "ties" occur quite often in properly typeset text, so it needs to be easy to type. My !vote goes to the single underscore. —Bkell (talk) 21:40, 13 April 2010 (UTC)
I agree with Happy-Melon that the underscore is an unsuitable character for this. I looked at 10 random pages and 6 of them used underscores. In particular, they're used rather frequently in the description parameter for Template:Coord (things like {{coord|51.01234|-1.56789|type:landmark_region:GB}}. I doubt there's any single character that appears on a standard English keyboard that isn't used in at least a small percentage of pages. Mr.Z-man 22:06, 13 April 2010 (UTC)
But the underscore in a {{coord}} parameter need not be substituted, because it doesn't show up in the article text, so that's not a problem. —Bkell (talk) 03:50, 14 April 2010 (UTC)
It will, however, break anything that uses that information, like the geohack system. [2] is not the same as [3]. And there are still the issues that Happy-melon noted above. Mr.Z-man 05:09, 14 April 2010 (UTC)
No, it doesn't have to break these things. That's what I'm saying. Why wouldn't we just leave those as underscores? The only underscores that would be replaced by non-breaking spaces are those that would otherwise show up as underscores in the article text. Other underscores, such as those in URLs, magic words, template parameters, etc., don't need to be replaced and shouldn't be. This isn't a proposal for an indiscriminate replacement of all underscores in the page source with non-breaking spaces. —Bkell (talk) 11:47, 15 April 2010 (UTC)
So then you wouldn't be able to use it in things like infoboxes and references? You're just trading off one downside for more. That fixes most of the conflicts, but now the behavior is totally inconsistent with the rest of wikitext. Mr.Z-man 12:17, 15 April 2010 (UTC)
Yes, actually implementing this would require some thought, and I don't know the internals of MediaWiki, but I still think it can be done. The underscore–to–non-breaking–space conversion doesn't have to be done before template expansion; it could be done after. So underscores get passed to templates as is. If the template expands the parameter somewhere where it will show up in the article text, it gets converted to a nonbreaking space; otherwise it stays as an underscore. I don't think the complexity of this is an insuperable problem, though maybe MediaWiki's architecture would make such an idea very difficult to implement without a major structural change. I don't know. —Bkell (talk) 23:05, 15 April 2010 (UTC)
@Mr.Z-man: For sufficiently large values of "small percentage of pages", there's ` (U+0060 GRAVE ACCENT). ― ___A._di_M. (formerly Army1987) 12:42, 14 April 2010 (UTC)

How is this discussion not over yet? &nbsp; has two outstanding advantages the other suggestions don't - it's googlable, and it doesn't look like a mistake (as ,, does). And googling a strange-looking thing like that is a first response for many unfamiliar with it - much more plausible than hunting down whatever help page tells you an underscore or {s} is a non-breaking space. Let's just leave well alone on this one. Rd232 talk 22:23, 13 April 2010 (UTC)

{{s}} is just one character fewer than &nbsp;. Doesn't look like a breakthrough to me. ― ___A._di_M. (formerly Army1987) 12:42, 14 April 2010 (UTC)
It's actually {{s|1}}, so... =\ –xenotalk 12:46, 14 April 2010 (UTC)
The point is the confusingness of nbsp, and the template s is easier to understand (Newbies will hafta learn what templates are sooner or later). ManishEarthTalk • Stalk 12:03, 16 April 2010 (UTC)
What do you mean "its googlable"? Google doesn't return the wiki-syntax, it returns the actual article page with the rendered text, so double-underscore or double-comma or whatever is decided wouldn't show up when Googled. For the record, I'm for double-comma. Since underscore is too common, double-underscore is already in use by MediaWiki.—NMajdan•talk 14:17, 14 April 2010 (UTC)
That's precisely my point. Google &nbsp; and you will quickly figure out what it is. Googling punctuation with special meaning for Wikipedia? Not so much. Rd232 talk 14:21, 14 April 2010 (UTC)
Wikipedia already has special meanings for '', ''', ~~~~, [[, {{, and other strange combinations of symbols, and yet no one complains that they aren't Googleable. If we used "Googleability" as a criterion for syntax, we would be using straight HTML and typing <a href="http://wiki.eso.workers.dev/wiki/Article">Article</a> instead of [[Article]]. Adding something for non-breaking spaces will be no worse than all the rest of the strange wiki-syntax we use. There are help pages for these things, if people can't figure them out for themselves. Somehow I learned how to use it all. —Bkell (talk) 11:58, 15 April 2010 (UTC)
It's not the same, because basic wiki syntax appears on every page. You either cope with it on sight (comparing the wikitext with the final page), or go and look for help. nbsp; is different both because it's rare (in articles; less so in templates) and because it's harder to guess what exactly it does. Rd232 talk 12:10, 15 April 2010 (UTC)
This would be far from the most exotic behaviour of the MediaWiki parser, or even the most exotic piece of wikimarkup. I don't think it's fair to assert this issue to be the absolute showstopper you present it as. Happy‑melon 12:35, 15 April 2010 (UTC)
It's just one of the issues. There's also a substantial element of "it ain't really broke". The "cluttering" issue only really applies to fairly complex templates, and changing this isn't going to make much difference in terms of making them easier to edit. Introducing a change, however, is a very substantial cost in itself. That said, out of the alternative suggestions I could most live with __ for a non-breaking space generally, plus changing the parser such that a single _ is treated as an nbsp within a wikilink. Rd232 talk 13:05, 15 April 2010 (UTC)
The whole reason &nbsp; is rare is because it's so awkward to put in. That's the problem we're trying to address. It should be a lot more common than it is; see WP:MOS#Non-breaking spaces. —Bkell (talk) 23:05, 15 April 2010 (UTC)
I suppose that's an argument. Do we have some examples of where we would use it in articles if it was easier? Rd232 talk 12:55, 16 April 2010 (UTC)
Sure. Yesterday I chose three random articles and put in non-breaking spaces where they should go: [4] [5] [6]. Note that Dimethylheptylpyran had quite a few non-breaking spaces already. —Bkell (talk) 14:36, 16 April 2010 (UTC)
Um, I don't think these changes are really necessary [7]. We're designing for web, not print, and these days people are used to lines breaking wherever. So I'd say this sort of addition of nbsp;s into body text is neither really necessary, nor, really (because of making it hard to read) a good idea. I'd reserve it for cases where it affects formatting more substantively than preventing line breaks between word(/data) pairs in article body text (templates are different). I think I'd say the same even with _ or __ instead of nbsp;. Rd232 talk 14:47, 16 April 2010 (UTC)
"We're designing for web, not print…" That's a little short-sighted, don't you think? Don't forget WP:REUSE, and remember that printed versions of Wikipedias have been published. Thinking of Wikipedia as just a single Web site that will always live only at wiki.eso.workers.dev is missing the point that we're creating a free-content encyclopedia. "…these days people are used to lines breaking wherever." Do you have a citation to back up that vague assertion? Are you saying that you don't notice bad line breaks, or are you saying that since most Web pages ignore principles of good typography, we should too? "…nor, really (because of making it hard to read) a good idea." I know, that's what I've been saying. We need something for non-breaking spaces that doesn't make it so hard to read. Look, I realize that non-breaking spaces are a subtle detail, and most people don't know what they are or when they should be used. But you could say the same thing about the proper usage of dashes or any of many other points in the Manual of Style. This isn't an extremely pressing issue, but it is a detail that would be nice to have addressed. —Bkell (talk) 16:08, 16 April 2010 (UTC)
Using hard spaces as much as your examples will make it hard to read even if it's just a single underscore. People are not used to that, it looks funny, and it will be a constant battle with people "fixing" it. I don't think it's worth the cost. Dashes are different because bot/AWB fixing of those (and many other MoS issues) doesn't confuse anyone. Stick to templates and maybe wikilinks and concrete cases where it's actually necessary, but not routinely as you suggest. Wikitext is often too much like programming anyway, but at least until now the main body text has generally been OK (barring overuse of cite templates - urgh); sprinkle nonbreaking space commands around in the main copy as you suggest, and we lose even that, making it even harder for people to get started editing. Rd232 talk 16:42, 16 April 2010 (UTC)

A clarification seems needed here. I doubt if "using hard spaces" per se makes for hard reading. More the reverse: the whole point of good typography – and this is just as relevant on a screen as on paper – is to make the reading clearer. (E.g., keeping measurements together with the units of measurment.) I think what you mean is that the current markup for non-breaking spaces ("&nbsp;") makes for hard reading of the source text. Which is why we are having this discussion – to see if there might be a cleaner, simpler way of implementing non-breaking spaces. - J. Johnson (JJ) (talk) 20:52, 16 April 2010 (UTC)

Just to say that we desperately need a shortcut for the ugly duckling six-character entity. The reason it is not much used is because it is so arduous to key in. It is the kind of clutter that puts newbies off and makes editing no easier ever for experienced users; replacing it with a single- or double-character entity would be ideal and easy for newbies to learn. Tony (talk) 07:30, 17 April 2010 (UTC)
One easy way for newbies (and anyone else entering text directly in the edit window) is to add nbsp to the list of special characters; all you have to do it click on it. However! For many of us being able to prepare text off-line is not just preferred but obligatory, so there is still need for some kind of markup code. Also, the non-breaking spaces really need to be visible for editing existing text. But this could be a special symbol, or glyph. Even if it is not one of the standard "keys", that's okay for me, as I don't mind using the Compose key, and the newbies can pick it off of the list. - J. Johnson (JJ) (talk) 20:52, 17 April 2010 (UTC)

Medicine and molecular cellular biology Wikiprojects announce collaboration with Google.org

Announcement of the first stages of a project to peer-review, improve and translate medical and biology articles. This project aims to transfer high-quality articles from the English Wikipedia to other Wikipedias that are written in languages used in developing world. Tim Vickers (talk) 17:40, 16 April 2010 (UTC)


Core system for MOS and policy

This is a notification of a discussion where by see also are replaced with transcluded cores Wikipedia_talk:Manual_of_Style#Trial_of_.22core.22_conceptGnevin (talk) 15:19, 17 April 2010 (UTC)

A quick way for me to add all articles in a wikiproject to my watchlist ...

... should exist. Better yet, a way to add myself to ONLY THE TALK PAGES. Or a way to transclude the changes to those talk pages into one page. The idea is to permit the wikiprojects to better supervise what's going on in their articles. JD Caselaw (talk) 18:34, 17 April 2010 (UTC)

You have a list? Paste them into: Special:Watchlist/raw. Supervise their articles? You've an off-notion of wikiprojects' authority. See WP:OWN. Jack Merridew 18:41, 17 April 2010 (UTC)
(edit conflict) A number of WikiProjects have bot-created lists of articles of interest to them, and it is possible to monitor changes to those pages using Special:RelatedChanges. If the list contains only talk pages of articles, then (if I'm not mistaken) only changes to those will be shown. -- Black Falcon (talk) 18:47, 17 April 2010 (UTC)
Black Falcon, thanks for the helpful response. I am not aware that it's possible to watchlist a talk-page without watchlisting the corresponding article itself. If it is possible, then my proposal is solved.
Jack Merridew -- there is a distinction. The set of all economics departments at universities around the world has a fair claim to "supervise" any claims made about economics, even though that claim is not mutually exclusive to a claim of "supervision" made by the sociology departments. That is the sense in which our wikiprojects supervise articles, and it has nothing to do with WP:OWN. I think most people agree that it would be a good thing if wikiprojects could be more closely associated with the articles within their... ummm ... area of interest. JD Caselaw (talk) 19:00, 17 April 2010 (UTC)
Actually, I was slightly mistaken: Special:RelatedChanges monitors both articles and talk pages, but it is possible to filter the results by namespace. See e.g., Wikipedia:WikiProject Africa/Watchlist (page size is > 250 KB) and Special:RelatedChanges/Wikipedia:WikiProject Africa/Watchlist (and filtered to show only the Talk namespace). -- Black Falcon (talk) 19:16, 17 April 2010 (UTC)

If the project has a category into which all tagged pages are added (which is down to MAIN_CAT in the banner template - see {{WPBannerMeta}}), then you can use RecentChangesLinked on that category to track talk page recent changes for all the wikiproject's talk pages (it's the talk pages in that category). Example. Rd232 talk 19:53, 17 April 2010 (UTC)

Retrieved from "https://wiki.eso.workers.dev/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_60&oldid=1251683008"