Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by CWii (talk | contribs) at 20:31, 5 April 2008 (→‎Oppose). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
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.


Black version

I find it frustrating that wikipedia uses black text on a bright, white background, since this effectively turns the computer screen into a bright light. After a while this reading text like this becomes unpleasant, and could even have negative effects on vision. A webpage is not a sheet of paper, as much as we might want it to look like one. Would it be possible to add a feature allowing users to switch the colour scheme to white text on a black background, if they preferred, since this would solve the problem?

On the "Gadgets" tab of "my preferences", you'll find an option for green text on black (this doesn't apply to IP editors, only to registered editors). It that doesn't meet your needs, you might track down whoever wrote the gadget and ask for a white on black version for your personal use.
Also, please put new sections at the bottom of the page; clicking on the "+" tab will automatically take care of that. And sign each new section, please. -- John Broughton (♫♫) 17:57, 29 March 2008 (UTC)[reply]

>"this effectively turns the computer screen into a bright light"

Amen! It probably stems from the duh-fault background in Windows being the very brightest white possible. The masses may accept it as "normal" and "right" because Windows does it. And Wikipedia is providing what the masses have been conditioned to expect as a "normal" background color – even if it blinds them.
I suspect that you may be right about bright backgrounds having negative effects on vision. Maybe Redmond will become a center for vision products after software sales cool.
My solution:
  • Use Opera for my browser
  • Specify my own background color
  • Don't let it use the style sheet provided with the web page. Too many web designers specify a bright white background in their style sheets.
Opera has a one-click toggle to enable/disable style sheets quickly. Some pages are botched so badly that navigation is severely impaired without letting the style sheet do its thing – which too often involves putting everything on a glaring background.
Most of the time, Opera allows me to browse in much more comfort than many webmasters think about providing. Too many don't think about it. They adopted the blinding-is-good mentality without questioning it. If they never bothered to change the color scheme on their computer away from the duh-fault Windows colors, they may be oblivious to the notion that some other colors might work better for a web page.
It might not occur to them that they don't _have_ to specify a color scheme in their web page. How novel to allow a visitor to use their own color scheme on their _personal_ computer! -Ac44ck (talk) 22:54, 2 April 2008 (UTC)[reply]
I agree that a dark theme would be a nice option, but as for "The masses may accept it as 'normal' and 'right' because Windows does it", it's probably a bit more likely that people accept it because paper is traditionally light with dark text. You tend to not see many books with white text printed on black pages. It goes back to parchment and ink; parchment is naturally white-colored (almost), so black ink had to be invented to make marks on it. There are many things we can blame Microsoft for, but white backgrounds probably isn't one of them. Equazcion •✗/C • 23:02, 2 Apr 2008 (UTC)

Multiple watchlists

For organizational purposes, it would be nice to be able to maintain more than one watchlist. I've been cleaning up my watchlist every couple months but I usually end up deleting things I actually want to keep, just to get the list cut down to a more manageable size. I'm tempted to maintain an external text file or something so I can move chunks of listings in and out of the raw watchlist editor depending on what I want to look at, but would it really be so difficult for the wiki have that kind of functionality already built-in? I can't see it being an additional resource hog. Equazcion •✗/C • 15:23, 12 Mar 2008 (UTC)

See m:Help:Watching pages#Related changes feature for "additional watchlists". Although they do have some drawbacks: such a list is not private, you have to explicitly put links to talk pages, there are less options to filter the changes. —AlexSm 15:30, 12 March 2008 (UTC)[reply]
Thanks, that is helpful. However, still, I think multiple watchlists for each user is a good idea. It would offer a lot of convenience and benefit for very little performance cost, if any at all. Equazcion •✗/C • 15:38, 12 Mar 2008 (UTC)
I was going to propose something like this! I suggest that each item on a watchlist have a "flag" or parameter which could be a bit, an integer or a short piece of text which the user associates with the item.
Suppose you're going to be really busy for a few weeks. Then you want only the few articles most important to you to show on your watchlist during that time. But then afterwards, when you have some time and want to see what's happening in the general areas you're interested in, currently you have to start from scratch rebuilding your watchlist. Under my proposal, you'd only have to click one setting, "show all items" or "show all items with priority level of 5 or fewer" etc. If it's a text parameter, you could click "show all items that I've tagged with "medicine" etc. depending on what your interests are at the moment. You could also label things as "watchlisted during RC patrol" or "watchlisted when I posted a message there" so you'd know why the heck things are on your watchlist. It might also be useful if the date the item was placed on your watchlist could be (optionally) displayed. --Coppertwig (talk) 01:23, 14 March 2008 (UTC)[reply]
Yeah, similar solution, probably even better since you'd be able to see all "watchlists" at once if you chose to, but also be able to filter based on user-defined tags. I actually like that better. Equazcion •✗/C • 01:28, 14 Mar 2008 (UTC)
I like that, too. However, I think I ought to mention an already existing tool: the ability to monitor changes in all the pages that link to a specific page. John Carter gave me the idea, and applied it on SBS's Templates page; all changes made on pages linked to from that page can be seen in a list accessible from a box in SBS's main page. I can tell you, it helped me clear my watchlist a long way. One can create a subpage in one's userspace with all the pages one is interested in watching; one may categorise its contents as one wishes (with headings and sections) and has the ability to hide links (or, indeed, entire groups of links) whenever one wishes by turning them into HTML comments. This tool, which I have only recently learnt about, has many potentials in my opinion. Waltham, The Duke of 20:33, 14 March 2008 (UTC)[reply]
Yeah that's the related changes feature, see the first response to the original post above. It's a good temporary solution but the watchlist is so much more functional, easier to use and read. I think it should be expanded to include this functionality. Equazcion •✗/C • 12:30, 16 Mar 2008 (UTC)
I guess I missed that. Yes, I quite agree, it is a good provisional solution, but it definitely won't cover all of our needs. Waltham, The Duke of 17:50, 20 March 2008 (UTC)[reply]
I really like this idea. I have articles on my watchlist that I'm actively editing, but others that I just want to monitor because they've been subject to vandalism before. To have different watchlists for the different reasons you watch an article just makes sense. But in lieu of multiple watchlists, I like Coppertwig's tags idea. Elle (talk) 00:00, 25 March 2008 (UTC)[reply]
Add me to the list of people who would find this really useful.Doug Weller (talk) 13:46, 31 March 2008 (UTC)[reply]

Reducing barriers to entry

I've been talking to non-Wikipedians about their experiences with the project for a while, and have published some IM interviews in my user space. I intend to do more, and I highly recommend talking to your non-Wikipedian friends in the same way. Another way to observe is to read the questions people are asking about Wikipedia (and the awful answers they receive) in the Yahoo Answers! Wikipedia section.

I think we have some really major issues with outsider perception of the project. I'd guess that the majority of people visiting our site from a Google search have not a clue as to how the site works or that they can contribute to it. This is bad because it fuels the endless criticism we receive, and because it prevents these people from becoming contributors. Fixing these misperceptions and reducing barriers to entry should be one of our first priorities, and I don't think it's really even that difficult. Wikinews seems to be better at all of this than we are. Some ideas:

  1. On Article pages, you usually click "edit this page" to edit the entire page, or click the section edit links. But on Talk pages, you rarely edit the entire page at once. You're either adding a new section or editing a pre-existing section. For this reason, the new section link (currently identified with a completely inconspicuous "+" sign) should be made more prominent, by changing the button to "add comment" or "new section" or something along those lines, and the "edit this page" link should be made less prominent, maybe just saying "edit". I have tried to implement this in the past, and others have implemented it on other wikis, but some people are really resistant to any change to the interface. I don't understand why.
  2. In the corner of every article should be a short notice to the effect of "See a problem with the article? Fix it yourself or leave a comment". Obviously this could be worded better, but the idea is that clicking "fix it yourself" would be just like clicking "edit", except that there would be a "newcomer box" above the edit box explaining the basics of how the site works and how to edit and find more help. Clicking "leave a comment" would go directly to the "new section" screen for that article's talk page, again with a "newcomer box" above it. You would just be presented with a blank box to fill in with the text of your comment, press save, and go on your way. This way when someone sees an error, we can at least get notified about it, instead of them pressing "edit", being overwhelmed by wikicode, and giving up. I'd say we should even go as far as removing the need to enter four tildes if you're editing from this link. Your signature would just be added automatically after the comment (and would show up in the preview screen).
  3. Check out Talk:Elephant, and try to see it from a newcomer's perspective. That's a lot of yellow boxes, no? I think we should greatly reduce the prominence of most of the templates (especially the pointless WikiProject ones). I also wonder why the {{talkheader}} box is not at the top of every talk page. I predict some people will complain about it being annoying when you already know about editing. But this a situation where you make the default behavior cater to newcomers, and let the experienced editors hide it with javascript or css. At the least, we could always display it for unregistered users.
  4. I've tried to change the tagline to more clearly spell out the way the project works (linking "free" to free content, since you know everyone visiting thinks it just means "free of charge", and adding "that anyone can edit" at the end, for instance). We even had some support from Jimbo, but it ultimately went nowhere. There is apparently no shortage of Wikipedians willing to resist change. I'd like to renew this campaign again someday, but I haven't found the energy.
  5. Always endeavor to reduce complexity of code and interfaces, instead of adding more and more features without thinking about how it complicates the user experience. Ideally, the code would have very little special syntax in it, like the good old days, and all the boxes and categories and tables and interwikis and so on would be added, not withcode, but with real "Web 2.0" interactive tools like Flickr's tagger. This isn't something that can be implemented in a day like the others, but something to always keep in the back of your minds.

Please discuss. — Omegatron 06:08, 16 March 2008 (UTC)[reply]

Support in principle. Just today, I ran into a newcomer who couldn't figure out how to add a new comment (as opposed to adding to an existing comment) to another user's talk page. Sbowers3 (talk) 15:17, 16 March 2008 (UTC)[reply]
Great ideas, all of them!
One little addition: when someone adds a comment via the "leave a comment" box, there could be some little symbol or quirk or "This message was added via leave a comment box" or something added to it so that established users will know that it's been added via that box. Some established users might want to regularly use that box, but it would help if such messages are marked so that people can be aware that it might be from a new user. (Not that new users should be treated any differently than established users, or vice versa ...) --Coppertwig (talk) 18:24, 16 March 2008 (UTC)[reply]
Good idea. Only for the link from the article, though, not from the regular new section link. — Omegatron 21:32, 16 March 2008 (UTC)[reply]
  • I think that a modest learning curve on the mechanics is a nice barrier. If someone is not bright enough to figure out our simple processes or ask for help, I'd question the competence of the contributions. I think that our barriers are too low as it is. --Kevin Murray (talk) 21:17, 16 March 2008 (UTC)[reply]
    • The mechanics of this place are so simple that the editor's index has more than 2500 entries. And I think you're confusing process learning with content learning - there are a lot of people who are very knowledgeable about a topic but don't want to have to spend their (limited) time learning yet another set of processes and procedures. -- John Broughton (♫♫) 21:42, 16 March 2008 (UTC)[reply]
  • It's worth adding that the editors index largely consists of Wikipedia bureaucracy and policies with much of it being unavoidable on a project of this size. -Halo (talk) 02:12, 17 March 2008 (UTC)[reply]
