Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The proposals section of the village pump is used to discuss new ideas and proposals that are not policy-related (see Wikipedia:Village pump (policy) for that).

Recurring policy proposals are listed at Wikipedia:Perennial proposals. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Wikipedia doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.

Before posting your proposal:

• Read this FAQ page for a list of frequent proposals and the responses to them.
• If the proposal is a change to the software, file a bug at Bugzilla instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
• If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there.
• If the proposal is for a new wiki-style project outside of Wikipedia, please go to m:Proposals for new projects and follow the guidelines there. Please do not post it here. These are different from WikiProjects.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Community something about ArbCom

Moved to Wikipedia:Village pump/ACFeedback

Dated Watchlist items

Proposal: (note, I did search for previous suggestions, and didn't find this one). I propose that a date stamp be added to a watchlist entry. Meaning, when I edit my watchlist, I can see when that page was added to the watchlist.

Reason: Editors often edit many pages in a short time, and often add that page to their watchlist. I'm sure many editors add that page to the watchlist in order to monitor their edits to see if they are providing positive edits, and not simply reverted, or someone finding mistakes that the editor made. Often the editor may not have a particular interest in the topic, but simply want to see how their edits are accepted. If a date stamp is added to the entry that was watchlisted, an editor can see that it was a page that was added over a week ago (an example), and decide that the page is no longer wanted on their watchlist. Stated poorly, I hope the idea is understood Ched (talk) 01:30, 18 January 2009 (UTC)

• Support: as editors often edit many pages in a short time, they will most likely forgot when which page was added, so that would be useful in reminding the user when a watched page was introduced. In fact, it would be pretty sad if I didn't even notice that, considering that I have "3,135 pages on my watchlist (excluding talk pages)" (beat that record, Wikipedaholics!). ~ Troy (talk) 01:49, 18 January 2009 (UTC)

I'd like to see this added to the “View and edit watchlist” view (and not the regular “Display watched changes” view), along with the option to sort by date added instead of alphanumeric. Anyone know if this data is in the database? —Michael Z. 2009-01-18 04:13 z

Yes yes yes ... is it something that would be very hard to do? Sorry for getting overly enthusiastic, but most servers, databases, and file systems that I've ever worked with do contain a modification date (and time) stamp. I wouldn't think that Wikipedia's system would be that far removed from a MySQL type of thing (although I admit to never having read the wiki specifics) Ched (talk) 04:22, 18 January 2009 (UTC)

Support Yes, this would be very helpful. Anything that makes it easier to categorize the article's that one is interested in is welcomed by me. Themfromspace (talk) 06:28, 18 January 2009 (UTC)

You are correct, Ched, MediaWiki does use MySQL; see mw:Manual:Database layout for a description. Watchlist details are stored in the Watchlist table, everyone's watchlists bundled together and distinguished by having each entry marked with the user id of the user who watched it. So although the date entries were added to the table is not recorded, it would be possible to order the entries as older ones will be nearer the top of the table and newer ones at the bottom. Iff SQL queries preserve the order of the records, it would be easily possible to order the entries, although an absolute timestamp is not available without a schema change, which is a Big Deal. Happy‑melon 09:56, 18 January 2009 (UTC)

If I understand correctly, having an actual date/time stamp would require more work than it's worth (no problem). But, it might be possible to add the ability to sort the watchlist in the order that a line item was added (rather than alphabetically). If that's a possibility, then adding it would be great (at least for me). I have tweaked my preferences to display more than the simple watchlist as well by the way. As far as 3,000 items on a watchlist ... whoa nellie ... take a break and enjoy a sunset my friend ... :) Ched (talk) 18:56, 18 January 2009 (UTC)

although an absolute timestamp is not available without a schema change, which is a Big Deal. Why would it be a big deal to add a field to a MediaWiki table? In most applications, this is pretty trivial. -- John Broughton (♫♫) 16:26, 22 January 2009 (UTC)

Doing a schema change with no downtime is hard. Doing it on a multi-terabyte database is harder. --Carnildo (talk) 04:55, 23 January 2009 (UTC)

Indeed. Wikimedia operates over three hundred servers on three continents, interlocking on an enormous scale. We notice performance degradation when more than about half a dozen servers go offline at once. A schema change is massively more disruptive than that. Most organisations have sufficient resource surplus to be able to take half their servers out of sync for a few minutes without anyone noticing. Even if wikimedia does that at three in the morning, we're usually picking up the pieces for a week afterwards. So yes, schema changes are a Big Deal, and they tend to 'stockpile' them and then do several at once as a consequence. Pretty much the only developers who can authorise them are Brion and Tim. Happy‑melon 15:59, 24 January 2009 (UTC)

How would sorting by order of entry be implemented? Add a link to "Display watched changes | View and edit watchlist | Edit raw watchlist"? And allow clicking on sorted a second time to reverse the sort? Display only the last change for each item? Display the first 20/50/100/200/500 articles? Apteva (talk) 16:37, 31 January 2009 (UTC)

• Going by the spirit of the proposal, a timestamp will only show when I made my first edit to the article. I could have made 4 edits to it in a span of 4 years, and my first edit could well have been trivial, like fixing a spelling error. It would be better to know all the edits I made. For this, the history page of the article in the watchlist can have a "My edits" link. Or to make it universal, the history page could have a Contributor Search box, which would search and list all edits by a particular user. If the user has a habit of providing summary comments on all edits, the search result will exactly show a user's contribution to an article. A "Sort by oldest" option in the search could be a close solution to what the OP wants, i.e., when the page could likely have been added to his watchlist. Jay (talk) 09:56, 4 February 2009 (UTC)

Blocking policy

I may not be doing this entirely correctly, but I propose that the terminology of the blocking policy be changed. Currently, the blocking policy states that blocks are not meant as punishment. However, as an elaboration upon that point, the blocking policy states that blocks are intended to deter future disruption.

I have a problem with this. Blocks are punitive, no matter what the policy says. Two things make it quite clear blocks are punitive. First, the policy says they are meant to deter. There are several rationales used by scholars to explain punishment, but I would submit that nearly every scholar educated in penological theory would agree that the two historical justifications for punishment (besides divine revelation) are retribution and deterrence. Like it or not, by conceding that blocks are meant to deter, the policy is contradicting its claim that blocks are not punishment. That’s my substantive problem with claiming blocks are not punishment. My second argument is procedural. The actual administration of blocks is done so in a punitive fashion. Repeat offenders are given longer blocks. More egregious offenders are given longer blocks. That’s a punitive system.

I suggest that the blocking policy be reworded to say that blocks are not for retribution, because they are certainly for deterrence. Those are the two classic justifications for punishment. Blocks deter; that means they punish. However, they aren’t necessarily retributive. This also has some other consequences. I also think that blocked users should be allowed to use “retribution” as a defense against their blocks. If the length of the block or the disposition of the blocking administrator indicate retribution, the block should be shortened or lifted. Hopefully, if applied correctly, this wouldn’t result in more blocks being lifted. Rather, it would result in more blocks being above controversy because removing any hint of retribution would increase transparency on Wikipedia. Chicken Wing (talk) 00:25, 20 January 2009 (UTC)

Unfortunately, you will never get people to admit that blocks are punitive, even though they frequently are. Same as how people insist that votes on adminship requests are not votes, and that there's no such thing as a cool down block, and so on -- Gurch (talk) 17:36, 20 January 2009 (UTC)

Most kind of blocks are punitive. And the fact they get extended is proof they are punishments. And almost every kind of block is a cool down block. Majorly talk 18:01, 20 January 2009 (UTC)

I know you know that, but try saying that when asked about it in an adminship request -- Gurch (talk) 19:07, 20 January 2009 (UTC)

I'm just trying to make Wikipedia more transparent. I don't think people should fail adminship requests because they stumbled on a trick question, especially when the "correct" answer has no basis in reality. Nor do I think Wikipedia should give its critics a foothold by dogmatically holding to patently incorrect policies. In my experiences editing Wikipedia, it would appear to me that the legitimate criticism of Wikipedia comes from people who are on the wrong end of policy text and policy implementation being at odds with each other. Besides, I don't see any serious harm that could come by changing the policy to say "retribution" instead of "punishment".

And, let me say thanks for the input to everyone who has commented on this. I appreciate it. Chicken Wing (talk) 20:54, 20 January 2009 (UTC)

I mostly agree with this change. Blocks serve essentially three distinct purposes: a preventative measure, to prevent the user from doing further damage, a deterrent measure, to discourage them from taking the same action again once their block is over, and a discouragement to others, who may avoid destructive behavior out of fear of blocking. The analogy with real-life justice systems is clear: we lock criminals in jail so that they cannot commit further crimes, so that they will be discouraged from committing them again after release, and to deter others from committing crimes. However, just as a criminal can get out of jail early if they've shown signs of effective rehabilitation, so may a blocked user; we are only concerned that they do not repeat their disruptive behavior, not that some arbitrary standard justice is meted out. It is in this sense that one can say that blocking isn't punitive (in addition to it not being about retaliation). Dcoetzee 22:57, 20 January 2009 (UTC)

Does someone want to link to the text in question? I agree with OP. This sounds like a simple case of poor use of english which should therefore be corrected - the word 'punishment' has been misused - if blocking is intended to deter future transgressions, then it is punitive, punishment, whatever, according to any half-decent dictionary. Even Punishment includes: "Possible reasons for punishment ... Deterrence / Prevention: to act as a measure of prevention to those who are contemplating criminal activity." Jaymax (talk) 22:17, 25 January 2009 (UTC)

This is the Wikipedia block policy. The first paragraph of the policy says in part, "Blocks are used to prevent damage or disruption to Wikipedia, not to punish users. Blocks sometimes are used as a deterrent, to discourage whatever behavior led to the block and encourage a productive editing environment." It may seem like I'm being trivial in trying to get this fixed, but I'm not. This contradictory policy has been repeatedly use to browbeat unsuspecting candidates for adminship. Chicken Wing (talk) 00:08, 26 January 2009 (UTC)

Further agree - the wording does not make any sense using a correct definition of 'punish'. Entirely valid reasons justifying the punishment (incapacitation, deterrence) notwithstanding. Also agree (best guess) the intent seems to be to say that blocks are not reprisal/retaliation against users for breaking rules Jaymax (talk) 00:37, 26 January 2009 (UTC)

This seems to be based on the premise that since people may use punishment as a means of deterrence or prevention, then deterrence or prevention is punishment. However, observing that "A is used for B" does not imply that "B is a form of A". Deterrence is owning a nuclear submarine fleet. Punishment is launching the missiles after being attacked. SHEFFIELDSTEEL^TALK 16:19, 27 January 2009 (UTC)

But we do launch the missiles. Threats of blocking only get so far. Mr.Z-man 17:47, 27 January 2009 (UTC)

I don't agree with the assessment by SheffieldSteel. To punish is "to subject to pain, loss, confinement, death, etc., as a penalty for some offense, transgression, or fault." A block subjects a user to the loss of editing privileges. A block subjects a user to the confinement of exercising speech in a manner other than through editing Wikipedia. A block is the penalty for an offense, violating a rule of Wikipedia in such a fashion as to warrant a block. A block is punishment. The goal of the block is deterrence, a legitimate goal of punishment. Your nuclear analogy falls apart because the equivalent analogy would be warning a contentious editor that you own the ability to block. Blocking is the actual use of a nuclear weapon. Through the correct use of your own reasoning, not only is a block a form of punishment, it's analogous to punishment of the nuclear variety. Frightening. Chicken Wing (talk) 20:51, 27 January 2009 (UTC)

I find this discussion interesting because I am currently reading The Roots of Evil ISBN 0313201986 which is a history of crime and punishment. The most salient point is that cruel punishments create cruelty in the people. When I was in high school it was explained to me that technologically we live in the space age, but sociologically we are still in the stone age. However, WP is hopefully on the cutting edge of wherever we are. Apteva (talk) 18:28, 31 January 2009 (UTC)

Either make "Help" pages at en.wikipedia into copies of Meta "Help" pages, or stop saying that they *are* copies

Many, probably most "Help" page on the English Wikipedia say, at the top, This is a copy of the master help page at Meta. Do not edit this copy. Edits will be lost in the next update from the master page.

In fact:

1. Almost all of these pages in the English Wikipedia are edited, and no one reverts the edits.
2. There is no systematic process by which improvements to the English Wikipedia version of a "Help" page get copied to the related Meta Help page.
3. "Updating" of English Wikipedia "Help" pages by overwriting (with information on the related Meta page) seems to be sporadic at best, presumably because editors realize that such overwriting will remove useful information (see points 1 and 2).

