Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Mackdiesel5 (talk | contribs) at 23:29, 23 December 2009. 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
New ideas and proposals are discussed here. Before submitting:

Get rid of PROD

I've been thinking about it for a while now. The process involved in PROD, while ideally designed to reduce the workload at afd, leaves too many articles open for deletion that simply don't have anyone watching them. Articles that have inherent notability (such as many facets of geographical locations. Towns and such in countries that do not have any involved English editors) can often be deleted without notice to anyone. These articles are not "less important" because they do not have any sources, or because they haven't changed in several years, or because they contain a bare minimum of information. These articles have broken the ground where other editors will one day expand upon and fill in information.

In short, PROD only determines that nobody is watching an article, not that its deletion is uncontested. All non-speedy deletions merit some discussion. - ʄɭoʏɗiaɲ τ ¢ 19:20, 3 November 2009 (UTC)[reply]

I don't know of an admin that would delete an article through PROD that they believe has poor reasoning to be deleted... I don't totally disagree with you, but there are people who watch WP:PRODSUM too.--Unionhawk Talk E-mail Review 19:24, 3 November 2009 (UTC)[reply]
This sounds more like an argument of deletionism versus inclusionism. As noted above, WP:PROD doesn't automatically delete pages after seven days. It still comes down to a judgment call by the acting admin. --King Öomie 20:44, 3 November 2009 (UTC)[reply]
Interesting page, thanks. I might have seen it before, but can't remember. I've just declined a PROD I saw there. –Whitehorse1 12:40, 6 December 2009 (UTC)[reply]
Admins should not be deleting article on-sight merely because they are an expired PROD. Spurious nominations can (and should be) declined. Shereth 20:46, 3 November 2009 (UTC)[reply]
Well you can look in the deletion log, and ask an admin to have a second look at deletions that look as if there ws a prod on a notable topic. Do you have some examples you would like restored? Graeme Bartlett (talk) 20:48, 3 November 2009 (UTC)[reply]
You are assuming an admin opens the article and looks at it. There are several different tools designed to allow one to delete entire categories (like old PROD categories) without the bother of having to manually open each page. Dragons flight (talk) 20:55, 3 November 2009 (UTC)[reply]
That would be bad, and I would be disappointed if that occurred (without review). People have been shot down at RfA's for missing a single CSD borderline case. If we have admins deleting entire categories of content without review, that would be a very bad example. —TheDJ (talk • contribs) 21:48, 3 November 2009 (UTC)[reply]
I would expect that an administrator deleting all expired prods without bothering to look at them would be admonished, if not desysopped. That's a severe misuse of tools. -- Atama頭 22:07, 3 November 2009 (UTC)[reply]
Well perhaps you should talk to the frequent deleters of PRODs and ask them about their process. (The history of PRODSUM makes it easier to identify who is is really doing the deletions.) For example, NuclearWarfare (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) is a frequent closer of PRODs and often deletes 20 such pages in a single minute. I would assume he uses a tool to accomplish deletions at that speed. Now, he could have reviewed every one of those beforehand, in which case there is no issue. Historically though there are certainly examples of people using tools to clear deletion backlogs with no review. For example, I remember someone deleting some 700 disputed fair use images without looking at their content or considering the validity of the dispute. Such people can get yelled at, but they are rarely desysoped. Dragons flight (talk) 22:45, 3 November 2009 (UTC)[reply]
I'd like to point out that when I was an admin, I often handled several days of PROD at a time. I'd open up dozens or hundreds of tabs, go through them all (removing more than a few nominations, although in general PROD seemed pretty accurate & I consider myself an inclusionist) either editing them or opening up the deletion field, and then I'd make a second pass. So even though the log would show many deletions a minute (and even per second if I was typing particularly fast), I was still reviewing them all exactly as they should've been. Doing it this batch way saved me vast amounts of time because I didn't have to wait for several seconds of loading & rendering time for each page. From the outside, I don't think there's any easy way to see whether NuclearWarfare is employing a batch method or not. (Although I suppose you could look to see whether there are miscellaneous edits or PROD removals in the 20 or 30 minutes preceding a mass-deletion.) --Gwern (contribs) 00:52 10 November 2009 (GMT)
  • oppose if an article has no one watching it, I don't see it as much of a step towards creating a genuine article on the topic. Stubs are good up to a point, as sort of an outline for future development, provided it's actually a good outline. But I would think that the unwatched status of unwatched stubs might be correlated with them not being particularly good outline items. In cases where that's not so, the article can always be recreated. There's a legitimate concern that the editors who do care might have large watchlists and not notice the PROD, but that could be dealt with by formalizing the courtesy notices into a requirement. --Trovatore (talk) 20:54, 3 November 2009 (UTC)[reply]
  • Oppose. Prod is a valuable process. There is a group of regular prod patrollers who could always do with extra help. I regularly prod patrol, and in my experience the vast majority of articles deleted by prod have no chance of meeting our criteria. We delete maybe 60-80 articles per day via prod, and I rarely deprod more than two from a single day. Prod avoids the drama and sucking up of time of editors that AfD involves, and it is less severe than speedy deletion. Admins don't just blindly delete expired prods as they can contest the prod themselves if they see fit, and any prodded article can be restored at any time. Another option if you don't have the time to properly improve a prodded article is to move it to the Article Incubator. Fences&Windows 21:20, 3 November 2009 (UTC)[reply]
  • Oppose - I wonder what basis Floydian has for this argument, as it doesn't seem to match what WP:PROD states or how proposed deletions are actually processed. Articles that do not have any sources, haven't changed in several years, or contain a bare minimum of information would be as unlikely to be deleted via PROD as they would via AfD or CSD. As said above, every article deleted through PROD has been reviewed by an administrator who uses his or her own judgment regarding the deletion justification given when the deletion is proposed. Should we get rid of speedy deletions because someone might incorrectly put an A7 tag on a notable article subject that isn't being watched? -- Atama頭 22:05, 3 November 2009 (UTC)[reply]
  • Oppose - PROD helps keep the workload at AFD manageable. Users' time is not an infinite resource, we should allocate it to discuss articles that actually might warrant a discussion. If anything we need to use PROD more. Any article deleted after a unanimous AFD could potentially have been PROD'ed. Mr.Z-man 23:16, 3 November 2009 (UTC)[reply]
  • Alternative: WT:PROD#Userfy PRODs instead of delete?. Rd232 talk 00:57, 4 November 2009 (UTC)[reply]