Eh? I use just 3 key best practices most of the time, and get by just fine. ^^;; --Kim Bruning (talk) 05:03, 18 March 2008 (UTC)[reply]
I'm sure it helps that you've been around long enough to know what the real, unwritten, policies are. --Carnildo (talk) 07:31, 18 March 2008 (UTC)[reply]
A stinging indictment. :-( I've been trying to document what I know for some time now. --Kim Bruning (talk) 17:44, 19 March 2008 (UTC)[reply]
I'm personally against adding any more prominent static content on pages, so I think adding anything to the top right is a very bad idea - notices are already chronically misused, ugly and very annoying, and adding a permanent one in the top-right that's only useful to a small niche is just going to clutter the site. Helping new users really shouldn't be at the expense of annoying current users.
The "+" button was previously changed to "Leave a comment", but it was quickly reverted back after several prominent Wikipedians objected to the change at the time - the suggestion comes up repeatedly but no-one wishes to actually make the change. To be honest, I think "Leave a comment" is too long.
I fundamentally disagree with your final point that Wikipedia should be more "Web 2.0" when it comes to things like categories. "Web 2.0 interactive tools" are too often more annoying than useful, complex to develop and I honestly think Mediawiki's relatively simple "all content in one textbox" philosophy is a good idea - it's platform independent, relatively simple to use, extremely simple to implement (both in terms of client-side and server-side - the database schemas could get a lot more complex) and an easy concept to grasp. Separating content and markup is bad idea IMO.
Oh, and do you know about LiquidThreads? Based on your want to improve Wikipedia talk pages and want of 'Web 2.0' technology, it sounds like something you might be interested in. -Halo (talk) 02:12, 17 March 2008 (UTC)[reply]
To be honest, I think "Leave a comment" is too long - point well taken, but the better proposal - still not implemented - is to have something like "+comment". That's the way that the tab appears on discussion pages at Wikimedia Commons. -- John Broughton (♫♫) 13:46, 17 March 2008 (UTC)[reply]
I was trying to be helpful since no-one else mentioned it. I'm not against the change - as I've previously stated many times (including on the persistent proposals page), I'm completely indifferent about it, especially considering it's not a feature I use (I find it's generally less hassle to start a heading by hand). -Halo (talk) 15:03, 17 March 2008 (UTC)[reply]


adding a permanent one in the top-right that's only useful to a small niche

A small niche? Last I heard, more than 80% of page views are unregistered users. It would be good to get a better statistic on that. But they are by far the bulk of visitors to the site, and the whole point of the site is that they're supposed to be contributing to articles. They, collectively, know a lot more than we do. Wikipedia is not a clique.

"all content in one textbox" philosophy is a good idea - it's platform independent, relatively simple to use, extremely simple to implement

It's simple to implement, but it is not simple to use. Our code is way too complex for the average person to be comfortable with. Our editors are predominantly from technical fields for a reason. This is bad, because it skews the content and bias of the articles.
It would be much better if, for instance, you could type a potential category into a search box, and be shown a dynamic list of matching category names, with local tree structure, and pick one from the list to add by clicking on it. Similar with interwiki links. Then the article wouldn't be as cluttered up with code. Of course these would still show up in the history like any other edit.
And yes, we could definitely use a better talk page system. One that allows subscriptions, forked threads, full mediawiki syntax, localizable dates, never-ending threads that can be "bumped" by additional comments so that we don't have 100 separate conversations about the same subject, threads displayed on multiple talk pages for consolidated discussion (an issue that needs input from people on the village pump, article talk, and admin noticeboard all at the same time), etc. I've thought about this a lot, too, but it requires major software changes. The things I have proposed here can be done without software changes. We just need to convince certain people that they're a good idea.
(Also, in addition to recruiting passers-by to contribute article edits, we should be recruiting developers as much as possible, too, to implement the more complicated things our site needs. I get the impression our code is way too complex for most people to dive into, so we are stuck with a small number of developers who don't have time to do very much, which is why our site's functionality is so dependent on on user-written templates and user-written bots.) — Omegatron 00:12, 18 March 2008 (UTC)[reply]
In reply to Kevin Murray: I don't want that kind of barrier to entry. Someone may be quite capable of learning to use the syntax, yet it may still be a barrier because they don't have much of an incentive to spend effort learning it until they've discovered how rewarding it is to contribute. John Broughton also has a very good point about different types of knowledge. We need more contributions from people who actually know how to use (and have access to, and desire to spend time using) actual paper books and that sort of thing, not just people who feel comfortable using computer codes.
Reminds me of when I started using Generic Mapping Tools, years ago. I spent a whole day reading the manual and trying to run some of their examples before I got any results at all or enough information to make a decision as to whether it was worth spending any time learning it. I later emailed them and suggested that they make their first example something that you can just type in and it will work (e.g. produce a map of the world), which they could easily have done; instead, their first examples required downloading additional files, which for some reason took hours when I did it. I did learn to use their system and I still use it often, but I could easily have given up and never learned to use it. Whether someone has the ability to learn is not always the same thing as whether there is a barrier.
Reply to Omegatron: yes, that's what I meant: only the "comment on this article" link from the article page would produce messages with a special mark; though I'm actually not sure whether that's a good idea or not even though I suggested it. It might contribute to the whole "us versus them" mentality. Besides, the post would probably be signed with an IP username, so that would clue people in anyway that it's likely a new user.
Another option for the name of the tab at the top of the talk page is "New topic". This may be familiar to users of some other website fora. Just "comment" would be OK, I think. It might be worth asking some non-Wikipedians how they would react to a tab called "+comment". Possibly just "comment" might be less confusing to some less math-oriented users. Not that people don't know what a plus sign is; just that it looks like some unknown computer code.
Here's an idea, for all those Wikipedians resistant to change: the new "comment on this article" link could show up only for unregistered users (assuming that's technically feasible). --Coppertwig (talk) 02:07, 18 March 2008 (UTC)[reply]
I've actually been working on a "leave a comment" system with Javascript (though something built into the software would be better). Its not really done, mainly due to laziness by me. Mr.Z-man 02:44, 18 March 2008 (UTC)[reply]
Even if 80% of page views are IP addresses, you're making the assumption that out of that 80% a large proportion are people who want to contribute but don't know how or that they can - which I certainly disagree with - and you're at risk of compromising the reading experience to make that happen. I stand by the fact that unnecessary static content is horrendously ugly and largely pointless, and I'm strongly opposed to it in general.
I disagree that MediaWiki is 'too complex' and even if it is that there are better practical solutions to that problem. Most editing on Wikipedia are already of the type "typing words into a box" which can't really be simplified, and you're always going to be left with some sort of markup language (even if I don't particularly like MediaWikis flavour of it). A web-based
I also don't think trying to proactively "recruit developers" to open source projects ever actually works. As far as I'm aware, the problem isn't MediaWiki's code itself as much as the fact that any project the size of MediaWiki has inherent complexity. I think bots exist simply because the projects lend themselves to bots more than anything else. -Halo (talk) 03:15, 18 March 2008 (UTC)[reply]
you're making the assumption that out of that 80% a large proportion are people who want to contribute but don't know how or that they can
That's absolutely correct. It's probably higher than 80%, in fact.
"typing words into a box" which can't really be simplified
It can be simplified by giving them an empty box to type into instead of requiring them to learn a computer programming language in order to contribute. — Omegatron 03:24, 18 March 2008 (UTC)[reply]
Y'know, wikimarkup started out fairly simple. Having full WYSIWYG is not really simple either, and has huge disadvantages. WYSIWYM is more like it, but that requires teaching people new techniques yet again. But... hmmm, less bad that is, plausible too. --Kim Bruning (talk) 05:06, 18 March 2008 (UTC) yoda I now sound like[reply]
(WYSIWYM is plausible because: A: New users will still grasp it fairly quickly. B: It needn't interfere with existing wikimarkup, thus making it "easy" to code, in theory. ) --Kim Bruning (talk) 05:08, 18 March 2008 (UTC)[reply]
Wasn't the original point of wiki markup supposed to be WYSIWYM? — Omegatron 20:21, 5 April 2008 (UTC)[reply]

Here's a mock-up of what I'm imagining for the notice that unregistered users will see:

User:Omegatron/Sandbox

Click the links to see the "newcomer boxes". — Omegatron 03:17, 18 March 2008 (UTC)[reply]

Hearty applause. As a person who has to refer to a manual to shut off the alarm on a digital watch, I'm all for enabling less technologically inclined editors to contribute. Some of us need extra guidance getting in but are capable of learning our way around once we've done so. --Moonriddengirl (talk) 13:48, 19 March 2008 (UTC)[reply]
Well, there's nothing stopping me from just implementing it right now, so the "only" things left to do are:
  1. Decide on the exact wording and formatting of the notice and screens
  2. Convince people it's a worthwhile change so it isn't insta-reverted.
There's some on my talk page discussing a WikiProject, which might be a good next step. — Omegatron 01:19, 21 March 2008 (UTC)[reply]

Fancy JS leave-a-comment thing

Okay, I've got a working version of a "Leave a comment" system using Javascript and an HTML form. You can test it yourself by adding 

importScript('User:Mr.Z-man/feedbacktab.js');

to your monobook.js page and then bypass your browser cache. It still needs a bit of work - Something explaining what to put for each field, some might be replaceable with other input types (drop-down, radio buttons, check boxes) and some (or all) should probably use multi-line input. I'm open to suggestions about which parts may be unnecessary, what you'd like to see in it, improvements, or bugs (I've only tested it in Firefox). Mr.Z-man 02:44, 19 March 2008 (UTC)[reply]

Interesting. I don't think implementing it as a tab is really a great idea. I don't think the people we're trying to reach even notice the tabs.  :) I also kind of think it's better to just give them a blank box and let them comment, as they would on a Youtube video or blog, but maybe giving them some structure to work in might be good? Not sure. If were implementing "quality voting" for everyone to leave, I think that would be better handled by a metadata extension than leaving comments on the talk page. — Omegatron 01:16, 21 March 2008 (UTC)[reply]
The location of the link can be put just about anywhere on the page, adding it as a tab is just the easiest way (remember that readers only see 4 tabs by default). Any suggestions as to where it might be better. It could be put in the article page itself, but then there's the risk of messing up content, especially if its on the top (infoboxes, maintenance templates). A lot of the current boxes are probably redundant, 1 main box might be the way to go. Maybe a couple minor options, using a dropdown or checkboxes, then one main comment box? Mr.Z-man 00:20, 22 March 2008 (UTC)[reply]
  • I'm fairly strongly against a "leave a comment" box at all. If you look at sites and blogs that have them, most users interpet the invitation as "leave an opinion" and you get a vast string of "Foo is great", or much longer appreciations of Foo, or of course "foo is crap" and elaborations of this too. For busy articles with thousands of viewers every day, this is the last sort of thing we want to encourage. In my experience most people are now well aware they can edit WP if they want to, as the point is stressed (usually negatively) in almost all media coverage. "edit" is hardly ambiguous. Johnbod (talk) 03:38, 24 March 2008 (UTC)[reply]
So improve the wording. It doesn't just say "leave a comment". It says "leave a comment if you see an error or other problem". — Omegatron 16:14, 29 March 2008 (UTC)[reply]

RfC — rethinking the list of the top ten wikipedias

Please comment on the discussion at m:Top Ten Wikipedias. Waldir talk 19:07, 23 March 2008 (UTC)[reply]

How about a list of the ten top most visited articles on Wikipedia, just for curiosity's sake? Deus Maximus 375 (talk) 22:23, 29 March 2008 (UTC)[reply]

How to Recruit

The list of requested articles can be a useful tool for recruiting new contributors: when viewing an article, the side could contain "Do you know what <term> is?" where <term> is a phrase that an article has been requested for, randomly chosen from the requested articles listed in the category that the currently viewed article is a member in. This would give readers a concrete, obvious way to jump into contributing, "Geeze, I know that!" I believe this could be successful, and also be a way to get better coverage on vertical/narrow fields where knowledge on one thing while lacking on another is not uncommon. — Preceding unsigned comment added by Fenglich (talk • contribs)

if we could also see the date the account was created

It would be nice if when looking at a user's contributions, we could also see the date the account was created. This can be useful when deciding how to protect an article.

For example, if a user is pestering an article, and I see that said user has only edited today, then I may decide to semi-protect the article - only to find said user editing the article anyway - because said user actually created the account a long time ago. If I could see that said user created the account three months ago, then I wouldn't waste my time with a semi-protect, and I would take a different action. Kingturtle (talk) 03:32, 27 March 2008 (UTC)[reply]

For that, can't we just look in the user's logs (which are linked from the contribs page)? Users who have registered recently (as opposed to "older" users who might not have a user creation log entry) are the only ones for which this difference is relevant, and they are likely to have so few log actions that it will be immediately apparent. It (the status quo) might be a bit more annoying, but do we really need to change this? Nihiltres{t.l} 03:38, 27 March 2008 (UTC)[reply]
(ec)I might be misunderstanding your proposal, but doesn't the user creation log do this already? Equazcion •✗/C • 03:39, 27 Mar 2008 (UTC)
Hmmm. I guess I just want to save the extra steps and have the date shown on the contributions page. Kingturtle (talk) 03:46, 27 March 2008 (UTC)[reply]
That could be a minor convenience... and maybe a JS script could even accomplish it. Although I think in the example you describe, it would be better to warn/block the user that's pestering the article rather than protect the article. Page protection is for a multi-user problem. Equazcion •✗/C • 04:00, 27 Mar 2008 (UTC)
I was trying to keep my example simple. The real world example involved edit wars involving sock puppets of banned users. But I can live with accessing the user creation log myself. Kingturtle (talk) 04:07, 27 March 2008 (UTC)[reply]
You could always use Wannabe Kate -- RoninBK T C 05:21, 30 March 2008 (UTC)[reply]

Changes that are reverted test edits should be hideable in watchlists

A pair of test edits where an editor, almost always an IP, makes an edit and then immediately self-reverts, leaves an article unchanged; the only effects are to add to the article history, and to clutter other editors' watchlists. I would prefer not to see such test edits by IPs cluttering up my watchlist. I would like to propose a new preference to enable editors to choose whether to show or hide such test edits by IPs from their Special:Watchlists. It might be excessive work for the MediaWiki developers to implement though. Is it a good idea? Would there be any negative effects? Should editors be allowed to make this choice for their watchlists? - Neparis (talk) 18:39, 27 March 2008 (UTC)[reply]

From a process standpoint, the edit would have to be noted; then the undo would have to be used; by the same editor; within a specified amount of time. What would an appropriate time window to qualify for "test edit"? What if another part of the document is edited before the undo, so that there is an interruption of the editing sequence? It seems the most difficult aspect of something like this would be to firmly define what a "test edit" is so that it could even be programmed. Gwguffey (talk) 19:02, 27 March 2008 (UTC)[reply]
I agree. I was thinking of test edits that are pairs of edits where an editor makes one edit that inserts or deletes something in an article, then in a second edit the same editor completely undoes the first edit, and there are no intervening edits by any other editors. In other words, the diff of before and after edits is null. Here's a real example of such a pair of test edits:

Template:Multicol Revision as of 18:03, 24 March 2008

80.24.125.138 (Talk)

(→Bonded post-tensioned concrete) Template:Multicol-break ==Bonded post-tensioned concrete==

Bonded post-tensioned concrete is the descriptive term for a method of applying [[Physical compression|compression]] after pouring concrete and the curing process (''[[in situ]]''). Template:Multicol-break ==Bonded post-tensioned concrete==

post-tensioned concrete is the descriptive term for a method of applying [[Physical compression|compression]] after pouring concrete and the curing process (''[[in situ]]''). Template:Multicol-end

followed by this:

Template:Multicol Revision as of 18:05, 24 March 2008

80.24.125.138 (Talk)

(→Bonded post-tensioned concrete) Template:Multicol-break ==Bonded post-tensioned concrete==

post-tensioned concrete is the descriptive term for a method of applying [[Physical compression|compression]] after pouring concrete and the curing process (''[[in situ]]''). Template:Multicol-break ==Bonded post-tensioned concrete==

Bonded post-tensioned concrete is the descriptive term for a method of applying [[Physical compression|compression]] after pouring concrete and the curing process (''[[in situ]]''). Template:Multicol-end

This pair of test edits left the article unchanged. In my proposal, I could choose to have the null pair of test edits not listed in my watchlist. That would be very useful because the watchlist would instead list the most recent non-null edit on that article. In the above example, there was an earlier, much more significant non-null edit by another editor. I would like the earlier non-null edit to be shown on my watchlist even after the null pair of test edits.
- Neparis (talk) 20:24, 27 March 2008 (UTC)[reply]
I think it would be resource expensive determining if the edit did in fact set the page to the previous version. (1 == 2)Until 20:51, 27 March 2008 (UTC)[reply]
That is an interesting issue. I wonder how the calculation would go in practice. A watchlist is a list of diffs that are calculated on the fly without caching. To display a watchlist, the software has to calculate a diff for the most recent edit for each article in the watchlist. I am thinking that that is the base cost for the way watchlists currently work. In the proposal, detecting a null pair of test edits so as not to show them at all in a watchlist would require the software to calculate two diffs — one for the most recent edit, and one for the most recent edit before that, for each article in the watchlist, and trivially to check that both edits were by the same editor. The software also has to do a couple of other things in displaying a watchlist, which adds to the total cost of displaying it. So, the question is relative to the total cost, how much extra cost is there in the extra diffs? Is it excessive? Another issue is what proportion of editors would decide they like the new style watchlist so much that they start using it exclusively? - Neparis (talk) 21:26, 27 March 2008 (UTC)[reply]
No, watchlist only needs to take the ID of the revision that has the latest timestamp on it for each article in the watchlist and stick it into the links. It loads the time, edit summary, editor, size etc, but it never loads the content or calculates a diff. It only calculates a diff when one follows a diff link. To do what is being suggested then a checksum would either have to be calculated on the fly going back 2 revisions(everytime someone looked at the history or a watchlist), or an extra table entry would need to be added to store the checksums. This would be a significant increase in our resource usage. (1 == 2)Until 21:33, 27 March 2008 (UTC)[reply]
And in general, diff generation is very resource intensive and caching generally can't help as much as it can with article content (I'm not sure if diffs are server-cached at all actually). So much so that Wikimedia doesn't use the default PHP diff engine in the software, but one written in C++. Mr.Z-man 22:12, 27 March 2008 (UTC)[reply]
However, figuring out if two revision are identical is not resource intensive. Simply checking the revision sizes would address a large fraction of all cases. Beyond that, yes if it is to be widely used it should be implemented as an additional boolean column in the revision table. I'd go farther than the original poster however and make it a flag for revisions that A) were reverted or B) generated by making a revert, regardless of whether the reversion was done by the same editor (e.g. a test edit). I think in general it would be useful to have a way to selectively exclude edits that have no functional impact on the development of content. Dragons flight (talk) 22:44, 27 March 2008 (UTC)[reply]
Excellent thought, Dragons flight, as it is more generalized case. I would be very interested in the ability to filter out "zero sum combinations" of edits as I generally do not care whether the same editor or a different editor reverts/undoes an edit. Gwguffey (talk) 01:36, 28 March 2008 (UTC)[reply]
Ah yes, we all know how much the devs enjoy adding a column to a db table with over 200,000,000 entries hehe. (1 == 2)Until 02:01, 28 March 2008 (UTC)[reply]
They actually do it far more often then you might think. It's not uncommon for new features (e.g. cascading protection, stable versions, etc.) to require modifications to the database tables. Dragons flight (talk) 02:11, 28 March 2008 (UTC)[reply]
It's pretty crude to use the byte count to identify "identical" versions of a page; calculating a hash value would require more processing but would be pretty much fail-proof. (That's what some researchers did in a fairly recently published paper, where they tried to figure out who "added value" to articles; edits that were reverted, and reverts, weren't counted.) -- John Broughton (♫♫) 23:16, 28 March 2008 (UTC)[reply]
On a perhaps more constructive note, I wonder if what Neparis is interested in can't be done fairly easily in Javascript. Specifically, User:Stevage/EnhanceHistory.user.js collapses consecutive edits from the same person into one; could that user script be modified so that (a) when multiple edits are collapsed and (b) the net byte change for the multiple edits is zero, then (c) don't show the collapsed/combined edits at all? -- John Broughton (♫♫) 23:23, 28 March 2008 (UTC)[reply]
Thanks for pointing out the script. I still would like to see the function developed in a future version of MediaWiki. If it were built in to MediaWiki, it is there for all editors without the need to fiddle around with any scripts to get it working. As it happens, the script you suggested does not work in any of the different browsers to which I have access (each restarted to avoid cache woes). I'm not a great fan of addon scripts for various reasons, including reliability. - Neparis (talk) 05:26, 30 March 2008 (UTC)[reply]
Sorry, to clarify, the direction I was heading was to suggest that if there were a lot of interest in this (I certainly would be interested), it could be implemented as a gadget. Then using it would (for an editor) simply be a matter of checking a box and saving the change, in an editor's personal preferences. It's true that it would be good to build this into the Mediawiki software (ideally with hash values), but that may be a long time coming, if ever, given all the other priorities for developers. -- John Broughton (♫♫) 12:51, 30 March 2008 (UTC)[reply]

(od) Oh, I agree it could be done in a gadget, though a gadget is just a script with official blessing, i.e. doing it by a gadget or a script imposes more load on the servers than implementing it in MediaWiki per Dragons Flight's suggestions. - Neparis (talk) 02:12, 4 April 2008 (UTC)[reply]

The "creating page" bar

In reference to the bar that appears at the top of the page after clicking on a red link, that reads:

  • Before creating an article, please read Wikipedia:Your first article, or search for an existing article to which you can redirect this title.
  • To experiment, please use the sandbox.
  • As you create the article, provide references to reliable published sources. Without references, the article may be deleted.

I think it should tell the creator about user subpages, or {{underconstruction}}. WEBURIEDOURSECRETSINTHEGARDEN I push my hand up to the sky 12:14, 29 March 2008 (UTC)[reply]

Well, just leave a detailed {{editprotected}} at MediaWiki talk:Newarticletext. Sounds good… unless someone objects, it seems trivial as the page-create message is already specific for different namespaces. Nihiltres{t.l} 15:04, 29 March 2008 (UTC)[reply]

10 M banner?

Reply on this talk page. -- Zanimum (talk) 14:56, 29 March 2008 (UTC)[reply]

The Wikipedian's Court

Shouldn't we have a court for resolving conflicts on Wikipedia. The users would be the jury. Nothing444 17:40, 29 March 2008 (UTC)[reply]

We already have several ways of resolving disputes - why do we need another one? Hut 8.5 17:59, 29 March 2008 (UTC)[reply]
We do have a "court" see: WP:RfAr-- penubag  (talk) 20:24, 29 March 2008 (UTC)[reply]
The Arbitrary Committee is not a legitimate authority. It was created not by the community but by the dictate of one man who really isn't all that special, and he still retains final say on its membership. Kurt Weber (Go Colts!) 16:56, 2 April 2008 (UTC)[reply]
They don't work, especially Third Opinion.--MahaPanta (talk) 20:29, 29 March 2008 (UTC)[reply]
The users would be the jury - ah, and how would the jury be chosen? We don't have the ability to force anyone to serve jury duty. -- John Broughton (♫♫) 22:32, 29 March 2008 (UTC)[reply]
We are actually a Common law jurisdiction, as we are based more on practice and precedent than on laws (with the exception of the constitution). :-) Waltham, The Duke of 08:35, 30 March 2008 (UTC)[reply]
And to respond to MahaPanta, I've seen third opinions work in many cases. They're nonbinding, so of course they can be ignored, and that means in some cases they will be, but in many cases, a neutral uninvolved party's take can be a great stride toward settling a dispute. Seraphimblade Talk to me 08:41, 30 March 2008 (UTC)[reply]
...And by "a great stride toward settling a dispute" we mean "the editors either agree to the third opinion or we start hitting them with increasingly large sticks until they do". --erachima formerly tjstrf 08:55, 30 March 2008 (UTC)[reply]

Optional spell/grammar checker

When someone edits a page, I think it would be a good idea for them to have the option to spell/grammar check the edit they are about to make, this would reduce the amount of unnoticed spelling and grammar mistakes which appear in wikipedia articles.

I appreciate that what I have just recommended isn't a minor change to wikipedia, but would be a significantly large project, however there are open source applications which algorithms could perhaps be used from (such as openoffice.org, and for dictionary's of words to use in a project such as this, people only really need to look as far as wicktionary).--Dave (talk) 18:35, 29 March 2008 (UTC)[reply]

Nice idea, if it could be done. Your post ("dictionary's") proves that the need really does exist. Adrian M. H. 19:26, 29 March 2008 (UTC)[reply]
I agree, the big problem is if it can be done. Having said that online email services such as gmail have online spell checkers so it isn't beyond the realm of possibility, however it would be a big project. --Dave (talk) 21:42, 29 March 2008 (UTC)[reply]
Spelling checkers belong in web browsers - both Firefox and Safari have nice ones already built in. Other browsers like IE7 have add-ins that can be downloaded. See Wikipedia:Spellchecking#Using a Web Browser. -- John Broughton (♫♫) 22:25, 29 March 2008 (UTC)[reply]
The thought of having a spell checker in your browser hadn't entered mind before, and I'll certainly be looking into it. However I imagine most other people won't be aware of it as well, as according to Usage share of web browsers, Internet Explorer has an 83.27% share of browser usage (February 2008 - Global usage share data from OneStat.com) and I doubt that very many people of that 83.27% will have installed an extension to allow them to spell check in their browser (of course I could be very wrong and if you can find any statistics to support this then I would be interested). - For the sake of presenting both sides of the argument Firefox has a 13.76% share and Safari has a 2.18% share. --Dave (talk) 22:46, 29 March 2008 (UTC)[reply]

Be confident

I thhink there should be a policy called be confident. You should always be confident of yourself AND other users, even if it looks like you would fail. This is an essential policy for maintaining a kind community. Nothing444 19:55, 29 March 2008 (UTC)[reply]

You can feel free to write an essay, but how would this work as a policy? Mr.Z-man 20:30, 29 March 2008 (UTC)[reply]
Wikipedia:Be bold seems to be quite similar to what you're suggesting... Black Falcon (Talk) 20:59, 29 March 2008 (UTC)[reply]

Collaboration

We should definitely get Collaboration of the week back together. Could someone please help me accomplish this? Mm40 Your Hancock Please

It's much better to do collaborations within WikiProjects, I think - that way, people are working together with others with similar interests. COTW died a natural death, and there are plenty of other collaborations as is. -- John Broughton (♫♫) 22:07, 29 March 2008 (UTC)[reply]

Copyediting

In addition, we should organize a huge one day/week/month/ long effort to get the Articles needing copyedit down. Any comments would be appreciated. Mm40 Your Hancock Please

See Wikipedia:WikiProject League of Copyeditors. -- John Broughton (♫♫) 22:09, 29 March 2008 (UTC)[reply]

I have and I haven't gotten a response. Mm40 Your Hancock Please

Proposed Lupin filter update

I propose adding an option to the filter that allows users to ignore edits with edit summaries, as those edits are generally constructive.--Urban Rose 01:26, 30 March 2008 (UTC)[reply]

Should prominently note about other languages

For every registered user should be option to enter a list of languages. Then when displaying an article, prominently (near the top of the Web page) should be shown if this article is also available in the languages from the user's list of languages.

Example: I would set for myself the list of languages consisting English and Russian. Then viewing the English article Russian Desman I would note that there is also Russian version of this article. In fact, currently the Russian version of this article is far more detailed than English one. So I would profit from viewing prominent notice that it is also available in Russian. —Preceding unsigned comment added by Porton (talk • contribs)

I realize that to implement this MediaWiki software need to be modified, but I think it's worth the cost.

One way of doing this would be to put li.interwiki-ru {font-weight:bold;} in your monobook.css which would make the link to the Russian version of the article bold, although it will stay in the languages box. If there's a particular place where you want the link, you could use javascript. You can ask at Wikipedia:WikiProject User scripts/Requests about this. Tra (Talk) 17:56, 30 March 2008 (UTC)[reply]


Wikipedia:Reproposal tags

As no response in any shape or form was given to this proposal previously, I will post it again.

Park Crawler, otherwise known as 69.141.213.16 (talk) 20:45, 30 March 2008 (UTC)[reply]

I feel like this proposal is a little vague at the moment. Could you give me an example of a past situation where this new system would have helped? Thanks. Canderson7 (talk) 20:55, 30 March 2008 (UTC)[reply]


"Did you mean:" feature in search function

I would like to know so if nobody else has had a problem with this, but I think that Wikipedia requires a search function, as a slight misspelling of the topic you are looking for will often not return anything useful in the search results. Is there a good reason why Wikipedia cannot adopt a “Did you mean” function like Google has, perhaps by utilizing Google for searches? I commonly go to Google to find out how to spell something before searching for it in Wikipedia or Wiktionary because of this problem. Am I alone here, or can we do something about this? Celebere (talk) 01:52, 31 March 2008 (UTC)[reply]

This is a perennially requested feature. The search function is one of the things on the To Do list for Wikimedia to upgrade, but it hasn't gotten there yet. As for integrating Google searches, that would mean including Google advertising. Won't happen. -- Kesh (talk) 02:23, 31 March 2008 (UTC)[reply]
There's a good reason not to include a "Did you mean" function: Google has a hundred thousand servers, a large number of people with PhDs in computer science, and a budget of hundreds of millions of dollars. Wikipedia has a perpetual shortage of servers, a grand total of two paid developers, and a budget of less than five million. My impression is that Google's "did you mean" uses peoples' search habits as its raw data, so that's another thing Google has that we don't: hundreds of billions of searches to work with. --Carnildo (talk) 07:58, 31 March 2008 (UTC)[reply]

New way of tagging

Would it be possible to amalgamate all the tags we currently have for clean up into one tag, which indicates where an article fails our encyclopedic standards? This would allow editors and readers to more readily identify the issues within an article and hopefully help move articles closer to FA status.

Now, looking at WP:FAC and WP:GACR it suggests our standards are:

  • Clear prose, no issues with grammar and spelling
  • Complies with the manual of style
  • Is verifiable to reliable sources
  • Is neutral, presenting no bias
  • Is stable
  • Complies with Wikipedia:Citing sources in the formatting of citations
  • Uses images in keeping with WP:FUC
  • Is not too detailed

I suggest we look at creating a template which can display which of those criteria an article does not meet, and then deprecate all others. This template would need the tagger to further outline the issues on the talk page, in the shape of a to-do list.

Hopefully this could move articles forwards towards FA status and also solve the issue of notability. We wouldn't need to debate notability any more. Articles would be tagged as not meeting our encyclopedic standards. Then we need to refocus AFD as being a debate about how to fix the article. That means we need to ignore any comment which does not engage in the debate, for example one word comments or people who make the same comment repeatedly in a vast number of debates. People need to identify why the article can never meet Wikipedia's standards, and why the information cannot be used in another article and therefore not merged, for an article to be deleted. This requires a huge sea change across Wikipedia, with everyone focussing upon the bigger picture, that of writing an encyclopedia together. We need to start working together on this project, focus our attention on the article space and focus our attention on our standards. We aren't judged so much on articles which are bad that we ourselves openly identify as bad. We aren't judged so much on how many articles we have on trivial topics. We aren't judged so much on any space other than article space. And what we are judged on, more than anything, is our ability to produce an encyclopedia. That's where we need to refocus our energies. That's where we need to devote our energies. We need a root and branch re-evaluation of our processes and toolset, and work out whether they focus our energies on creating an encyclopedia. Anything that doesn't needs to go. Anything which conflicts with the fact that Wikipedia is an encyclopedia needs to go. We need to set in stone the fundamental principles of WIkipedia, and stop endlessly debating them. Protect the policy pages. We need to take this project on. We've come a long way, but there is still a long way to go. We need to commit to the underlying principle of Wikipedia as best we can, and build the encyclopedia. We're not a talking shop. Okay. That's a lot of blather. Anyone want to figure out ways to take it forwards? Hiding T 09:45, 31 March 2008 (UTC)[reply]

I am not sure I understand the question. Sorry if this misses the point, but is there anything wrong with using {{multipleissues}} to amalgamate multiple tags for different issues into a single tag? - Neparis (talk) 02:34, 4 April 2008 (UTC)[reply]

Funding

It may be that at some point in the future there will be a funding crisis. I know this a perennial, but I'd like to keep the discussion on this page for the time being and propose we as a community revisit the idea of advertising. I think there's two models that we could maybe look to adopt.

  • Only have adverts on our featured articles.
  • Only keep our featured articles free of adverts.

I'll just toss them out. I think we as a community need to tackle this idea. If we can agree some way forward on the issue, we can perhaps take it to the foundation. I appreciate there is a groundswell of opinion which fundamentally opposes advertising, but I think we have to explore the issue. If it was a choice between advertising and staying charitable, or private ownership, which way would you jump? Remember, this content we produce is free for anyone to use. We're giving this away. What are we all most committed to. What is the ideal which fundamentally unites us? Hiding T 09:51, 31 March 2008 (UTC)[reply]

  • The most valuable advertising would obviously be on the most commonly seen articles, plus those related to high-value topics - investment issues, maybe some music, etc. Another way might be to say only the 1,000 (or whatever) most popular articles get ads, so maximising revenue but minimizing seeing the damm things, or to allow registered users to hide them (as default). In fact if the ability to hide the things were limited to those with DYK/GA/FA noms ..... Johnbod (talk) 18:33, 31 March 2008 (UTC)[reply]

Use the Geotag Icon in association with coordinates

Wikipedia currently use a little globe icon to indicate GPS coordinates e.g. here:

http://en.wikipedia.org/wiki/Empire_State_Building

The globe currently in use is indistinct and not location-specific, since globes are used in a variety of other contexts. The community-designed and free Geotag Icon has been created expressly for better illumination of geodata:

http://www.geotagicons.com

It is appropriate for geotagging using any format (meta data, microformats, EXIF-GPS, etc) and has been added to the microformats.org icons page:

http://microformats.org/wiki/icons

The information on the Project website is comprehensive and self-explanatory, but if I can answer any questions or be of other assistance please don't hesitate to get in touch.

Project Coordinator: Bruce McKenzie The Home of the Geotag Icon Project www.geotagicons.com

Stable versions is coming; what standards, guidelines, and processes need to be written?

See Wikipedia:Flagged revisions, currently in testing at http://en.labs.wikimedia.org/wiki/Main_Page. See also meta:Article validation feature and Wikipedia:Pushing to validation.

So Stable versions, as you all know, is currently in test mode. It will not be turned on until there is a community consensus as to how it will be implemented. So currently, in my mind, there are these questions:

How do we decide which users are allowed to be "Editors" and "Reviewers"?
Do we allow any article to be reviewed?
Do we want this?
Does this take away from the spirit of a "wiki"?
What are the long term advantages and disadvantages of implementing this?

Did I miss anything? Personally, I would like it turned on and have any article be reviewed. Although some might argue this takes away from the spirit of the wiki, this would better for us in the long run. The Placebo Effect (talk) 16:09, 31 March 2008 (UTC)[reply]

I think this is a great idea for some articles, but I hope it will not be the default way of handling all articles. (1 == 2)Until 16:11, 31 March 2008 (UTC)[reply]
I don't really see a pressing need for this. Sorry. I know this is a valid issue, and I'm not denying that; I'm simply putting out my opinion on this. also, I'm not totally familiar with this. could please provide a link for more information? thanks. --Steve, Sm8900 (talk) 16:18, 31 March 2008 (UTC)[reply]
Well there is certainly a need for some article, specifically those about living people, but not across the board. (1 == 2)Until 16:19, 31 March 2008 (UTC)[reply]
"stable versions" could be FA articles at the time of becoming featured. I don't see any other use for this at present. There may be a limited "update" process of a FA, deciding whether the present version is an improvement over the version as featured. If an article isn't FA-worthy, I see no reason to treat it as "stable". FAC has been our (ever rising) benchmark for years. I object to treat "living people" articles any different from others. The "stable version" should not be the one displayed by default, of course, there could just be a note to the reader that they have the choice of displaying a reviewed "stable" article as an option. dab (𒁳) 16:22, 31 March 2008 (UTC)[reply]
Wow, Featured article or not at all? I am sorry to disagree, but I think there is a gray area. I also think this can be used not only to preserve the "best" version, but also to keep unsourced slander out the displayed articles on living people. I also think it is a less harmful alternative to protecting an article. (1 == 2)Until 16:24, 31 March 2008 (UTC)[reply]
Personally, I think the only articles that should be Stabled are FA, GA, and BLP. FA and GA to preserve quality, BLP to prevent slander. Maybe Current Event Articles also. The Placebo Effect (talk) 16:34, 31 March 2008 (UTC)[reply]
In terms of "Which articles should have the stable versions applied to them?", there are a few options. We need to consider, however, that there are multiple levels of flagging available (at least as appears on the test wiki); what I think is important is that we use the flagging where it is appropriate for each level. We have, or at least the open test has, "unapproved", "basic check", "good", and "featured" as levels. It seems like, to start, it would be simple enough to allow free flagging of "basic check" revisions by all "editors" (that is, those with the "editor" right), which would be a great help for BLPs and vandal-fighters. From there, "good" and "featured" revisions would fall easily into tagging the featured and good articles; that is, good articles should get "good" upon being successfully nominated, and "featured" in the same way for the next level up. Periodic reconfirmation of featured articles might be an issue - to keep our flagged revisions recent will probably involve a periodic reconfirmation with checks on what updates have been made since the last revision marked "featured".
I'm afraid I'm not clear, however, on which versions are displayed by default for a page; I think that by default, the most recent version should be shown, except for particular pages, such as some of those which are currently indefinitely semi-protected, where a process of flagging revisions that are decent and only displaying flagged "clean" revisions might be worthwhile and allow more people to edit, which is generally a good thing. For some, however, like George W. Bush, it might take more; I can see the potential for a wave of nonsense revisions making finding clean revisions difficult. Nihiltres{t.l} 17:11, 31 March 2008 (UTC)[reply]
  • Personally I think BLP related articles, GA and FA articles should be stable versions. I also think the stable version should be displayed as default to non registered users, with registered users defaulting to not showing the stable version but having the option to change this if they wish. This will help to ensure that readers, who we are writing this for, will always see what we feel are our best articles (GA and FA), and helps to keep our most sensitive articles free of non BLP compliant material. The amount of trouble we have with BLP related articles makes a very strong case for why we need stable versions which could do a lot to resolve our problems in this area. Davewild (talk) 18:16, 31 March 2008 (UTC)[reply]
  • I would say FAs (not GAs), and BLP articles which have had a history of BLP problems. Also articles with a history of nationalist/religious/political disputes, if a concensus version can be agreed. Johnbod (talk) 18:27, 31 March 2008 (UTC)[reply]
    • Why not other pages? If we give out "editor" right liberally, or even automatically, and we show the current version by default, why shouldn't we mark a specific revision as "given a basic check" on any page that would pass a basic check? Mr.Z-man 18:31, 31 March 2008 (UTC)[reply]
Basically because there will be a lot of resistance to this being introduced at all, "the free encyclopedia that anyone can edit" will be quoted a lot, this was discussed (I think last year) and there was a lot of opposition to this being introduced at all - people saying this was against the principals of wikipedia etc. If we introduce this to a, relatively, limited area will gain more support for the proposal, will be done on the articles where we need it most and will let us see how stable versions work on such a large and frequently edited wiki as the English wikipedia. If it is a huge success then expanding the articles that have stable versions should be much less controversial. We need to demonstrate a community consensus here in order for stable versions to be turned on and the proposal must be geared towards gaining the necessary support. Davewild (talk) 18:41, 31 March 2008 (UTC)[reply]
I think we should wait for a page to demonstrate the need for such tools before applying them. But many such pages will exist, about prophets, evolution, etc... (1 == 2)Until 18:34, 31 March 2008 (UTC)[reply]
The idea is to have some form of quality control. Right now, an average reader goes to an article and has no idea whether it is a good article or the last editor changed all the numbers in it. More experienced users might check the history to verify that, but an average non-editing reader probably won't know what all that crap in the history page means. With this system, even if we don't show the stable version by default, there can at least be a link to a version that has been marked as stable so that the average reader can go to a page and see a version of it that they might be able to trust a little more than the average Wikipedia article. Yes, it may reduce the need for semi-protection and help BLPs, but if we only look at the conveniences to editors and not the advantage from the readers' perspective, we miss the point of the extension. I also encourage people, if they haven't already, to test out the system at the Wikimedia test site and see the available configuration options on the MediaWiki page. Mr.Z-man 18:45, 31 March 2008 (UTC)[reply]
You lack the Web 2.0 prosumer attitude, sir! ;-) --Kim Bruning (talk) 19:25, 31 March 2008 (UTC) Actually it's quite hilarious that some random economists accurately identify the existence of prosumers, but many wikipedians are still stuck in the 19th century ;-)[reply]