All of which I found to be embarrassing (perhaps my expectations are too high). If we want to systematically keep Meta and en.wikipedia.org "Help" pages synchronized, and we want Meta pages to be the ones that are first updated, then let's do that (and keep the notice at the top of the en.wikipedia.org "Help" pages). Otherwise, let's acknowledge the current reality and remove the notices at the top of our "Help" pages, or modify them to say something like "A similar help page can be found at Meta, which may have different information".

So: what do other editors suggest? Should we keep the notices and actually do what the notices say, or should we modify or delete the notices and continue the current practice of letting the two sets of "Help" pages not be systematically synchronized? -- John Broughton (♫♫) 15:18, 24 January 2009 (UTC)

I must agree that I find the current system bizarre and rather clunky. Although what solution would be viable depends on what is technologically possible, and what would technologically work best. --.:Alex:. 15:25, 24 January 2009 (UTC)

This has been floating around my list of things to do for a long time. I agree that the template is actively counterproductive, suppressing editing where it is most needed. Those pages haven't been updated from meta for literally years. I'm inclined to TfD the template. Thoughts? Happy‑melon 15:45, 24 January 2009 (UTC)

It should also be a trivial task to make a bot that would update the pages at enwiki from meta as necessary, if it's decided that it's best to keep the help pages synchronised. As to what's best, I don't know. Is there reason to assume the pages at meta are updated more often, or are more helpful for some other reason? — Twinzor ^{Say hi!} 16:34, 24 January 2009 (UTC)

Originally it seemed like a good idea, back when meta was fairly active compared to the other projects. Now meta has largely stagnated, and more importantly its help content is being moved to http://www.mediawiki.org which is the main website for the MediaWiki software itself. So the meta pages are very definitely not more active than the en.wiki ones. Probably the best-quality ones are at mediawiki.org. Happy‑melon 22:05, 24 January 2009 (UTC)

Why do we have to host copies of the pages here at all? Why can't we direct users to MediaWiki.org, and make all improvements there? —Remember the dot ^(talk) 22:23, 24 January 2009 (UTC)

I would definitely support such a move. Happy‑melon 22:27, 24 January 2009 (UTC)

There is a feature that just rolled out on Wikia called "wikia:central:Help:Shared Help", where all of the help pages from Help Wikia are embedded into each of the other 9000 some odd projects. This could help (no pun) our situation, though I do not know that the extension is publicly available, however. --Izno (talk) 22:55, 24 January 2009 (UTC)

It's not that much harder to type mw:Help:Magic words instead of Help:Magic words, and unified Wikimedia accounts can already edit at mediawiki.org without trouble. So, I don't see a lot of benefit to a shared help extension. —Remember the dot ^(talk) 23:00, 24 January 2009 (UTC)

Just a suggestion that I thought was pretty neat and which would ensure documentation for all (English) Mediawiki wikis. It could then lead to efforts to ensure documentation for the other languages, something which I'm sure Betawiki would be appreciative of (if not for the extra work >.>). --Izno (talk) 23:15, 24 January 2009 (UTC)

It's not a bad idea, and you're right that it would probably help internationalization. However, in the absence of such a feature I'd prefer simply redirecting our duplicate pages to mediawiki.org. —Remember the dot ^(talk) 04:59, 25 January 2009 (UTC)

(←) As it happens, just yesterday I wanted to update Help:Edit conflict to fix a broken link. Since Help pages are flagged as "copies" of Meta and I wasn't sure of the procedure, I asked at the Help Desk and was told to "Just fix it on both" (meaning separately). We obviously have a problem with our own Help Desk experts not knowing how this works. Since then I've discovered the template-based technique that was supposed to allow copying help pages from Meta to WP without loss of project-specific help. (For those who don't know, each help page has a [[Phh:name-of-help-page]] template for project-specific header info and a [[Ph:name-of-help-page]] template for project-specific footer info.) The intended procedure is:

1. If the change applies to all Wikimedia projects, edit the Meta help page and then re-copy it to WP.
2. Otherwise, edit Template:Ph:name-of-help-page (or Template:Phh:name-of-help-page).

Happy-melon, which template are you inclined to TfD? I don't see a common template that says This page is copied from Meta.

Twinzor, pages at Meta are available to be updated by editors from other Wikimedia projects. Even non-English project editors' changes are, theoretically, supposed to be translated and propagated to the English version. So yes, it's possible that valuable edits would be lost in severing the connection to Meta.

Remember the dot, navigating to Meta (or MediaWiki) to get help pages means we'd lose all Wikipedia project-specific help. I did a survey of all the Help footer templates. Out of 84 pages, 59 have project-specific information, some of it quite extensive. I don't think we want to lose that. And we wouldn't want to merge that into Meta/MW, where it would confuse editors from other projects.

It seems to me that what we really need is more activity in Wikipedia:WikiProject_Help. Nobody even seems to be monitoring the Talk page there. I've been looking for ways to expand my contribution to the (overall Wikipedia) project, and I'd be willing to help, but I'm too new to the "back office" to feel comfortable taking a leadership role right now. - Unconventional (talk) 20:30, 31 January 2009 (UTC)

It'd be easy to provide a hatnote to the MediaWiki help page, with Wikipedia-specific information below that. That way, there's no duplication and no loss of Wikipedia-specific help. —Remember the dot ^(talk) 20:42, 31 January 2009 (UTC)

The template I intended to TfD was {{H:h Help}}, the one that explicitly instructed editors "do not edit this page", which is unhelpful at best. In the end I just blanked it instead, although I'm still tempted to TfD the entire lot of them; they're archaic in the extreme.

The situation here is analogous to WikiProject template sharing, a valiant effort to make robust templates that could be copied without modification across projects. Unfortunately, it made itself so complicated and bureaucratic that it eventually strangled itself with it. I can show you some of the templates that were involved if you like, they are hideous. This is a less choked situation, but it's still analogous: an absolute priority must be to make editing and improving these help pages as straightforward as possible, or editors simply won't bother.

There is a fundamental distinction between help content that relates to the MediaWiki software and help content that relates to site-specific conventions. I am of the belief that the two can be separated without loss of clarity; you notice that there are numerous redirects out of the Help: namespace where pages that describe wikipedia-specific topics have been moved into the Wikipedia: namespace. There is actually relatively little content left in our Help: pages.

My belief is that we should be separating those two concepts, and moving the pure technical help to mediawiki.org and the site-specific stuff to appropriate Wikipedia: pages. IMO, the Help: namespace is essentially deprecated unless and until the devs give us a method of dynamically including that content from mediawiki.org back here. Happy‑melon 20:57, 31 January 2009 (UTC)

Edit button highlighted

I noticed on the fr.wiki that the edit button is highlighted in blue[1], to attract more attention/raise participation, maybe its discussed before, are there plans on EN to do the same ? Mion (talk) 21:25, 24 January 2009 (UTC)

We already bolden it in Common.css (it's the same as the others by default). Perhaps if we made the 'selected' tab (which is also bolded) normal font, it would increase the contrast? Happy‑melon 22:03, 24 January 2009 (UTC)

I like this proposal. Unbolding the selected tab would help a little, but following the French model would help more. » šᾦῥъ^{τ • ¢} 22:31, 24 January 2009 (UTC)

Maybe the French version is not the maximum amount of attention we can draw with it, would this do ? Mion (talk) 00:21, 25 January 2009 (UTC)

If it's technically feasible, why not? We're supposed to encourage editing by anyone, so let's walk the walk. » šᾦῥъ^{τ • ¢} 01:00, 25 January 2009 (UTC)

If you must go with anything, go with the blue. Something as drastic as a green semicircle would just drive me demented, personally, and probably most other editors too. I do think something a little more subtle would work better overall though, such as underlining it or changing the colour of the font or something. --.:Alex:. 19:42, 25 January 2009 (UTC)

Mion was being sarcastic, of course. :-) I hope? Dcoetzee 02:07, 27 January 2009 (UTC)

So technical says it's feasible—what do we do next? Come up with a reasonable color/size scheme and start a straw poll on it? Get the straw poll listed at the top of everyone's watchlists? Some help or guidance from someone who's done it before would be great. » šᾦῥъ^{τ • ¢} 21:10, 25 January 2009 (UTC)

Please no. Think about how absurd some of the possibilities are. Right now, it is simple and elegant. Ottava Rima (talk) 23:01, 25 January 2009 (UTC)

Agreed. We have far more important things to worry about that bolding the edit button. –Juliancolton ^{Tropical Cyclone} 23:02, 25 January 2009 (UTC)

More important things ? Wikipedia:Wikipedia Signpost/2009-01-03/Editing stats Mion (talk) 00:19, 26 January 2009 (UTC)

Yeah, really. The whole "lets not fix this problem because other problems are bigger" argument doesn't make any sense, nor does the "it's a slippery slope to an absurd festive edit button" argument. Now, how do we bring this to a larger segment of the community to get a real consensus? » Swpb^{τ • ¢} 04:10, 27 January 2009 (UTC)

I prefer "the suggestions would be way too embarrassing" to be honest. Ottava Rima (talk) 05:01, 27 January 2009 (UTC)

So because some variations would be bad, it shouldn't even be considered? How does that make sense? » Swpb^{τ • ¢} 13:52, 28 January 2009 (UTC)

Ugh... no, please. *shudder* EVula // talk // ☯ // 05:20, 27 January 2009 (UTC)

Wikipedia should be justified

Well the text anyway. Ages ago I changed my user setting to justify paragraphs and completely forgot that it wasn't the default setting. I just think text looks better than way. Has there every been a debate over what the default should be? — Blue-Haired Lawyer 22:38, 25 January 2009 (UTC)

I doubt you could agree on that. I personally would disagree, justifying looks good in paragraphs, even letters but it does not with Wikipedia pages. For example if you're using a widescreen monitor like I do, it makes the text actually harder to read, as well as when manual breaks are used. If you like it, you can set it yourself, but there is no reason to make it default. Otherwise people will just complain why align left is not default... SoWhy 22:49, 25 January 2009 (UTC)

Justified text also looks bad on narrow monitors, so it really is the worst of both worlds. As you have found, users who wish to see the text justified can trivially do so. Why do you think this style preference should be enforced on the entire readership? Happy‑melon 00:20, 26 January 2009 (UTC)

That kind of begs the question, why do you think your style preferences should be enforced on the entire readership? I'd just be curious to know out of all the registered users who know about the option, enable it. If I'm in the minority, so be it. — Blue-Haired Lawyer 11:01, 26 January 2009 (UTC)

That's not what I'm saying, although there are some reasons given already: namely that it looks inferior on extra-wide and extra-small screens. I'm mainly saying that this is the default position, both in terms of what's currently the case, and in terms of this is not AFAIK being specified by our stylesheets at all: non-justified text is in most cases the browser default. There should be a good reason to move away from that default position. Happy‑melon 23:36, 30 January 2009 (UTC)

Text with a ragged right margin uses the font's normal word spacing, and the shape of the right margin helps the reader's eye navigate the page. Justified text has the word spacing adjusted differently for each line. It only works well with a fairly short measure (length of line), with hyphenation to help keep the word spaces from growing too large, and with the attention of a skilled typographer. Its disadvantages can also be exaggerated in a flexible-width page design like Wikipedia's.

So justified text is likely to be less comfortable for the reader in many or most situations (e.g. different screen resolutions, available fonts, window sizes). This is not just someone's preference, this is based on accepted typesetting principals, and could be confirmed by practical testing. —Michael Z. 2009-01-30 23:59 z

Never mind! — Blue-Haired Lawyer 00:04, 31 January 2009 (UTC)

See also Justification (typesetting). —Michael Z. 2009-01-31 00:21 z

aquarellista

question that I cannot find an answer to:

I have founded a movement, "Aquarellista!" which has as main objective to put the noble art of aquarelle (transparent type of watercolours) out of its niche of old ladies that paint roses/old men that paint landscapes. Reading the "things not to put on Wikipedia" I get the feeling that I shouldn't contribute, as the movement (that should be a link somewhere in "aquarelle") is founded by me, the website (under construction btw) is made by me, as is the blog, my website, the manifesto etc. But that cannot be helped as we do not yet have many members because we need to be published etc in order to be taken seriously (and go to Artschools etc to "recrute" other aquarellista's) - chicken and egg problem so to say. We aim to be worldwide, well known and an answer to all that "shocking" art of right now. We're based in france, members dutch, australian, english, irish, american, swedish etc. I'd like some input on this from more experienced wikipediists! Thank you... Marina

The short version is that Wikipedia is not the place to promote anything, just to report on movements that are already noted by reliable sources. Try to get your movement noted in art magazines & papers and, once people start writing about it, you should have enough sources to fill in an article. Good luck! — The Hand That Feeds You:^Bite 13:15, 29 January 2009 (UTC)

