Misplaced Pages

Revision as of 07:39, 8 July 2012

Jimbo welcomes your comments and updates. He does not consider alerting him to any topic to be canvassing.

This is Jimbo Wales's talk page, where you can send them messages and comments.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, Index, A, B, C, D, E, F, G, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252Auto-archiving period: 1 day

Archives

Index –index– October 28, 2001 – April 12, 2004 April 16, 2004 – August 23, 2004 August 28, 2004 – December 8, 2004 December 9, 2004 – March 23, 2005 March 23, 2005 – July 24, 2005 July 26, 2005 – September 9, 2005 September 9, 2005 – September 24, 2005 September – December 2005 January 2006 January – February 2006 February 2006 February 2006, cont. March 2006 April 2006 – late May 2006 May 24 – July 2006 July 2006 – August 2006 August 2006 Most of September 2006 Late September 2006 – Early November 2006 Most of November 2006 Late November 2006 – December 8, 2006 December 9, 2006 – Mid January 2007 From December 22, 2006 blanking Mid January 2007 – Mid February 2007 Mid February 2007– Feb 25, 2007 From March 2, 2007 blanking March 2–5, 2007 March 5–11, 2007 March 11 – April 3, 2007 April 2 – May 2, 2007 May 3 – June 7, 2007 June 9 – July 4, 2007 July 13 – August 17, 2007 August 17 – September 11, 2007 September 14 – October 7, 2007 October 28 – December 1, 2007 December 2 – December 16, 2007 December 15 – January 4, 2008 January 4 – January 30, 2008 January 30 – February 28, 2008 February 28 – March 11, 2008 March 9 – April 18, 2008 April 18 – May 30, 2008 May 30 – July 27, 2008 July 26 – October 4, 2008 October 4 – November 12, 2008 November 10 – December 10, 2008 December 5 – December 25, 2008 December 25 – January 16, 2009 January 15 – January 27, 2009 January 26 – February 10, 2009 February 8 – March 18, 2009 March 18 – May 6, 2009 May 5 – June 9, 2009 June 10 – July 11, 2009 July 12 – August 25, 2009 August 26 – October 3, 2009 October 4 – November 20, 2009 November 20 – December 21, 2009 December 22, 2009 – January 25, 2010 January 22, 2010 – February 22, 2010 February 22, 2010 – March 17, 2010 March 17, 2010 – April 9, 2010 April 11, 2010 – April 24, 2010 April 23, 2010 – May 12, 2010 May 10, 2010 – June 4, 2010 June 4, 2010 – June 26, 2010 June 26, 2010 – July 22, 2010 July 22, 2010 – August 23, 2010 August 4, 2010 – August 28, 2010 August 28, 2010 – September 14, 2010 September 13, 2010 – October 6, 2010 October 6, 2010 – November 8, 2010 November 8, 2010 – November 21, 2010 November 21, 2010 – December 6, 2010 December 6, 2010 – December 22, 2010 December 21, 2010 – January 17, 2011 January 16, 2011 – February 10, 2011 February 6, 2011 – March 19, 2011 March 16, 2011 – March 26, 2011 March 26, 2011 – April 22, 2011 April 22, 2011 – May 16, 2011 May 17, 2011 – June 9, 2011 June 10, 2011 – July 1, 2011 July 1, 2011 – July 15, 2011 July 16, 2011 – July 26, 2011 July 26, 2011 – August 15, 2011 August 14, 2011 – August 23, 2011 August 21, 2011 – August 31, 2011 August 30, 2011 – September 7, 2011 September 4, 2011 – September 25, 2011 September 26, 2011 – October 19, 2011 October 16, 2011 – November 5, 2011 November 4, 2011 – November 12, 2011 November 11, 2011 – November 24, 2011 November 24, 2011 – December 6, 2011 December 3, 2011 – December 14, 2011 December 10, 2011 – December 16, 2011 (RFC about the Stop Online Piracy Act) December 15, 2011 – December 30, 2011 December 27, 2011 – January 9, 2012 January 9, 2012 – January 18, 2012 January 17, 2012 – January 30, 2012 January 28, 2012 – February 12, 2012 February 7, 2012 – February 25, 2012 February 19, 2012 – March 4, 2012 February 27, 2012 – March 18, 2012 March 17, 2012 – April 2, 2012 March 31, 2012 – April 13, 2012 April 12, 2012 – April 18, 2012 April 18, 2012 – April 26, 2012 April 26, 2012 – May 6, 2012 May 2, 2012 – May 22, 2012 May 19, 2012 – June 9, 2012 June 4, 2012 – June 20, 2012 June 18, 2012 – June 28, 2012 June 26, 2012 – July 12, 2012 July 3, 2012 – July 22, 2012 July 19, 2012 – July 29, 2012 July 25, 2012 – August 9, 2012 August 7, 2012 – August 30, 2012 August 29, 2012 – September 13, 2012 September 13, 2012 – September 27, 2012 September 26, 2012 – October 5, 2012 September 24, 2012 – October 20, 2012 October 9, 2012 – October 31, 2012 October 29, 2012 – November 19, 2012 November 17, 2012 – December 5, 2012 December 2–15, 2012 December 15–28, 2012 December 24, 2012 – January 12, 2013 January 13–31, 2013 February 1–10, 2013 February 11–28, 2013 March 1–16, 2013 March 17–27, 2013 March 28 – April 6, 2013 April 6–19, 2013 April 19 – May 3, 2013 April 25 – May 8, 2013 May 6–19, 2013 May 18–30, 2013 May 27 – June 16, 2013 June 17–30, 2013 June 27 – July 30, 2013 July 31 – August 4, 2013 August 4–12, 2013 August 13–27, 2013 August 28 – September 4, 2013 September 5–10, 2013 September 11–22, 2013 September 24 – October 6, 2013 October 7–16, 2013 October 17–27, 2103 October 28 – November 6, 2013 November 7–19, 2013 November 20–27, 2013 November 28 – December 5, 2013 December 6–24, 2013 December 25–30, 2013 December 31, 2013 – January 14, 2014 January 15–24, 2014 January 25–29, 2014 January 30 – February 10, 2014 Archives not yet dated: 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 This manual archive index may be out of date. Future archives: 184 185 186