I am opposed to applying stable versions to the English wikipedia at this point in time, as I would like to be cautious. Stable versions severely alters the wiki model, so no one really knows what will happen (though people are making both positive and negative predictions).

The German wikipedia is the first wiki likely to implement stable versions. I would like to monitor performance of that wiki for 6-12 months before we consider applying stable versions to the English wikipedia. That way, only 1 wiki will be in trouble if stable versions turns out to have negative effects.

Note that standards, guidelines and processes document existing best practices. As we currently have none, and shouldn't have any for at least the next 12 months, the second part of the question can be answered with "we have nothing to document at this point in time".

--Kim Bruning (talk) 18:43, 31 March 2008 (UTC)[reply]

Letting another wiki test this first seems like a good idea. Some places like de.wiki probably have a stronger consensus in this direction, and if they do, then there is no harm in letting them prove it works (or doesn't) and then implementing it here. MBisanz talk 18:51, 31 March 2008 (UTC)[reply]
  • I've added some links to the top of this thread, though I'm not at all sure which are relevant. Please update/correct as needed.
It'd also be nice to have a 1-paragraph-summary of how it works (2 roles, 4 selectable ratings), at the top of this thread, perhaps with a link to these screenshots, or something. All I can find in the Signpost archives are 2006-07-10/More stable versions and 2006-08-07/Wikimania tech. Can anyone point out ongoing or important-historical discussions (mailing list threads, local/meta/de talkpage threads, etc). An update to the Flagged revisions page might be helpful, too. Please and thank you :)
Also, I agree that waiting (2 or 3 months) for de.wikipedia to test it, is probably the best course. Calm discussion is preferable to learning-whilst-controlling-damage/confusion (plus then we have time to update/clarify the documentation...) -- Quiddity (talk) 19:14, 31 March 2008 (UTC) 03:53, 1 April 2008 (UTC)[reply]
  • We should also consider how we currently handle protection, since this in essence another form of more relaxed protection (which allows changing categories but delays other edits taking affect, IIRC) so some situations could migrate from protection to this. We might not want this for all BLPs, since some won't get enough attention, but it would be useful for some of them. -Steve Sanbeg (talk) 19:38, 31 March 2008 (UTC)[reply]
If there are editors who do feel that this is needed, and/or beneficial, then I have no objection to it. my only question was whether people out there had had experiences which led them to believe this was truly needed. sounds like people here have in fact had reasons for believing this might be needed. thanks. --Steve, Sm8900 (talk) 19:56, 31 March 2008 (UTC)[reply]
    • This is a good idea in a small number of controversial articles such as certain BLP articles and certain articles on controversial subjects but I agree with until that to use it on all articles would be really bad and go against the open wiki principles that haver done us so well up till now. Thanks, SqueakBox 20:36, 31 March 2008 (UTC)[reply]
  • Can there be a process that a common editor can ask for a certain page version to be considered "stable" though not necessarily at GA/FA levels? Maybe what is done is that there would be a RfSV, with appropriate talk page templates, that can be setup. These "requests" would point at a specific version by oldid to be made stable, and would be a simple !voting discussion that must be announced on the article's talk page. After a couple days, as long as no major editing concerns are pointed out, the "reviewers" monitoring the page can decide whether to make it stable or not. I'm thinking this would be something that may happen to an article about a major event or release just prior to the event or release. --MASEM 23:13, 31 March 2008 (UTC)[reply]
  • With regards to Kim Bruning's suggestion of letting someone else test it first for practically a whole year, while that would work, it seems to me like an awfully fearful way of going about things. I realize that adding features just because we can isn't a particularly good idea either (Table: namespace anyone?), but there seems to be agreement to use the feature, if not today then eventually, and if not fully then in part. Is there any reason besides opposition to change/the unknown not to try it ourselves, at least for the Featured Articles? If we like it there, we can gradually expand it until we either find the point where it all goes to hell on us or reach the point where it's fully implemented.
    As a related question, once it's turned on, how much adjustment can be done locally, and how much needs developer intervention? --erachima formerly tjstrf 23:27, 31 March 2008 (UTC)[reply]
  • I'm strongly opposed to its implementation here except for articles with severe and ongoing BLP problems, and perhaps Featured articles. Any wider implementation appears to negate the whole concept of a wiki. I agree with Kim Bruning that testing somewhere with stronger consensus first would flag what effects the change has on editing dynamics. Espresso Addict (talk) 23:43, 31 March 2008 (UTC)[reply]

I'm fundamentally opposed to adding more classes of users, or giving more roles to administrators, and think doing either would be an extremely bad thing, especially as administration should be a housekeeping task, not being able to make decisions over the quality of articles. Whatsmore, the current implementation is the ugliest, least intuitive design in the history of web development and its ugliness is enough to put me off implementing it on enwiki -Halo (talk) 01:21, 1 April 2008 (UTC)[reply]

  • I was going to come out in favor of stable versions, but upon further consideration, I can see the wisdom in Kim Bruning's approach of seeing how it goes on the German Wikipedia before applying it here. Why don't we put together a task force of editors who are regular editors both here and on dewiki, and have them report on how it is going there in six months?--Danaman5 (talk) 06:52, 1 April 2008 (UTC)[reply]
  • I find it highly amusing that the feature, which has been in the pipeline for years and pointed at whenever anyone has a complaint about Wikipedia's processes, has responses which seem to boil down to "No, we don't want to take a risk with it." Personally, I think being bold is the desired course of action, and I also think article assessment shows that we can trust a vast majority of our logged-in users. Nifboy (talk) 14:59, 1 April 2008 (UTC)[reply]

I'd say that stable versions would take all the fun out of wikipedia. --Chris 1,000,001 (talk) 23:18, 3 April 2008 (UTC)[reply]

Discussions and ideas on the Flagged Revisions in Russian Wikipedia

In Russian Wikipedia there is a group of users who is eager to turn this feature on (it's called "Verification of Articles" there).

Despite the currently-ongoing discussion/poll shows that many users fear that this feature would harm the spirit of wiki, we can reasonably argue that the following reflects the public opinion:

  1. The default version shown to any user (including anonymous ones) should be the most recent (unstable) version of an article.
  2. The "editor" should be granted to almost all somewhat active users (with some simple census, including 100 edits and a month of participation), being granted by "admins", not by the software automatically. "Easy come, easy go" principle should be used.
  3. The "reviewer" status is the most controversial one. While some users think that the "reviewers" should be well-educated in the subject of the respective article, most suppose that the "reviewer" should only know and follow the rules of reviewing well, and that the "reviewers" are capable to decide themselves whether they are able to "review" the respective article; "relatively easy come, undoubtedly easy go" principle should be applied as well.

If you are interested in more comments, please ask! Dr Bug (Vladimir V. Medeyko) 08:40, 1 April 2008 (UTC)[reply]

Instead of semi-protection

Is there any objection to start rolling out this feature only' as a replacement for semi-protection. It might be good to discuss one issue at the time, so I ask: is there at least universal consensus that flagging is more welcoming for anonymous contributors than semi-protection? --Vesal (talk) 14:05, 1 April 2008 (UTC)[reply]

No! Semi-protection allows users with a minimally significant amount of editing history to immediately change controversial articles. There is nothing wrong with this. I would support stable versions only as a replacement for full protection.--Michael WhiteT·C 18:02, 1 April 2008 (UTC)[reply]

Not just for online

It is worth noting that Flagged Revisions isn't just about what content is displayed online. It is also about identifying versions of articles that are of high quality and can then be recommended for use in offline media like DVD or print versions of Wikipedia. Dragons flight (talk) 19:15, 1 April 2008 (UTC)[reply]

Hear, hear. Stable versions will also be an important incentive for more experts to contribute, since the main complaint is that "anyone" can come along and disrupt their work. To some extent, that's a valid complaint, in that keeping articles free of biased, unbalanced, or unscholarly content takes a level of vigilance that is unappealing. To some extent, it's more the perception than the reality, in that well-sourced content tends to be very stable. Still, the existence of stable versioning will help assuage experts' fears both real and imagined.--ragesoss (talk) 02:08, 2 April 2008 (UTC)[reply]

Whether or not to let all articles be sighted is a different issue from what to make the default view on controversial ones

I would like to clear up a misconception that I have seen some people have about this process. We can have sighted versions of all articles, regardless of quality or controvertibility without compromising our wiki principles if the sighted version is not the default viewed by IPs. By having sighted versions, we give every article a button telling readers that the article they are reading might be vandalised or unreferenced, but that they can click here to see a version that is definatly clean (though it might be shorter than the current version). We need only make the sighted or assessed version the default view for IPs when the article would have otherwise been protected from editing. That way, everyone can edit the most controversial of articles without them being in a constant state of vandalism. In this way, it makes our FA/GA/BLP articles more like wikis while making our other articles have the option of being more reliable. --Arctic Gnome (talk • contribs) 00:33, 4 April 2008 (UTC)[reply]

First, not even FAs are good enought to be Stable, and heaven forbid that GAs are made that way. The Wikipedia process, as embodied by FAC, is inherently susceptible to Fan Club Voting and other more harmful biases. The recent FARC of Che Guavera, which is presented in a POV manner (enough so that it could almost be a press release from a Guavera fan Club) is merely one case in point. Second.. based on human nature.. the advent of Stability will create incentives for POV pushers to game the system in any and every way possible in order to get ther articles Stabilized. Third, what if a new editor with abundant resources to improve an article happens upon a Stable version, but doesn't have the familiarity with the relevant wiki processes to wend their way through the system? In a system without Stable versions, all revisions are merely the click of an edit button. Ling.Nut (talk) 03:42, 4 April 2008 (UTC)[reply]

Slippery Slope

While I understand the need for stable versions on controversial articles this principal goes against the fundamental element of the wiki and in the long run may threaten its very existence. The controversial articles generally have a cadre of editors protecting them and perhaps we could assign/volunteer editors for FA's. Garycompugeek (talk) 19:15, 4 April 2008 (UTC)[reply]

We haven't waited this long to get stable versions to not even try it out. It is clear to me that the displayed version should always be the current version and not the stable version. That way, the most up to date one is always the first seen, and those who must have some assurance of accuracy can look at the stable version. And as long as the stable version is updated very regularly, there may be little difference between them most of the time. Judgesurreal777 (talk) 20:22, 5 April 2008 (UTC)[reply]

Placement of source by {{cquote}}

template:cquote provides parameters for including the source and reference for the quote, but the placement of the attribution line is too far below the quote (leaving too much vertical space in the surrounding article) and too far to the right (it frequently ends up practically on the right margin). I think it would help to bring the attribution to the same right margin as the body of the quote. Elphion (talk) 16:23, 31 March 2008 (UTC)[reply]

{{sofixit}} :-) --Kim Bruning (talk) 18:44, 31 March 2008 (UTC)[reply]
Oooh -- if only it were that easy! Elphion (talk) 00:44, 1 April 2008 (UTC)[reply]
Besides, it seems to be locked. (Whew!) Elphion (talk) 00:47, 1 April 2008 (UTC)[reply]
You're not getting away with it that easily. You can just get an admin to unlock it, right? --Kim Bruning (talk) 08:49, 1 April 2008 (UTC)[reply]

User:Erachima/test now has a version of the code with the buffer amounts adjusted. The top buffer was removed, and I added a right buffer of a few percent. Not perfect, but it's as good as you'll get without adding another #switch to adjust the buffering for each size case and should keep the things a bit further off the right margin. Any admins care to copy it over? --erachima formerly tjstrf 10:02, 1 April 2008 (UTC)[reply]

Comparison (old/new):

Notes towards analysis of inclusion precedent for media franchise elements.

That's a big improvement. Let's try another test. Elphion (talk) 19:05, 1 April 2008 (UTC)[reply]

Notes towards analysis of inclusion precedent for media franchise elements.

Looks like an anonymous benefactor has copied it over. Thanks! Elphion (talk) 13:37, 3 April 2008 (UTC)[reply]

31 March 2008 - a day for Wikipedians to remember

Those who heard news on BBC Radio 4 tonight at six p.m. will have been informed how today (March 31 2008) Wikipedia saw creation of its ten millionth article, an article on Nicholas Hilliard in Hungarian. Surely this calls for celebration among Wikipedians? I was surprised to see that this fact was not mentioned, as far as I could see, on the Wikipedia Main Page (unless I missed it); I would have thought that it was worth at least a DYK feature there. Perhaps Wikipedians are people who are very modest! ACEOREVIVED (talk) 21:28, 31 March 2008 (UTC)[reply]

The ten-millionth article was actually created a couple of days back, and there was an announcement of it on the Main Page at the time. --Carnildo (talk) 22:55, 31 March 2008 (UTC)[reply]
In addition, it was created in the Hungarian Wikipedia, so there would be no DYK here. Waltham, The Duke of 12:06, 1 April 2008 (UTC)[reply]

Thank you - I have now found where to look

Thank you for these comments. I have now seen that if one goes to:

http://en.wikipedia.org/wiki/Talk:Main_Page#10_million_articles.3F_WOOHOO.21

one can read a very lively range of comments,debate and discussion on this topic - including many which say we should be proud of our achievment. By the way, I have also seen that if one goes to the article on Nicholas Hilliard and looks at its talk pages, one will find reference to the achievement. ACEOREVIVED (talk) 19:18, 2 April 2008 (UTC)[reply]

In addition, according to:

http://wikimediafoundation.org/wiki/Press_releases/10M_articles

the actual date was March 28 2008, even though the BBC did not report this achievement until March 31 2008 (unless any one can tell me that she or he heard an earlier news report than the one I heard). ACEOREVIVED (talk) 19:23, 2 April 2008 (UTC)[reply]

Sample RfA Poll

You know how there are sample polls for the presidential election to see who do you think would win? What about a Sample RfA? Nothing444 21:52, 31 March 2008 (UTC)[reply]

…Yes, this exists. It's called asking around ("Hey, do you think User:Example is ready to be an admin?"). Anything more than that is just creepy. Nihiltres{t.l} 23:06, 31 March 2008 (UTC)[reply]

New policy proposal

I've formed a proposal that should help alleviate backlogs, reduce admin-burnout, and curb our increasing reliance on process, I would appreciate any comments on the talk page. Mr.Z-man 00:00, 1 April 2008 (UTC)[reply]

A process to form processes? This smells like an April Fool's joke if I ever saw one. :p Nihiltres{t.l} 02:23, 1 April 2008 (UTC)[reply]
It works better if you don't expressly point it out =P Equazcion •✗/C • 02:29, 1 Apr 2008 (UTC)

Proposals

Post new marriage proposals below. Copy this and fill in the blanks: [name], will you marry me? ~~~~

Stephanie, will you marry me? --67.185.172.158 (talk) 01:51, 1 April 2008 (UTC)[reply]

April fools limits

So um... can I edit Barack Obama and/or Hillary Clinton to say something outrageous, like one of them pulled out, or that they agreed to call it a draw? I think that'd be the most awesome April Fools joke of them all, but I wonder if it's going too far, what with BLP and all. Equazcion •✗/C • 02:47, 1 Apr 2008 (UTC)

Yes, don't do it unless you want to be banned. WP doesn't take April Fool's jokes lightly. 71.131.31.51 (talk) 02:53, 1 April 2008 (UTC)[reply]
April Fools' jokes are fine, so long as you stay away from the articles. --Carnildo (talk) 03:04, 1 April 2008 (UTC)[reply]
That makes it significantly less fun... Equazcion •✗/C • 03:09, 1 Apr 2008 (UTC)
But there is no rule against creating a joke copy in your userspace and using crafty wikilinks and header images to fool people... MBisanz talk 03:11, 1 April 2008 (UTC)[reply]
Heh...you said "pulled out"...heh. Kurt Weber (Go Colts!) 03:17, 1 April 2008 (UTC)[reply]
You're leaving loopholes open, Carnildo... "In the news" is not an article, so Equazcion could add a false report there, with tremendous success (and outrage—we obviously love that, though, so it's not an issue).
If he's an administrator and acts promptly enough, that is. Quick, Equazcion, before they catch us! :-D Waltham, The Duke of 12:05, 1 April 2008 (UTC)[reply]
When doing April Fool's jokes, I prefer to try to make the news outrageous, but true. See my userpage. Soxred93 | talk bot 12:14, 1 April 2008 (UTC)[reply]
I'm not an admin, so it's sadly moot. Only admins can cause true havoc... what an injustice. Equazcion •✗/C • 19:06, 1 Apr 2008 (UTC)
We're trying our hardest to wreck havoc. Blocking random users in good standing, deleting FAs as nonsense, but Equa is right, there is a limit to the amountof bad things 1,000 people can do. Is there a vandal out there who we could give a crat-bot account? MBisanz talk 19:10, 1 April 2008 (UTC)[reply]