Bad Links Flagging Checkbox

FYI-Suggestion (re response needed)

Running into a lot of bad links (external). Would be user-convenient if a "bad link" check box was available by external links, so that when one is encountered, it can be manually flagged for attention. Dougcouch (talk) 21:27, 26 January 2009 (UTC)

Being a wiki, if you find a bad link, you can just edit the article and delete the link. Just point out in the edit summary that the link is bad, and everything will be fine. EVula // talk // ☯ // 05:24, 27 January 2009 (UTC)

• Adding checkboxes requires complicated coding in the software. You could somply add (dead link) behind the link in question to draw attention to it, or move it to the talk page for other editors to see. Both are a lot easier to accomplish. - Mgm|^(talk) 12:41, 30 January 2009 (UTC)

Question about uncategorized templates (cross-posted from Village Pump-technical)

We have a special page for uncategorized articles, Special:UncategorizedPages. I was wondering if it would be possible to have a similar listing of uncategorized templates (i.e. pages in the Template namespace which do not contain a category). I think this would be very useful for maintenance and organizational purposes. --Eastlaw ^talk · _contribs 21:38, 26 January 2009 (UTC)

like this? Redekopmark (talk) 06:24, 29 January 2009 (UTC)

Never mind, sorry. --Eastlaw ^talk ⁄ _contribs 10:53, 30 January 2009 (UTC)

Expand maximum lengths for watchlists

The current maximum length of a watchlist, 7 days or 1000 edits, is sometimes too small. Consider raising the maximum. Also consider adding a "(prev 100)(next 100)" setup like article histories have. davidwr/(talk)/(contribs)/(e-mail) 02:33, 27 January 2009 (UTC)

• Questions for editors: Would anyone else find this useful?
• Questions for coders: Is this feasible?

Yes, there are times when it would be helpful. Someone spammed this page several days ago, for instance, resulting in edits to one page occupying much of my watchlist. The only way I could think of to fix that was to unwatch this page, which I didn't want to do. Please see also this proposal above. Perhaps they could be implemented together. Rivertorch (talk) 06:09, 27 January 2009 (UTC)

I would welcome this proposal, as it would greatly enhance the watchlist for me. I use the "enhanced" view (with the 1 000 edit limit) as it is far more detailed than the standard version, but the limit means that my list often stops only half a day back. (I've got a large list, plus many pages that are vandalism targets. A busy day on an admin. noticeboard or a guideline page can involve a hundred or more edits, which uses up ten percent of the list just for that one page.) --Ckatz^chat_spy 06:16, 27 January 2009 (UTC)

I would really love to be able to double the current size, and so would many of those of us who have been active for a long while. But what i'd like even more is simple and direct way of having multiple watchlists,. DGG (talk) 09:38, 1 February 2009 (UTC)

Central overview page for certain processes

I would like to propose the creation of a page where all the current cases involving disputes etc, are listed in the one place. So, in other words, one would have all the current RFC, RFA and RFAR cases listed, in abbreviated form, so that users could see at one glance who or what was being debated. Part of the current problem we have, I think, is that such processes are scattered around on different pages and obscured from ready view. If we had a central page that listed all such processes, users would know they needed to go to only one page to keep tabs on things, and it might encourage more participation, which is often woefully lacking. Gatoclass (talk) 10:00, 27 January 2009 (UTC)

Support. It absolutely makes sense. Rivertorch (talk) 10:34, 27 January 2009 (UTC)

Support. The whole layout of the behind-the-scenes Wikipedia needs a way more centralised approach I think. Autonova (talk) 12:37, 4 February 2009 (UTC)

Wikipedia Search

High (very high), I am Janezdrilc, admin on sl:. I have a proposal how to improve a Wikipedia Search options. As admin I miss an option to search within deleted articles, so I thing it would be very handy to have a one little square more on the search site where you could select Deleted articles. And there is one other thing: select all and deselect all options. Ok, those are just two ideas I am expecting to be realised :) Have fun. --Janezdrilc (talk) 12:58, 27 January 2009 (UTC)

Very few people know anything about the internal workings of the search function (apparently it's 40,000 lines of code :S), so I have no idea if searching deleted revisions is possible. By "select all" and "deselect all" options, I presume you mean for the namespace checkboxes in advanced search? If so, this is something I noticed a while ago, and I coded a fix for myself - you can see it in my .js files. I'd love to see it implemented either in core javascript or in our own files. Happy‑melon 14:04, 27 January 2009 (UTC)

• Well, you could search the deletion log, but if you don't have an exact match, it doesn't work. I too would like to see the search box extended so admins can use it to search deleted revisions (or have the prefix coding and the like added to the log pages) - Mgm|^(talk) 12:39, 30 January 2009 (UTC)

Improving Wikipedia's credibility

I may well get flamed for this, but my intentions are noble. I'd love your feedback on it. It may well have been dealt with before as I am relatively new to this.

I have often wondered how reliable a particular article is on a subject I know little about; I usually have to cruise through assuming that it sort of sounds right, so it must be. Clearly this is Wikipedia's chief challenge; that of credibility.

Three ideas that I'd love your feedback on (and that you may well have considered):

1. What if there were a system whereby contributors could voluntarily publish their full name and credentials directly on the pages they edit? This would require no oversight; the present wikipedia oversight process would suffice (if a false credential or false name were given, it could be removed and locked, for example.)

2. What if there were a place on each page where scholars could give a dated tick of approval to a page that they are a recognised expert in (for instance, astrophysicists from various universities could sign and date their approval of the veracity of information on a particular page)?

3. What if pages (particularly, controversial subjects) were able to have an extra level of credibility attached? For instance, if some scholars wished to edit and peer-review a page, the text that had been peer-reviewed could appear in a slightly differentiated font to edits made after the latest peer review.

I know that I would be infinitely more confident about my usage of Wikipedia if such processes were available. What do you think?

Cheers betacrucis

Replies:

• 1) You can use your real name or even "Real Name, Ph.D." as your username, so it shows up in the edit history. Since edits can be made by anyone at any time and your contribution today may disappear one piece at a time over the next few months, putting your name at the end would cause major issues with stale-ness.
• 2) If you use your real name, and you were careful to make sure the entire article met your approval before editing under that name, your edits would gain a reputation as being authoritative. You might want to use a non-realname account for edits to articles you weren't an authority on or when making edits to articles you are an authority on but where you aren't "blessing" the current version.
• 3) We already have WP:Good Articles and WP:Featured Articles. As a counter-proposal, I'd like to see the talk-page templates for GA and FA/FL contain snapshot-in-time links to the version at the time it made GA or FA. The problem with controversial issues is everyone wants to sit on the peer-review committee and nobody wants people who don't share their viewpoint on the committee. As written, your idea would never work for controversial issues due to the conflict it would generate.

davidwr/(talk)/(contribs)/(e-mail) 18:07, 27 January 2009 (UTC)

One problem is how to validate that people are who they say they are. That is bitten WP before. Karanacs (talk) 15:34, 27 January 2009 (UTC)

Surely the best way to establish the accuracy of an article is to verify the content against the sources. SHEFFIELDSTEEL^TALK 15:38, 27 January 2009 (UTC)

See: Citizendium. Arnoutf (talk) 15:40, 27 January 2009 (UTC)

I am quite new here and it's a challenge simply to add a reply here... I figured there was a more user-friendly way than literally typing four colons at the beginning of each paragraph and signing my comment with four tildes but alas, it it not immediately apparent to me. Perhaps you can enlighten me.

Meanwhile, Citizendium has nothing on Wikipedia; I searched on a topic and the page was bare. I suspect the oversight is too onerous there, combined with a lack of popularity. It's not fair to compare them.

I also disagree that Wikipedia "verifiability" is sufficient; the sources that are usually given are frequently unreliable. Something more is needed.

In answer to Karanacs, I agree that this could pose challenges but my interest is first and foremost in gauging your sense of whether providing optional scholarly "seals of approval" and/or optional lists of fully identified contributors would be a useful addition. Identity verification is clearly an issue but could be dealt with if the community agrees that these features would be useful.