This page has archives. Sections older than 24 hours may be automatically archived by ClueBot III when more than 2 sections are present.

Username penalty: IP users see articles 5x-50x faster

We need to remind users to logout to view mainstream articles 20x 30x faster. Avoid the username penalty which reformats major articles so much slower than for IP users. In running tests of template speed, I noticed that registered users (logged-in) now view articles which are formatted 5x to 50x times slower than what the IP-address users see (due to IPs seeing the common, quick, cached copies of formatted articles). Some of us were recently trying to optimize template speed, and were able to make a core template run about twice as fast, rather than having hundreds of "sub-optimized" one-line templates. In running those tests, then I noticed that hundreds of major articles can be displayed for IP users in about 1/8 second, whereas the username-specific reformatting of those articles runs several times slower, typically 20x 30x slower for mainstream articles, such as classic encyclopedia topics with formatted references. As you probably know, the complex citation templates use vast amounts of time to slow a large text article from a half-second formatting into several seconds during an edit-preview or view by a logged-in user. Of course that's fine, when people expect to hit "Show-preview" and wait several seconds for citations and navboxes to be formatted into a half-second text article. However, more users should know to log out and view the major articles 30x times faster, and edit them when needed, but after edit-preview log-in before saving the changes with an unwanted IP-address user ID. I would hate for most registered users to think that big Misplaced Pages articles are really displayed as excrutiatingly slow as when users are logged in. Logout and view the major articles 30x faster. Stubs display at the same quick speed either way, due to few {cite..} or navbox templates piled on those stub pages. Long term, I am wondering how to change major articles into simple large text pages that still format within one second, perhaps using dozens of quick templates. Reduce the current username penalty. -Wikid77 (talk) 17:49, 1 July, revised 00:14, 3 July 2012 (UTC)

Assuming one is not a computer, then I don't see why this matters. I very rarely have to wait more than a second or two for an article to appear. I don't know what my reading rate is but I would say 30 words a second is a decent upper bound. So at the very worst this costs me the time to read a couple of sentences.

This will matter for bots of course. But then they shouldn't be running off cached pages most of the time... Egg Centric 21:40, 1 July 2012 (UTC)