The basis I have, which initially got me going on this idea (aside from my own opinion that as long as an article isn't utter BS of defamatory than it usually deserves a place here) was the over PRODing of articles by Less Heard van U (who is an admin I believe, and may have been deleting those articles after 7 days), who was doing so solely on the basis of A) a lack of sources and B) a certain size requirement. - ʄɭoʏɗiaɲ τ ¢ 03:00, 4 November 2009 (UTC)[reply]
If you think the articles should have remained, tell the deleting admin, and they should restore it as a contested PROD.--Unionhawk Talk E-mail Review 03:09, 4 November 2009 (UTC)[reply]
That's an issue to take up with the admin, or his/her behavior. There's no benefit to changing our policy based on one incident. BTW, you can see who deleted an article in the logs. Would be best to do that before making accusations. — The Hand That Feeds You:Bite 18:58, 4 November 2009 (UTC)[reply]

PROD was intended to replace AFD and CSD. Somehow that process stopped halfway, and now we have 3 systems, instead of one good one. I wonder how much time it would take to take things a few steps forward again, sometime soon? --Kim Bruning (talk) 01:30, 5 November 2009 (UTC)[reply]

Kim, I think your memory is betraying you on this one. I don't believe anyone seriously proposed PROD as a replacement, but rather it was originally proposed as a way to take some of the load off a chronically overworked AFD. Dragons flight (talk) 01:56, 5 November 2009 (UTC)[reply]
I know at least some folks (like me ;-) )wanted it to be side-by-side and then eventually replace, because AFD at the time was really bad, and admin deletion sucks in general. AFD has improved since then, CSD hasn't. It might be nice to actually work on updating the systems with what we've learned since last time, and simplifying besides :-) --Kim Bruning (talk) 02:10, 5 November 2009 (UTC)[reply]
I don't know why we need multiple systems and huge bureaucratic structures for deletion proposals. There should be one template that you stick on the talk page if you think a page warrants deletion. Have a bot date these templates, then an admin comes round after the appropriate time and decides what to do (based on the arguments given, if any, plus his/her own knowledge about wider consensus). No fuss (well fuss about whether to delete the page, obviously, but no additional complications spawned by the process itself). Ah, but that would be too simple, we have to let the wikibureaucrats have somewhere to play... --Kotniski (talk) 16:14, 5 November 2009 (UTC)[reply]
We don't have to let 'em play at all! I think you could sort of treat it like a hygiene issue analogous to -say- malaria at the panama canal: Eliminate the breeding grounds for them and/or the vector (simplify and tidy areas where too much bureaucracy has encroached), and inoculate people against them (by getting people to understand IAR and consensus as early as possible)
Do you think we can still stamp out the disease? ;-) --Kim Bruning (talk) 22:21, 5 November 2009 (UTC) To be clear, I'm not sure AFD is as much of a problem area as it was years ago. I think the bureaucrats have retreated to other areas.[reply]
Getting rid of PROD would at least concentrate the problem in one area (AFD), rather then spreading it out. The real issue with the current deletion process is simple: it's not structured enough. Surveys and widespread general opinion have shown for quite a long time now that at least the perception, if not the reality of, our current deletion process is simply too random. I know from my own personal investigations that the admins who regularly participate in AFD definitely have a brain on their shoulders, and there is at least a DRV process now in order to take care of the more egregious deletion problems. Those two items make me fairly confident that the majority of deletions that do occur are at least defensible. The fact remains that the process itself is still far too random, however. We all know that there are articles that almost every would agree should be deleted, yet when those articles manage to be identified they can still be difficult to delete. More serious is the fact that many "borderline" articles continue to be deleted on a daily basis. What some deletion advocates seem to (continuously!) fail to grasp is just how permanent and therefore demoralizing and damaging deletion is to author/editors... I don't want to turn this into more of an Inlcusionist rant then it already is, so I'll end here by simply saying that I support deprecating the confusing and unnecessary PROD procedure.
— V = I * R (talk to Ω) 05:00, 7 November 2009 (UTC)[reply]
FWIW, the majority of deletions are via CSD. In terms of deletions per day, there are about as many articles deleted via PROD as via AFD, and about 10 times as many articles deleted through CSD as AFD and PROD combined. Mr.Z-man 05:33, 7 November 2009 (UTC)[reply]
Yeah. Honestly, I only use PROD if it's only borderline CSD. Most of my prods get deleted under speedy criteria.--Unionhawk Talk E-mail Review 05:43, 7 November 2009 (UTC)[reply]
The thing is that you guys are right. Nobody is disputing the point that probably 99.9999999+% of all deletions are perfectly acceptable... but, none of that matters. The 0.0000001% of deletions that are not acceptable are the ones that are noticed, and the fact is that they should be. No matter how much potential good that the proper deletions gain the project, the fact is that the few instances of bad deletions do enough damage to far outweigh the good. At least, in my opinion.
There are those who take similar views and create an ideology that "all deletions are bad", which is just as much of a problem as doing nothing with the current deletion process is. I personally feel that a temporary moratorium on deletions (and a short one at that, possibly even just a few hours) is at least called for. However, that action is predicated on the belief that we can and should actually make a change that will better the project as a whole. Article deletion for it's own sake shold be stopped. Preventing article deletions for the sake of preventing deletions should be stopped as well. The process as a whole needs to be tweaked, at least, and intentionally slowing it all down certainly couldn't hurt (although, admittedly I do recognize that doing so will anger a certain percentage of the editorial population). At the very least, if all but the most egregious deletions take 7 days (or possibly even a couple of days longer)... who or what is harmed by that?
— V = I * R (talk to Ω) 06:56, 7 November 2009 (UTC)[reply]
I would say that even if 5% of deletions by Prod were erroneous, the system is working fine. When people notice that their article is gone, they generally contract the deleting admin, and the article is restored. Abductive (reasoning) 07:01, 7 November 2009 (UTC)[reply]
No, no, no... anything as "in your face" as deleting articles simply cannot stand up to this line of thinking. If we were talking about normal open editing procedures then I would agree with the point that you're making here, but the simple fact is that we're not.
Article deletion needs to be treated with the same... "respect" (for lack of a better word) that blocking is treated with, and for the same reasons. I'm not arguing that the deletions are a mistake at all, just as the vast majority of blocks are perfectly acceptable. However, in the exact same manner that good blocks still create controversy and emotion, deletions will and should cause the very similar reactions.
Think about this: if there was some sort of a "speedy block" policy/procedure being proposed, what would your reaction be to that? Granted, the analogy is far from perfect here, but at least give it a chance.
— V = I * R (talk to Ω) 07:21, 7 November 2009 (UTC)[reply]
I guess I was just wondering why you seem to have a problem with the lack of a formal process for PROD and not for CSD, even though PROD can be overturned by anyone for any reason at any time. Why are you assuming that all of the bad deletions come through PROD? It isn't a "speedy" procedure at all, so your analogy doesn't make any sense. PROD takes as long as an AFD. Mr.Z-man 17:05, 7 November 2009 (UTC)[reply]
Actually, if I had my druthers, I would prefer to severely restrict the use of CSD, along with simply switching the PROD procedure to use AFD instead (which is effectively what we're talking about here). I don't really believe that any change in the deletion process is possible, but this at least started a discussion about it. It's just... complicated. For newer editors, and especially for part time editors (which, in my view, are probably the most important editorial members of Wikipedia), the fact that there are three different processes with a fourth follow up (CSD, PROD, AFD, with DRV to follow up) is simply confusing and overwhelming. The WP:DELETION document is in a perpetually confusing state. Whether someone comes along and decides to start one of the deletion processes on an article is way to random, and CSD and PROD almost always occur too quickly for non-regular editors (and even many regulars) to really follow the process (never mind the fact that there are simply too many deletion discussions to really follow). PROD does take as long as AFD, but it's a mostly silent procedure so the perception is still there of fast change.
Anyway, as I said earlier I don't really think that there are many bad deletions, if there are any at all. This isn't actually a discussion about reality though, it's a discussion about perceptions. All of you who oppose this proposal are on solid factual grounds, but the fact is that doesn't change the perceptions of those who are supportive. We're talking past one another still, at this point.
— V = I * R (talk to Ω) 21:31, 7 November 2009 (UTC)[reply]
  • Oppose. The proposer has brought up some hypotheticals, but I don't see any evidence that clearly notable articles or stubs are being routinely deleted via the PROD process simply because nobody is watching them. Sure, it could happen, but it's very unlikely. The system works, there is oversight to it, there's a strong fail-safe worked in to curb abuse (anyone can ask for it back at any time, an article can only be marked with a PROD once and only if it meets certain criteria.), and while having three separate processes can be confusing to outsiders, it's not that hard to explain things. I'm not entirely convinced PROD is necessary anymore, to be honest, since I'm not sure the problem it was intended to solve exists anymore. But I see no reason it should be dismantled because of what might happen in theory (if we're doing that, let's drop CSD first. In theory, one could get the main page deleted that way). --UsaSatsui (talk) 14:59, 7 November 2009 (UTC)[reply]
  • Oppose. Most PRODs in my experience are merited (and I deleted hundreds if not thousands of PRODs), usually have been looked over by a second user (excluding the deleting admin), and they do us a genuine service in considerably lightening the load on AfD, letting people focus on truly borderline articles. The userfication proposal has merit, but that's a separate issue (though I encourage Floydian to take it up next!). --Gwern (contribs) 00:57 10 November 2009 (GMT)
  • Oppose I regularly partrol PRODs, and regularly deprod about 5-10% of what's PROD'ed. I routinely restore prods per request... just check my talk page archives. The problem may be with individual admins not doing their jobs well, but not with PROD itself. Jclemens (talk) 04:23, 10 November 2009 (UTC)[reply]
  • Oppose. It's too easy to stop, if anyone really cares. Unschool 06:14, 10 November 2009 (UTC)[reply]
  • Oppose. PROD is vital for its drama-reducing effect on the deletion process.—S Marshall Talk/Cont 21:49, 10 November 2009 (UTC)[reply]
  • Oppose, but that's not to say that the process doesn't need serious improvement. Unwatched and uncared-for pages are a problem (I've seen many decent articles go), and the deletions shouldn't be done blindly. That said, the process has its place. As an idea it's much better than what AfD has become. Let's delete AfD instead. I'm not kidding. --wwwwolf (barks/growls) 21:21, 11 November 2009 (UTC)[reply]
  • Oppose with alternative - require articles that have been around more than, say, 30 days to have 3 people agreeing to the deletion instead of just 2. This would allow today's "very easy" prods for new articles that weren't speedy-able but have a higher standard for lightly-watched articles. davidwr/(talk)/(contribs)/(e-mail) 02:05, 18 November 2009 (UTC)[reply]
  • Comment while I don't follow PRODs it does seem likely that, as I hae observed with CSDs, they do get deleted on the basis that thye are correctly and validly nominated. When I used to do CSD's it was delete, delete, delete.. wait lets examine this one: edit- not speedy, save - the page has been deleted by someone else - sigh, undelete. It may be better now of course. Rich Farmbrough, 21:19, 18 November 2009 (UTC).[reply]
  • Comment I don't know what the answer is, but the system as it is doesn't always work as it should. I see a lot of AfDs which were contested PRODs, so although it's designed to lighten the AfD workload it has the potential to add to it instead. I think some editors try to use it as a short-cut process for articles which end up at AfD anyway. Sometimes I wonder how many people actually read the bit that says PROD is supposed to be for uncontroversial deletion candidates. It serves its purpose correctly when it's used for articles like How to be a spy, but on the other hand we have candidates like Wendy-O Matik, which probably has the potential for a decent article even though the current version needs a complete rewrite, and The Novocaines, which looks a perfectly acceptable article aside from the lack of citations and perhaps questionable notability of the subject: since the article was only created in October 2009 it's unlikely to have been completely abandoned by its author, and I think this one would have been better dealt with by tagging it appropriately and perhaps later AfD if concerns were not addressed. I would certainly support Trovatore's suggestion of making the courtesy notices on talk pages a requirement, which would lessen the chances of editors overlooking PRODs on a busy watchlist, but I also think that 7 days is a pretty short time period: editors could return from holiday, internet connection problems or real-life demands on their time to find their articles deleted. This isn't a major disaster with PRODs since articles can be reinstated on request, but it's still a bit demoralising especially for newbies who may be unfamiliar with procedures. Contains Mild Peril (talk) 05:33, 25 November 2009 (UTC)[reply]
  • Concur w/CMD. In large part, the problem is editors who do not do a search on their own per wp:before, prior to prodding. The same problem afflicts AfDs.--Epeefleche (talk) 21:01, 29 November 2009 (UTC)[reply]
  • Oppose per MrZ. ╟─TreasuryTag►stannator─╢ 21:04, 29 November 2009 (UTC)[reply]
  • Strong oppose - AfD is already overworked. At times, AfD discussions need to be relisted multiple times because no one added any comments after the first relist. I think that PROD is a good solution - it's easily awatched through WP:PRODSUM, and apparently there are a lot of users who do so. עוד מישהו Od Mishehu 11:50, 6 December 2009 (UTC)[reply]
  • I regularly check the prod categories for anything that shouldn't be deleted. --NE2 11:58, 6 December 2009 (UTC)[reply]
  • Keep Prod All our deletion processes have lots of errors, but at least Prod is far less bitey than Speedy. ϢereSpielChequers 19:30, 11 December 2009 (UTC)[reply]
  • FYI: there's a related discussion here: Wikipedia talk:Articles for deletion#Consolidation
    — V = I * R (talk to Ω) 12:05, 14 December 2009 (UTC)[reply]
  • Comment I both like prod and find it imperfect. I wonder if an article is prodded and the prod not removed if the article could be taken out of the articlespace, the page blocked from editing, but the talk page kept open? Also, is there any searchable record of deleted prods similar to the AfD archives? Шизомби (talk) 06:53, 20 December 2009 (UTC)[reply]

Namespace for books

See also: Wikipedia:Village pump (proposals)/Archive 45 § Namespace for books

I suggested a separate namespace for Books on the Books feedback page, and another editor felt it'd be better to make the proposal here.

Should we consider splitting Books into its own namespace, so that we'd have, for example, Book:University of Waterloo instead of Wikipedia:Books/University of Waterloo? I think this is a cleaner way to implement the Books feature. This would require quite a few changes (Mediawiki custom namespace config, templates, moving book pages etc.) so if it's a desirable feature, we should do it while there are still relatively few pages that would need modification. Mindmatrix 17:27, 4 December 2009 (UTC)[reply]

Strong support, provided we do it smart and synchronize (see note below). I like the idea very much. It's a much cleaner way to do it than what we have now, and less confusing. There's relatively few books now (~500), but it will grow over time so if there's a time to do it, it's now. This would probably affect the other Wikipedias, but they too have books (French, German, Simple, and others are looking into it if I recall correctly).
Note that if we agree on creating the book namespace, it's possible that it would requires a few change to the rendering software so we would need to synchronize with the PediaPress devs, Bot-coders, Mediawiki devs, and Wikiproject WikiPedia-Books. It's possible, and I don't mind coordinating these these efforts, should we agree on the creation of that namespace. Headbomb {ταλκκοντριβς – WP Physics} 20:43, 4 December 2009 (UTC)[reply]
Update He!ko confirmed (email) that the changes would be minimal on the Pediapress side of things and make things easier for them and for editors, and would enabled/improve lots of namespace based features. Headbomb {ταλκκοντριβς – WP Physics} 21:12, 5 December 2009 (UTC)[reply]
Sounds very good. Having a namespace for books would raise their profile and would be a sensible way of arranging them.
Might I also suggest a template that could be placed in the 'See also' or 'External links' section of an article that has a book related to it, like here:


Book link


... Or would that be a bad idea? --rannṗáirtí anaiṫnid (coṁrá) 19:18, 5 December 2009 (UTC)[reply]
There's already a template like that ({{Wikipedia-Books}}). Headbomb {ταλκκοντριβς – WP Physics} 20:34, 5 December 2009 (UTC)[reply]
Ah, cool. Thanks. --rannṗáirtí anaiṫnid (coṁrá) 21:03, 5 December 2009 (UTC)[reply]
Support separate namespace. Adds to visibility and also will probably make it easier to manage books as well. John Carter (talk) 19:27, 5 December 2009 (UTC)[reply]
I strongly oppose anything which would help enable this feature. As I stated in the past, the feature is little more than an attempt for the foundation to profit off of the free content editors submit here. I would support this feature being indefinitely blocked, and nothing less. The template shouldn't be implemented as well. Books are easily exploitable for POV pushers and basically consist of original research. They shhouldn't be linked to at all from the mainspace. ThemFromSpace 20:05, 5 December 2009 (UTC)[reply]
I think you have some misconceptions of what books are. All they are are user-generated collections of articles, they can be download PDF or ODT (completely free), the code used to generate them is open-sourced (again free), and you can print them yourself if you feel like it. It's only the printed book from PediaPress that costs something, because printing and shipping stuff isn't free.
Content problems can be dealt with as any content problem is dealt with anywhere else on Wikipedia. For instance Wikipedia:Books/Hadronic Matter is monitored by both WikiProject Physics and WikiProject Wikipedia-Books, Wikipedia:Books/Japan: Examples of Its History and Culture is monitored by both WikiProject Japan and WikiProject Wikipedia-Books, and so on. If there's POV-pushing (or whatever else), use the talk page, contact the projects, start an RfC, or whatever you think will best deal with the issue, and it'll be dealt with. Headbomb {ταλκκοντριβς – WP Physics} 20:28, 5 December 2009 (UTC)[reply]
Support separate namespace. The profiteering off free content angle is a bit of a red herring as the GFDL allows anyone to commercially exploit existing Wikipedia content anyway. Anything that helps to advance this free book project is more likely to reduce commercial interest as it will probably be replicated among the many free content mirrors, making commercial resale of Wikipedia content more difficult.
Someone is bound to catch onto the idea of packaging wiki content in book form, but if we get there first we get to have more control of the content and the distribution mechanism. Road Wizard (talk) 19:03, 6 December 2009 (UTC)[reply]
Alphascript Publishing got there before Wikipedia did. Fences&Windows 03:07, 7 December 2009 (UTC)[reply]
I hadn't heard of them, but if User:PrimeHunter/Alphascript Publishing sells free articles as expensive books is true it is even more important for us to release a viable alternative. Road Wizard (talk) 07:46, 7 December 2009 (UTC)[reply]
I think this will be in addition to book-class rather than instead of it. No matter what namespace the books sit in (some/all) WikiProjects will want to keep track of them. Road Wizard (talk) 10:29, 10 December 2009 (UTC)[reply]
Yes to tracking, but maybe using a simpler process than incorporating it into the Wikipedia: Version 1.0 assessments? Or are we all too addicted to that gaudy clutter on the talk pages? --Kleinzach 23:38, 10 December 2009 (UTC)[reply]
  • Support - This would make things much cleaner and help curb resales by profiteers. NB I wondered at first if all the linked articles in a book would have to be given full URLs instead of the usual [[article name]] shortcut, but then remembered User pages have a different namespace. In other words, these books remain part of Wikipedia, if I understand correctly, rather than becoming part of Wikibooks or whatever. --Jubilee♫clipman 18:30, 10 December 2009 (UTC)[reply]
  • Support Clearly the format and extension are sufficiently mature as to merit a namespace and further work. Though I wonder if it would quickly become a form of greater overlap with Wikibooks? Steven Walling 01:17, 11 December 2009 (UTC)[reply]
    I doubt it, Wikibooks takes a more personalised how-to approach to their writing style, which is fantastic for some things (I finally learnt how to use Blender. Well, I sort of made a snow-man that looks like the devil incarnate, but you see where I'm going with this). We take a more encyclopaedic factual approach which is better suited for some other things (a how-to guide on genital mutilation and regicide would get us into all kinds of trouble with the pesky Interpol people...). —what a crazy random happenstance 17:26, 14 December 2009 (UTC)[reply]
  • Support: agree fully with Happenstance, but this should always have been the case. Isolating books into their own namespace makes so much sense it's unreal: we can customise searching, search-engine-indexing, subpages, transclusion, formatting/appearance, and countless other aspects, with much greater ease. Having them in their own namespace will make identification, by "Book-Class" or whatever, totally trivial. Happy‑melon 11:26, 15 December 2009 (UTC)[reply]
  • Support. I honestly don't fully understand the books feature myself, but if that's the way the wind is blowing, let no one say I don't also blow. Plus it's been a while since there were any major changes around here. Seriously though, if Books is a feature of the software rather than a Wikiproject, it shouldn't be stuck under some project-space page. That didn't make any sense at all. So I do fully support this. Equazcion (talk) 11:53, 15 Dec 2009 (UTC)

Forbidding programme guides

I think we should forbid programme guides like those at some american TV network articles. Those are already at the websites of the networks. This forbidding of programme guides is already at Nl wikipedia. Wikipedia is a encyclopedia not a programme guide KlokkoVanDenBerg (talk) 20:03, 4 December 2009 (UTC)[reply]

To an extent, I agree with you, but that information is already present on Wikipedia via the Categories of the shows. Linking them to the network article itself just makes that information easier to find on the site. --King Öomie 20:08, 4 December 2009 (UTC)[reply]
It is reasonable for a reader of an article on a programming network to want to know what is on the network currently. The grid format presents the information in a clear, concise format. Further, the grids do not present information on a by-episode basis, but only for the current season. There should only be two rounds of changes (fall premieres and mid-season replacements.) In that respect, it's not a program guide. What do you propose as an alternative? The only things I see are prose sections listing the programs or a long See also section with links to the current programs. —C.Fred (talk) 20:09, 4 December 2009 (UTC)[reply]
I am wanting the Long See also system KlokkoVanDenBerg (talk) 20:12, 4 December 2009 (UTC)[reply]
Why? How does it make life easier for the reader? —C.Fred (talk) 20:16, 4 December 2009 (UTC)[reply]
Yes but i want a uniform Wikipedia ruleset and this is one of the things of that KlokkoVanDenBerg (talk) 20:18, 4 December 2009 (UTC)[reply]
This was recently discussed, at length, at Wikipedia talk:What Wikipedia is not/Archive 30#Per station television schedules. I didn't follow it closely - can someone that did please summarize key points?
Afaik, centralizing the schedules at a single location is preferred, such as 2008–2009 United States network television schedule, whereas per-network lists such as Fox Broadcasting Company#Programming are deprecated. But that might be wrong. -- Quiddity (talk) 20:52, 4 December 2009 (UTC)[reply]
Please give an example of a program guide. I'm not sure what you're talking about. - Denimadept (talk) 20:53, 4 December 2009 (UTC)[reply]
Unless I'm mistaken, he's referring to pages like House (season 3) --King Öomie 21:01, 4 December 2009 (UTC)[reply]

[Note: Example taken from the article NBC (this diff/section) ]

This:

NBC 7:00 p.m. 7:30 p.m. 8:00 p.m. 8:30 p.m. 9:00 p.m. 9:30 p.m. 10:00 p.m. 10:30 p.m.
Sunday Dateline NBC The Marriage Ref The Celebrity Apprentice
Monday Local programming Chuck Day One The Jay Leno Show
Tuesday The Biggest Loser 100 Questions
Wednesday Parenthood Law & Order: Special Victims Unit
Thursday Community Parks and Recreation The Office 30 Rock
Friday Law & Order Dateline NBC
Saturday Dateline NBC Law & Order (E) Law & Order: Special Victims Unit (E)

We had something like that at the Dutch Nederland 1 article but i deleted it because it was against the rule sof Wikipedia NL.. as i have said Wikipedia isnt a programme guide KlokkoVanDenBerg (talk) 21:02, 4 December 2009 (UTC)[reply]

  1. ^ "NBC Fall Preview", NBC.
  2. ^ "'Heroes' Back in a Big Way This Fall", Zap2it.
There's absolutely zero reason for such tables to be in WP. It's a clear violation of WP:NOT. ♫ Melodia Chaconne ♫ (talk) 21:08, 4 December 2009 (UTC)[reply]
I agree that such tables shouldn't be here. OTOH, the list of episodes such as what Kingoomieiii pointed to, I can see a use for. - Denimadept (talk) 21:25, 4 December 2009 (UTC)[reply]
There's no good reason for the tables, or for the scheduling information. In rare cases changes to a timeslot have historical significance (say, when Bullwinkle became the first primetime cartoon show) — but that can be discussed in individual cases. Also, it's undesirable to get into a controversy between editors on every network, every TV station about whether its past, current, and future schedules are significant. All of them are promotional, all inappropriate. Piano non troppo (talk) 21:59, 4 December 2009 (UTC)[reply]
As I pointed out above, these were discussed in-depth recently. There was a fairly clear consensus that historic lists are relevant/notable/useful. See List of United States network television schedules, and Category:Television_schedules and it's sup/sub cats.
Whether to have the information for current-schedules repeated within each network's article (as is being given as an example above), was the only thing I recall strong disagreement of, but again, I didn't follow the WT:NOT thread closely. I'll ask a couple of the participants there to chime in here.
Someone could also Search through the afds for precedent, if desired. -- Quiddity (talk) 22:09, 4 December 2009 (UTC)[reply]
The result on the most recent link from that search was "no concensus". A weakness in the argument of those in favor is claiming that a past schedule is "historically significant", without saying why. The fact that the timeslot for Show XYZ was taken by Show PDQ is probably no more significant than "executives thought they could make more money" ... and that would be somewhat significant ... if that reason was given a reliable citation. Another compound failing of the "historically significant" position is that the instant a schedule changes, it becomes "historical", on the one hand, that's a lovely way to add relatively promotional material to Wikipedia, and on the other hand, it causes the schedules to be at least always slightly out-of-date. I.e., it's misleading. Unadorned "historical schedules" are in some ways more of a problem than current schedules. Regards, Piano non troppo (talk) 22:32, 4 December 2009 (UTC)[reply]

The result of the debate was no consensus. Historical network schedules, such as 1951–52 United States network television schedule, can easily be sourced (and are) to any number of reliable print references, but the WP:FANCRUFT crowd is so adamant about deleting television content that they would actually delete articles with tons of inline citations from print publications. Firsfron of Ronchester 00:56, 5 December 2009 (UTC)[reply]

A list of the programs presented by a network is no more promotional than a list of vehicles currently manufactured by a car company. It is something that a reader of the article will find useful. It makes sense to present it to the reader in an easy-to-use format—especially for US networks that have predictable weekly schedules. The alternative would be seven bullet points with each day's programs in a row. While that works for late night, it's cumbersome for prime time. The table works better; why do we want to hinder the readers? —C.Fred (talk) 03:48, 5 December 2009 (UTC)[reply]

My recollection of the previous discussion was clearly that per-station schedules like the one exampled above (particularly "current" schedules) are inappropriate; the consensus was split, but generally held in favor due to historical reasons of the type of national, larger-picture schedules that compare various networks as 1951–52 United States network television schedule examples were generally ok, as long as they did not take a very fine-grain approach to the schedule. --MASEM (t) 05:49, 5 December 2009 (UTC)[reply]

The one exampled above is not a per-station schedule, it is a network schedule. 99.166.95.142 (talk) 17:15, 10 December 2009 (UTC)[reply]

I've been asked to comment here, but I think I'll defer to Masem. By best attempt at summary was here. It wasn't terribly well received by Firsfron and it doesn't offer a hard and fast rule. So I'll agree generally w/ Masem here. Protonk (talk) 02:56, 6 December 2009 (UTC) It is true that, as readers of WP: What Wikipedia is not will know, Wikipedia is not a "how-to" manual, so no one should view it as a manual to tune in to television channels or a series of programme listings in the same sense that the Radio Times would be. However, it is surely quite central to the basic information about a programme to know when it is on, for example, if a series has been a regular part of the BBC Radio 4 schedule or the BBC Two schedule, it is quite central to know the time of day that a programme is normally broadcast or the day of the week when the programme is normally broadcast. ACEOREVIVED (talk) 23:18, 6 December 2009 (UTC)[reply]

What's the argument against their inclusion? There seems to be a tendency among some to say this isn't allowed and this isn't possible and generally forbidding things. All other things being equal that strikes me as being against the original spirit of Wikipedia. If there are people willing to put the time and effort into it, there is some justification for the information, and as long as they do not otherwise infringe on others or harm Wikipedia, then allow it. Lambanog (talk) 12:31, 15 December 2009 (UTC)[reply]
Where to start? There's always a better source of information than Wiki: The stations themselves. After a few years, there would be dozens of historical schedules in a single article. It's information that could easily be vandalized, and would be difficult and tedious to correct. If the example table in the article is typical, it's amateurish and ugly (in part because there's no easy way to describe to editors some uniform color scheme), and doesn't contribute to understanding the topic. It's a mass of undifferentiated facts being quoted without meaning just because the figures happen to be available. I.e., unencyclopedic. Piano non troppo (talk) 13:24, 15 December 2009 (UTC)[reply]
  • The stations are often terrible sources, since they tend to try keeping this info out of the public eye for whatever reason (nevermind the fact that the stations are a primary source, with the attendant issues that comes with).
  • Vandalism is an oft used strawman argument about anything that people don't like. All of Wikipedia is susceptible to vandalism.
  • The example above is just an example. If you have an aesthetic concern with it, then you can go ahead and change it. I don't see an obvious need for a "uniform color scheme", regardless. And the meaning of the content is blatantly obvious by the context.
  • Define "unencyclopedic". Even easier: define "encyclopedic".
    — V = I * R (talk to Ω) 14:45, 15 December 2009 (UTC)[reply]
The point, "encyclopedic" here, is to understand what impact the broadcast schedule has on human knowledge, as without that, it is simply factoids. When you look at a specific station (or broadcast network to address the concern of the IP above), that schedule means little, because it just tells you when things aired. But when you put that schedule against all other significant rivals, now you have information that is more transformative and going to be better sources: the examples I present include the rivalry between The Cosby Show and The Simpsons, and the impact of NBC's Must See TV on ratings of the other networks to the point they didn't even try to compete with it. Furthermore, the side-by-side comparisons bring out the information in a less indiscriminate form, while individual station/network schedules tend to get too detailed (even to the point of week-by-week schedules, which is NOT important). --MASEM (t) 14:54, 15 December 2009 (UTC)[reply]
I think I understand what you're getting at. I tend to stay away from television articles as much as possible (too much angst involved) so there's probably something that I'm missing here. However, the schedules that stations/networks have and are using is at least information, so I don't see what we're gaining by "forbidding" their inclusion. The transformation of information into knowledge is a writing/editorial function, so I don't see how tying people's hands by expressly forbidding the use of certain information is helpful at all. Anything beyond that is a bit beyond the scope of what we should discuss here, isn't it? Specific content issues should be discussed in the context of the content itself (ie.: the article talk page, or a meta/related Wikiproject talk page).
— V = I * R (talk to Ω) 20:52, 15 December 2009 (UTC)[reply]
There is always a source of better information for anything than Wikipedia, because we rely on outside sources as a basic principle. But the point of having an encyclopedia is to conveniently assemble information for users. In fact, if we didn't do that we'd be a mere Web Directory, and that's pretty basic NOT. In reality, for material such as this, we are often the best readily available source of summary information. DGG ( talk ) 01:00, 22 December 2009 (UTC)[reply]

WP:NOTNEWS - Encouraging compliance by redirecting to Wikinews

I previously had a number of Wikipedia templates tweaked to allow optional links to appropriate current articles on Wikinews. Picking Ted Kennedy and the obituary template met with great resistance, and I — personally — don't have the patience of a saint required to deal with arguments that should not be dragged into daylight where certain material is technically against Wikipedia policy, and such should be redirected to Wikinews.

I have taken some time to put together another attempt at what I see as the appropriate templates to be changed. The examples shown there are with links to Wikinews, click through to the template copies there to see the proposed display where no parameter is given. Note! There is extensive use of tooltips in my changes.

I would like to get this sorted out before Christmas, please suggest how this proposal could be improved. Naturally, I would like to be able to add the Wikinews logo but, there has to be some balance and keeping this relatively unobtrusive.

Thoughts? --Brian McNeil /talk 14:03, 6 December 2009 (UTC)[reply]

And what if there is no accompanying article on Wikinews? Would your change to policy be just not to note that this subject is currently in the news? 99.166.95.142 (talk) 17:17, 10 December 2009 (UTC)[reply]
Where, precisely, do I propose change to policy? Had I thought this impacted policy I would have raised it on that section. The policy is WP:NOTNEWS. I propose templates regularly applied to articles where this policy is applicable be used as a way to direct contributions unwelcome as a consequence of that policy to another Wikimedia Foundation project where such contributions are welcomed and appropriate.
Have you any further, and preferably constructive, criticisms to add? If there is another policy which you feel the proposed changes would violate, please enlighten me and give a cite as to why there is a problem. --Brian McNeil /talk 06:58, 13 December 2009 (UTC)[reply]
Actually, I think that's a great idea. To address the above concern, if there's not yet an article on Wikinews, we could always have a template saying "This subject is a current event that is not appropriate for an encyclopedia article at this time. If you would like to write about it, you may wish to consider writing about it on Wikinews." I think that would vastly help compliance, as well as drive a lot of news type stuff where it actually belongs. Seraphimblade Talk to me 07:18, 13 December 2009 (UTC)[reply]
  • Thank you for the encouragement! I was just adding an additional piece to my user talk (the initially linked to section above) to try and explain what I was guessing might be the anonymous user's issue if they did not look there, or at the alternate visible here. As said above, there are tooltips embedded in my proposed changes to these templates; for one, a very long Wikinews title might mess the template formatting, so only pop it up when the user mouses over the link to it. I was reluctant to link to WP:NOTNEWS within my proposed changes because when I last looked at that it is a redirect into a largish policy document.
Would copying the template examples from my user talk page here (adding a little colour) provoke more feedback on this? --Brian McNeil /talk 07:35, 13 December 2009 (UTC)[reply]

This is what I'm proposing. Click on the links to sub-pages of my usespace to see the template without a completed |wikinews parameter

Each of the below attempts to redevelop these templates includes an optional "wikinews=" parameter. The given examples show what is presented when this parameter is filled in; to see the template with no "wikinews=" parameter, click on the link to the sub-page.
  • User talk:Brian McNeil/Recent death
    Example:
  • User talk:Brian McNeil/Current
    Example:
  • User talk:Brian McNeil/Current related
    Example:
  • User talk:Brian McNeil/Obituary
    Example:
  • User talk:Brian McNeil/Recentism
    Example:

--Brian McNeil /talk 02:13, 18 December 2009 (UTC)[reply]

P: and T: namespace aliases

Over a year ago, there was a discussion about adding P:, T: and C: as namespace aliases for Portal:, Template: and Category: respectively. This discussion resulted with some people supporting and one opposing, and a request was filed on Bugzilla. This request has been rotting in bug hell for over a year until I stumbled upon it today. I'm willing to make this happen, but I'm a bit leery of making a change that was last discussed over a year ago and may have gotten controversial since. If you guys still want this to happen, I'd like to see a fresh discussion or at least a fresh vote. --Catrope 16:30, 12 December 2009 (UTC)

  • Not that it'll ever actually happen, but support. Maybe someone will notice in a few years and actually implement it. *shrug*
    — V = I * R (talk to Ω) 16:35, 12 December 2009 (UTC)[reply]
    • It'll happen for real this time. I'm dealing with a lot of old shell bugs now, and once this achieves consensus it'll happen within days. It'll also not hold up existing requests (on the Bugzilla side at least), which was a concern voiced elsewhere on this page.--Catrope 21:30, 15 December 2009 (UTC)
  • It would certainly be very useful for many editors, but let's make sure we appreciate what the cost is: I believe it means that we could never create an article with a title beginning P:, T: or C: . Which people might sometimes need to do. (I don't know, but it might work better to use aliases which have less chance of beginning the names of things in the real world, something like P;: or P-: .)--Kotniski (talk) 16:50, 12 December 2009 (UTC)[reply]
  • Comment: Currently there is one "T:" article, T:kort, and one redirect, T:MP that don't point to templates. There is one "P:" article, P:ano, and two redirects, P:D & P:RUS/NEW, that don't point to portals. There are 4 "C:" articles. The C: pseudo namespace is barely used at all, the T: one is lightly used, and the P: one is heavily used. The normal shortcut for categories is CAT: by a 24:1 margin over C:. --ThaddeusB (talk) 20:09, 12 December 2009 (UTC)[reply]
  • The request, IIRC, wasn't for a "C:" alias because we realised that then [[C:Foo]] (we discussed [[CAT:FOO]]) would act the same as [[Category:Foo]] - that is, actually add the page to the category. What we really might like is for [[C:Foo]] to be equivalent to [[:Category:Foo]], but that's not supported in the software AFAIK. I definitely support adding P: and T: aliases. Happy‑melon 20:26, 12 December 2009 (UTC)[reply]
  • Seems useless to me. Template links usually use {{tl}}. Are portals linked to often enough that saving 5 characters is really worth it? "CAT:" (not "C:") I could see using if it could be equivalent to [[:Category:Foo]], but not otherwise. Anomie⚔ 23:32, 12 December 2009 (UTC)[reply]
    Don't forget the innumerable times the required titles are navigated to directly from the search box; I know I certainly 'link' to templates this way often enough to benefit from the abbreviation. "Useless" is a pretty weak argument, especially since you then state a usefulness in the same paragraph; what you mean is "not worth the effort/hassle". But if someone is prepared to put the effort in, what sort of an argument is that? Happy‑melon 23:49, 12 December 2009 (UTC)[reply]
    Having a shortcut for categories that wouldn't require the leading colon would be a use. But having an arbitrary short prefix for something that is rather infrequently used seems like too little benefit for the added complexity and risk of name collisions. Anomie⚔ 03:16, 17 December 2009 (UTC)[reply]
  • Sure, if it can be done easily and without holding up existing proposals. –Juliancolton | Talk 23:39, 12 December 2009 (UTC)[reply]
  • Yes, it'd definitely be helpful. ≈ Chamal talk ¤ 01:51, 13 December 2009 (UTC)[reply]
  • Support T: and P:; I'd like C: to be CAT:. —MC10 (T•C•GB•L•EM) 16:21, 13 December 2009 (UTC)[reply]
  • 'Support "P:" and "T:", but "C:" should change to "CAT:"--Unionhawk Talk E-mail 00:09, 14 December 2009 (UTC)[reply]
  • Support P and T, I'm neutral on C and CAT, could we maybe get both? And some chips? Ta. :) A solution to the problem pointed out by my delicious friend would too be brilliant, but that's a separate problem. Has a Bugzilla report been filed for it? —what a crazy random happenstance 17:44, 14 December 2009 (UTC)[reply]
  • Oppose: Single letter NS aliases and Interwiki links are more likely to cause issues with page naming for both current articles as well as any future articles that may be created (Which has already been discussed in this discussion) so we should try to avoid them were possible, And are we really that lazy we have to shorten them that far? Peachey88 (Talk Page · Contribs) 12:29, 15 December 2009 (UTC)[reply]
    We as a civilisation saw it fit to abbreviate the three-letter word yes to 'y' and tiny little two-letter no to 'n'. So yes, I think we really are. —what a crazy random happenstance 15:35, 15 December 2009 (UTC)[reply]

Documentaries

I've been watching a lot of documentaries lately on the Discovery Channel and the History Channel and the like, and it struck me: why don't we (Wikipedians) make some short documentaries? For the most part, documentaries have four components: 1) a narrator reading a script; 2) film of images relevant to the topic (lions hunting, for example, or a reed canoe being paddled down a river); 3) interviews with experts (usually college professors); and 4) animations designed to show things like the curve of a trend, or the biological structure of a creature. All of these elements could be compiled by Wikipedians with access to specific resources or with particular editing talents. For example, for the Lion article, we could 1) find some public domain stock footage of a lion using its regular means of attacking a prey animal (there is an amazing supply of such footage available from a variety of sources); 2) get someone with a camcorder to record a few sound bites from a local zoologist or biologist who knows enough about lions to speak authoritatively on the subject; 3) create an animation that shows things like how the lion positions its jaws to go in for the kill; 4) write a short script to describe the details of how the lion is going about its kill and to introduce the expert and the animation; 5) have someone with a good voice record that script; and 6) piece it all together with appropriate subtitles, transitions, maybe even some background music into a ready-made snippet of "documentary footage" which could be embedded right into the article. bd2412 T 03:47, 13 December 2009 (UTC)[reply]