I have to say that if a serious, well-respected historian put their name to a dated version of a wikipedia history article, the article becomes infinitely more trustworthy and valuable. How much moreso will credibility be improved with multiple scholarly names vouching for the accuracy of a page (with perhaps some sort of rating system and/or link to a page of each scholar's concerns about that particular page... the possibilities here are endless). This is the one thing missing from Wikipedia. It is not right to say "Well, if you want credibility, go to Britannica or Citizendium"; Wikipedia can become more credible and it ought to.

I think this is a serious issue for an encylopaedia that is widely relied upon as a source of information, and I think some sort of system of voluntary scholarly/real-name assurance would do wonders for the credibility, usefulness and public image of Wikipedia. Betacrucis (talk) 18:24, 27 January 2009 (UTC)

Sorry about the brief "See Citizendium". I think the lack of articles on Citizendium is the direct consequence of the demand that editors are experts. Experts are not always as motivated to edit compared to the motivated hobbyist. Hence by demanding expertise, in my view, you would take away one of the strongest points of Wikipedia: The vast body of editors. So I would say no to such ideas. Arnoutf (talk) 18:33, 27 January 2009 (UTC)

Thanks Arnoutf; to clarify, I am not demanding expertise. I am saying that there ought to be an optional, specialized, rarefied box on each page for which an expert decides to give the page a rating or a "tick" and/or a link to their comments about the article. This would not interfere whatsoever with the normal usage of Wikipedia. It would be an optional add-on to articles which self-declared experts decide to rate/comment on the accuracy/quality of a page. I believe this could be done with a minimum of fuss and a very low rate of false IDs. Betacrucis (talk) 18:44, 27 January 2009 (UTC)

Think of it this way -- a lot of people who are experts get paid for their expertise. They aren't going to come in their free time and contribute for free, when they already have to deal with (whatever) in their paid time. That's one big reason. Another problem of course is the whole original research factor -- yes, someone may be an expert on a topic, but that could work against them, as they "know" something that most people don't and can't be sourced. ♫ Melodia Chaconne ♫ (talk) 20:13, 27 January 2009 (UTC)

Personally, I like to think good edits speak for themselves. However, a systematic way of fact checking articles would be great. I'd like to hear a reasonable proposal for this, even if it's just based on talk page notes. Dcoetzee 20:15, 27 January 2009 (UTC)

It would be impractical to verify that a person is the expert he claims to be. Using real names and titles on wikipedia is pointless because anyone can claim to be anyone he wants to be.

What if, after a year, someone says he didn't make this or that edit or approval. Has someone been impersonating him? Is he embarrassed because he noticed a flaw in the article and is now trying to cover his mistake? Has he changed his mind? and so on. That sort of thing would just harm Wikipedia's credibility.

Just because someone has a ph.d. in a subject doesn't make him right either. There are many scholars with controversial views, and Wikipedia should portray the non controversial view.

Any source is unreliable, that is true whether it's Britannica, Citizendium a big newspaper or a government. If it's critical information, you should always be skeptical and check the source and verify with independent sources. On Wikipedia this is much easier to do than in almost any other case: you can request citations, check the sources, check the talkpage and can ask other editors for feedback. If you read Britannica you have to take everything for granted and simply trust their editors.

It could always be better of course, and there are undoubtedly nonsense every here and there. Personally I'm very positively surprised over the high quality of many articles though. One of the things I like about Wikipedia is that everyone is equal and only defined by their contributions.

(Unfortunately the talk pages aren't very user friendly, colons and tildes are the easiest option).
—Apis (talk) 00:06, 28 January 2009 (UTC)

Thanks for your contributions to this discussion, friends. I multiposted it because of the instructions at the top of this page - "If the proposal is a change in policy, be sure to also post the proposal to, say, Wikipedia:Manual of style, and ask people to discuss it there". Perhaps someone might explain to me where I went wrong!

I agree and am often surprised by the quality of the articles on Wikipedia. However, I think that Dcoetzee's comment sums up the feelings of many of us (he wants "a systematic way of fact-checking articles"). When I read an article I don't want to have to go and check every source - and believe me, many sources are sitting up here on pages that have clearly not been checked properly by contributors. I'd like something more.

I get the sense that my suggestions are not going to be especially popular but that there is a feeling that Wikipedia's credibility ought to be improved somehow. That some mechanism could be introduced to give some old-school cred to Wikipedia articles; that the use of peer-reviewed journals and books as sources ought to better encouraged within Wiki's mechanisms.

Any ideas? Betacrucis (talk) 02:50, 28 January 2009 (UTC)

What I see as one the biggest hindrances to this is the fact we tend to say "no thanks" to new users who come in feeling they can offer something useful because they do "know" something. This in itself is not a problem but it is the support of the underlying concept that "merely being true or useful does not automatically make something suitable for inclusion in an encyclopedia" and that one can always "ignore all rules" that leads into the problem. A new user is not really allowed to "ignore all rules" and tell facts they know because it is OR and, even if the editor is the subject, "merely being true or useful" is not a valid reason for that information to be included. However if it is part of "significant coverage in reliable sources that are independent of the subject" it may be. See the core policies already prevent a user from having any sort of "first hand" knowledge of a subject that can be shared and it has turned many people away. What ♫ Melodia Chaconne ♫ said above it very true, "a lot of people who are experts get paid for their expertise". And that being the case most professionals in a given field are not going to want to "work for free" when they are are challenged at every corner. Another "minor" problem is that one of the criteria we use to "judge" others, or if a source is verifiable as a reliable source, is too see if the source, such as a newspaper or magazine, has a publisher, editors and a staff. Matter of fact if they don't, and it is a "wiki", such as this, we say it is not acceptable to use it. I have said it before but will say it again, here and now, I think that when Wikipedia (as a whole) starts to accept that, in order to make certian areas better, "instruction creep" is not always bad and sometimes there has to be a bureaucracy only then will others start to feel it is credible as a source. Soundvisions1 (talk) 18:44, 28 January 2009 (UTC)

As a bare minimum, I propose a {{factcheck}} template, to be used on the talk page. It refers to a specific quotation from a specific revision and a specific source, and states that the person placing the template, who is not the one who added the content, has verified the quoted information against the stated source. It might also be useful to have something in the article, keeping in mind that any such template should be unobtrusive and refer to a specific revision. Dcoetzee 18:42, 28 January 2009 (UTC)

Errors turn up in all media sources. Many newspapers have a "corrections" section that lists the mistakes that wound up in print. Absent of employing full-time fact checkers (which some major media companies have), we would have to maintain good faith that the people writing and editing the articles here have all of their facts in place. Pastor Theo (talk) 00:55, 29 January 2009 (UTC)

I personally think a new user should NOT be allowed to edit articles until he has logged about 250 edits, thus showing his worth. Let him edit talk pages and policy only until then. Silk Knot (talk) 06:13, 30 January 2009 (UTC)

With all due respect to those who've commented, this is getting away from my suggestion. All I am putting forward is that we allow verified scholars to rate articles on quality. This would not make any difference to the actual content; it would simply provide a point of reference for those who are not familiar with the subject matter of the article to be able to have a rough idea of how accurate/contentious the content of the page is.

As for not allowing a new user to edit articles until 250 edits, SilkKnot, I think that would defeat Wikipedia's chief advantage. The vast majority of content on wikipedia is added by anonymous users. See http://www.aaronsw.com/weblog/whowriteswikipedia

Betacrucis (talk) 07:40, 30 January 2009 (UTC)

While not fully the same as your suggestion we already have the {{expert}} tag available for use. But, as has been alluded to, because we do not, say, require an OTRS for users there is not a clear cut way to be sure the "expert" user is not a self appointed expert. On the other hand one could suggest that only Featured articles be used to give "a rough idea of how accurate/contentious the content of the page is" as they must follow the "Featured article criteria" in order to achieve that status. But that also leads to the overall issue of "merely being true or useful" not being a valid reason for that information to be included here and that anyone can sill edit the article after it has become a featured article to add or remove information that may, or may not be, "true or useful". Even in your suggestion there would be, currently, no way to prevent anyone from adding, or removing, information once the "verified scholars" have looked over the article and "rated" it. Soundvisions1 (talk) 13:51, 30 January 2009 (UTC)

I have myself often wished for way of saying in an article in my subject field, that I have looked at it , and that it meets at least my requirements. This is obviously of no authority except to the extent that people have any particular confidence in my judgment, but in various fields there there are people who judgement tends to be at least taken into account carefully. Sometime it is possible to find away to say so on the talk page, but I usually don't like to say it flat out, unless there is some controversy to answer, because it looks too much like putting myself forward when other do not do it. What I'll sometimes to is congratulate someone else on what i thin is a very good edit. I'm very leery, though, of introducing any more formal structure here--we already have an excessively confusing amount of it.DGG (talk) 09:35, 1 February 2009 (UTC)

Random image

Proposal: It would be very useful if a template could be created that could display a random image, selected from a list, every time a page is loaded. For example, I could have a list Image:Example.jpg, Image:Example2.jpg, Image:Example3.jpg, and upon reaching the page a random image would be displayed from the list. Any ideas or comments about this? Thanks, -download | sign! 01:49, 28 January 2009 (UTC)

The utility of this in articles is minimal. I can see it for articles which discuss randomness or articles on topics which embody randomness but not much else. It would be useful for wiki-ads and on user pages but that's not the main purpose of Wikipedia. davidwr/(talk)/(contribs)/(e-mail) 02:17, 28 January 2009 (UTC)

It would be good on pages which have a large number of good, relevant images. At the moment, once there are a few good images of different aspects of a subject, new ones are pointless even if they're really good. This would allow a wider selection to be used. --Helenalex (talk) 02:34, 28 January 2009 (UTC)

You could add a picture gallery (e.g. Tiger#Gallery).
—Apis (talk) 02:53, 28 January 2009 (UTC)

Well generating a random image would be much more useful. For example, if you only wanted one image rather than a huge gallery of images. For example, on some articles, there are huge galleries that are very distracting. -download | sign! 02:54, 28 January 2009 (UTC)

To me it seems like a bad idea since every user would get a different version of the article. Isn't it better that the editors decide on some of the pictures? If they are all of equal quality you could just as well throw a dice once yourself.
—Apis (talk) 05:47, 28 January 2009 (UTC)

If an article is being overwhelmed by images, move most of the images to Commons and add a link. That's what Commons is for. --Carnildo (talk) 06:24, 28 January 2009 (UTC)

Well just a side comment; if it is decided that a template should be created that does this function, would it be easy to code? -download | sign! 02:38, 28 January 2009 (UTC)

One other major downside: It breaks break the permanence of links to specific revisions. You expect a perma-link to be the same whenever you look at it. This wouldn't be without precedent, there are already things like CURRENTTIMESTAMP that break this permanence. For example, by saying "The current time is 2024-09-08 07:36:41 AM" I just broke the permanence of every revision that contains this text. davidwr/(talk)/(contribs)/(e-mail) 03:53, 28 January 2009 (UTC)

Isn't such permanence already broken by the myriad of templates that can appear on the average article? I don't see it as much of an issue.
As for the code, it's fairly simple; I've got some random text on my header if you'd like to take a look (purge the page over and over to see it in action). EVula // talk // ☯ // 06:03, 28 January 2009 (UTC)

From a user's point of view, there is a practical difference between a template that could change at any time but in reality is stable, and a template or other item like CURRENTTIMESTAMP that changes every time it is loaded or every time the cache is purged. davidwr/(talk)/(contribs)/(e-mail) 13:38, 28 January 2009 (UTC)

This is true, but are images truly so important to a specific revision of an article? If they want that specific image, they can just grab that specific image. *shrug* I can see this being handy for an article where numerous free use images are available, but unfortunately, there aren't many; the only examples I can think of are common animals, like dog or cat. On the whole though, this probably wouldn't be getting used very much. EVula // talk // ☯ // 17:31, 28 January 2009 (UTC)

There are two main problems with this proposal: one is that rendered articles are cached for anonymous readers, and this dramatically improves performance. Under your scheme this could not be done, unless it were done on the client side with Javascript or something. The other problem is think of print: someday someone will want to create print versions of Wikipedia articles, like a book, and a number of features like sound, animation, and this proposal are problematic in that setting. Dcoetzee 18:38, 28 January 2009 (UTC)

Deferred revisions

Wikipedia:Deferred revisions is a new proposal to use the abuse filter to defer suspect edits for review without the need to enable 'classic' flagged revisions, but able to work with it. Please express your opinions on the talk page. Cenarium (Talk) 18:37, 29 January 2009 (UTC)

GeoHack analogue for case citations

GeoHack is a wonderful tool for all of those who wish to access maps of geotagged areas through Wikipedia. That said, I propose a similar tool for accessing the full text of court decisions, allowing the user a choice of publishers to pick from (e.g. Findlaw/Lexis/Resource.org). Is this feasible? --Hashbrowncipher (talk) 22:51, 30 January 2009 (UTC)

Yes I think so, and I think it's a good idea. We have something similar for books too. I'd post about this on the associated Wikiproject. Dcoetzee 00:19, 31 January 2009 (UTC)

Examples of common names

Time to make the donuts again. Tony Blair, W, are no longer in vogue, and are not even very popular at the moment. I suggest they be replaced as examples of common names with the current PM and current President. This does not happen very often, but does make a simple change. As I see it the two choices are to pick some well known historical examples, like Winston Churchill not Sir Winston Leonard Spencer-Churchill, Abraham Lincoln, George Washington (though I can not find any middle names for them!), or use the current PM and President if they have a common name that differs from their full name. W is a particularly bad example at the moment. It is sort of like using Blagojevich or Hitler, as they are once popular but now disgraced. See discussion at Wikipedia talk:Naming conventions (common names)#Examples 199.125.109.126 (talk) 16:18, 31 January 2009 (UTC)

Editnotice for all blps

To see how the blp edit intro works, add the line   importScript('User:RockMFR/blpeditintro.js');   to your monobook.js and edit any blp after bypassing your cache.

I propose to use an editnotice for all biographies of living persons. It would be added to all articles in Category:Living people, similarly to what has been done for disambiguation pages. We may use the text from {{blp}} for example, thus it would render this (from Template:BLP editintro):

I'm sure it would help highly that editors become more aware of the blp policy, and it's prevention, which is particularly important when it comes to blps. We really should try this before considering implementing some drastic measures. Cenarium (Talk) 22:50, 31 January 2009 (UTC)

I like the idea - is there an automatic way to do it, or does it have to be done on a per-article basis? Dendodge Talk^Contribs 22:56, 31 January 2009 (UTC)

This has been done for all disambiguation pages, see Template talk:Disambig editintro. I've asked at VPT if this is adaptable. Cenarium (Talk) 23:17, 31 January 2009 (UTC)

Apparently this can be done. You can try to add User:RockMFR/blpeditintro.js to your monobook to see the result. I'll add this discussion to WP:CENT. Cenarium (Talk) 00:23, 1 February 2009 (UTC)

Good idea. Sceptre ^(talk) 00:31, 1 February 2009 (UTC)

Yes, I like this. I think the wording of the editnotice should be changed to something along the lines of 'if you want to add material that might be controversial, make sure it's reliably sourced, otherwise please don't add the material' rather than focussing on what to do after the bad material is added. It would also be good to also have a template which activates the editnotice, in addition to the category. This could be added to certain articles which are not biographies but which contain a lot of content about living people. Tra (Talk) 00:35, 1 February 2009 (UTC)

I agree.Bsimmons666 (talk) 01:43, 1 February 2009 (UTC)

The wording can be changed, this is just to begin with something that I used the text from blp. Cenarium (Talk) 15:12, 1 February 2009 (UTC)

What is the main idea that we want to tell the editor?

1. That they should includes sources for everything they add.
2. That there is a Wikipedia policy that covers articles on living persons.
3. That vandalizing an article on a living person is bad and can have real-life consequences.

The editnotice should focus mainly on one thing, and it should be the thing that causes the most problems. In my opinion, it is #3. --- RockMFR 06:06, 1 February 2009 (UTC)

To be blunt, we're dealing with people that have trouble with the concept of "saying someone is dead when they really aren't is a bad thing." I don't have much faith that an editnotice will actually have any positive impact. I'm not trying to rain on the parade here, just pointing out the obvious. EVula // talk // ☯ // 06:21, 1 February 2009 (UTC)

• I'm bearish on the idea of edit-notices that admonish people to not vandalize or otherwise fool around actually working. One of the reason edit notices...get noticed (Sorry) is that there aren't many of them. The dab edit notice jumps out at you because you aren't used to seeing edit notices. Before we consider reducing the overall effectiveness of edit-notices in general, we should be pretty sure that this one will actually stop people. Unless we can be sure of that, I'd rather we not have one. Protonk (talk) 07:04, 1 February 2009 (UTC)
  • It's not about asking people not to vandalize (to which I'm also opposed), it's rather to spread the knowledge of the blp policy and explain to editors how to deal with blp issues (and how to report them: at the blp noticeboard). It's wrong to say that users breaching WP:BLP are necessarily evil, vandals, etc, some are just not aware of blp policy and the consequences of their edits, so it's also preventive. Cenarium (Talk) 15:12, 1 February 2009 (UTC)
• Good call. Go do it :) Stifle (talk) 11:54, 2 February 2009 (UTC)
• Yes, this is an excellent idea and deserves at least a trial run. Protecting BLPs from crap is our highest priority, far more important than properly formatting dab pages. Point of information: other than dab pages, article edit-notices currently number about 60: [2].--chaser (away) - talk 04:30, 3 February 2009 (UTC)
• This is a good idea indeed. -- lucasbfr ^talk 22:21, 3 February 2009 (UTC)

Proposal regarding "moving pages"

I'd like to make a proposal regarding the "move page" feature to stop users vandalising via moving pages to "vandalistic" locations. My proposal would only make the "move page" feature available to:

1. Administrators (it should be included in the administrative tools)
2. Good-faith users accepted via a new process similar to the rollback acceptance process.

Thoughts? D.M.N. (talk) 13:51, 1 February 2009 (UTC)

I see this as well intentioned and totally unworkable. Most page moves are valid. Those that are bad are easy to police. I oppose this proposal. Fiddle Faddle (talk) 14:02, 1 February 2009 (UTC)

I agree, this needs to be available to most users. Many many pages are named incorrectly, but innocently so. I just moved on a little while ago. Sure as I have rollback I'm sure I'd get the level easily enough, but remember that rollback is just a speed tool -- anyone can preform the same basic function with a couple extra clicks; what you're proposing is an extra level that of user that we don't have already. Remember people need to be registered and auto-confirmed to move pages, that already takes care of a large majority amount of the vandalism. Sure it's not all, but almost inevitably anyone who goes to the trouble will be moving a highly watched page in the first place. ♫ Melodia Chaconne ♫ (talk) 14:26, 1 February 2009 (UTC)

Either Flagged protection or Delayed Revisions would be better able to prevent vandalistic page moves. — Blue-Haired Lawyer 14:37, 1 February 2009 (UTC)

What fraction of page moves are vandalism, right now? (We'd need some good numbers on that before I'd support this proposal.) I suspect that limiting page moves in this way might reduce vandalism somewhat, but only at the cost of drastically increasing the number of cut & paste page moves. The latter are generally far more work to clean up than the former if not caught right away. Vandalism page moves are usually obvious enough to be detected and reverted immediately; cut & paste page moves may linger for months and lead to unwanted content forking and required complex history and content merges to repair. TenOfAllTrades(talk) 17:37, 1 February 2009 (UTC)

We get this on Wikiquote all the time as well, and it has led me to think of a solution in algorithmic terms. Rather than making a move require a higher level of authority, we ought to tie the number of moves and the type of pages that can be moved to the potential mover's level and quality of participation. Simply put, a relative newbie with few edits should be able to make perhaps three page moves in a 24-hour period (if they try to make more, they would get a "move limited reached" message and be directed to an admin for assistance). The number would go up incrementally as the account persisted and good edits were made from it. This would not apply to the newbie's own userspace (move to your heart's content there). But other kinds of pages would require a longer edit history or a higher status to move. For example, there is no reason anyone but an admin should be able to move a page in another user's userspace, or in project space or template space (with the exception of a newly created page being moved by its creator, if that creator is the sole editor). The older a page is, the harder it should be to move because if it has been there a long time, there is probably nothing wrong with where it was; the more editors a page has had, the harder it should be to move. So, those four factors should basically balance out in a formula, which would make it well nigh impossible for a submarine newbie vandal account to move a large number of pages. bd2412 T 18:27, 1 February 2009 (UTC)

Autoconfirmed already does most of what you want. I don't know if autoconfirmed can be disabled but a "noautoconfirmed (expires=date)" flag would be a useful tool to combat page-creation and page-move vandals who do not otherwise vandalize the project. Or, a "block=nomove expires=date" or "block=nopagecreation expires=date" would do just as well. I haven't checked lately, these might already exist. davidwr/(talk)/(contribs)/(e-mail) 01:15, 2 February 2009 (UTC)

You're kidding right? Are there any examples of users who vandalize through pagemoves but otherwise constructively contribute? Mr.Z-man 01:38, 2 February 2009 (UTC)

As I mentioned the last time someone proposed this, the main effect of restricting who can move pages will be to increase the number of cut-and-paste pagemoves, which are a pain to spot and even more of a pain to fix. --Carnildo (talk) 04:33, 2 February 2009 (UTC)

How many newbies have a legitimate need to do more than three page moves in 24 hours? bd2412 T 04:37, 2 February 2009 (UTC)

A particular productive newbie who works on a page for move requests or one that is particularly productive in article writing, moving pages from his userpage to mainspace. I oppose restrictions too since restrictions would cause newbies to do page moves in other more destructive manners. - Mgm|^(talk) 11:46, 2 February 2009 (UTC)

The algorithm can be adjusted to accommodate this mythical newbie who dives in to making productive page moves on their first day. That consideration is no reason to eschew protection. bd2412 T 03:17, 3 February 2009 (UTC)

• Strong oppose. Don't fix it if ain't broken, or a solution in search of a problem. Now, the problem is dealt by editors reverting the move, just like any other type of vandalism. Creating code, procedures, etc to implement this proposal is totally unnesserary work. On top that, adding a bureaucratic procedure for nominating editors; rollback rights is a right that was delegated from admin rights. Here we are creating a previously non-existent right with all the increase in complexity it entails to deal, again, with a trivial problem. Which will create secondary non-triviel problems, named by Carnildo, TenOfAllTrades, ♫ Melodia Chaconne ♫ and, I'm very sure of that, people sending articles to AfD because they lonk like the title. ¨¨ victor falk 10:30, 3 February 2009 (UTC)

Rising funds for Wikipedia trough Wikimedia chapters

original proposal here Wikipedia:Village_pump_(proposals)#Rising_funds_for_Wikipedia In some countries, people can choose that 1% of their tax to go to a specific NGO. Did any of the Wikimedia chapters tried to do raise funds that way? Jim92 (talk) 15:26, 1 February 2009 (UTC)

Forum for Wikipedia

I think it would be very useful to have a web forum for Wikipedia. A web forum has certain advantages, comparing to the village pump. Threads are easy to follow, non-wikipedians are encoruaged to come with ideas too. I am not suggesting that village pump should be replaced with a forum. I am only saying that a web forum would be a great addition. A forum where all wikians (not only wikipedians) meet would be a great place to exchange useful ideas and information good for all wikis. Also a place where people can meet to talk about creating new Wikis. Jim92 (talk) 15:26, 1 February 2009 (UTC)

There has been discussion about LiqiudThreads being integrated into the wikis, but this hasn't happened yet. In the meantime, the village pumps do serve that purpose reasonably well. EVula // talk // ☯ // 16:15, 1 February 2009 (UTC)

Idea for blocking

It would be useful to have the ability to block an IP or username from editing a particular article. Yes, Article bans exist, but they are community enforced.

To assure that there wouldn't be abuse of such a feature, we could make a policy that it could only be used to enforce community bans, repeat offenders of edit wars or vandalism. Kingturtle (talk) 17:55, 1 February 2009 (UTC)

I'd support that idea, very useful from an editors perspective. However, when an editor is banned from editing an article, it tends to be pretty mainstream and any additions are quickly undone, and the user is blocked. I'm not sure this would add much to that, since people watch these pages anyway. —Cyclonenim (talk · contribs · email) 18:03, 1 February 2009 (UTC)

This is a counter-productive perennial proposal. No, if we take away the free will element, we won't know which users would otherwise edit in defiance of their topic ban. This creates a deceptive situation where one appears to gain trust by "behaving" and respecting their ban (from the forbidden fruit article perhaps), but it doesn't really meaning anything just because the server said "no" every time they tried to edit it. Seriously, how do we decide whether and when to lift a user's topic ban or ban them completely (when we don't know how reckless they'd have been up until now if they had a choice in the matter). — CharlotteWebb 18:18, 1 February 2009 (UTC)

I'm aware of a recent issue that was finally submitted to Arbcom where a per-article block option might have saved a lot of time. (The editor has now been indef blocked). Editors at ANI sometimes agree on article bans but the discussions are long and exhausting. My prediction is that these bans would be easier to agree on if the end result was a simple technical step, where an admin pushes one button and sets an expiry date. Occasionally indef blocks are handed out that would be unnecessary if article-level blocks were possible. EdJohnston (talk) 19:20, 1 February 2009 (UTC)

I don't know what case you are talking about, but had there been a technical way to lock somebody out of one or more articles, you're right, the user(s) would probably not be completely banned yet. Sure we'd have a fool-proof way to keep them out of a small set of articles for a certain duration of time but we don't know what they'd be doing meanwhile. Sure, they could be learning from their misfortune and becoming "reformed", or they could be waiting in the weeds for the page-specific block to expire or be lifted, or they could be causing trouble somewhere else and drawing less attention. If they can't control themselves, if we are suddenly asking Brion to develop an automatic way to baby-sit certain users by keeping them out of certain articles, why trust them to edit at all? Please answer this. — CharlotteWebb 20:28, 1 February 2009 (UTC)

Because sometimes very good editors get too involved in one or two articles, where WP:OWN starts becoming an issue. This isn't to say they can't be useful elsewhere, but it means we can lock them out of certain articles to prevent them causing a fuss there. —Cyclonenim (talk · contribs · email) 22:54, 1 February 2009 (UTC)

The Arbcom issue was due to this editor. If you check USS Liberty incident, there are at least two editors who've been blocked in the last three months, whose blocks would be unnecessary if they could be locked out of that article. (They truly have no other interests on Wikipedia). I would have proposed a 6-month article ban for each if it could have been done by technical means. I doubt they would have done any damage elsewhere on Wikipedia, so there would have been no need for other babysitting. Yet we could avoid the indignity of an indef block. EdJohnston (talk) 23:09, 1 February 2009 (UTC)

Strong support with respect to IP addresses and net-blocks, providing that time-limits would be the same as for a sitewide block under the same conditions: It's a lot less disruptive to put a 3-day IP article-block than the same 3-day IP site block. Limited support with respect to usernames: An alternative would be two per-user configuration pages that contained a list of pages not to edit. If a user attempted to save a page in either list, he would be warned not to do so. The first list would be for admin use, read-only for the editor, to "remind" people of article bans. The 2nd use would be for personal convenience, as a tool for wikiholics and others trying to moderate their own editing. The admin list would eliminate the "oh I forgot" excuse, the personal list is just a case of "we made the technology, might as well kill two birds with one stone." Optionally: Have an admin-only watchlist for edits made in contravention of the admin-watchlist. Such a watchlist eliminates the honor system though, so CharlotteWebb's objection above would still remain. davidwr/(talk)/(contribs)/(e-mail) 01:12, 2 February 2009 (UTC)

• Support Many reasonable people have too strong opinions about a particular subject. It is sad that we have to site-block them. --Apoc2400 (talk) 22:41, 2 February 2009 (UTC)

Proposal: Enable suppressredirect rights for sysops on the English Wikipedia

The suppressredirect right allows a user to move a page without creating a redirect. For admins, it is silly to have to create a redirect when you move a page, and then delete the page you just moved, if you are, for example, cleaning up page move vandalism. For non admins it is a bit of a problem, because normally you can't do a multiple page move that has the effect of replacing a page with an entirely different one (A->B C->A). But for admins this isn't an issue, they can do that anyway. This right is already given to users in the global bot, global rollbacker, and steward groups. This right is already possessed by administrators of the German Wikipedia, and there is a proposal on meta to enable it on all wikis. Prodego ^talk 01:33, 2 February 2009 (UTC)

[feel real smart] As far as I understand, all bots have the right; I remember giving myself a bot flag on Wikispecies (I'm a bureaucrat there) when reverting a load of vandalism and having a button suppress redirects. I just confirmed that. (User:Maxim on an alternate account.) maxypoda kiss! 02:20, 2 February 2009 (UTC)

Enabling tools that let trusted users do things they can already do only more efficiently shouldn't require a Village pump proposal. If anything, this should've originated on an admin mailing list or admin-only wikipedia page and implemented or not purely based on technical feasibility. Assuming this works as you describe, I endorse this proposal with the comment of "if the admins want to be able to do their job faster, let them." davidwr/(talk)/(contribs)/(e-mail) 02:51, 2 February 2009 (UTC)

I also think this is a good idea. It could simplify the Grawp fixing, for one thing. bibliomaniac15 03:35, 2 February 2009 (UTC)

Isn't User:Grawp "#REDIRECT WP:BANNED". davidwr/(talk)/(contribs)/(e-mail) 03:49, 2 February 2009 (UTC)

Unfortunately, there is a reason we keep having to trot out things like this. And a bunch of soopersekritcabal stuff that's hidden to most people as well, for when that fails. In any case, I'm surprised this already is enabled. I'd support its adding to here, and I'm going to go to meta to say the same thing. NuclearWarfare _(Talk) 04:27, 2 February 2009 (UTC)

Please do, it was extremely useful for pagemove vandalism cleaning. Did someone raise concerns at some point for it to be disabled? -- lucasbfr ^talk 09:20, 2 February 2009 (UTC)

• Support Of course providing there are no technical issues caused by turning it on again. PeterSymonds (talk) 09:21, 2 February 2009 (UTC)
• As this is just a technical convenience, I don't see much problem with this (will be very nice for userfying). Unless ... I can imagine that people start using it in cases where the redirect would be not a problem. (I see many people who move pages, then tag the redirect as a G6; as most of these redirects meet WP:R, I usually decline). Please, only use this feature if the redirect is truly speediable. Kusma (talk) 10:10, 2 February 2009 (UTC)
• Strong support - This is a very useful feature if an admin is reverting page-move vandalism (deletable per CSD G3), fixing the name of a page he/she had just created (CSD U3), moving a user's page back into the userspace (CSD U2 - shouldn't be done if the page was created in the mainspace, since an attempt tpo recreate it won't display the move log) or dealing with cut&paste moves (CSD G6). In the first case it helps WP:DENY and, if the page name reveals private information, reduces the number of log entries which contains such information. עוד מישהו Od Mishehu 11:00, 2 February 2009 (UTC)
• Support This seems sensible and useful. Nick-D (talk) 11:21, 2 February 2009 (UTC)
• Support –xeno (talk) 13:45, 2 February 2009 (UTC)
• Support A voting is good. Majorly talk 14:46, 2 February 2009 (UTC)
• Support - per no-duh. J.delanoy^gabs_adds 15:14, 2 February 2009 (UTC)
• mw:Manual:User rights is the mediawiki user rights page with some info on the subject. Protonk (talk) 15:19, 2 February 2009 (UTC)
• Support please and thank-you. Really, this is a no-brainer, barring technical issues. -Jeremy ^{(v^_^v Dittobori)} 19:48, 2 February 2009 (UTC)
• support Looks good. I have some slight concerns that if this is used badly it could potentially lead to GFDL violations(can someone who understand such issues comment on that concern?). As long as this is used only to deal with vandalism it should be fine. JoshuaZ (talk) 22:13, 2 February 2009 (UTC)
  • I don't think it will. Moving those pages moves the edit summary while leaving a redirect, so the movement portion of things satisfies the GFDL. Protonk (talk) 22:42, 2 February 2009 (UTC)
• Support, unless some catch is found. --Apoc2400 (talk) 22:37, 2 February 2009 (UTC)
• Support this is a minor tool, yet one that is nonetheless invaluable. Happy‑melon 23:40, 2 February 2009 (UTC)
• Supported on meta, might as well do so here, too. JoshuaZ does bring up a good point, that'll be something to watch for. – Luna Santin (talk) 00:20, 3 February 2009 (UTC)
• Support wholeheartedly, especially as עוד מישהו points out, it will be a great assist in U2/U3 & G3 issues that make this a tedious job right now! Skier Dude (talk) 01:34, 3 February 2009 (UTC)

It has been done, by tim starling, on all wikis. Thanks everyone for commenting! Prodego ^talk 02

54, 3 February 2009 (UTC)

WP:Notdirectory should be clarified

I AFD'd a large group of lists (about 150) basically named "List of companies in ..." as violations of wp:NOTDIRECTORY. It seems from the initial responces that the NOT policy is either unclear on this point or I am misunderstanding it's purpose. Please consider either commenting at the above linked AFD or helping to reword the policy to give clearer guidance. NJGW (talk) 04:37, 2 February 2009 (UTC)

Proposal: Adding "Monaco" (as seen on Wikia) skin as an optional skin (without ads of course)

I searched the archives and this was only suggested 1 other time, in November 2008 (Wikipedia:Village pump (proposals)/Archive 38#A New Skin), with no responses. Would it be possible for Wikipedia to add Monaco as an optional skin in the preferences menu? (like on Wikia, but without the banner ads). Monobook is pretty tired looking, and the only decent alternative currently is Modern. This would give editors an additional, more modern option, even if Monobook remains the default skin.

• Example of skin usage at Wikia

Outsider80 (talk) 05:12, 2 February 2009 (UTC)

You want one of the slowest loading skins possible??? --Izno (talk) 14:49, 2 February 2009 (UTC)

Adoption of V2-style Infobox headers, as developed on other Wikipedias (includes links to mock-ups)

Propose adopting, or investigating adoption of, "Infobox/V2" graphical style in Infobox headers on English Wikipedia. The presentation is much more professional (& better looking) than the current style. Basically, the title/topper of each infobox type (Music, film, person, society, etc) gets its own background color and background graphic. (For example, infoboxes about transport have a specific background, as seen in Golden Gate Bridge article link below) Other mock-ups can be found in the link below. I raised this at the Infobox Wikiproject's talk page about a month ago, and the response was that while technically possible the question would be if it should be done (so proposing it here to see if there is interest in pursuing/investigating its application here). Examples below (including link to French Wikipedia's Infobox V2 project)

• File:Infobox-french-music.jpg — French Wikipedia mock-up of music infoboxes, other examples at next link:
• French Wikipedia: fr:WP:V2 — French Wikipedia's Infobox wikiproject (V2 subpage) Rough English translation courtesy Google at: [3]
• fr:Golden Gate Bridge — Golden Gate Bridge article at French Wikipedia, infobox uses V2 style.
• Commons:Category:Infobox_pictograms — transparent-background Infobox pictograms used as watermark-type graphics on top of background colors & under title text in the infobox titles.
• Hungarian Wikipedia: hu:Sablon:Képregényszereplő_infobox#Minta comics character infobox.

Outsider80 (talk) 05:50, 2 February 2009 (UTC)

It does look quite good. The selection of background graphics looks like it could use some refinement. I'd like to see a more comprehensive set of examples, at least covering the top-level subject areas seen in Portal:Contents/Portals . —Michael Z. 2009-02-02 07:28 z

fr:WP:V2#Feuilles de style has examples of various top-level topic areas (afaik this is the most comprehensive examples they have, apart from the pictograms on Commons). the examples all use orange backgrounds, but the mock-ups in other examples show different background colors used for different topics. Outsider80 (talk) 08:09, 2 February 2009 (UTC)

hu:WP:IB (project page @ Hungarian Wikipedia) also has some examples about 1/4th of the way down the (long) page. it is mostly redundant w/ the French examples, though it does use a Bridge-specific graphic for bridges, and a football instead of the olympics symbol for sports. Outsider80 (talk) 08:15, 2 February 2009 (UTC)

Current guideline discourage decorating and inventing icons Gnevin (talk) 08:47, 2 February 2009 (UTC)

True (mainly for user-level editing), but this would be built-in to the template at a non-user-editable level, as an automatic design based on which type(topic) of infobox is used, and would not be very distracting. Outsider80 (talk) 11:12, 2 February 2009 (UTC)

It looks nice, sure, but whatever they're doing to get that effect hides both the title of the infobox and the lead image in text-only browsers like Lynx. --Carnildo (talk) 10:04, 2 February 2009 (UTC)

aside from resolving that bug, I think this is something we should simply move to as quickly as possible. the only questions I have show it will work on some of the more complicated infoboxes--the ones shown are rather simple. I certainly do nott thinks we'dwant an orange color in general, sicne we use that a a color for warnings. DGG (talk) 10:25, 2 February 2009 (UTC)

The French model (and likely other Wikipedias) use different colors for different topic categories, the orange was just used for all of them on the mock-up. English Wikipedia could of course decide which colors to assign to which topics (I think we already do this w/ infoboxes, or at least I have seen different colors used) Outsider80 (talk) 11:12, 2 February 2009 (UTC)

Note: The following message was just posted at Wikipedia talk:WikiProject Infoboxes, in the thread I mentioned at the top of this proposal. Am cross-posting it here since it contains useful links (and examples/mock-ups) for other language Wikipedias not mentioned above. Outsider80 (talk) 11:12, 2 February 2009 (UTC)

Hallo. Also the both sorbian wikipedias use such background images. The project pages are at hsb:Wikipedija:Infokašćik and dsb:Wikipedija:Infokašćik. But also the Esperantowikipedia has such a project at eo:Vikipedio:Informkestoj. I added some background images there, which are not in the french page. You can find all my added images on my commons user page. Greetings --Tlustulimu (talk) 10:19, 2 February 2009 (UTC)

It's attractive, but it needs some consistent graphical guidelines and set of icons before it's ready for deployment.

Specifically, the theatrical masks, game console, and compass are realistic 3-d images, with a lot of detail and shading, while most of the others are 2-d solid-colour graphical icons. Some are light-coloured only, while others have a lot of dark tone in them, and the bridge and highway add dark backgrounds for some reason. They vary too much in size (e.g., the filmstrip is 4 times the width of the beer mug). And a few are poor quality, like the planet and star, which seem to have contrasting edges, which appear to be antialiased for some other background colour.

We also need a comprehensive directory of subject areas, so that a full set of icons can be assembled. If we start with 20, then there will be 100 others of varying appearance and quality thrown in by various wikiprojects.

I think we need one or more artists ready to develop icons specifically to meet some guideline, rather than trying to mix and match found icons. This is on the right track, but if we're going to suggest changing infoboxes project-wide, the design should be a bit more mature to have a good impact. —Michael Z. 2009-02-02 16:50 z

It looks great. Work out any bugs and deploy it gradually to infobox templates. --Apoc2400 (talk) 22:33, 2 February 2009 (UTC)

Commercial photography permit requirements and free content licenses

If a photographer releases a photograph under the GFDL or a similar free content license, it is possible for others to reuse the photograph in a commercial manner. Assume that the photographer does not mind this. At the same time, however, some locations require permits for commercial photography. For instance, there is information about certain categories of photography in California state parks. In the case of the film permit policy for the city of Hermosa Beach in California, it appears that the permit requirements even apply to private property.

If photography permit restrictions apply to photographers when releasing photographs under a free content license, it might be useful to document this as advice for photographers. (Users of photographs would probably not be affected.) In particular, it might be useful to identify locations where commercial photography permits are not required or where such permits are compatible with free content licenses (assuming that such locations exist.) Should this be discussed in the Wikipedia image use policy section? - Elegie (talk) 06:06, 2 February 2009 (UTC)

• You can make an essay about it. We don't have policies saying "don't run over a bussload of nuns on the way to write an article". I don't want to be glib and I understand that you are making a much more nuanced point. I just want to note that we want to keep wikipedia policies about conduct here. Protonk (talk) 15:23, 2 February 2009 (UTC)
• As a general principle, pictures taken illegally still belong to the photographer and may still be released under a free license by them. This kind of advice may be useful to contributors (right along with "don't trespass" and "don't break museum rules") but it's also largely not our problem. Dcoetzee 20:25, 2 February 2009 (UTC)

Are you a lawyer? I'm not. However, regarding that last "principal" stated above, I suspect that the owner of a work of art does not loose control of their rights just because someone take an illegal or unauthorized photograph of that object. If the owner of the artwork claimed copyright violation on a GFDL photograph of that art, would Wikipedia be obligated to remove the photograph? Can the photographer grant rights that are not his/hers to grant? -- Tcncv (talk) 00:41, 3 February 2009 (UTC)

I'm not a lawyer, but I'm a Commons admin and I've dealt with a lot of image policy on the project. A photograph of an artwork or sculpture is generally considered a derivative work and the photographer does not solely possess copyright on it, so they cannot release it, as you say. However, the case raised by Elegie is the case where a person takes commercial photographs without a permit; but where the photos are not derivative works (say photos of state parks). In this case the photographer may have committed a crime by taking the photo, but still is the sole copyright holder; conversely, you can (and many people do) take a photo of a copyrighted work without committing any crime, but you would not be the sole copyright holder. Dcoetzee 00:49, 3 February 2009 (UTC)

Understand. I misinterpreted your earlier remarks. Thanks for the clarification. -- Tcncv (talk) 07:41, 3 February 2009 (UTC)

Apologies for being unclear, I see why I was misinterpreted. :-) Dcoetzee 20:29, 3 February 2009 (UTC)

New Citation tool?

Hello,

I was just wondering if there was any tool existing/in the works for an easier creation of citation sources - the existing system a) is a great dissuasion to going through all the trouble to correctly find/format citations and b) makes the editing of articles into a real headache (sorting out where a reference tag ends and the text continues/begins).