• Only major articles slow, not stubs or small articles: Thanks for noting the difference. The problem is typically a speed factor for only major articles, such as the top 500 articles on any mainstream topic, where the {cite} templates have been used extensively (or navboxes are large). I think a typical infobox formats within 1 second, so a large half-second text formats within 1.5 seconds with an infobox. However, the various {cite} templates use the gargantuan Template:Citation/core with over 620 parameters in the markup, so using {cite...} often adds several seconds to the formatting time, at the rate of nearly 1 second per 13 {cite} transclusions. The result is that a major article formats in over 11-12 seconds, rather than 2-3 seconds, for registered users, or for anyone during edit-preview. Because the Internet is typically very slow (with exceptions such as Google Search), then many registered users do not realize that IP users see major articles several seconds faster than they do. It is an issue that I have been trying to improve for years (working on {cite-fast} templates which run 85 per second, 6x times faster), but Jimbo has advised to avoid "all templates" which would also solve the problem, but many templates (such as infoboxes) are valuable, so we just need to optimize (and reduce) the larger templates. -Wikid77 (talk) 11:46, 2 July 2012 (UTC)
• Making major articles 3x faster for editing: Okay, the reality, obviously, is that cached copies of articles will always be, typically, over 10x faster than any optimization of reformatting. A major article that IP users view in "0.249 seconds" is likely to reformat in over 11 seconds (44x slower), and my efforts at optimization are showing reformat times no faster than 5 seconds (20x slower than the cached copy), even though twice as fast as major articles display now. I think we could get major articles to reformat 3x times faster, to allow faster edit-preview of the whole page, by having special versions of templates which are specifically fast for the basic parameters (so for rare customized parameters, use the larger massive templates). Extensive functionality seems to be the enemy of speed, because checking for use of extra features, or giving users helpful advice during use, causes extra overhead and slows the whole template, or leads to n-variety sets of similar templates which are difficult to update in similar, synchronized functionality. A possible strategy would be to have 3 types of related templates:

• Template:Hogger - the typical massive template with many features
• Template:Hog_fast - a smaller version with only the basic features
• Template:Hog_helper - a training-mode version which warns of errors.

From the tests I have run, I am seeing that any template with many parameters will be something of a resource hog. This confirms Jimbo's advice to avoid large templates. Hence, we have the infobox templates, but they tend to slow reformatting by 1 second each, so limit their use (having 20 infoboxes in an article could slow the article by nearly 20 seconds). We can live with 1 or 2 large infoboxes per article, no problem. However, {citation} templates for 200 footnotes per article are going to eat major time, currently 1 second for every 13 footnotes, or almost 15 seconds for 200 footnotes. Instead, many people are hard-coding several footnotes, in areas, so not all "200 footnotes" use {cite} templates. The tests for the experimental {cite_fast} run faster as 70x per second, or almost 6x faster, but 200 footnote templates would still consume 3 seconds of reformat time, so again, hard-coding many footnotes (where the detailed parameters are not needed) can keep 200 footnotes below 3 seconds of formatting with a {cite_fast} template. -Wikid77 00:14, 3 July 2012 (UTC)

I've run a couple tests myself using citation templates. I did 3 tests: one with just the urls, one with full citation templates, and one with short Harv citation templates in the "Notes" section that called the longer templates in the "References" section. The no-template was obviously the fastest. The one with 200 full citation templates was the slowest, and the one using Harvard templates was in between. It's a good option for articles that have a lot of citations to the same source. ~Adjwilley (talk) 02:16, 3 July 2012 (UTC)

The discussion at Misplaced Pages talk:Featured article candidates/Citation templates (technical) is useful background reading. A fuller debate exists at Misplaced Pages:Centralized discussion/Citation discussion. It's demoralising to see how the actual solution (extend cite.php and move away from templates) is opposed at Demo of specific proposal for all the wrong reasons. Any technical solution that requires changing something is likely to fail because of the culture of inherent Ludditeism that exists in Misplaced Pages. --RexxS (talk) 07:33, 3 July 2012 (UTC)

• The vcite solution is great for now: Most users would be stunned to realize the articles will reformat or edit-preview 3x (thrice) as fast now, using Template:Vcite_book (etc.). Awesome! As for internal changes to Cite.php, I try to also consider the "worst possible scenario" of how the proposed internal PHP functions might include some hideous bugs, stuck for years, because template coders could not help to fix them. Instead, by using fast-cite templates, we can gain 80% more speed now, while also fixing any format bugs, within days, rather than months or years. Reducing a 23-second edit-preview to only a 8-second wait is a wikimiracle at this point. Beyond the cite templates, we can also optimize other issues, to gain even more speed than from citations alone. -Wikid77 15:48, revised 23:59, 3 July 2012 (UTC)

• Possibility of caching subst'd template results: Another tactic, which could be used in rare circumstances, would be to create "segmented articles" composed with cached segments appended to the current markup text. We could take very slow portions of articles and run the templates as wp:subst'ed, then save those segments and transclude them into the final article. For example, with an article named "Mars colony":

• Mars_colony/dynamic_map - a segment with a complex (slow) map template
• Mars_colony/dynamic_map_cache - a segment with the subst'ed template(s)
• Mars_colony - then transcludes {{Mars_colony/dynamic_map_cache}}

The rule would be that changes should be made to the template-based segments (not the cache versions), which are subst'ed into the cache-based segments, and then the cache files are appended into the article, allowing massive slow templates to be used in a huge article which reformats (around the cached segments) within seconds. -Wikid77 (talk) 17:29, 4 July 2012 (UTC)