Perhaps because it wouldn't be encyclopedic? :-) Possibly one of the sister projects would be a good home for those?—RJH (talk) 18:43, 13 December 2009 (UTC)[reply]
I'd put it that a series of documentaries would simply be an videographic encyclopedia. I don't see why it wouldn't be "encyclopedic" if the information presented is accurate and given an encyclopedic tone. bd2412 T 19:32, 13 December 2009 (UTC)[reply]
Agreed. (FWIW)
— V = I * R (talk to Ω) 11:47, 14 December 2009 (UTC)[reply]
I've done a limited amount of professional video, but I would say this is not practical because of the unusually stringent skills required. Have a look at the professional video accompanying the Britannica, National Geographic, or PBS. These aren't a matter of an enthusiast getting together friends for a weekend, but of an experienced team with professional camera, lighting, video editing, and video compression tools. The nature of the media would make it difficult for subsequent editors to seamlessly change it, making it distinctly un-Wiki.
An alternative that avoids some of these problems -- within the capacity of quite a few people -- would be a narrative slideshow. Regards, Piano non troppo (talk) 00:09, 15 December 2009 (UTC)[reply]
A narrative slideshow could work - and it could incorporate some animation in the individual slides. The biggest problem facing collaborative video editing, on the other hand, is the lack of an online platform through which different contributors could add to and work on the arrangement of the whole video. Surely the people who brought us the wiki software could create such a platform. bd2412 T 16:19, 17 December 2009 (UTC)[reply]