Content Rating System

Good morning,

I want to suggest you to include on the Wikipedia an "article rating system". So everyone that reads a Wikipedia article is able to rate it, good or bad. This will enable all Wikipedia users to have a quality indicator of the articles presented. Of course, it is important to show the amount of votes that have been submitted for each article so that users can evaluate the rating's reliability.

Best regards,


--201.153.90.8 (talk) 02:54, 1 April 2008 (UTC)Luis Villegas. LVVL100@hotmail.com Mexico.[reply]

The problem with that is, as is the design of Wikipedia, pages change frequently. As such, a page that you vote on may be changed shortly thereafter to make it better or worse than what you voted on. Besides, if something makes the article worthy of a bad vote, you should fix it so it's good (within consensus, NPOV, etc. of course). JeremyMcCracken (talk) (contribs) 04:57, 1 April 2008 (UTC)[reply]
This has to be the most suggested thing in all of Wikipedia's history. Anyway, you may be interested in the stable revisions idea that's currently being tested, which is under discussion just a couple topics up from this one. --erachima formerly tjstrf 05:18, 1 April 2008 (UTC)[reply]

Expand Template:Bots to allow opt out of other notices

I would like to expand Template:Bots to be compatible with all scripts to all users to opt out of receiving any or all notices produced by bots or scripts. A user can select to receive no messages at all, or specific no messages. That is, if a user wants to not receive any "no rationale" notices, they could put {{bots|nomessage=no rationale}} and then they don't get anymore. Standardizing the tags so it easier for bot owners and script writers to program would be needed but could quickly be done. We could change all the user notice messages to help spread the word, putting a little "Opt out of these messages?" link to the instructions on how to opt out.