You know that Tim is working on Lua ("scheduled for 2013")? The aim is to replace frequently-used templates with a new and much faster system. Johnuniq (talk) 00:35, 5 July 2012 (UTC)

• Conversion to fast Lua language: Thanks for noting that option for 2013. It would be great to have the ultra-efficient Lua scripting language, with loops and recursion, even if more complicated for many users. Beware that a massive change in technology is a typical tech solution for "deus ex machina" and typically needs almost a year longer than hoped (=2014?) to "quickly save the day". There is also a danger of interface overhead, such as a "faster" system needing a "10-second" connection link (hopefully not with Lua). Often, a rewrite can duplicate unneeded complexity, and there might be a feeling to handle all "620" parameters now in Template:Citation/core. Meanwhile, I am still focusing on actions to take within a few weeks, which already show 3x speed improvements. Long term, the use of Lua might allow extremely smart, and yet fast templates, so that is another benefit beyond today's cumbersome templates. -Wikid77 06:27, 5 July 2012 (UTC)

• Working on essays about performance: I think we will need several essays about various performance issues, depending on people's level of perspective, such as explain how an article can process over 900 templates per second, but they must be (very) small templates. There are too many topics to cover in a single essay. One essay already introduces the readers to technical performance issues:

• WP:Analyzing performance issues - gives intro & links other essays.

We need a new essay about making templates run much faster. -Wikid77 (talk) 11:15, 6 July, revised 19:08, 7 July 2012 (UTC)

The efficiency dividend

I know you prefer to avoid discussions about technical software changes, so this is another performance issue which applies to general users, rather than internal software structure. An interesting effect in page-load speed I have found is the "efficiency dividend" that allows shortened templates to run even faster, on a busy system. This issue should be included in an essay about page-load performance. It explains why users can view the improved major articles so much faster (even if they do not want to consider the math behind the improvements). In rewriting templates which can run 9x faster than before, over the past 2 years, I have noticed how the "busy" servers occasionally show a slow-down, for pretty much everything, and that delayed response often seems 1.4x (140%) longer, so a complex page-load of 10 seconds becomes 14 seconds when servers are busy. The figure of 1.4x is a general approximation, and might run even slower (such as rarely 2x or 20 seconds) when the system gets very busy.

The quite interesting aspect of the 1.4x delay is, while it applies to both short or long pages, it intensifies the benefit of making pages shorter. For example, if a 10-second article display (worse case: 14-second) is reduced to only a 2-second load, then the math predicts an improved "worst case" of 2.8-second load (1.4×2) when servers are busy. This has been observed in live tests of faster pages. The net result improvement includes the worst-case difference of 14-10 versus 2.8-2 seconds, or 4 versus 0.8 seconds = 3.2 seconds. That 3.2 is the "efficiency dividend" (or "efficiency bonus"), because the worst-case page-load time, for the faster page, never incurs that prior 3.2 extra seconds, and only risks the 0.8-second delay added by 1.4×2 seconds. Hence, although the prior page-load time of the 10-second run was shortened to a 2-second run, the busy servers will no longer delay the page to a 14-second run (+4 seconds), only 2.8 seconds, and thus the users avoid the 4-0.8 or 3.2 extra seconds as an efficiency dividend when the servers are busy, and the delays would seem even more irritating. When compared to the total page-load time, the result is 14-2.8 seconds faster, or 11.2 seconds faster, not just the ideal run times of 10-2, as 8 seconds faster. That 11.2 savings shows the effect of adding the 3.2-second efficiency dividend, so a faster page avoids the potential 11-second delay of the prior slow page. The point is that by simply improving a page-load from 10 to only 2 seconds, the improvement also avoids that 11-second delay, which users had often experienced at times of the day when the servers were running slower. Now, applying that to real articles, with a major article (such as a nation) which has a common 20-second load time, then shortening the 20-sec to a 6-second load time also gains the efficiency dividend of (28-20) - (8.4-6)= 5.6 seconds. With busy servers, an improved major article would load faster by 14+5.6=19.6 seconds, almost 20 seconds faster at busy times.

Overall, the "rule of thumb" would be, for a speed-improved article, the new load time would be an additional 5.6 seconds faster, at busy times, or about +6 seconds faster. The efficiency dividend for faster major articles is, thus, also +6 seconds faster than the underlying, basic speed improvement. Simply by improving major-article speed 3x, we gain yet another 6 seconds we did not anticipate. That is why improving a major article, to run faster, can become even another +6 seconds faster, as a free "efficiency dividend". -Wikid77 15:48, 5 July 2012 (UTC)