We at least should have raw videos embedded in the articles. So the lion article should have a raw video of a lion. Sole Soul (talk) 04:05, 16 December 2009 (UTC)[reply]

Backlog at PR and GAC

It's gotten to the point where it's actually easier to get an article featured than it is to get a PR or a GAC review. Is there simply a shortage of willing reviewers, or is there something structurally wrong? Serendipodous 17:12, 14 December 2009 (UTC)[reply]

As I remember GAC has always been backlogged, although backlog elimination drives usually help. Ruslik_Zero 19:26, 14 December 2009 (UTC)[reply]
For an individual reviewer a GAC can be at least as much work as a FAC (if not more so because a GAC can have more problems to fix) and there are surely many more GA candidates as compared to FA candidates. Sometimes you just have to be patient and wait until a volunteer is available.—RJH (talk) 23:41, 14 December 2009 (UTC)[reply]
It may have to do with the large number of people who don't think the process is meaningful. 99.166.95.142 (talk) 17:21, 15 December 2009 (UTC)[reply]
An anonymous poster speaking for the majority? Hmm, well I'll choose to disbelieve you. That being said, however, I think a way to make the PR/GAC more significant is to require them for all A-class articles and to make them prerequisites for a FAC.—RJH (talk) 22:38, 15 December 2009 (UTC)[reply]
GA reviews are often very thorough, and looked upon well when an article comes to FAC. Casliber (talk · contribs) 22:48, 15 December 2009 (UTC)[reply]
Yes, I think both the PR and GAC processes are very useful for the purposes of getting an article ready for FAC.—RJH (talk) 21:08, 16 December 2009 (UTC)[reply]
In what environment does "large number" = majority? 99.166.95.142 (talk) 17:35, 16 December 2009 (UTC)[reply]
Well this is getting argumentative and all I've said is that I chose to disbelieve you. Out of curiosity then, exactly how many wikipedia editors are you speaking for?—RJH (talk) 21:08, 16 December 2009 (UTC)[reply]