So what the heck does this have to do with policy? WP:Bot policy only currently states under Guidelines: Bots which edit many pages, but may need to be prevented from editing particular pages, can do so by interpreting Template:Bots; see the template page for an explanation of how this works. I'm not aware of a scripting policy, but this would include scripts as well. I would like to require all bots and scripts that leave user messages to be required to honor these user opt out requests by May 1, 2008. (date negotiable, I figure 1 month should be sufficient to develop the system and give time for owners/writers to develop the code.) Any bot that is not compliant after this date will be disabled, and then required to reapply through WP:BOTREQ demonstrating they are compliant before having permission granted again. All new bots shall also be able to demonstrate they are compliant with the requirement. Scripts that are not compliant by May 1 will be blanked and the owner warned to become compliant or not use the script. To reiterate, this is only for bots and scripts that leave user notices which include, but are not limited to: orphaned fair use, no rationale, replaceable fair use, no source, no license/copyright, prod, IFD, AFD and xFD. Tags that a user cannot opt out of include, but are not limited to: Warning messages, copyright violations, and blocking messages. By a user placing the tag(s) on their own page, they would be stating they understand they may not receive a message for an image or article that may then be deleted. We could at the same time as advertising this, to advertise/recommend that users place images and articles they are interested in on their watchlist (stressing images, since it is less commonly done, to include images on articles they are interested in).