I think that would have been better if it had all been chopped down to something more manageable. I got a feeling rather like on hearing the bit in Monty Python's The Meaning of Life about "Now before I begin the lesson; will those of you who are playing in the match this afternoon move your clothes down on to the lower peg immediately after lunch before you write your letter home if you're not getting your hair cut - unless you've got a younger brother who is going out this weekend as the guest of another boy; in which case collect his note before lunch, put it in your letter after you've had your hair cut, and make sure he moves your clothes down onto the lower peg for you." Dmcq (talk) 10:43, 6 July 2012 (UTC)

Well, that is very similar, with slow pages and their faster brother pages, playing games on the servers, where the servers will get busy and slower in the "afternoon match", so improve articles to run on the streamlined "higher peg" as being much faster (+6 seconds faster) during the match. -Wikid77 (talk) 12:03, 6 July 2012 (UTC)

• Page load-time is 72% of busy time: Another rule of thumb, when considering performance, is to retro-calculate the actual, minimal page-load time, as 72% of the server's reported load time during busy periods, which happen several times during each day. The 72% is a ballpark estimate, but gives a fair impression of the delay. So, if the HTML-page source (<View><Source>) shows 10 seconds at a busy time, then apply 72% to get "7.2 seconds" as the actual page-load time if the servers were idle. Another way to view the efficiency dividend (above) would be to answer the question: "When the servers were busy in 2011, how much longer did major articles take to display for logged-in users?"  Answer: about +6 seconds. -Wikid77 (talk) 14:47, 7 July 2012 (UTC)

Forking large major articles to: (full)

I am re-thinking your advice to have smaller, more-focused articles on major topics, perhaps named as article "xx" with the current large version renamed as "xx (full)". I initially thought the Simple English Misplaced Pages would handle the issue enough, but now, I think we really need to have 2 versions of major articles, here, as you suggested long ago. I was looking at article "YouTube" and thought "way too big" for general readers. So perhaps:

• new "YouTube" - a smaller article, limited in size (perhaps 700 words?)
• new "YouTube (full)" - the original large article moved to a new name.

Otherwise, I really would fear wholesale deletion of extra information, such as the interesting list of other nations having YouTube versions, but all of that extensive description overwhelms the basic details of the 6 W's ("who, what, when, where, why, and how"). In many cases, the full article is almost "YouTube (rant)" because of the tedious detail, but obviously, we cannot label articles as "rant" simply because they contain 5x-9x times as much detail as most readers seek. There could be numerous cases, such as a notorious crime article, where the "(full)" version could include lists of forensic evidence to explain "whodunit" or why other suspects were freed, while allowing a smaller article to generalize the issues (but knowing the "(full)" version explains things oversimplified in the top, condensed version). Since you have already thought about this issue, and content forks are entirely valid, what other concerns should we address before making such article forks?

From a practical standpoint, I would focus on the 100 (or 1,000) most-viewed articles, and count what percentage of them need a simplified overview article. In terms of Misplaced Pages performance, everyone would benefit from the numerous advantages: most readers would see the nutshell version they expect; the smaller article would appear within 2 seconds; large articles could be protected from excessive trimming of details; limiting size (700 words?) would discourage POV-pushing (where currently, tangent comments are allowed in large articles because wp:NOTPAPER protects long sections); and ideally any POV-pushing in "(full)" versions would have less impact (because few people would read the massive full versions). Currently, WP is a major "advert-magnet" because people know any boosterism wedged into major articles has a good chance of being info-spammed into the "captive audience" who view the major article by name, whatever that name happens to display. Any other thoughts or advice? -Wikid77 (talk) 06:42, 7 July 2012 (UTC)

Ideally, I think the lead sections of all articles should combine to something like the Micropædia. —Kusma (t·c) 08:56, 7 July 2012 (UTC)

See also: Introduction to general relativity and general relativity. benzband (talk) 09:25, 7 July 2012 (UTC)

I set up an RfC at WT:Article size#RfC: Should the rule of thumb for article size refer to readable prose size or markup size? which I believe is relevant. I should be neutral about notifying about that but I think the featured article candidate editors have completely forgotton and don't care about WP:NOTPAPER and just want to produce the equivalent of printed papers on the topics. Dmcq (talk) 10:57, 7 July 2012 (UTC)

I just had a look at the Youtube article and personally I would consider it a large article where bits should be turned into sub-articles if they grow to any size but not one where that should be a major consideration of the editors yet. Perhaps what is wanted is an easy way of just viewing the lead of an article? That perhaps could be an option which is automatically invoked in mobile profiles so they have to click on a button to get the whole article downloaded. Dmcq (talk) 11:10, 7 July 2012 (UTC)