Searching through old edits

Listing what links to a page

If you mean Talk pages, you can limit the Namespace of the pages that WhatLinksHere lists.
However, I'd find it useful if there was a way to separate links from References to others, as it is hard to determine where pages like News Limited are used that is not a reference. Mark Hurd (talk) 07:02, 20 December 2009 (UTC)[reply]

CollabRC

I've been working on a motivation and purpose statement for a proposed new recent changes and new pages patrolling tool similar to those like Twinkle and Huggle which takes technologies introduced by already-existing tools and incorporates new ideas to promote collaboration between patrollers. I would greatly appreciate any feedback regarding the development of this tool. The tool's statement is located at User:Shirik/CollabRC. Thanks for any comments! --Shirik (talk) 07:34, 16 December 2009 (UTC)[reply]

Expand the use of messages used when editing articles and talk pages

I made this suggestion on the talk page for the evolution article, and I was advised to come here:

Would it be possible to add a message to the edit page for this article and the talk page, much like the one for BLPs, saying something like "If you wish to add or remove content from this article, or start a new topic on the discussion page, please see the FAQs, which provide explanation as to why certain additions have been deemed inappropriate to include in this particular article. This especially applies to topics regarding subjects such as objections to evolution and others which are not directly relevant to the science of the subject, or which express a belief or point of view." While this is unlikely to deter people such as the user who posted "ATHIEST PROTECTIONISM???", I think it would reduce the numbers of these "zombie arguments", (from people such as this user) which seem to come up very often. It could also be used for other similarly misused articles. I think this would be more effective than the "important notice" at the top, as people would have to see it if they wanted to edit. It's just a suggestion though.

A possible problem arising from this may be that if the messages were used too often, then they would be ignored, but I think that this sort of idea would be useful on evolution and other controversial articles (intelligent design appears to have a similar situation) where editors frequently place information, often in good faith (increasing the likelihood they will respond), which has been deemed inappropriate by editor consensus, and results in time being used up on things which have been discussed before and can easily be fould out by the editor. Jhbuk (talk) 20:22, 16 December 2009 (UTC)[reply]

For my part, I wouldn't object to the proposal. The only point that I would make is that I think it's to our advantage to relax when it comes to the subject of fringe beliefs. As a group, it seems to have become our culture to aggressively remove er... less than neutral content as soon as possible. I just think that it's (often, not always) more constructive to work with such additions then it is to simply remove them. It's important not to censor the fact that fringe beliefs exist, and what they are, to me. More importantly, it's easy enough to talk about fringe beliefs without making them seem true. I'd rather let teachers deal with that sort of problem in person then to keep it from appearing at all in Wikipedia (assuming that we can maintain editorial control, of course).
— V = I * R (talk to Ω) 21:07, 16 December 2009 (UTC)[reply]

LiquidThreads almost ready to deploy

(cross-posted to foundation-l, wikitech-l, Village pump (technical))

Hi all,

With the Foundation's support, I've spent the last few months churning away at Extension:LiquidThreads, a new discussion system that is proposed for use on Wikimedia projects.

Essentially, it's an attempt to marry the radical openness of the wiki paradigm with the usability and practicality of a forum-like system. As the name implies, LiquidThreads is designed to allow any user to easily refactor discussions while maintaining edit history, to edit other users' comments, and to collaborate on a summary of an ongoing discussion. LiquidThreads also brings many standard communication features lacking from wiki discussion pages, such as watching and protecting individual discussion threads, RSS feeds of comments in a discussion or on a discussion page. In the world of online communication, its approach is entirely unique.

LiquidThreads has been in alpha testing on Wikimedia Labs for several months, and, more recently, it's been used in a production context on the strategy wiki, where it has been quite well-received. It's been easy to run these smaller trials, as the extension allows the activation and deactivation of LiquidThreads discussions on individual pages with a simple parser function.

While there are still some issues remaining before wider trials, I believe I can resolve most of them quite quickly (within a few weeks when my vacation finishes at the end of next month), and I'd like to get the ball rolling in proposing small-scale trials on some of the larger wikis, so that a full discussion can be had, and so that adjustments can be made on the basis of ongoing feedback. I'd especially like to see LiquidThreads used on some of the higher-traffic discussion pages on English Wikipedia (such as the technical village pump), and progressive rollout on some of our mid to large sized wikis.

So, I'd like to encourage you to have a play with LiquidThreads, either on the strategy wiki or on the test site (which generally runs a newer version). Tell me what you like about it, and (far more importantly) what improvements you think it needs before we can expand our trials to wider parts of the Wikimedia Universe, and perhaps move towards a full rollout of this very exciting technology.

I should give the following caveats about LiquidThreads as it stands. These are all issues that I intend to address before any trial expansion occurs.

  • Presently the system is somewhat vulnerable to abuse. I intend to make changes to the way signatures work, and improve tracking and listing of thread actions by specific users.
  • While LiquidThreads allows for thread summaries and discussion headers, the system does not currently have support for collaboratively-edited posts which are unsigned or signed by a group of people. These are a key piece of any decision-making framework, and I intend to make adjustments to make this possible.
  • There is no support for embedding LiquidThreads discussion pages on other pages.
  • There are plenty of minor interface issues which I intend to clean up.

Feedback is best directed to the dedicated Feedback page, or, alternatively, to bugzilla (although before filing a bug, you should check the list of existing LiquidThreads bugs).

— Werdna • talk 20:59, 16 December 2009 (UTC)[reply]

Hallelujah! Best thing to happen to Wikiepdia is ages!
— V = I * R (talk to Ω) 21:12, 16 December 2009 (UTC)[reply]

Proposal drafting

I suggest that we adopt something along the lines of the template {{proposal draft}}, as shown above, for occasional use at the top of a section or subsection on this page and perhaps elsewhere. It is intended for vaguer or more complex proposals where substantial debate is needed on a wide variety of issues. In such cases discussion currently too often closes off debate too quickly because of some easily identified problems - without sufficient discussion of whether or how those problems might be overcome, or whether the benefits outweigh the costs.

On a related note, I'm also thinking we should try and find a way to do collaborative editing at least of summaries of proposals. Collaborative editing is fundamental in article space, but it barely exists in project space, where proposals are created by individuals, and then discussed and amended by individuals based on discussion, etc, which works fine for simple things, but not for complex ones. Rd232 talk 01:25, 17 December 2009 (UTC)[reply]

I support the template, while I must agree I have been one has in the past jumped on and dismissed a proposal in early stages (as Rd232 well-knows) I have also been on the other side protecting an editor's proposal hoping that it would at least get more comments and a look at and I have admonished editors who thought it was best to just say "no" with no reason behind it or comments of what could be done to make it at least a little appealing.
For the collaborative project space, that's a problem with editors, not with any fundamental flaw in our system. Dank at WP:Policies and guidelines had a broad idea and collaborated with many users including myself on how his proposal would work across the entire Wikipedia policy "universe". The fundamental reason why collaboration doesnt work at places like policy talk pages or the VPP is that there are too many of the conservative group who believe policies as written right now are how they should stay and change is bad ("this is long standing wording" is the most common reason I hear, which I dont even understand how that is possibly a reason for keeping something, Leninism existed for 50 years in Russia, why would they change that?!) It's hard to collaborate with people whose fundamental outlook is that things shouldnt be changed if they've been there "for a long time".Camelbinky (talk) 03:07, 19 December 2009 (UTC)[reply]
Addendum- Oh! What if we always had a system similar to the US Congress, where a proposal at the VPP is automatically labelled "in committee" where it would still be open to comments from anyone/everyone but where discussion is "strongly" encouraged to be debating the wording of the proposal and to add ammendments to it; then after its been "voted out of committee" (basically everyone agrees that whoever is going to be against it is going to be against it no matter what and any further amendments are useless); it gets labelled "on the floor" where it is then discussed whether or not the measure is needed. Its really not new bureaucracy, its basically the same as the template, but instead of a template we just give a short label that is automatic to any proposal; some will move to "on the floor" almost immediately or skip that step altogether, others may take a longer time. But the point is that all proposals will be given a chance to be worked on first.Camelbinky (talk) 03:13, 19 December 2009 (UTC)[reply]
Not sure about that, it sounds a little complicated (more than it actually would be, perhaps, but appearances matter). I'd be happy to just have a "draft proposal" template that proposers could use if they felt their proposal was complex enough to need it, and if people generally understood and respected the template. Rd232 talk 12:22, 19 December 2009 (UTC)[reply]

Wikipedia:Flagged revisions petition

^ --MZMcBride (talk) 15:42, 17 December 2009 (UTC)[reply]

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This discussion is continuing at Wikipedia talk:Flagged revisions petition

Flagged Revisions petition Discussion

I'll be courageously honest here: Flagged revisions scare the hell out of me. But then, I don't understand what the major issue is with BLP's that people have been screaming their heads off about for years now. Specific and blatant personal attacks can and should be removed of course (and if there's any good reason for "oversight", that would be it), but there seems to be an obvious desire to impose some level of censorship on Wikipedia from some. I think that's what scares me the most, is that those who strongly advocate for flagged revisions are those who I don't think should be entrusted with the added power it provides. I'm perfectly willing to listen, but most of the advocacy for Flagged Revisions to date seems to be nothing more then hyperbole, so I'm slightly worried about a petition.
— V = I * R (talk to Ω) 16:43, 17 December 2009 (UTC)[reply]