I've sketched out an ajax/javascript idea that would a) open an ajax DHTML layer "form" (indicating the info to be entered) upon a selection from a right-click menu at desired point of insertion, and b), in the text-editing window, "compact" any citation tags in existing text to better facilitate the editing of the content-text body.

Has this already been done? Cheers. THEPROMENADER 09:03, 2 February 2009 (UTC)

You might want to have a look at refTools, which can be enabled in your Gadgets (Special:Preferences, Gadget Tab, Editing gadgets section). -- lucasbfr ^talk 10:11, 2 February 2009 (UTC)

I'll second this. I like reftools a lot. If you talk to User:Mr.Z-man you can probably convince him to collaborate with you on improving it. Protonk (talk) 15:43, 2 February 2009 (UTC)

Thanks, guys. Could you make this a ~tad~ more available to new users? Cheers. THEPROMENADER 20:00, 4 February 2009 (UTC)

Another Proposal regarding "moving pages"

Recent events show certain users abuse this feature. In a similar fashion to the number of rollbacks a non-admin users can perform per minute, I propose limiting the number of page moves done by autoconfirmed users to 1 per minute. This has the benefit that ligitamate users can still move pages ,allbeit more slowly, without the need to be penalized. --DFS454 (talk) 18:37, 2 February 2009 (UTC)