I've just put a proposal at WP:VPT#Section viewing about how one could deal much better with download time. I still think the FAC editors tend to push articles so they are about twice the readable size even with a good computer. Dmcq (talk) 13:24, 7 July 2012 (UTC)

Alert !

Hello Mr. Jimbo.

I want to point out to you a problem, which I have identified in the current interpretation by other editors of WP:NOR:

If someone would mix a poison "X" and some fruit juice, and call it a "D" drink, and sell it to people, there is no way that fellow editors here would allow to mention the side effects of the poison ingredient "X", in an article about "D".

Why? Because the sources about "D" will not list the side effects of "X", as they would probably be PR for "D", and the sources for "X" will not mention "D", because what do scientists, who study the side effects of a poison "X", care about the drink "D" or "Z" that "X" will be put into.

Due to that there are two problems:

First according to the WP:NOR it is not allowed to use the scientist's source because it don't mention "D". Although, I think, that "X" is directly related to "D", as "D" contain "X", other editors' practice is to mandate explicit mentioning of "D" in the scientist article about the side effects of "X", and that is not going to happen, that is not how scientists work. They find a rule ("X" cause a side effect), they don't retest and make papers about every conceivable application of the rule, like when "X" is mixed in a "D" drink.

The second problem, is that according to the WP:SYNTH, if one say "D" contain "X" and "X" has a side effect, then it is synthesis. Again, I don't think that such a simple application of logic A->B, and B->C therefor A->C should be considered a synthesis, but other editors seem to be sure that it is.

And there you go, the drink "D" is on the street, and if a kid would open Misplaced Pages to learn about that drink, he will not learn of the side effects of "D" at Misplaced Pages, and drink the drink in ignorance.

I think that this is awful, and that something should be changed, so that editors will understand that a source can be related to the topic of the article, even if it doesn't mention the topic, but does mention some relevant ingredient of the topic, and that simple logic, that any educated person can verify, is allowed. --Nenpog (talk) 20:04, 7 July 2012 (UTC)

. <-- -- Avanu (talk) 20:25, 7 July 2012 (UTC)

Presumably, this refers to delicate clinical decision-making issues regarding indications to X-ray computed tomography (also discussed here). In addition to WP:NOR and WP:SYNTH, I think WP:MEDRS is a valuable defence against applying simplistic assumptions, however well intended. —MistyMorn (talk) 21:26, 7 July 2012 (UTC)

If this is about someone selling drinks containing poisons, the appropriate course of action is to inform the authorities, not raise it on Jimbo's talk page. If this is about the risks associated with CT scans, why not say so? 'Simple logic' suggests to me that trying to compare the two is nonsensical. AndyTheGrump (talk) 21:35, 7 July 2012 (UTC)