Why? I have been getting more frequent requests from users to stop leaving the messages on their talk pages, which is inconvenient for me using a script. Allowing users to opt out will increase Wiki happiness, reduce editing loads (bots/scripts won't have to save an edit to a user page, sometimes x10 or more). The only negatives I can see are that images (and other things) may be deleted with users not getting notified, but they would have accepted these consequences. We would help reduce this by suggesting using their watchlist as well. Another problem would be an editor vandalizing a user's talk page by including one of these opt out tags. Perhaps informing vandalism patrols that a user putting one of the opt out tags or changing an opt out tag on another user's talk page is to be considered vandalism and immediately removed/reverted would help. I don't think coding for this should be very difficult for anyone running a bot/writing a script. I personally would use this to stop receiving orphaned fair use messages. Many fair use images I reduced and it appears to bots/scripts that I am the uploader but I am not, so I get the message but I don't care. It would help save my sanity in stop receiving these messages, and requests (sometimes rude) to stop leaving messages on user's talk pages. MECU≈talk 14:09, 1 April 2008 (UTC)[reply]

More tools for Non Admin Users

In the constant every day battle of Vandalism on Wikipedia, one user might find that its almost irritating that he/she cannot do what may need to be done to successfully revert vandalism he/she may come across. Such instances may be protecting a page, blocking a user, ect. I feel that established users (with criteria set forth) have access to certain tools i.e. page protection. Some may say that some users don't need access to this tool because he/she may not use it correctly. THEN REMOVE ACCESS TO IT FROM THE USERS ACCOUNT. I feel that with more tools avaliable, more can be done to make this Encylopedia better. Dustitalk to me 18:56, 1 April 2008 (UTC)[reply]

To be honest, I don't see such an idea gaining consensus. It could be disastrous as edit wars would escalate into protection wars and such like. Protection is a very powerful tool and its misuse could be devastating; imagine a libellous version of a BLP being fully-protected by a relative novice editor; such actions would be damaging to Wikipedia's reputation, even if quickly remedied. I personally don't believe a tool that could cause such harm should be given out to non-admins; RfA standards are not particularly strict, most user with several months experience and good service to the encyclopaedia can easily gain adminship. On your earlier point about "successfully reverting vandalism", many tools suitable for non-admins are available for this purpose including Twinkle which can be used to quickly post reports to RFPP and AIV. Unlike, rollback which is little more than a faster "undo" button, the ability to protect pages should IMO be a carefully-given out privilege to trusted users, with community approval — an effective vandal-reverter does not need the ability to protect pages. Regards, EJF (talk) 19:15, 1 April 2008 (UTC)[reply]
You want users to be able to protect pages and block vandals? And you want them to have these tools without having to prove their trustworthyness first? Theresa Knott | The otter sank 19:17, 1 April 2008 (UTC)[reply]
Dusti, please see this. Isn't gonna happen, sorry. Keeper | 76 | Disclaimer 19:17, 1 April 2008 (UTC)[reply]
No, I don't think they should just automatically given the tools. I think there should be criteria set forth and they should have to meet all that criteria. This would be kinda like the RFA process only not as rigorous. Dustitalk to me 19:45, 1 April 2008 (UTC)[reply]
But, it MUST be as rigorous; we can't just go handing out page protection and blocking rights to experienced editors once they hit 5000+ edits; a proper community process is needed, with the community trusting the applicant - the RfA process makes any such process redundant as it covers the same ground; RfA is not overly rigorous; it generally makes sure only those editors ready for the tools can receive them. An "RfA-lite" process would be added bureaucracy, which is not needed. EJF (talk) 21:41, 1 April 2008 (UTC)[reply]
OK, I can agree with RFA not being overly rigorous; however, with handing out page protection, the process isn't needed to be as rigorous. See, in my opinion, an Admin has access to very powerful tools, and some tools are needed for non-admins to successfully fight vandalism. Page protection is one tool that is needed. Just like with Admin's, an action can be reverted. This tool, in my opinion (and maybe others feel more tools are needed) should be given to those who, after proving themselves worthy, request it. Dustitalk to me 15:59, 2 April 2008 (UTC)[reply]
I'm not sure you realise how harmful a tool such as protection can be; misuse of such a toll could be devastating — and removing the tool is obviously the solution, but the damage will already have been done. I don't understand why you say vandal reverters need page protection, I don't; it is rare on RC Patrol to see that a page needs to be protected; most vandalism is by single IPs; anyway, RFPP is a quick process and there is no point risking damage to the encyclopedia by handing out page protection rights without due process; in BLPs it is extremely important that protection is properly used - would you want a fairly inexperienced user accidentally protecting George W. Bush's biography with the infobox title saying "George Wa*ker Bush"? Once an editor has the experience and judgement to discern when a sparingly-used tool like page protection is needed, they are ready for RfA. EJF (talk) 17:34, 2 April 2008 (UTC)[reply]

←One big advantage to this would be the ability to remove only the powers an admin uses abusively rather than completely desysopping them. Perhaps limited adminship could just be assigned at the discretion of ArbCom, and not through an RfX process. —Remember the dot (talk) 17:43, 2 April 2008 (UTC)[reply]

Agree that limited adminship would be a bad thing at RfX. With rollback, which has a non-rollback version in Twinkle, there is at least a thread a week of someone complaining about not getting it or having it removed. Imagine how many threads there would be about a non-duplicable flag like Protection! Although for very active non-admins (blofeld, sandy, etc), I would support handing out a SpecialUnwatchedPages, since they could help by watching some of those pages. MBisanz talk 17:56, 2 April 2008 (UTC)[reply]
Maybe a "trusted user" usergroup could be given some of the sensitive software features (such as rollback, Special:Unwatchedpages when it gets fixed), but I don't agree with giving non-admins protection, blocking or deletion as these tools are bound to be misused and can do serious damage in the wrong hands. Hut 8.5 18:09, 2 April 2008 (UTC)[reply]
Agreed with Hut 8.5. Also, while I don't like the idea of "unbundling" certain features (for example, giving either blocking or protection but not both would force a patroller to either block users during an edit war instead of protecting the page, or protecting the page instead of blocking a vandal), I think a "semiblock" could be useful (patrollers would be able to block rampart vandals for up to 30 minutes while an admin reviews the WP:AIV report). Sometimes AIV gets backlogged and vandals continue damaging for several minutes before blocked. Note that I don't think a "semiprotect" (protecting a page for up to 30 minutes while an admin reviews WP:RFPP) is necessary, since vandalism is focused on a single page (contrary to a vandal who is vandalizing random pages). -- ReyBrujo (talk) 19:11, 2 April 2008 (UTC)[reply]
I hate to say this, but I agree with all above opinions, and like them. I agree the "semiblock" may be best instead of being able to fully block the user, but I feel that some users (non admins) need to be able to protect a page if needed. What my happen is a user may be at an IP address and go on a vandal spree, like at a library. The user gets blocked on 1 IP and moves to another, and another, until its nerve wracking. At this point, a trusted user who really doesnt want to go through the RFA process, or just doesn't feel ready yet, should be able to do something about this, without having to wait for an Admin to be avaliable to protect the page. That's why I brought this here, to allow some trusted users who go through a process, whether they be considered Semi Admins or whatever, to have a couple extra tools avaliable to better protect the integrity of Wikipedia. Dustitalk to me 18:00, 4 April 2008 (UTC)[reply]

WP:BA (Bad Articles)

Just like we have Good Articles to recognize the reliable and well-written content on Wikipedia, it stands to reason that we recognize when an article is truly below any conceivable standard; in other words, meeting the "Bad Article Criteria". I think this would be especially valuable in that it points out the most dumbass of editors for later informal shunning by the mob community. Please post your thoughts on this. Thanks. Equazcion •✗/C • 19:03, 1 Apr 2008 (UTC)

April Fools' Day proposal

Please see Wikipedia:April Fools' Day. (No this is not a joke, this is very real). Majorly (talk) 23:19, 1 April 2008 (UTC)[reply]

Recent Creations

Basically the same idea as Recent Changes, but well, article creations. I don't know if Recent Changes displays creations, but I honestly think it would be a big help in easily finding articles that need to be tagged for deletion or approval. Something like this is possible right?— Dædαlus→quick link / Improve 10:14, 2 April 2008 (UTC)[reply]

Already there - see Special:NewPages - Peripitus (Talk) 11:44, 2 April 2008 (UTC)[reply]

DumziBot change

I posted this at User talk:NicDumZ, but the author has thus far ignored it. I think it's important, so I'd like to see what people think here and then approach the author again.

I think this bot is a great idea and it works perfectly as far as I've seen. I just have one suggestion: I find that the link text this bot generates is actually less descriptive than the URL. The bot just uses the title of the page, which usually doesn't distinguish the link all that well from others in the reflist. For example, if there's an article on Joe Smith, sourced with a few different biographies on that person, the links would all read "Joe Smith bio", "the life of Joe Smith", or something similar. There isn't much to distinguish one from the other, especially as far as which are from reliable sources.

The most important thing about references isn't really the title of the page, but the root site they're located on. I wonder if you'd consider modifying your bot to include the root site address in addition to the page title -- for instance, something like "Title at Site.com" (Joe Smith bio at timemagazine.com). This would allow a casual glance of the reflist to reveal any unreliable sources, any glaring omissions of sources that should be there, etc.

Thanks and please let me know your thoughts. Equazcion •✗/C • 23:00, 28 Mar 2008 (UTC)

I agree that something like this would be an improvement. The title text inserted by the bot is meant to be more informative than the url, but often it isn't for various reasons. Giving the domain name and the title seems helpful. It might be even more useful if the bot inserted an active link to the domain, and put the same content in the edit summary. - Neparis (talk) 02:24, 4 April 2008 (UTC)[reply]
There already is an active link - to a page in a domain; it's not clear why a second active link is necessary. On the other hand, putting the root domain in the edit summary definitely could be helpful (for someone scanning the bot's edits for improper URLs, or just looking at the article history). Similarly, listing the domain name (incensedblogger.com, or whatever) in the footnote would definitely make it easier to spot citations not meeting WP:RS criteria. -- John Broughton (♫♫) 19:52, 5 April 2008 (UTC)[reply]