I agree with DFS454 here. It would stop Grawp in his tracks if he is throttled... for a while anyways, at least until he manages to get a bunch of socks to bypass it. But even then, he can only do so much with those accounts. UntilItSleeps PublicPC 20:17, 2 February 2009 (UTC)

What technical capacity exists within the revision of mediawiki employed currently here to do this? I know admins are free from "rate limits" but I was under the impression that we don't actually have rate limits enabled anyway. Protonk (talk) 22:43, 2 February 2009 (UTC)

We didn't do this for Willy on Wheels back in the day and I don't see a reason to do it for Grawp. Page-move vandals move pages because they know it's more disruptive, but sometimes legitimate users do need to move large numbers of pages; for example, when naming conventions change, which may be happening right now with regard to plants. Dcoetzee 22:50, 2 February 2009 (UTC)

Maybe have it throttled for non-rollbackers? JoshuaZ (talk) 22:55, 2 February 2009 (UTC)

But that isn't what rollback is for. I could see devolving the right to users like rollback, but that is always a contentious issue. I'm not against placing technical limitations on the wiki for the purposes of restraining vandalsim, but I think we need to know what is within our capacity and what we intend to do. For instance, what is the average page move/mintute for editors working at RM? At NPP? How is that distributed? Could we get a guestimation of some threshold which would restrain only 5% of those editors? 1%? do we have that data? Protonk (talk) 23:09, 2 February 2009 (UTC)