The use of the word "demand" utterly turns me off. 99.166.95.142 (talk) 16:46, 17 December 2009 (UTC)[reply]
I agree. I think flagged revisions puts more power in the hand of anonymous untrusted people. We need to fix vandalism and other BLP issues as they arise, not create more layers of bureaucracy. The beauty and real power of WP is that it is self-policed and self-correcting. Crum375 (talk) 17:03, 17 December 2009 (UTC)[reply]
  • Everyone other than IPs sees the latest version on an article. IPs see only the latest checked version, unless they click on a link to see the latest unchecked version. What's so scary about this? Josh Parris 23:53, 17 December 2009 (UTC)[reply]
    One word: censorship. What you and I see matters about as much as... well, what we say here. What 99.999% of users (IP users) see on a page is about the only thing that really matters around here, and myself having direct control over your contributions, and vice versa, is a bad idea in my view.
    If we were talking about adding some sort of flagged revisions to project pages I really wouldn't be concerned at all (and would probably even support that), but this seems like a dramafest filled Bad Idea™ for implementation in the mainspace.
    — V = I * R (talk to Ω) 00:13, 18 December 2009 (UTC)[reply]
    Censorship vs Quality control; two sides of the one coin. I understand your view, and it might be considered the start of a slippery slope. At the same time, my perception is that it isn't censorship as anyone can get to the "uncensored" version of an article, and that the censorship isn't an active process, but one born of inaction. Of course I'm assuming that getting reviewer/checker/patroller status will be simple, easy and undemanding. Josh Parris 00:39, 18 December 2009 (UTC)[reply]
Even if it's simple, it's gonna be a job where one always has a big target on his back (similar to admins). This is especially due to the fact that the people PR'ing for the Foundation are making such a big deal about it that its efficacy, even on such a limited scope, will be so slim as to be a waste. -Jeremy (v^_^v Stop... at a WHAMMY!!) 00:46, 18 December 2009 (UTC)[reply]
Re Josh Parris: censorship vs quality control might be a useful discussion to have if flagged revisions represented quality control. What it actually means is that, if some casual reader sees libelous BLP vandalism, carefully checks our slogan to see if really says "anyone can edit", and edits out the libelous BLP vandalism, we will insist on continuing to display libels when we could have prevented it. Indeed, we will have actively prevented the removal of libels even while we allow less serious removals on non-BLP subjects. That is not an improvement. — Gavia immer (talk) 01:03, 18 December 2009 (UTC)[reply]
I agree. In my experience, many vandal reversions and other corrections and improvements come from casual users or IPs. This will now require more hoops for a correction, making things worse. In my opinion, it will destroy the core principle which made WP a success: that anyone can edit. Crum375 (talk) 01:30, 18 December 2009 (UTC)[reply]
Except that, with flagged revisions, the libel shouldn't be there in the version the IP would first see in the FIRST place, unless it was flagged as ok. Also, if it were for some reason, the IP would immediately see the new version, only a refresh/reclick/whatever would they see the old one. ♫ Melodia Chaconne ♫ (talk) 01:25, 18 December 2009 (UTC)[reply]
The point is that if there were a more subtle mistake in a BLP, which a reviewer missed, a bona fide casual editor, or an IP, won't be able to fix in the "approved" version without jumping through extra hoops. Crum375 (talk) 01:35, 18 December 2009 (UTC)[reply]
Indeed. I'm confident Flagged Revisions will prevent some vandalism. I am worried about what a smart vandal can do with it. Without invoking nasal beans, I know that I could push vandalism onto an article that's being heavily watched, and I know that I've seen vandals who understand what I do about how to accomplish it - so my concern is for what Flagged Revisions imply when the situation has already gone completely pear-shaped without any regular editor noticing it. — Gavia immer (talk) 01:55, 18 December 2009 (UTC)[reply]
What hoops? They edit the article just as it is now. The only difference is someone else has to approve it for IPs to see the change -- but ANYONE can still see the changed version with one extra click (there's a note that it's not the most recent version, etc). Mainly, it's the difference between turning back an edit after it's 'live' and not letting it go 'live' in the first place, but in both cases the edit is there, in the history, viewable by anyone. I don't quite get why the whole concept is so difficult for people to understand. ♫ Melodia Chaconne ♫ (talk) 03:10, 18 December 2009 (UTC)[reply]
What's not to understand? If the default version a casual reader sees has a subtle (but vicious) BLP error which reviewers missed, and a Good Samaritan IP comes along and tries to fix it, the fix will not go into the default version. Extra hoops will be needed for that important fix to become default, whereas today the fix is instantaneous. Improvement? Crum375 (talk) 03:30, 18 December 2009 (UTC)[reply]
From my experience, the number of IPs and new users adding BLP problems is much greater than the number fixing them. Mr.Z-man 03:35, 18 December 2009 (UTC)[reply]
I think we tend to notice the blatant vandals more, and I agree that many of them are either red-linked names or IPs, but if you look carefully, you'll see that a lot of vandal reversions and other corrections are carried out silently by IPs. I read a recent study somewhere which claimed much of WP's "real" content is created by IPs. Crum375 (talk) 03:52, 18 December 2009 (UTC)[reply]
And on the flip side, there will be ten other libacious edits that will never go into the default version in the first place (since we're using mock examples here). So yes, that seems to me to be an improvement. ♫ Melodia Chaconne ♫ (talk) 05:12, 18 December 2009 (UTC)[reply]
OK, let's assume for a moment that all of the BLP hyperbole is 100% accurate. Everyone always brings up "real world consequences", so... where are they? I've seen editorials where people complain about the Wikipedia article covering themselves or people they know, but I've never seen anyone actually damaged because some kid put the word "POOP" into their Wikipedia bio. Besides, I don't understand the desire to complain rather then fixing the problem! People sometimes do bad things in life, including on the 'net. Just today there was a story about a legal battle brewing in Italy involving YouTube. We can't prevent all bad behavior, and history shows that the harder institutions try to prevent bad behavior, the worse it becomes. I'm not against the BLP policy itself, but changing a cornerstone of how (the English) Wikipedia works to accommodate it seems to be going overboard.
— V = I * R (talk to Ω) 05:35, 18 December 2009 (UTC)[reply]
OTRS gets emails every day from people complaining about inaccuracies and potentially libelous statements in articles about them. Many are minor issues, but others are more serious. The problem is not people putting "Poop" in articles, its people putting untrue statements into articles, putting unnecessary personal information in articles, and making articles overly negative. YouTube is owned by Google, they can afford to set aside millions of dollars for legal issues, Wikimedia can't, so we take more proactive approaches. The real world consequences are pretty much beyond doubt here. Mr.Z-man 13:59, 18 December 2009 (UTC)[reply]
Except, you just said that the problems are already being taken care of. What do we need Flagged Revisions for, exactly? Aside from that, I'd rather we leave the legal issues to the Foundation.
— V = I * R (talk to Ω) 14:58, 18 December 2009 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


Different wording for the "rendering" screen when a book is being produced?

When a book is in the process of being generated, the following words appear:

Please wait while the document is being generated.

Progress: [percentage] Status: layouting (wiki page: [name of page being added to the book])

This page should automatically refresh every few seconds. If this does not work, please press refresh button of your browser.

Could the wording be changed to "please press your browser's refresh button"? The current wording sounds like Chinglish. Nyttend (talk) 21:54, 17 December 2009 (UTC) [reply]

Layouting? -_- Road Wizard (talk) 22:33, 17 December 2009 (UTC)[reply]

::Confused, what do you mean? Nyttend (talk) 22:47, 17 December 2009 (UTC)[reply]

Now I see what you mean; I'd not even thought of that, but you have a good point. I guess it means "making the layout"; perhaps it could be changed to "laying out"? Nyttend (talk) 22:49, 17 December 2009 (UTC)[reply]
"...please press **[the]** refresh button of**[on]** your browser." Yes. It took me a few reads to spot that typo too. "...please press your browser's refresh button" is better. --rannṗáirtí anaiṫnid (coṁrá) 23:02, 17 December 2009 (UTC)[reply]
Adds: could User:Happy-melon do this? --rannṗáirtí anaiṫnid (coṁrá) 23:03, 17 December 2009 (UTC)[reply]
Any admin can do this, there will be a MediaWiki: namespace system message somewhere that can be customised. Not sure which one; have a look at Special:Allmessages. Happy‑melon 15:19, 18 December 2009 (UTC)[reply]
Found (MediaWiki:Coll-rendering text) and done for the refresh button, not sure about where one might find "layouting" to change though. - Jarry1250 [Humorous? Discuss.] 15:23, 18 December 2009 (UTC) Of course, that's just locally. - Jarry1250 [Humorous? Discuss.] 15:25, 18 December 2009 (UTC)[reply]

Also filed as bugzilla:21889 so other installations can benefit as well. —TheDJ (talk • contribs) 15:32, 18 December 2009 (UTC)[reply]

Add Jabber XMPP option like IRC

I propose to improve Wikipedia to support also XMPP URIs.

Jabber/XMPP is a open source protocol used by a lot of people all over the world. There are users of Google Talk, Gizmo5, LiveJournal, Nimbuzz, Ovi, Jabber.org and a lot of other servers[1] [2] [3] [4] [5]... and there are a lot of XMPP clients[6]...

  1. ^ http://www.jabber.org/network/
  2. ^ http://xmpp.org/services/
  3. ^ http://www.jabberes.org/servers/
  4. ^ http://www.jabberfr.org/federation/
  5. ^ http://jabber.apinc.org/domliste.php
  6. ^ http://xmpp.org/software/clients.shtml


XMPP URI (xmpp:) is similar to mailto: and irc: (more information on URI scheme)


So, today, for contact a person/join a chan on Wikipedia:

  • It is possible to put a link to a user address with this format: <user>@<host> 
[mailto:<user>@<host>]
  • It is possible to put a link to join a chan: [1]
[irc://irc.freenode.net/wikipedia]

With XMPP URIs :

  • It is possible to put a link to a user address with this format:
[xmpp:<user>@<host>]
  • It is possible to put a link to join a room (XMPP chan):
[xmpp:jdev@conference.jabber.org?join]


There are three requests: URI Scheme for contact link/join room and Wikipedia Notifications.

For more informations:

— Neustradamus (✉) 14:52, 21 December 2009 (UTC)[reply]

This seems to be a proposal to allow a user to receive notifications when specific wikipedia article have been updated through XMPP. It seems like a good idea. Millueradfa (talk) 23:30, 19 December 2009 (UTC)[reply]

It's already possible to subscribe to an RSS feed of a page's changes. There's no need to go for another protocol; and it would involve a change to the back-end anyway, so this would have to be submitted through the bug system. — The Hand That Feeds You:Bite 17:31, 21 December 2009 (UTC)[reply]
Notifications is in second point, but about XMPP URIs ? — Neustradamus (✉) 21:44, 21 December 2009 (UTC)[reply]

Arbitration Committee: Logo change poll

Community review and input is requested here. Durova386 23:11, 19 December 2009 (UTC)[reply]

I have renamed the section from Arbitration discussion; very important to Arbitration Committee: Logo change poll because the previous title was a little pretentious and gave overdue weight to the matter. Peachey88 (Talk Page · Contribs) 06:58, 20 December 2009 (UTC)[reply]
Intended as dry humor. ;) Durova386 17:37, 20 December 2009 (UTC)[reply]

those 'pleas' are getting needlessly messianic.

seriously, this is the last time i'm gonna hear 'oh pleeeeeeeeeeeeeeeeash, donate or i'll day' before i'll throw up. this is not a hate message, this is a reality, it's getting old and you know it. tell that to that guy responsible for posting it to know it too. i.e. be more creative. --Leladax (talk) 01:49, 20 December 2009 (UTC)[reply]

If you're talking about the donation banner on top of a Wikipedia page, and you're typing from a computer that you control (i.e. not one shared at a library, school, job or Internet café), then just click the link that says "dismiss" and it's gone whenever you're logged in. The only time I see it is when I visit another part of Wikimedia (Wikicommons, a foreign-language Wikipedia, etc.) or when I'm not logged in. —— Shakescene (talk) 04:56, 20 December 2009 (UTC)[reply]

suggest an article

It used to be that when Ityped in a possible-article name, I would get an option to suggest that article if I couldn't find it by tweaking my search. I can't find this suggestion any-more (I had to fumble around to find the suggestion page).Kdammers (talk) 06:59, 20 December 2009 (UTC)[reply]

Enable single-click watching of all pages within a category

It's possible to watch a category page, but all this permits is knowing if it is renamed, deleted, commented on, vandalized, etc. There is not, AFAIK, a way of watching all the pages within a category short of doing so one by one. I think it would be handy to be able to click a single thing to watch all pages within that category and a smart feature that automatically adds any pages added to that category to this watchlist. In one's watchlist, they could be organized under that category, or have still have the alphabetical list, but the category next to the article by way of annotation. Watching all pages in a category could be turned off, removing all that were not individually added, or individual pages could be manually removed from the watchlist. Шизомби (talk) 07:18, 20 December 2009 (UTC)[reply]

You could use Special:RecentChangesLinked. For example, Special:RecentChangesLinked/Category:Living people. You could even have an RSS feed for that. ;-) Killiondude (talk) 07:23, 20 December 2009 (UTC)[reply]
Thanks, that's neat and I will have to experiment with it! Offhand, it appears to have more limited functions than what I'm suggesting and is less easy to find and set up. I think it would be more intuitive to be able to do it from the category pages (or even possibly for the watch star icon to appear next to categories in articles, so they could be added from there as well. Likewise, perhaps easier and more intuitive to have the watched categories appear under My watchlist built into our WP account rather than our browser. If we are accessing WP from some computer other than our own, we wouldn't have ready access to those RSS feeds. Also, it looks like I will have to submit a browser bug report, because I got this message: "can’t open the page “feed://en.wikipedia.org/w/index.php?title=Special:RecentChangesLinked/Category:Living_people&feed=rss&target=Category%3ALiving_people”. The error is: “The operation couldn’t be completed. (Mach error -308 - (ipc/mig) server died)” (NSMachErrorDomain:-308)" Шизомби (talk) 07:49, 20 December 2009 (UTC)[reply]
People have wanted to watchlist entire categories for a long time now, and the only thing I've ever seen that has come close to it is the SpecialChangesLinked option. Some people have those linked on their userpage or somewhere on-wiki for quick access no matter which computer they are using. The RSS feed option is found in the toolbox on the left side of your screen when you're viewing the RecentChangesLinked page. Depending on how your browser is set up to handle RSS feeds, it may not have liked that link. It worked fine for me. Killiondude (talk) 07:59, 20 December 2009 (UTC)[reply]
"People have wanted to watchlist entire categories for a long time now," a good proposal then! Yet not listed as a perennial one. Linking from on-wiki would be an option, I suppose, yet without affording the same degree of privacy the watchlist does. I'll work on the bug problem. Шизомби (talk) 08:05, 20 December 2009 (UTC)[reply]
I would absolutely LOVE this option....on another Wiki I'm on that uses MediaWiki (there, you can't even use the RSS feeds like you can here except on select pages, alas). ♫ Melodia Chaconne ♫ (talk) 15:06, 20 December 2009 (UTC)[reply]
As a work around you could null edit every page in a category, thus adding it to your watchlist, with the right settings. Rich Farmbrough, 01:03, 22 December 2009 (UTC).[reply]
Not quite sure what you mean by "null edit," and if this would require opening pages for each article? Шизомби (talk) 23:55, 22 December 2009 (UTC)[reply]