no new articles

READ ALL OF THIS. PLEASE. Sorry for that. This might sound crazy, but I have a question. Does wikipedia want:

1: Lots of lower quality articles touching any thing people might want to look up or

2: Very good articles about things people really want to know?

I'm asking this because many articles are just things that could be found just as easily in a more reliable place. So, if you answer two, I propose this. One day to week where we focus solely on improving articles and not making new ones. As I said, call me crazy, but I say 2 is my opinion. Any responses would be appreciated. Thanks. Me what do u want? Your Hancock Please

I think that if you study the development of the project, there has been a slow migration from quantity to quality, and that process is still going on. In fact, I think our rate of new article creation has been slowin down recently. There are several huge initiatives, like all of the featured content assessments,Wikipedia 1.0, and countless WikiProjects that focus on bringing articles up to a high standards rather than making endless new ones. --Arctic Gnome (talk • contribs) 02:01, 3 April 2008 (UTC)[reply]
Because we have millions of wikipedians who won't all read this thread, it's better to try to organize the effort through quality-focused initiatives with people already doing this. Get on the horse and motivate more people to join those groups. Ictionary (talk) 02:21, 3 April 2008 (UTC)[reply]
I think it's useful for Wikipedia to have some short articles which provide external links to the more reliable places where the information on a topic can be found. Otherwise, people might not know where to look for the information. I like finding the official website of an organization in the external links at the bottom of a Wikipedia page, for example. --Coppertwig (talk) 10:56, 3 April 2008 (UTC)[reply]
Agree with the last two posts above. thanks. --Steve, Sm8900 (talk) 15:05, 3 April 2008 (UTC)[reply]
Actually, article creation has been going down since they prevented anonymous users from creating pages - it really isn't any indication of a "change of focus". -Halo (talk) 15:25, 3 April 2008 (UTC)[reply]
Why would the banning of IP creation cause a gradual decline in the rate of article creation? Wouldn't it cause an immediate drop off followed by the trend continuing as before? It seems pretty clear that article creation across the board has slowed down. --Arctic Gnome (talk • contribs) 16:58, 3 April 2008 (UTC)[reply]
The growth went from being exponential to becoming increasingly flat some months after - that's the effect of anonymous article creation. At the time Wikipedia's increased popularity was largely making up for the shortfall, and you also haven't considered the long-term effect of anonymous contributors attracting people to the project. I personally don't think it's coincidence that Wikipedia's growth stopped being exponential mere months after banning anonymous article creation, despite Wikipedia's popularity still growing in that time. -Halo (talk) 18:27, 3 April 2008 (UTC)[reply]
I think it's fallacious to say it's an either/or situation, and it's a false assumption that if article creation was prevented people would work on current articles instead. I see no advantages to "banning" article creation for even one day a week. -Halo (talk) 15:25, 3 April 2008 (UTC)[reply]
We are also just beginning to run out of new notable subjects in many fields, now all the existing Pokemon figures, sports players, tv shows, pop stars etc are covered or nearly covered. It's notable how the balance of DYK noms has switched to historical subjects of one sort or another. Johnbod (talk) 20:00, 5 April 2008 (UTC)[reply]

Editor IM solution

Bear with me because I am new to the process that drives the creation of Wikipedia. Yes, I speak of editing the project.

It occured to me first that articles under major construction could get greater simultaneous collaboration if people could use a JS-driven Wiki chat window to talk about changes and share insights. Of course, that is less-than-optimal because it costs resources to develop and we have user pages to list our IM handles.

So what would be better would be a template that we could easily propagate throughout the wiki that links to a person's IM stored in their User Page. Instead of having to look, you'd know who was editing it and could start an IM easily. Ictionary (talk) 02:18, 3 April 2008 (UTC)[reply]

I don't quite understand what part of your proposal isn't already covered by articles' talk pages, users' watchlists, and users' talk pages. --Arctic Gnome (talk • contribs) 02:40, 3 April 2008 (UTC)[reply]
If you really want real-time conversation, go on IRC, on freenode ; there are channels like #wikipedia, #wikipedia-en, et cetera. More information is available at WP:IRC, and you can log in easily using a Java app at http://java.freenode.net . Now, a lot of it might be off topic, but there are generally plenty of helpful people online, and you can get an admin's attention in real time by saying "!admin". Nihiltres{t.l} 11:43, 3 April 2008 (UTC)[reply]

New Pages

Is there any way that a message could be put on this page to remind editors who are patrolling to mark them as patrolled. It is very annoying when you click on a page and it has been patrolled already. Or maybe make the mark this page as patrolled bigger or move it to a more prominent position on the page. BigDunc (talk) 17:15, 3 April 2008 (UTC)[reply]

Well, I think really the deal with that is first come, first serve. Nothing444 22:00, 3 April 2008 (UTC)[reply]
What does that reply mean? Do editors not have to mark the pages as patrolled? And if not then why is there a link for it to be done? Im afraid I cant say that was the most helpful of replies. BigDunc (talk) 07:34, 4 April 2008 (UTC)[reply]
I think what it means is that it's not a must to mark articles as patrolled. I can imagine in some cases where users are unsure so leave it. I wouldn't be opposed to a notice, though. The message is at MediaWiki:Newpages-summary - perhaps an {{editprotected}} request there would get some attention. x42bn6 Talk Mess 19:21, 5 April 2008 (UTC)[reply]
I doubt adding more to the notice will have a very large effect and could have some WP:BEANS overtones, though I'm not opposed. I think the best course is to target those doing a lot of newpages patrolling of the sort that usually are associated with a full patrol for which a patrolled marking normally is done (i.e., prodding or tagging articles for speedy deletion, as opposed to stub tagging), who are not doing the marking, and dropping them a message about the issue. There really aren't all that many prolific newpages patrollers at any given time and we only get a few new ones per week I would estimate, so informing the bulk of them in this manner should not be impractical.--Fuhghettaboutit (talk) 19:35, 5 April 2008 (UTC)[reply]
Okay I made a template for alerting users to the issue. {{Uw-patrolled}}.--Fuhghettaboutit (talk) 20:03, 5 April 2008 (UTC)[reply]

Possible consequences of Axis victory in Second World War

It was in my thought, I am now proposing this. The editors who have major contribution in the Second World War or related articles, can they create a n article title Possible consequences of Axis victory in Second World War? The article may be somewhat speculative, but surely there are scholarly works available on this. Otolemur crassicaudatus (talk) 23:11, 3 April 2008 (UTC)[reply]

The talk page of World War II is probably the best place to ask - this is more for Wikipedia-wide proposals. I think there may be problems with that sort of article, since it seems too highly speculative to present anything concrete -Halo (talk) 03:04, 4 April 2008 (UTC)[reply]
Sounds a bit too much like original research to me. However, like you say, there may be a few people who have already put together some work on the subject that you could quote - the speculative fiction novel Fatherland comes to mind. Confusing Manifestation(Say hi!) 03:25, 4 April 2008 (UTC)[reply]

Protection of FA class articles

Perhaps when an article reaches FA class, it should be protected, vandals will usually seek out FAs and it will also protect from editors adding info that really subtracts from the FA. Doctor Will Thompson (talk) 06:04, 4 April 2008 (UTC)[reply]

See Wikipedia:Perennial proposals#Protect_featured_articles as to why this is a really bad idea. -Halo (talk) 09:52, 4 April 2008 (UTC)[reply]

Systematic bias of Wikipedia / A Solution

Description of the systematic bias

The economic basis for the academic's life is dependent on publishing papers. If they want to join a reputable institution, they have to become famous too. How can they do that, well all they need to do is to tell people: "so far you all thought that a matter was like this, now I tell you that you were all wrong" and then come up with a new theory. This is not so bad when it comes to empirical sciences because one can do new experiments BUT when it comes to history new data would not be created everyday. The original sources are all there.

So, how do the academic live? Academics are very lucky that most of the history is not sufficiently well sourced (and it is the academics themselves who define "sufficient"). Here is what makes academics look innocent: if something happens today, witnesses after some time start saying different things; what can we then say about something that happened thousands of years ago. This sad truth has given the academics enough flexibility to create their own curious theories, to project their own cultural tendencies and secular views back into the history.

The academic biases and shortcomings show itself most vividly in religous historiography. The academic don't have to openly express their underlying assumptions; it goes implicitly into their writings and evaluations. Suppose the academic is living in a society that is obsessed with something, the academic would then imposes his/her this in his/her scholarship of the past.

Let's take the example of someone wanting to write a biography of a figure like Muhammad or Jesus or other ancient figure. For that matter, the scholar has to first create a rough overall image of the figure. It is then under the light of this overall image that the scholar proceeds to evaluate which reports are sound, and how the sound ones should be interpreted. The formation of that rough overall image does not, and can not, be merely based on the early written reports of the figure. Much of it consciously or unconsciously comes from the underlying biases of the established intellectual tradition of the time, the scholar's own values and his cultural values, plus his own past experiences putting aside the politics. Please note that I am not claiming that the religous biographies are completely free from such distortions but there is a difference that I will point out in the solution section.

To cite another example I'd like to draw the attention towards the relation of scholarship and politics is very obvious. Here is a quote from Journal of Semitic Studies, Oxford University Press:

The relationships between the Jews and the Arabs throughout history have been the subject of numerous studies over many centuries. However, as long as the continuous Arab-Israeli conflict has not found a solution, historians will search through the past in order to find new evidence to prove the antiquity of the tension between the two communities and to illuminate its causes. The vicissitudes which have marked the lives of the Jews who lived under Arab rule or side-by-side with Muslims add to the complexity of the issue, and a great many of the assertions about Arab-Jewish relations made by scholars and amateurs alike are sheer speculation. This is particularly true of writers who strongly identify with either camp and have become emotionally involved in the subject. Consequently, the views they usually hold are often unbalanced, if not biased.

I have found such criticisms of academic approach to religous studies are found in serious apologetic texts of many religions.

Solution

I think the main wrong underlying assumption in the academic works is that knowledge is of one form and that is all that can be written on the paper, and in third person perspective (not personal). The knowledge and wisdom gained through experience has no value unless it can be written on the paper so that even a computer can check it. Most scientific works tend to minimize the role of the audience in the process of learning. In the eastern mode of thought however the person has to travel a path, reach some form of purification, enlightenment or whatever it may be called in order to be able to see the truth. Certain traditions have had much emphasis on the role of spiritual teacher in acquisition of knowledge. Such a perspective is seriously important when it comes to religious studies.

Wikipedia articles, as of now, are systematically biased because their representation of religous topics are so different from the way the religions traditions themselves represent themselves through an emphasis on practical advices, do-and-don'ts, rituals, or manuals. This is the way Muslims, Christians, Buddhists and in fact "non-philosophers" have looked at it(note: I am aware of the involved technicalities here- these religions say that understanding is granted from God to man as a gift merely by God's mercy). If I want to learn about a religous topic, I need to learn something about it, then do something from what I have learned, then learn something more, ... and back and forth. In Wikipedia therefore when we write about Christianity, I think, we should tell something about God's love in a section, then finish it with some concrete things one can do to understand it better, like say "forgiving others". This way, one can learn how Christians deduce the life style from the concept of "God's love". For Islam, it is "Tawhid" (unity of God) that replaces Love in Christianity but it is essentially same thing. The Qur'an like all other religous traditions puts emphasis on this aspect of understanding saying "None shall touch it except the purified" (Qur'an 56:79).

Now, my suggestion is that we create "practical advice/manual" boxes whenever appropriate in the religion related articles and make wikipedia articles more engaging. We can even have separate wiki named "wiki-practical-menus" just as we have "wiki-source" and other wikis.

I want to end my proposal with a poem from Rumi who said something in relation to the philosophers of his time that can be more accurately applied to current academia:

"The rationalists' legs are wooden
Wooden legs are very fragile.

Cheers, --Be happy!! (talk) 09:29, 4 April 2008 (UTC)[reply]

TL;DR
(cough) Okay, maybe I can be a little more constructive. What you're proposing is essentially more like teaching the religion than an encyclopedic article about the religion. We're not here to teach folks what it means to be Christian (as if we ever could encompass that in a single page!), but what structures and practices are in place that make up the Christian religion(s). In shorter terms, what you're proposing would just be a different bias than the one you believe is in the articles. -- Kesh (talk) 22:36, 4 April 2008 (UTC)[reply]
Kesh, consider someone who has only the capability to see the black and white images (no color). How the person's view of say color red would be? He/she can only talk about it symbolically; or assume a person who is living in two dimensional world, how can he/she talk about three dimensional objects? I hope you see where I am going. Writing about something is not really separate from understanding it especially if one wants to get into a bit of detail. --Be happy!! (talk) 07:42, 5 April 2008 (UTC)[reply]
In many regards I find I agree with both standpoints. I think that in some respects that in order to teach about the religion you have to teach the religion itself, but there are difficulties in that regard in that people interpret religion differently. Therefore, drawing 'conclusions' in matters that are not authoritatively verifiable is not only unencyclopedic, but dangerous.
On the other hand, it would not be feasible to just copy and paste the entire bulk of religious scripture on the matter, which is even less encyclopedic. I do think that Aminz is on to something in that greating some sort of guide to compiling the tenets of a religion or philosophy into an encyclopedic format is a beneficial idea for making Wikipedia more informative and readable. Peter Deer (talk) 09:21, 5 April 2008 (UTC)[reply]
Dear Peter,
Thank you for the input. My point was that action is not divorced from knowledge; in other words, acquiring knowledge and action go hand in hand, and one without the other can not possibly exist in full form. One can not separate the two even theoretically but that is in fact what is done in Academia. In my humble opinion, there are more differences of opinion when it comes the theoretical issues and statement of beliefs (already covered in wikipedia) than with the practical ones. --Be happy!! (talk) 09:41, 5 April 2008 (UTC)[reply]
Let me put it in another way: When does a theory gains widespread acceptance? It happens when many people find the theory makes sense; when the pieces fit together. But much of this comes from their shared personal experience in real life. Two persons can not communicate an idea with each other unless they share some sort of concepts and experience. But religions want to create those experiences for people so that people can understand its message. If scholars do not gain those experiences, they can sometimes miss the point completely.
P.S. I think Marxists go as far as saying that the criterion for a theory to make sense in a culture or subculture is determined by the economical basis of people living in that culture(or subculture). --Be happy!! (talk) 09:54, 5 April 2008 (UTC)[reply]
  • This looks to me to go against long-standing practice and to introduce special pleading. Religions can hold their own without this. Well, most can, and the ones that can't probably don't deserve to. The idea may be founded in a sincere desire to improve things, but as far as I can tell the most likely result is a series of POV-forks created on a separate namespace and linked as if they have some kind of official standing. Think Conservapedia here. Guy (Help!) 10:19, 5 April 2008 (UTC)[reply]