Decentralizing the Arbitration Committee

For anyone interested, I have proposed we decentralize the Arbitration Committee. Tim Q. Wells (talk) 23:34, 2 February 2009 (UTC)

A better way to treat certain redirects

Today I found these two redirect pages redirecting to two DIFFERENT articles:

• Social constructivism (learning theory)
• Social Constructivism (Learning Theory)

That should not happen and I fixed it. I've seen this situation maybe a couple of dozen times. In particular, I found these three redirecting to three DIFFERENT articles:

• Riemann–Hilbert problem (singular, with ndash)
• Riemann–Hilbert problems (plural, with ndash)
• Riemann-Hilbert problem (singular, with hyphen instead of ndash)

A bot cannot decide what pages things like this ought to redirect to, if any, but I would think a bot could be constructed to

• find things like this;
• make a list of them so that Wikipedians can go down the list and find those within their competence and fix them;
• possibly call them to the attention of the appropriate WikiProjects based on the target articles' category tags.

I know nothing about writing bots. So (1) Can this be done?; (2) Should it be done?; (3) Are there persons skilled in writing bots whom we should enlist to work on this? Michael Hardy (talk) 01:29, 3 February 2009 (UTC)

In theory a bot could do this. As a bonus, if the bot didn't make any edits or put a major strain on the server, it wouldn't need approval. A few reads a minute wouldn't be a strain, but a few a second probably would be. I would still recommend announcing such a read-only bot to BAG if it's going to read more than a few hundred articles an hour, as a courtesy. Now, if such a bot were to make any edits, then it would need approval. davidwr/(talk)/(contribs)/(e-mail) 04:35, 3 February 2009 (UTC)

It could probably be done even more efficiently using a database dump, you should ask there :). -- lucasbfr ^talk 10:57, 3 February 2009 (UTC)

I don't know what you mean by "there". WHERE are you saying one should ask? Michael Hardy (talk) 17:29, 4 February 2009 (UTC)

I meant the Bot Approvals Group (to be precise, Wikipedia:Bot requests), that's where the cool bot coders hang out ;) -- lucasbfr ^talk 17:35, 4 February 2009 (UTC)

I'd never have guessed that that's what you meant. I asked my question numbered (3) for a reason! Michael Hardy (talk) 18:30, 4 February 2009 (UTC)

Yes. Absolutely. I've noticed this problem before. Having a bot deal list them all would be a good thing. Once we had a list people could just go through the conflicts and resolve them as necessary. JoshuaZ (talk) 17:50, 4 February 2009 (UTC)

Display the count by Mediawiki software of the number of times a page has been visited

Let me start by saying that I know such a count is considered, by web purists, to be pointless, a vanity and a frippery. Nonetheless it is there as a default in MW software, and WP has chosen to either de-implement it, or not to display it.

This may have been discussed before, may have been discussed often, and consensus may have been reached back then. If so I feel it is time for a new consensus to be formed, whether for or against the proposal. We should bring fresh eyes, fresh views and fresh editors to form the consensus, though by no means ask prior participants not to participate.

So what is the proposal?

To unleash the field on each page that shows the number of times that the page has been visited.

So, is this important?

Not at all. It's trivial. It's like eating a comforting and familiar meal on a day you are cold or depressed. It shows, no more and no less, that a page gets visits, EVEN if they bounce away at once.

Could it be abused?

It could. Editors could argue that "This page has only been visited 53 times, and so is worthy of deletion because it is unpopular."

So, if we do show page visit counts we have to outlaw that as a pro deletion argument. We also have to outlaw the counter argument for keeping articles based on popularity. It may be interesting to see a page about a Polished turd but that page is, of itself, not encyclopaedic (I pray that to be the case!), nor is the knowledge that one cannot be polished, and any popularity should not deter us form deletion.

So why do I want it?

I like encouragement. I like to see if a page I worked on or created has actually been visited by people who are not me! I've created obscure and arcane pages in the past and will in the future. I want to see if I am the only lunatic, to see if the pages have an apparent use to someone else. I see it as part of the stroking that all editors, new and old, need in oder to feel a part of this great enterprise.

What does it cost?

I would need a Mediawiki engineer to double check, but I would say that it costs nothing. I believe that this field is already maintained in the database and simply displaying this extra data item has zero cost in server horsepower. There is the cost of serving those extra characters in bandwidth every time a page is served, but we have so little control over serving other stuff which may be good or unmitigated trash anyway, that I argue that this counts for nothing.

Can I summarise?

I can. I believe we should display the individual page visit count as an encouragement to editors to see that their work has been valued by others. I feel it will have zero cost impact, that abuses must be legislated against, and that it can only bring benefits to the project as a whole. Ladies and gentlemen, let us form a consensus. Fiddle Faddle (talk) 12:24, 3 February 2009 (UTC)

Technical background information

See Wikipedia:FAQ#Are page hit counters available?. --—— Gadget850 (Ed) ^talk - 12:35, 3 February 2009 (UTC)

I have read it and followed its full extent. It does not discourage me from making this proposal but is useful extra information. Fiddle Faddle (talk) 13:52, 3 February 2009 (UTC)

grok.se is nice, but uses manual extracts from the logs and is lagging "a bit". Wikirage works nicely too. -- lucasbfr ^talk 13:43, 3 February 2009 (UTC)

They are both fine, but each requires that one knows about it. A new editor will not. I've been aprund a while and I had no idea either. Fiddle Faddle (talk) 13:52, 3 February 2009 (UTC)

I agree with you on that. However it costs way too much to implement on our side. If you're interested in statistics, we keep Wikipedia:Statistics up to date with working third parties websites and tools. -- lucasbfr ^talk 14:10, 3 February 2009 (UTC)

You really need to make your case to the developers. They are the ones who have to deal with performance issues. Given the state of the job queue, anything that slows down the servers right now is not going to fly. --—— Gadget850 (Ed) ^talk - 14:31, 3 February 2009 (UTC)

A case to the developers made with no consensus will quite reasonably be ignored. There is no point in making such a case without the community desiring it. Thus I am here, making a proposal. Fiddle Faddle (talk) 14:38, 3 February 2009 (UTC)

Whereas the value of this feature is low (but not negligible), it should have a correspondingly low priority. Unless the cost, in server resources, for either updating the statistics or updating those statistics on each page, is similarly low, it is not worth implementing. Given that, at the moment, the job queue size is very large, it seems that the value of server resources is high. Until such time as we have an excess of server resources (which is unlikely to happen soon), I don't think that this feature is worthwhile. {{Nihiltres|talk|log}} 15:43, 3 February 2009 (UTC)

the Job Queue accessed from the stats page is an incompetently designed concept by the Mediawiki engineers. It ought to process the queue at periods of low load, balancing the system's overall load. Instead it requires high user page access or edit load to trigger jobs being processed from the queue. This is bizarre, counter intuitive, and documented in some page or other within the Mediawiki documentation. No reliance can be placed upon the length of the job queue to measure anything much except design and implementation incompetence, I'm afraid. All the job queue does is makes a server load problem worse. Go figure. Fiddle Faddle (talk) 17:46, 3 February 2009 (UTC)

See m:Wikimedia servers for the overall site architecture. The Apache servers running MediaWiki are front-ended with an array of Squid caches. Each Squid cache machine handles the load of 4 or 5 Apache servers, and roughly 3/4 of all "hits" never reach an Apache server. Using the MediaWiki feature would require disabling the Squid caches, which would require adding 200-300 servers to handle the current load. This would be distinctly not free. -- Rick Block (talk) 15:56, 3 February 2009 (UTC)

You know this is funny. So far I think everyone's come in with technical stuff. I'm impressed that you all know so much, but what do youfeel? What do you want?

Or are we too much in awe of technology?

This is a real simple thing. We form a consensus of desire, pro or anti. What I want myself doesn't matter much because I'm one guy. I have one opinion, but we matter and what we want matters. If the consensus is pro then we ask "Please will you give us this feature?" Then we wait for the reply.

If we like the reply we are pleased. If we dislike it then we argue again for it.

Surely what we don;t do is to second guess everything because we happen to be technically literate. That isn't consensus building. It's interesting information about the status quo and does nothing about any changes.

So how about shuffling the techno-speak into a "technical background" zone and putting the consensus building into another part? Fiddle Faddle (talk) 17:39, 3 February 2009 (UTC)

You're not listening. People have said what they "feel", they feel that even their limited knowledge of the site architecture tells them that This Is Not Possible. They feel that stats.grok.se is an adequate replacement for what even you have said is a "trivial" feature. We are "building a consensus", it appears, that we don't want this feature enough to waste time pondering how to overcome the enormous technical hurdle that is involved, or to assemble a strong enough argument (not that that is really possible) to convince the developers to do likewise. I oppose this proposal for reasons other than its technical impossibility, but that is unimportant in comparison: I know when there is absolutely no point in pursuing an idea, and I suspect others do likewise. I'm not trying to put you down, it's a sensible idea and the right way to go about raising it, but the consensus that we're forming is that it is technically impossible. We're not sheep, we don't need the devs to tell us that. Happy‑melon 18:17, 3 February 2009 (UTC)

And what if their understanding is imperfect? Form a consensus of desire and then ask those who manage the systems about it. They are the people who know. They are the paid servants of the foundation. Please don't tell me I'm not listening. I find that offensive. Fiddle Faddle (talk) 19:02, 3 February 2009 (UTC)