add categories from articles to AfDs

I think all categories that are in an article submitted to AfD should be added to the AfD itself. At the moment AfDs have no categories in them at all. I had suggested adding the categories here Wikipedia talk:Articles for deletion#put categories in AfD discussions.3F, where I wrote in part "The search should be able to search through categories in AfD as well then. There appears to me to be mixed views regarding how past AfDs have gone, perhaps partly because policies, guidelines etc. at the time they were done may have been different than at present, or because the consensus was small and unrepresentative, etc. and WP:OTHERSTUFF exists or doesn't exist and so on. However, there's likely (or hopefully) some discussion content that merits consideration. [...] an Afd on an article with for example [Category:Online encyclopedias] as a category should have [Category:Online encyclopedias] in the AfD in some form. That might mean sharing that same category, although in that case it would probably be desirable to have the AfDs in that category display on a different page than the articles do, if that would somehow be possible. Or the category could be slightly altered like [Category:Online encyclopedias (AfD discussions)] or there could be an additional namespace like [AfD category:Online encyclopedias]." Another option might be to have the article category [Category:Online encyclopedias] and a separate [Category: AfD discussions], which could also be subcategorized into [Category: Open AfD discussions] and [Category: Closed AfD discussions]. Then any pages with this AfD discussion category could be displayed separately from those pages in the article space category. I realize there is a secondary categorization system of broad categories utilized for open AfD sorting handled by Wikipedia:WikiProject Deletion sorting; I think those categories should be added to the AfDs as well. Шизомби (talk) 07:31, 20 December 2009 (UTC)[reply]

What would be the advantage over the deletion sorting lists exactly? --Cybercobra (talk) 08:07, 20 December 2009 (UTC)[reply]
Deletion sorting AFAIK is to assist people interested in finding open AfDs under general categories they have more interest in than others. People might be interested in finding open discussions on more specific categories, and also for reviewing archives of closed AfDs for articles within specific article categories, like for investigating Common outcomes or developing a new specific notability guideline or further developing an existing one, etc. At the moment, WP:Searching archived AfDs can only be done by title or keyword. Categorizing would enable such simple searches as incategory:Online encyclopedias prefix:Wikipedia:Articles for deletion, which at the moment can't be done. One can often come up with a keyword which is hopefully likely to appear in an AfD for a member of a category, but there's no guarantee. If you're interested in AfDs on academics, and a given AfD nom said just something like "NN, no sources" and subsequent recommendations were "Delete per nom" and so on, that this was an AfD on an academic or even simply on a person might not have been mentioned. I don't know how one would find it, other than paging through all AfD titles looking for peoples' names and then doing searches on and offline to find which of those people were academics, and then if it was an AfD on a person who merely shared the name of an academic, then you wouldn't know without doing a deletion review, but the amount of time it would have taken you to get there would have been ridiculous. Шизомби (talk) 08:47, 20 December 2009 (UTC)[reply]
I can see why keeping a permanent record of the types of deletion discussion would be useful, but using article categories is problematic as then the categories would fill up with AfD discussions, whereas categories are for navigating articles. Fences&Windows 16:41, 20 December 2009 (UTC)[reply]
Thanks, and I certainly see your point. As I said though, there are a number of ways they could be prevented from automatically appearing in the Category: namespace either by rules the Wiki software would follow, or by amending the name of the category while otherwise keeping the name intact. Some users might like to be able to view them from the categories pages, which could be an option that could be set by default to off, but able to be turned on and off optionally. That could be handy, but not necessary as long as the ability to search the category from the AfD search box, from the regular search box with boolean searches, or with user-created search links was possible. Or such search links could be also be placed on the Category or Discussion page of categories, but again, not necessary. Шизомби (talk) 17:41, 20 December 2009 (UTC)[reply]
There could be an Articles for Deletion sub-category for each category, so they would be accessible without cluttering up the category. We could add copying the article categories to the AfD to Twinkle, placing them into the AfD sub-category. Fences&Windows 15:57, 21 December 2009 (UTC)[reply]
Hmm, maybe. An article in [Category:Online encyclopedias] that was deleted would end up keeping that category but it would end up being [Category:Online encyclopedias]>[Category:AfD discussions]>[Category:Online encyclopedias]? I wonder if the duplication of the same name at different levels would be a problem. I suspect some would not like AfD discussions to appear even under a single link on a category page with articles in the mainspace, although I like the transparency of that. Шизомби (talk) 00:00, 23 December 2009 (UTC)[reply]

WP:COINFLIP

not sure if this is the correct place for this, however here is my idea. bear with me, i know it may sound a bit stupid, but it could work i believe

ok, say for example 2 editors cant agree on something within an article. lets say that they dont agree about which shade of blue should be used as a header for an info box describing different shades of blue. obviously any shade of blue will work right? not so fast. we have all seen edit wars, heated discussions, compassionate arguments, civilized arguments, and simple disagreements on wikipedia right? well instead of being serious all the time, lets take a step back and make it a tad interesting. because sometimes both parties may be correct, and there isnt a concensus on which side should have the upper hand. yes it does happen. how do we resolve it? sure we vote and all, but sometimes a vote isnt available, or it is involving something that cant be voted on, etc. below is from the wikipedia article coin-flipping:

Use in dispute resolution

Coin tossing is a simple and unbiased way of settling a dispute or deciding between two or more arbitrary options. In a game theoretic analysis it provides even odds to both sides involved, requiring little effort and preventing the dispute from escalating into a struggle. It is used widely in sports and other games to decide arbitrary factors such as which side of the field a team will play from, or which side will attack or defend initially. In team sports it is often the captain who makes the call, while the umpire or referee usually oversees such proceedings. A competitive method may be used instead of a toss in some situations, for example in basketball the jump ball is employed, while the faceoff plays a similar role in ice hockey.

im just toying with the idea, but maybe it could work. maybe its a dumb idea. i dunno im just putting it out there. heres some ideas:

1. obviously have a random coin toss generator of some sort.
2. make it so both parties will register for the coin toss, and all revelent information and points of view for both sides will have to be noted somewhere within the WP:COINTOSS protocol. what i mean is both parties involved have to put somewhere why they are flipping the coin to resolve the dispute, their arguments for/against etc.
3. make some sort of disclaimer stating that the cointoss is final. whatever the outcome, the losing party must agree to abide by the toss, and cant change whatever the winner wanted (say in our case light blue won over dark blue). dark blue cant be inserted into the table by the loser of the coin toss. it must stay light blue until someone else changes it, starts to argue etc.
4. make the coin toss case specific. all tosses are available to be viewed by anyone, results fully available etc. basically full disclosure to the community.
5. now im not saying that this is to be used on major things, just small things that the 2 editors are involved in an argument, but seek a civil resolution. obviously if its a flame war, this aint gonna fly.
6. make this a simple easy process. one that wont drag in an administrator or arbitrator to lay down the law and sometimes making a decision that a third grader could have made because it is so trivial. basically make it headache free, a simple quick and easy process.
7. again make this a simple and easy process. and at the same time, make it fun. if you were to lose, oh well. at least its a fair game. a civil end to a minor dispute.
8. also make the cointoss free to anyone to use. maybe you need the cointoss because you and your friend are at the computer arguing on who should go first in playing the xbox, and noone has a coin. crap what do you do? go to wikipedia, they have a coin. <---(lol sounds dumb, but id use it if i didnt have a coin)


anyone else have ideas? ways to tweak it etc? again i know it sounds stupid, but some form of it could be adapted, i think it could work. i know its just my opinion, but you all know the saying, opinions are like.... everyones got one. MACKDIESEL5 (talk) 06:41, 21 December 2009 (UTC)[reply]