Dear JzG, Thank you for the input. It is correct that we should not go for it in an arbitrary manner or to apply double standards. Yes, without this we can still live but we can and I believe we should go beyond it. Painting a flower is essentially less than the experience of smelling it.
My suggestion is to add special boxes (just as tables and images) whenever appropriate in the religion related articles and tell people about the practices or concrete actions that would provide the audience with the real-life experiences required to grasp the meaning of the section. I do not want to create new article.
Another suggestion is to create a "todo-wiki", "ritual-wiki", "practice-wiki" or a "manual-wiki" that specifically deals with this.
One last point: Academia is an established institution just like other institutions. It however has the claim of providing knowledge to people but in reality only restricts itself with certain types of knowledge. For example, if one looks at the testimony of converts to all religions, they indeed talk about a story, a series of experiences during which the person has gained certain knowledge. The academic definition of knowledge however excludes this form of knowledge. In academia, a person may teach ethics without practically being true to his or her teachings; this is because a strict line is drawn between knowledge and action. --Be happy!! (talk) 10:33, 5 April 2008 (UTC)[reply]
What Amin has written is true, but - and that's the problem - I don't think we can do much about it, since it seems like the proposed solution contradicts the idea of an encyclopaedia that tries only to present the current state of knowledge on things in academic discourse. However, I'm new here and not very familiar with things, so I might be wrong about the aims of Wikipedia. So, in my opinion, we should implement the idea of Aminz if it doesn't contradict Wikipedia rules. --Devotus (talk) 13:28, 5 April 2008 (UTC)[reply]
Wikipedia is supposed to be "The Sum Of All Human Knowledge" :) --Be happy!! (talk) 20:04, 5 April 2008 (UTC)[reply]

I vaguely understand what Aminz is suggesting. The problem is, particularly in the case of religion, there are no set standards that can be applied as to what the beliefs are, and how they should be represented. For example, there are between 15,000 and 40,000 sects of Christianity, all with different views about how to interpret the bible, or what version of the bible to use, or what books are included in the bible. They disagree with each other drastically, but proponents of each will claim only their sect is correct, and the article must be written from the viewpoint of their sect.

The same is true of other religions. Islam also has a large number of sects that disagree with each other. Is Salafism the same as Wahabism? Some say yes, some say no. Is Salafism really Islam? Some say yes, some say no. Are the Sufis Moslems? Some say yes, some say no. The Ismailis? Some say yes, some say no. The Sufis? Some say yes, some say no. Which hadiths should be followed? Which are most important? How should they be interpreted? What is allegorical and purely figurative, and what is literal? What does jihad really mean? Are Moslem husbands required to beat their wives are not? Some Imams say yes and some say no. Who can issue a fatwah and who must follow it? Is honor killing part of Islam or not? Is female circumcision? Are women allowed to be educated in Islam or not? Are images of Mohammed permitted or not? Were they ever permitted? The deeper you investigate all of these questions, the more complicated it becomes. There is immense disagreement and evidence on various sides of each of these issues.

The only way to deal with this is to take a neutral dispassionate view, as much as possible (although it is never totally possible). One can point out who believes what, and how these beliefs hae changed over time. One can cite sources so that the reader can dig in deeper and come to their own understanding. It is best to try to present ALL the relevant views and beliefs that are notable, and not try to decide which is the "right" view. Some might find this offensive, but Wikipedia is not a proselytizing tool or a religious tract. It aspires to be a scholarly examination of assorted topics. If this offends some, that is regrettable but unavoidable.--Filll (talk) 15:04, 5 April 2008 (UTC)[reply]

Agreed: one problem with the great religions is that different groups have different opinions about what the religion really is. DurovaCharge! 16:10, 5 April 2008 (UTC)[reply]
Thank you very much Filll for your comment. I think you are correct about the difficulty involved here. But sometimes practical disagreements are less than theoretical ones (which we are already covering): Religions try to produce certain forms of personal experiences in their followers that would facilitate their understanding of the underlying concepts. Thus for example one may not understand the concept of real charity without actually doing it. The idea of monotheism could not be understood if for example one does not recognize false gods in his or her daily life. Now, why are these important for historians? Because they want to decide whether some reports about a historical figure really happened, and they can be helped if the scholars and the historical figure share certain personal experiences and if the scholars can really connect with the personality of the historical figure. --Be happy!! (talk) 19:54, 5 April 2008 (UTC)[reply]

Rollback permission modification

Having admins use a separate requests page to handle rollback requests is time-consuming and inefficient. It wastes both editor time and admin time, when there are better alternatives that could be used. MediaWiki is capable of "autopromoting" a user automatically using set criteria.

Proposed: All users who have 300 edits and have had an account for over 30 days are automatically given the rollback right.

The only caveat is that using this method does not allow removing the right. If a user abuses their editing privileges using rollback, they will be blocked as most users who are disruptive are. --MZMcBride (talk) 03:59, 5 April 2008 (UTC)[reply]

Data: - on 4 April, the most recent day, there were a total of four requests for rollback. During the roughly three months that rollback has been available, 1125 editors have been granted this right - around a dozen per day. -- John Broughton (♫♫) 19:42, 5 April 2008 (UTC)[reply]

Support

Conditional support

If this is automatically granted, it should be revokable.

Comment: I don't know if the software even supports auto granting with manual removal. (1 == 2)Until 13:36, 5 April 2008 (UTC)[reply]

Oppose

  • We need to be able to revoke this tool, there are already people who are refused this tool because they have abused it. We cannot expect a user to use the tool properly if they don't even know what it is, and I would hate for the only alternative to be blocking the user. (1 == 2)Until 04:11, 5 April 2008 (UTC)[reply]
  • POV trolls + rollback = disaster. Sceptre (talk) 04:25, 5 April 2008 (UTC)[reply]
  • There are just too many possibilities of issues arising. Perhaps the current system is a bit flawed, but this solution isn't the best one. Jmlk17 04:27, 5 April 2008 (UTC)[reply]
  • Brb... going to create a few sleeper accounts and set them to edit their User: space and/or sandbox a lot. :P --slakr\ talk / 04:29, 5 April 2008 (UTC)[reply]
  • I disagree with this idea, as there will be many users who could possibly violate the use of this tool so they can edit war per their POV, and there are many more issues that could possibly arise such as the one slakr mentioned above. It would put much more strain on administrators to have to continually block people, instead of just accepting or denying rollback requests. --ChetblongTalk/Sign 04:34, 5 April 2008 (UTC)[reply]
  • Yea, I'm not seeing the current system as so flawed to require this sort of solution. MBisanz talk 04:36, 5 April 2008 (UTC)[reply]
  • Do the admins involved think this is a waste of time? Any time spent is probably overweighed by the overall benefit. –Pomte 05:18, 5 April 2008 (UTC)[reply]
  • Absolutely needs to be revokable. Majorly (talk) 14:10, 5 April 2008 (UTC)[reply]
  • Absolutely nothing wrong with the current system - there have been few problems so far, and any problems have been easily sorted. Removal of the tool due to abuse is far better than a block and is more likely to educate otherwise productive users in the future. There have been a number of cases of abuse of the tool, and these have been dealt with swiftly, but it shows that not every established user is capable of using the tool constructively. Ryan Postlethwaite 17:43, 5 April 2008 (UTC)[reply]
  • Strongly oppose this: there are some people who clearly cannot be trusted with rollback, the same way there are people who can't be trusted with adminship. Giving rollback to everyone would be disruptive: while this proposal says that the current system is inefficient and time-consuming, imagine all the time that would be wasted from every single POV-pusher and revert warrior having rollback. The "easy give, easy take" process is excellent, and I would rather have admins spend a few minutes reviewing a user's contributions than have AN/I bloated with threads about all the disruptive users abusing rollback. Finally, "300 edits" isn't a measure of trustworthiness either: there are people with 3,000 or even 30,000 edits who would abuse rollback. Acalamari 18:39, 5 April 2008 (UTC)[reply]
  • Very strong oppose for the exact same reasons as Acalamari. bibliomaniac15 Hey you! Stop lazing around and help fix this article instead! 19:10, 5 April 2008 (UTC)[reply]
  • It seems too risky to award a privilege like rollback automatically solely on the basis of number of edits and number of days of editing experience. Is there a longstanding problem of significant backlogs at rollback requests? If there is, couldn't it be solved by the involvement of a few more admins? - Neparis (talk) 19:15, 5 April 2008 (UTC)[reply]
  • Oppose per Acalamari. Soxred93 | talk bot 19:32, 5 April 2008 (UTC)[reply]
  • Oppose - there is no evidence that the current system causes admins a lot of work (given the low volume, it's hard to believe that the current system is a problem). On the other hand, the proposal make make it far easier to set up sleeper accounts with rollback privileges. -- John Broughton (♫♫) 19:45, 5 April 2008 (UTC)[reply]
  • Oppose Per others. It aint' broke, so don't let's fix it. Johnbod (talk) 19:52, 5 April 2008 (UTC)[reply]
  • Oppose - this would have been great on any other wiki but on enwiki, it will spell disaster, such as POV pushing, rise in 3RR cases etc...--Cometstyles 20:20, 5 April 2008 (UTC)[reply]
  • Strong Oppose: Automatic rollback? Getting 300 edits is easy, and a month? After which rollback could be used for POV pushing, and reverting a large amount of user edits. I feel this would increase 3RR violations, edit wars, and could be misused by vandals. I'm sorry, this is something I cannot support with good confidence. It's too risky. Steve Crossin (talk) (anon talk) 20:27, 5 April 2008 (UTC)[reply]
  • No-way Oppose Bad idea per above. CWii(Talk|Contribs) 20:31, 5 April 2008 (UTC)[reply]

Discussion

  • Comment - I think that although the rollback right is a good tool to give out widely and so forth, I'm initially cautious of the idea to give it to people automatically. Aside from the fact that it should be revokable, one of the current dividers that separates rollback and other bits from nasty use is self-selection. People who self-select to receive a tool will look at that tool differently from those who are given it innately as a right. From there, it's only a delay. For example, our semi-protection of articles is a ridiculously low barrier to overcome to vandalize an article - wait four days, and you have at least one account that can edit semi-protected articles at will. The difference is that users self-select to register and gain rights which allow them to accumulate trust. This, interestingly enough, deters most vandalism as it adds a level of self-selection to those who choose to vandalize, who must then apply even a minimal effort to achieve their mischief.
    By extension, there should probably be some level of self-selection for slightly more advanced abusable tools within the community; we already have a heavy form of this for adminship, where users are forced to undergo a gauntlet run, a review of those actions which they have taken and their dedication to the community. It, nevertheless, is game-able - people might remember Oldwindybear as an example. Self-selection is the best tool we have for finding people who are deserving of the community's trust; they come forward of their own because of their interest, with a willingness to follow community guidelines. I'm therefore concerned that removing the element of self-selection applicable to the right might cause issues with its use. As long as self-selection is applied and the right is revokable, I don't see how this could be a problem. Nihiltres{t.l} 06:29, 5 April 2008 (UTC)[reply]
  • Comment - what would this give me that Twinkle doesn't already give me? I've done a lot of edits and quite a few of those were because of vandlism, but Twinkle has worked fine for me.Doug Weller (talk) 09:28, 5 April 2008 (UTC)[reply]

Peer reviewed material

Wikipedia provides one of the most extensive user friendly information dat bases in the world. Scholars often frown on it's used becuase of the free access and abilty to update.

I am proposing that a peer review designation be established. Scholars could be invited to review subject matter and then provide a certification. the participation could be totally voluntary. A verification interface would be need so that users could contact the institution or association that certifies the reviewer is quanlified to make the scholarly review.

wikiFood

I suggest we make this and official sister of wikipedia. – i123Pie biocontribs 14:51, 5 April 2008 (UTC)[reply]

Sister sites of Wikipedia are not existing sites, unrelated too Wikipedia but using wiki software, that we "make" into sister sites. Rather, sister sites are sites founded by the overarching organization, The Wikimedia Foundation, Inc., that operates Wikipedia as one of its stable of online collaborative projects which includes Wikipedia and other sites (full list). Wikifoods at Scribblewiki is apparently owned by Linger Media Company, and is wholly unrelated to the Wikimedia Foundation. So we couldn't just make it a sister site. We would have to buy or lease the rights from the owner. You can, of course, propose new projects to the Wikimedia Foundation. Please see m:Proposals for new projects. In fact, a wikifood project was previously proposed in March of 2006, as you'll see if you search that page, but it seems to have garnered little support as yet.--Fuhghettaboutit (talk) 15:40, 5 April 2008 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=203590371"