Déjà vu (from Wikipedia_talk:WikiProject_Medicine/Archive_27#Adverse_effects_of_a_component_of_a_medical_procedure.). —MistyMorn (talk) 21:45, 7 July 2012 (UTC)

-AndyTheGrump, there are many poisons that are completely legal to consume (e.g. alcohol, cigarets, etc, an expression-"what is your poison?"), and which may include immediate side effects, and delayed side effects that may manifest after years of consumption, or years after consumption.

-MistyMorn, I am not talking about "assumptions" or "simplistic assumptions". I am talking about simple logic, where A->B, and B->C are well sourced. In that case it follows that A->C. It is verifiable. Nothing is assumed. --Nenpog (talk) 22:07, 7 July 2012 (UTC)

...except all your assumptions about the real world? As Oscar Wilde once said, "The pure and simple truth is rarely pure and never simple". Good night, —MistyMorn (talk) 22:19, 7 July 2012 (UTC)

No assumptions. If you think an assumption is made you should point that out and refuse to accept, that the premise of the simple logic is sourced. Instead the situation today is that one can't argue in Misplaced Pages, that since one source suggest that , and the other source suggests it follows that . --Nenpog (talk) 22:40, 7 July 2012 (UTC)

The OP's question has been dealt with quite well in a number of other forums. On the other hand I'm glad that at last Misplaced Pages is warning about the drink DHMO made from the combination of a source of dangerous free radicals and an explosive that is being peddled cheaply or even being given away freely all around the world, If a reliable source had not been produced about the dangers of dihydrogen monoxide people could not be warned about it according to WP:SYNTH. How can something be a fire retardant and a component of many pesticides and yet be safe to drink? Everybody should be warned of the potential dangers of DHMO. Dmcq (talk) 22:29, 7 July 2012 (UTC)

One other danger is the drastic and unexpected cooling effect that dihydrogen monoxide can cause. Some children in the neighborhood somehow got a large supply of the stuff and were filling balloons with it and casually tossing these things at passerby, obviously unaware of the hazard involved. -- Avanu (talk) 22:49, 7 July 2012 (UTC)

Try formulating that as , where the first two are sourced. Lets see if you can arrive with false conclusions.--Nenpog (talk) 22:54, 7 July 2012 (UTC)

So, is this about poisons, or about CT scans? If it is about the later, it seems evident from a little perusing of your edit history that you are on some sort of 'mission' to alert the world to the risks involved in their use, and are repeatedly resorting to original research to do so. Multiple contributors have tried to explain to you that (a) Misplaced Pages isn't here to provide a platform for your 'mission', and (b) we don't write articles by cherry-picking primary sources to 'prove' a particular viewpoint. Yes, there are risks involved with CT scans, as our article makes clear - but it does so according to reliable sources, not by convoluted 'simple logic' that appears anything but simple (the biological effects of ionising radiation are a complex issue for a start), and less -than-logical of it ignores the benefits of CT scans as a medical procedure, and makes out that we are discussing a 'poison' instead. Our article on CT is written the way it is because it conforms to our policy regarding medical issues - which is to use only the best sources, and strictly avoid synthesis or the giving of undue weight to primary sources. In consequence, our coverage of medical issues has been commented on by outside researchers as some of the best, and often as reliable as more conventional sources. To change policy in order to allow soapboxing, POV-pushing and the like would be a serious mistake - and it isn't going to happen. If you want to alert the world to your views on the dangers of CT scans, you'll have to find somewhere else to do it. That isn't what Misplaced Pages is for. AndyTheGrump (talk) 22:56, 7 July 2012 (UTC)

It is about that simple logic is verifiable. --Nenpog (talk) 23:06, 7 July 2012 (UTC)

That you are pushing a POV is verifiable. That this POV is contrary to what reliable sources say is verifiable. That Misplaced Pages articles are written according to reliable sources is verifiable. Simple logic says that you can't push your POV on Misplaced Pages. Do it somewhere else... AndyTheGrump (talk) 23:31, 7 July 2012 (UTC)

In simple logic I meant . Try writing it that way, or present the logic rule you employ. Please share the sources for your claim. Are you implying that you have a source that claim that simple logic is not verifiable? --Nenpog (talk) 00:23, 8 July 2012 (UTC)

To answer the OP's question, an example would be "Vitamin K". For that article we had a hatnote on pointing out its slang use as a term for ketamine until it fell victim to a vandalism and anti-vandalism cycle.. While that usage may be comparatively uncommon, there's still a fair possibility that Misplaced Pages saved the life of some idiot kid who would otherwise have snorted up a megadose of the vitamin and become a casualty a la "The Andromeda Strain". Wnt (talk) 00:09, 8 July 2012 (UTC)

I don't understand your point here. --Nenpog (talk) 00:23, 8 July 2012 (UTC)

There's no problem whatsoever. You've been confused by the fact that statements made in a biological or medical context are phrased as if they were universal, when in fact they carry with them a complex set of unstated assumptions about conditions. e.g., if I said "Mannitol is harmless", the assumption in the biological context is that I'm not delivering it in the form of a superheated plasma, for instance. Your problem is that to invoke "simple logic", A->B must be universally true. Making universal statements about complex real-world entities is surprisingly hard. To give a concrete example, drinking concentrated acid (A) entails burns in your throat (B). Drinking concentrated base (C) entails B as well. Since A->B and C->B, if you mix equal amounts of A and C, A AND C->B...except that, in actual fact, A and C neutralize each other and the real result is not-B. The flaw is not in the logic, but in the statements that A->B and C->B, which were falsely taken to be universal through a failure to appreciate the implicit assumptions behind the statement that "concentrated acid burns your throat".

In short, the problem is not with your logic, but with your premises. Since we really can't make universal statements about the effects of a chemical "X" on a biological system, the onus is on you to show an empirical demonstration that the claimed effects of X are applicable to a particular system. Given that you're engaged in special pleading here on Jimbo's talk page and making a specious argument about logic, I assume you're getting badly spanked as far as the burden of proof goes. Choess (talk) 02:05, 8 July 2012 (UTC)

Nice. The logic rule you try to employ is . That is a different rule than the simple logic rule that I mentioned, where the conclusion B of one statement (A->B) is the exact premise of the other statement (B->C), and very easy to verify as such.

Additionally A=(drinking acid) C=(drinking base), and (A and C)=(drinking acid and drinking base). A mix of equal amounts of acid and base is a neutral solution, N=(drinking a neutral solution). N is not equal to (A and C), and there isn't a logic rule - . So (A and C) means that someone don't drink a neutral solution, and there will still be consequences for the throat B, thus (A and C)->B hold. Try again. --Nenpog (talk) 07:35, 8 July 2012 (UTC)

• Could I ask that people back off a bit here? What we have is basically somebody saying something reasonable, or at least defensible, but saying it in such an obnoxious way that nobody wants to pay attention. That's a very unfortunate situation. If Nenpog knew how to work cooperatively with other editors, it is quite possible that some of the material he favors would make its way into the article -- the science here has, after all, been evolving. But he has tried to do it by edit-warring, and that's a disaster. Looie496 (talk) 01:49, 8 July 2012 (UTC)

Sorry, but no. It is totally obvious from a few minutes inspection of Nenpog's editing history that we have someone not in the slightest interested in doing anything other than pushing an agenda - and doing it in a way that is totally contrary to the way Misplaced Pages works. Some people just don't seem to understand what Misplaced Pages is for - and the only appropriate response is to show them the door. As for 'evolving science', we will report on it after it has evolved, not beforehand. Nobody is arguing that there aren't risks involved with CT scans. As far as I'm aware, nobody is arguing that anyone has an exact understanding of what all the risks are. This is a legitimate subject for scientific enquiry. And given the possible risks and the widespread use of CT technology, such scientific enquiry is not only legitimate, but common sense - and such enquiries seems to be ongoing. This is what we should be reporting in our articles, not the speculative waffle of POV-pushers who seemingly can't tell the difference between a medical procedure applied when the apparent benefits outweigh the apparent risks (or at least, where those applying the procedure suggest they do), and a 'poison' which somehow justifies starting a thread on Jimbo's talk page entitled "Alert", followed by a heap of bollocks about 'logic' and the rest. POV-pushers obsessed by some 'injustice' or another are neither good for Misplaced Pages, or for scientific research. The least impolite way to handle such obsessives, once they make their obsessions clear, is to tell them to go away - to do otherwise is only to encourage them to carry on wasting everyone's time on matters that have nothing to do with article content. Nothing that Nenpog can say on the risks of CT scans is relevant to our article, per policy, if it is based on 'logical' original research aimed at 'proving' that it is dangerous - if for no other reason than that there is nothing remotely 'logical' at engaging in research to 'prove' what you 'know' already. WP:MEDRS is there for a reason, and episodes like this convince me that the reasoning behind it makes sense - Misplaced Pages is here to report on science, not to engage in it. Nenpog is in the wrong place... AndyTheGrump (talk) 04:44, 8 July 2012 (UTC)

Great Job Opportunity for Jimbo at Elance!

Hi Jimbo,

Apologies if you've seen this before, but this Elance ad is looking for a Misplaced Pages Admin or 'Crat who can publish the Misplaced Pages articles their clients have written "without having them deleted a few weeks later." I figure why settle for a 'Crat, when you can hire Jimbo himself?! After all, he runs this place, doesn't he?

But seriously, if "Swift11" got a quick note (or a visit - he appears to be in London) from you explaining how things work around here, it might (or might not) convince him to change his ways. Cheers, Ebikeguy (talk) 23:57, 7 July 2012 (UTC)

The discussion on this is herePharaoh of the Wizards (talk) 01:49, 8 July 2012 (UTC)

Misplaced Pages's red links...hot or not?

If you saw an editor adding hundreds of new red links (links to nowhere) in existing articles, would that be cause for concern? Would it depend on circumstances? Do you like red links or hate them? How many people see a red link and think "I must go immediately and research that topic and create a new article" versus simply saying "Eh, the good samaritan behind me on this road will take care of it" and pass it by? -- Avanu (talk) 04:23, 8 July 2012 (UTC)

See Misplaced Pages:Red link.—Wavelength (talk) 04:45, 8 July 2012 (UTC)

I have. I want to see other opinions. -- Avanu (talk) 06:16, 8 July 2012 (UTC)

Wavelength - the attitude of "See this policy document" is of no use at all. doktorb _words 06:42, 8 July 2012 (UTC)

Personally, I have never been a fan of redlinks unless there is a realistic chance of creating the corresponding article in the near future. Speculative redlinks are of little use.--♦IanMacM♦ 07:23, 8 July 2012 (UTC)

The redlink needs to be notable - it could have an article but is just not written yet. Interestingly we have means of finding redlinks on a most-wanted-list where the number of incoming links to any non-existant article shows its relative importance and article creators pick their chores from that. Anyway suitable redlinks are great, turning them blue is the icing on the cake. Agathoclea (talk) 07:39, 8 July 2012 (UTC)