It would be easy enough for a bot to do the actual tossing of the coin, and could easily enough be generalized to "3-sided coins" and such if necessary. And having it on-wiki would effectively force everything to be community-visible. As for #8 in your list, it's not the purpose of Wikipedia to be providing "coin tosses" for people playing xbox and crap like that. I have no opinion on the rest, besides wondering whether WP:3O wouldn't work better for most cases. Anomie⚔ 12:59, 21 December 2009 (UTC)[reply]
"sometimes both parties may be correct": can you give an example of such a case? I can't imagine people would go for a literal crapshoot to settle something, when consensus already seems like that sometimes. Also, "the cointoss is final" - most things on Wikipedia aren't final. Temporarily decisive, that's about it. Шизомби (talk) 13:12, 21 December 2009 (UTC)[reply]
I don't think this sounds stupid, but I don't think it's practical, for two reasons:
Remote coin flips are actually a very hard problem, not an easy one, if you want them to be fair, trustworthy, verifiable, and cheat-proof. Moreover, you do want them to be all of these things, because if they aren't they're worse than useless - they will cause problems that wouldn't exist otherwise.
From a social-interaction perspective, you can use even a perfect coin-flipping mechanism to cause all sorts of problems and disruption. Most importantly, if something has already been settled in an arbitrary fashion, anyone who disagrees with the arbitrary resolution can try to disrupt the settled issue with an insistence on using a "fair" coin flip - if the issue has already gone against them they have nothing to lose. This would actually prevent issues from being settled. — Gavia immer (talk) 13:41, 21 December 2009 (UTC)[reply]
Even if there is consensus on a topic (or lack of it), it can change if a given user provides new and convincing arguments on why should something be done differently. But a flip of a coin isn't ar argument and can't be "refuted". We don't have things decided by "ultimate truths", much less we should have "ultimate random chance results" MBelgrano (talk) 13:55, 21 December 2009 (UTC)[reply]
Very few things are truly arbitrary. Wikipedia is not on a deadline, we should actually take the time to figure out which option is best. If it is really some stupid edit war like over the color of a template and there aren't any issues with accessibility or relevance, the easiest solution is to just go back to whatever it was before the argument started, like we do with units on measurements. Alternately, we could could block the edit warriors for edit warring over something so stupid, then let someone else decide. Mr.Z-man 16:44, 21 December 2009 (UTC)[reply]
What you would do with {{Coin toss}} I dunno, but have fun with it. Rich Farmbrough, 03:29, 22 December 2009 (UTC).[reply]

Proposal to Expand Chinese Wikipedia

Persons interested,

I noticed that Hudong Encyclopedia, a Chinese Encyclopedia, is much larger than Chinese Wikipedia. I would like to suggest that someone associated with Chinese Wikipedia begin to copy over parts of Hudong Encyclopedia in order to expand the Chinese Wikipedia, as it is way, way smaller in comparison.

I do not speak or read Chinese, and would not be able to work on this project. However, as I said, we could ask someone that's associated with Chinese Wikipedia to help expand our reserves.

We could claim this as a "reference" for the pages that we copy, if need be.

This is merely a suggestion.

Signed,

Sean

Sean 0000001 (talk) 09:28, 21 December 2009 (UTC)[reply]

We can't copy Hudong's content, as it is copyrighted. Firsfron of Ronchester 09:32, 21 December 2009 (UTC)[reply]
Rather ironic that the encyclopedia from the socialist country doesn't use a free culture license. --Cybercobra (talk) 09:40, 21 December 2009 (UTC)[reply]

OK. That's cool. As I said, it's merely a suggestion, and Cyber, that truly is ironic. What has the world come to?

Is there any way we could get them to work with us?

Sean

Sean 0000001 (talk) 21:32, 21 December 2009 (UTC)[reply]

That would be something best brought up on the Chinese Wikipedia, as the English Wikipedia has no control over it. --Golbez (talk) 03:59, 22 December 2009 (UTC)[reply]
OK. I don't really read/write Chinese, but I'm sure that someone will read this that can speak Chinese, and hopefully they will bring it up over there. Until that happens, though, this idea will be pretty much dead.
Thank you all very much for all of your help.
Sincerely,
Sean
67.83.48.26 (talk) 05:26, 22 December 2009 (UTC)[reply]
But how do you know that chinese wikipedia is shorter, if you can't read it? MBelgrano (talk) 23:55, 22 December 2009 (UTC)[reply]
Sean isn't wrong; the fourth Google hit for Hudong is an article with the statistics. Hudong: 3 million articles, Chinese Wikipedia: 280,000 articles. It's not even close. Firsfron of Ronchester 06:58, 23 December 2009 (UTC)[reply]
I could bring up the idea of cooperation between Hudong and Wikipedia on the Chinese Wikipedia, but honestly I think that such an idea has very little chance of success. Hudong has no incentive to cooperate with an encyclopedia so much smaller than itself, and the Chinese government doesn't really trust Wikipedia, which would also scare away Hudong. Honestly, Wikipedia's failure in China, in my opinion primarily due to the Chinese government's blocking it for years, is really unfair and unfortunate.--Danaman5 (talk) 07:24, 23 December 2009 (UTC)[reply]
The Chinese internet is almost entirely self-sufficient. They hardly use Google, or Wikipedia- they prefer their own version. Could be a government-pressure thing, but they have no incentive to plug in to the west. --King Öomie 20:47, 23 December 2009 (UTC)[reply]

Build a wall

We all saw some of the discussions in the talk pages where 2 editors are endlessly arguing against each other, repeating accusations without saying anything new. I propose in these cases that we designate a separate section for each editor "Statement by user A" and "Statement by user B" with a template that instructs the users to focus on making their cases and to write the versions they like to see in the article. Sole Soul (talk) 09:30, 22 December 2009 (UTC)[reply]

Or we can treat editors like adults... and let them deal with it themselves. We arent here for social control, we're here to make an encyclopedia. If two individuals cant agree on the wording to put in an article, that's sad but they need to work it out themselves somehow. This is more bureaucracy and instruction creep to make decisions and resolve conflicts for us. We are adults, we should learn to work together without others telling us how to do it in a uniform way. Uniformity and conformity is for chumps.Camelbinky (talk) 00:51, 23 December 2009 (UTC)[reply]
Your objection is a philosophical one I think. I'm interested in which way would maximize the benefits and reduce the negatives. We already have separate sections for each user in ArbCom requests and RFC. I'm not saying that we do this in all cases or to enforce it upon users. Sole Soul (talk) 10:07, 23 December 2009 (UTC)[reply]
And what happens when a third editor wants to join? MBelgrano (talk) 13:46, 23 December 2009 (UTC)[reply]
He/She joins. Sole Soul (talk) 15:01, 23 December 2009 (UTC)[reply]
So after they write their statement, then what? Not being able to directly engage the other person isn't very conducive to coming to a compromise, as they're essentially prevented from working together. Mr.Z-man 16:14, 23 December 2009 (UTC)[reply]
The statement will be updated (not repeated tens of times) in response to the other user statement. Keep in mind, this approach will only be applied in certain situations were incivility and lack of communication are problem. See for example Talk:Mark Levin. Sole Soul (talk) 17:16, 23 December 2009 (UTC)[reply]
My point is that its difficult to come to a compromise when you can only communicate indirectly. With a mediator, such an approach could work well, but otherwise any calming effect would likely just because it became more difficult to discuss. Mr.Z-man 19:32, 23 December 2009 (UTC)[reply]
I agree with you if building consensus is the real goal of the discussion, but sometimes this not the case. My proposal is a way to make building a consensus the goal of the responses instead of a response for a response sake. Sole Soul (talk) 20:11, 23 December 2009 (UTC)[reply]
this would be an easy enough template to build - a table or div-based template with a fluid number of columns (one for each participant) to enter their username and a brief statement. I'll start one at {{inbrief}} so that we can try it out in practice and see how it flies. we can always delete it later. --Ludwigs2 20:32, 23 December 2009 (UTC)[reply]
Thanks. Just a try. Sole Soul (talk) 20:36, 23 December 2009 (UTC)[reply]
We can make it in addition to (not instead of) the direct discussion to summarise their overall stance Sole Soul (talk) 20:39, 23 December 2009 (UTC)[reply]
well, there's a completed (if under-documented and fairly ugly) version at the above link, for demonstration and revision purposes. Take a look at it, tell me what more you want to see in it (I'm thinking maybe a box at top for a question statement), and I'll revise it in a bit. --Ludwigs2 22:08, 23 December 2009 (UTC)[reply]

New guideline/goal for 2010

Moved from WP:AN. ╟─TreasuryTag►UK EYES ONLY─╢ 16:26, 23 December 2009 (UTC)[reply]

Sadly to say, there is disagreement and arguing in Wikipedia, such discussion about another named user. A cursory look at the complaint suggests that he is not liked and doesn't write articles for the most part.

Would there be any support for the stated Wikipedia goal that all editors should devote a minimum of 33% of edits to articles and edits directly involved in article improvment? That means articles, article talk pages, Wikiproject pages, etc. AN, ANI, AFD, RFA edits would be considered other Wikipedia space type edits.

There would be no sanctions for not achieving the 33% guideline but meeting it would mean that the user has passed one of the criteria to be a good editor. Editors could manipulate the statistics by using automated minor edits but I'm not concerned about that at the moment. Suomi Finland 2009 (talk) 16:24, 23 December 2009 (UTC)[reply]

Completely unviable, and the fact that you mentioned another editor by name is going to cause this proposal to collapse amongst collective bickering. ╟─TreasuryTag►assemblyman─╢ 16:25, 23 December 2009 (UTC)[reply]
name removed as not important to the discussion and was only initially provided to explain how the suggestion originated. Suomi Finland 2009 (talk) 16:28, 23 December 2009 (UTC)[reply]
Fair enough – but it's still not a remotely viable proposal. ╟─TreasuryTag►Speaker─╢ 16:34, 23 December 2009 (UTC)[reply]
What is a "good editor" and why should we be labeling people as such? If you have a set of criteria upon which you base your opinion of who is and who is not a good editor, that is fine. We ought not be in the habit of declaring, as a community, that such-and-such is a "Good editor". Shereth 16:38, 23 December 2009 (UTC)[reply]
All editors that contribute in a positive manner to the project are "good editors". We can't go around naming people "good editors" and "bad editors" on the -amount- of contribution. Good editors are those that help improve the encyclopedia, while bad editors are those that vandalize. warrior4321 16:56, 23 December 2009 (UTC)[reply]
How are you even defining this? Is reverting vandalism counted (which a large amount of my edits is toward)? I mean, this IS, after all, a completely voluntary project and to suggest that people can't participate in one thing without doing the other is completely against the WP spirit. ♫ Melodia Chaconne ♫ (talk) 17:18, 23 December 2009 (UTC)[reply]
What about things that don't fit into either category? Things like templates and user scripts don't always improve articles directly, but they certainly shouldn't be lumped in with RFA and ANI. You also say "one of the criteria" - what are the others? Mr.Z-man 19:37, 23 December 2009 (UTC)[reply]

Making the edit toolbar more intuitive

I know there's a big overhaul of the editing interface in the pipeline, but it's been in the pipeline for a year now, with no deadline set. In the meantime, can we implement some quick and simple fixes to make our toolbar more intuitive to newbies? IMO, a lot could be done to redraw the icons, but I'll limit this to the most glaring problems. Those being:

  1. The 'link to' (third and fourth) button captions could be phrased better -- instead of stating "internal link" and "external link (remember http:// prefix)", it would be better to have them as "link to another article" and "link to an external website".
  2. The 'inserting media' (sixth and seventh) buttons could be vastly improved, both in that:
    • The images are not clear or representative of what they do; better images would be something like and
    • The captions do not properly describe what the buttons do; instead of "embedded file" and "file link", the captions should read "insert a photograph or diagram" and "insert a sound or video clip".
  3. The 'small text' button is a truly terrible graphic; something like would make far more sense.

As far as I'm aware, the last one can be easily implemented by altering MediaWiki:Common.js/edit.js, but I don't know about the others. Anxietycello (talk) 22:50, 23 December 2009 (UTC)[reply]

Number 3 isn't very legible. Fences&Windows 23:10, 23 December 2009 (UTC)[reply]
i agree, it is hard to see and figure out what it does (#3). good job on the other two though, i must agree on what you propose. just my 2 cents MACKDIESEL5 (talk) 23:29, 23 December 2009 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=333675498"