What Rick Block said is absolutely correct. It is your understanding that is imperfect. The built-in hit counter system is not only hidden, its disabled entirely. It doesn't work with Wikimedia's squid caching layer, and as it adds an extra database query on every page view (every view that isn't served entirely by the squids), is an unacceptable performance hit. Mr.Z-man 19:41, 3 February 2009 (UTC)

I do not need to understand this to make a valid proposal. It doesn't matter to me whether anyone is correct here about the system as it works today. Nor should it matter to anyone. What matters is not how the current system works. What matters is how, if we choose, we wish it to work in the future. A good piece of systems analysis can find a solution to any issue, if the solution is desired by the community. Wikipedia must move forward, not be hamstrung by peole assuming that things cannot be done.

I don't need to be technically right or wrong. I'm sure it's amusing to see that I am a techno-turkey, but I always have been. I don't mind if you tell me so. I'm used to it. But I also refuse to trip over the hurdle of "it's not possible". So did The Wright Brothers. The answer is that things can be made to be possible if they are desired enough. We do not decide what is technically possible. The Foundation does that. We decide what we woudl like. Fiddle Faddle (talk) 19:49, 3 February 2009 (UTC)

My point was only that the claim "that it costs nothing" (because it's a feature of the MediaWiki software) is incorrect. Anyone thinking they want this should understand however it would be done it wouldn't be even particularly close to free. There may be some way to approximate this feature, but to characterize it as "free" is grossly misleading. My personal opinion about this is that given the number of urgently pressing issues facing the meager development staff, even if there were a broad consensus that this was desirable (which there doesn't seem to be) I wouldn't want them to spend any time even seriously thinking about it. -- Rick Block (talk) 02:23, 4 February 2009 (UTC)

This is impractical as a realtime goal, but there is no reason that a page views field couldn't be updated from the stats.grok.se logs periodically (e.g. once a day). Again, as a practical exercise, one should probably only rerender such information at times when the other page content changes (rather than forcing all pages to be recached when pageviews is updated). Subject to those caveats about information being semi-static, and delayed upto a day or more, one could choose to add a page views field using the present architecture, if one wanted to. Dragons flight (talk) 19:23, 3 February 2009 (UTC)

No argument with that approach. Let's decide on the desirability and then those closest to the technical issues can decide upon any potential implementation, if the community wishes to have it. Fiddle Faddle (talk) 19:27, 3 February 2009 (UTC)

This could be done directly since grok simply uses the squid logs (I don't know how the other sites work). However I still don't think this is useful (only pageviews since the beginning could be interesting, and we don't have them). I think having an entire tool devoted to it (grok, or wikirage, or any other one) is more practical and useful. -- lucasbfr ^talk 20:33, 3 February 2009 (UTC)

Consensus for or against the proposal

• Personally I find this feature insignificant and wouldn't want to enable it even if it were technically free; the reason is because it's not total hit count on an article that's really interesting, but more the trend over time, which is too complex to show at the page footer. There's a reason so few webpages have hit counters. What I think is a lot more useful is an on-wiki list of "most visited articles." Dcoetzee 20:36, 3 February 2009 (UTC)

  You mean like Wikipedia:Popular pages?  ;-) Dragons flight (talk) 21:10, 3 February 2009 (UTC)

• As the original proposer notes, this is indeed "pointless, a vanity and a frippery." Even if it only costs a vanishingly small amount of bandwidth or server horsepower, we've got better things to do with our resources. TenOfAllTrades(talk) 04:38, 4 February 2009 (UTC)

Add apihighlimits right to rollbacker group

The 'apihighlimits' user right allows API queries to be made in larger chunks. All administrators and bots have it, though I daresay many of them don't know that they do. I assume it is not given to all users in case it gets overused.

I don't see anything to suggest it can't be given to other user groups. It doesn't seem to be something that is worth forcing people through adminship requests to get, any user that operates a bot accout has access to it regardless of what that bot account is intended for, and indeed anyone who does want it merely has to think up some random bot task and get approved for it, and its use is not logged so nobody here knows or cares what queries are made.

Certain queries would benefit very much from being made in larger chunks. For example, getting a list of all biographies of living people. This is something that would be rather useful to integrate into patrolling processes, but currently is some hassle to do, takes rather a long time. Giving the apihighlimits right to the rollbacker group would do more or less nothing as most people don't know what it is or how to use it, but it would make these queries easier. By 'queries' here I am talking about only a small number in any case.

Does anyone have objections to this? -- Gurch (talk) 17:30, 3 February 2009 (UTC)

If we do that, change the name of the group to "trusted users" or "established users" - users who have no additional actual rights, but who can do things faster or more efficiently than those who aren't. davidwr/(talk)/(contribs)/(e-mail) 18:17, 3 February 2009 (UTC)

You and I both know that isn't going to happen; there are plenty of "trusted" and "established" users without the rollbacker right. The administrator group wasn't renamed when given this, nor was it renamed when given ipblock-exempt, proxyunbannable, autopatrol, tb-override, ub-override, override-antispoof, reupload, centralnotice-translate or any of the other user rights that nobody knows or cares about -- Gurch (talk) 18:24, 3 February 2009 (UTC)

Personally, I'd like to see 2 levels of autoconfirmed, with override-bits for both. The first would act as the current one does, the second, "more experience required" one would give a bunch of other "efficient editing" rights including rollbacker and the things talked about here. Both would have "override-bits" like "autoconfirmed-always" and "autoconfirmed-never" that administrators could set if needed. For example, users of 2 legitimate sockpuppet accounts could request the same experience-based rights as the main account, and those who demonstrated abuse or simple incompetence with efficiency tools could have those rights turned off. As new "efficiency rights" were made available, they could just be added to one or both of these automatic levels. As a straw number, I'd say this higher level should be given to anyone with at least 150 edits in the last 3 months and at least 500 edits and 3 months total experience, or, for editors who edit lightly, anyone with at least 1 year and at least 1000 edits total and at least 10 edits in the last month. Those are straw numbers and I'm not married to them. davidwr/(talk)/(contribs)/(e-mail) 19:40, 3 February 2009 (UTC)

Fair enough, but what does that have to do with apihighlimits? As I said, virtually nobody knows what it is, what it does or how to use it; nobody in the rollbacker group would actually be making their own queries with it or even knowing that they had it -- Gurch (talk) 20:00, 3 February 2009 (UTC)

It doesn't really. Such niche rights should probably be handed out on request but only only request, and only if the person can explain what the right is and how he would use it. davidwr/(talk)/(contribs)/(e-mail) 20:28, 3 February 2009 (UTC)

Then that makes it pretty useless; the average Huggle user probably wouldn't be able to explain what rollback was and how they used it, let alone this -- Gurch (talk) 20:30, 3 February 2009 (UTC)

Much as I hate to be 'that guy', and much as I would hate to be opening a can of beans, I have to ask. What is the worst case scenario if we give this to some people who shouldn't have it? Would a malicious user be able to bring our servers to their knees, or not? Presumably this limit was imposed in the first place for some reason; what is that reason, and does that reason still exist? TenOfAllTrades(talk) 04:35, 4 February 2009 (UTC)

They were imposed to prevent DoS attacks. Ruslik (talk) 11:05, 4 February 2009 (UTC)

All administrators and bot accounts have it, and nothing has gone wrong yet. Running time isn't much of an issue with queries (a few days ago some API queries got completely stuck running for ever and nobody noticed for ages); conventional denial-of-service attacks come about by making a very large number of requests from many different sources simultaneously (often using a network of compromised computers), something that's possible without logging in at all -- but also not much of a threat (or more likely, nobody with the ability to do so gives a damn about Wikimedia) else we'd have already heard about it -- Gurch (talk) 12:01, 4 February 2009 (UTC)

I really can't bring myself to actually care about the practicalities of giving the apihighlimits permission to group X, as it's probably the most utterly trivial of all the permissions we have available. However, I do care very much about the principle of giving permissions to the 'rollbacker' group other than rollback. We really do need to make our bloody minds up: is the rollbacker group a purely technical permission akin to 'ipblock-exempt' or 'accountcreator', or does it have accepted (if unacknowledged) connotations of 'trust' akin to 'sysop' and 'bureaucrat'?? If the former is the case, then it should under no circumstances be given any additional permissions that are not inextricably linked to rollback such that neither can be effectively employed without the other (there are few such pairs of permissions, the most obvious example is delete and undelete). If the latter is the case, we need to recognise that elephant and think seriously about why we're still calling it "rollbacker". Happy‑melon 12:17, 4 February 2009 (UTC)

I don't quite follow you. The whole point of having separate concepts of rights and groups is so that rights don't have to be given out individually. The idea of tying every user right to a separate group and then insisting people get approved to use every one of them individually seems silly. Adding a user to the "bot" group also gives them autoconfirmed, autopatrol, suppressredirect, nominornewtalk, skipcaptcha, apihighlimits and writeapi, but nobody goes on about how it shouldn't be called "bot" then -- Gurch (talk) 12:20, 4 February 2009 (UTC)

The 'bot' group was created for the purpose of containing bots. As such, it has a bunch of rights which it is appropriate for bots to have. The 'rollbacker' group, on the other hand, was created for the purpose of giving users the rollback right. If it is to be used for some other purpose, then its new purpose should be discussed properly (and the group should probably be renamed, as Happy-melon suggests). Algebraist 12:41, 4 February 2009 (UTC)

But it isn't to be used for any other purpose. All users have API access, so that is not new. The only difference being that some queries that would have to be done if people are going to have what they are demanding re. patrolling would actually be feasible --Gurch (talk) 14:23, 4 February 2009 (UTC)

That's exactly my point, Algebraist. I don't disagree, Gurcy, we separate groups and permissions for exactly that reason. We have a group called 'bot', which is given to "bots". What is a "bot"? It's an automated program that performs maintenance tasks; in order to do that effectively it requires a number of permissions, which you've listed. We also have a group called 'rollbacker'. My question is, what is a "rollbacker"?? Is it "an account that can use the rollback feature"? If so, then it should not be given any other permissions; users do not require apihighlimits in order to rollback. On the other hand, is a "rollbacker" "an account that is trusted to a certain degree, enough to be given permissions that are useful and not overly dangerous"?? If so, then assigning apihighlimits is entirely appropriate, but we should stop pretending that the situation is any different, and rename that group to "trusted" or similar (I dislike that exact term as much as the next user, but I haven't ever heard any better names). Hope this clarifies. Happy‑melon 18:37, 4 February 2009 (UTC)

If you look at all the current WP functionaries, vandal, IPuser, user, admin, CheckUser, Oversight, OTRS volunteer, bureaucrat, steward, it makes more sense to pick a name like trusted (or trustee), than a name like "rollbacker". Apteva (talk) 20:01, 4 February 2009 (UTC)

Article gallery

As well as the "Article", "Discussion" etc. tabs at the top of the article, why not a Gallery tab? There could be a facebook-style album of all pictures related to the article but which didn't make it onto the article's front page. There are many articles which are criticised as having too many pictures, yet all of them are as useful as each other. For example, an article on a country could have a gallery full of policial, geographical and population maps, pictures on notable landmarks, pictures of historic events, etc. What do you guys think? Autonova (talk) 12:33, 4 February 2009 (UTC)

You can effectively do this today with free images by creating a gallery on the Wikipedia commons then putting a link to it in the "See Also" section. You can't do this with non-free images, and you probably shouldn't try for a variety of reasons. davidwr/(talk)/(contribs)/(e-mail) 16:00, 4 February 2009 (UTC)

WP:NOMORE proposal is being redirected to WP:CREEP without wide consensus

Please consider giving your opinion at the discussion here. Latest non-redirect version of the page is here. Thanks. 212.200.240.241 (talk) 13:46, 4 February 2009 (UTC)

Since there were no grounds for redirecting the page without a deletion discussion, I've reverted it. Equazcion •✗/C • 14:32, 4 Feb 2009 (UTC)

A couple of editors, and perhaps more, continue to edit war, after Equazcion's last coment, to delete / redirect the (now) essay, claiming a consensus to do so. Frankly, I don't see where they are coming from. I don't really see the point of the page either, but some people seem to be working on it and there would have to be a very strong reason to want to delete a policy proposal people are still drafting. I've restored it one time but don't want to end up in an edit war... normally I would suggest the page be protected but that seems to defeat the purpose of letting people work on proposals if they wish. Wikidemon (talk) 17:48, 4 February 2009 (UTC)

The people working on it are mostly the same person, and the person who originally wrote the essay. The consensus on the talk page there was to redirect. Thanks. Verbal chat 18:04, 4 February 2009 (UTC)

Watchlisted. –xeno (talk) 18:05, 4 February 2009 (UTC)

Why don't they just move or copy it to a sandbox and come back when it's ready for prime time (which, at the risk of sounding too harsh, may be never)? Also, if as they say it is a proposal for augmenting CREEP, when they are ready to propose something it would seem to make the most sense to add a sentence or a brief section to CREEP about the hurdle that a new proposal should overcome before it gets added to a policy or guideline page, which is itself....CREEP. Wikidemon (talk) 18:27, 4 February 2009 (UTC)

I'd have to agree that userfication seems to be the path of least resistance. –xeno (talk) 18:32, 4 February 2009 (UTC)

I agree with that. There is an ANI discussion about this editors account and IP hopping. Thanks, Verbal chat 21:34, 4 February 2009 (UTC)