User talk:Dinoguy1000

Signature fix
Allo, I've done some fixes to your signature as it was causing issues on Opera (specifically, the lazy html tags and lack of "" on attributes were causing green text for the rest of the page). When I get my bot up and running, I'll do a site scan for your sig and apply the fixes globally. In the meantime, just say no to lazy html tags! :P --Gnu32 17:22, 12 February 2011 (UTC)


 * Aah, sorry about that. I originally used the version that I use on Wikia, which didn't leave out attribute quotes or closing tags, since I wasn't sure if HTML Tidy was installed here or not. After experimenting, it looked like it was, so I switched to the much leaner (and much more invalid) version I use on Wikipedia, since Tidy should fill in the missing quotes and closing tags itself (there haven't been any complaints about my sig on WP in Opera, so I assume Tidy actually does what it's supposed to there). If it's not too much trouble, could you play around with my sig, removing quotes and closing tags, to see if there's a shorter version that plays nice in Opera? 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 17:48, 12 February 2011 (UTC)

thankyouthankyouthankyou
What a coinky-dink. Just as I hit the "Save Changes" button to add Mystery Block to the proper "Removed" section, I get hit with the ol' Edit Conflict. Checked the history and saw you fixed my silly mistake. Thank you kindly :) ''(I has an excuse! I only had 3hrs of sleep last night, and didn't notice the original "Removed" section)'' That Canadian Guy 19:04, 2 March 2011 (UTC)


 * Heh, no problem. =) Truth be told, if I had my way, that template (and the other navboxes) would look quite different, at least in the edit box, but that's just me (and really has nothing to do with your message ;P ). 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 19:06, 2 March 2011 (UTC)


 * Believe me, if I had the time (which I don't), I'd go purchase some cheap site hosting and make my own Minecraft Wiki. And things would be alot different. Much more professional looking, as if it was a Wiki for the FBI (no offence to this Wiki, I'm just a professional kinda guy), and I'd probably do things differently such as splitting up the Mob page into separate pages for each mob (I wouldn't care if half of 'em were stubs. Stubs are awesome.). That Canadian Guy 19:11, 2 March 2011 (UTC)


 * Without knowing how you feel about Wikia, let me point out the Minecraft Wikia. ;) 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 19:24, 2 March 2011 (UTC)


 *   Wikia. Wikia can go   itself. I loved how they introduced the NEW WIKIA SKIN :O, then within like a month of it being released, half of the bigger Wikis (Such as the Pikmin Wikia) said "Screw this" and ended up getting their own site hosting. Wikia just screwed itself over big time. I did use Adblock Plus to get rid of all the Wikia ads on the Monaco theme, but their new theme is just ridiculous and overcrowded with ads. That Canadian Guy 20:45, 2 March 2011 (UTC)


 * Yeah, I figured you might be like that. =D I can tell you that the main reason the YGO Wikia didn't also leave was because we decided we probably wouldn't be able to compete with our own work (and the fact that we'd have to find a host that could handle the traffic didn't help matters any, either). 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 21:06, 2 March 2011 (UTC)
 * Er, to address an above point, isn't the mob page already split out into separate pages? --JonTheMon 21:11, 2 March 2011 (UTC)

Food
Whoa. Nice edit. --R ocĸetor talk  07:49, 4 April 2011 (UTC)


 * Thanks, took me a while. =) I'm now trying to decide whether a refactoring of the table would justify the columns it would add. 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 07:51, 4 April 2011 (UTC)

Why?
Why did you undo my changes? Where was the fail? --Yulex2 03:44, 19 April 2011 (UTC)


 * I perhaps worded my edit summary too strongly (especially considering you are a new contributor here), but I reverted because of the change you made to the template's CSS and the fact that you used Sprite directly instead of using BlockLink, resulting in a lot of extra code. In addition, we don't have an article on the Spider Web, or, as far as I know, any sourceable information on its intended purpose. 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 04:46, 19 April 2011 (UTC)


 * Ok I understand now. --Yulex2 10:44, 19 April 2011 (UTC)

Reddit
Yes, I am the same NipplesOfTheFuture from reddit :D I'm also GhettoGreen on Minecraft, but I don't play on nerd.nu as much as I used to (I have a private server I play on with friends). --NipplesOfTheFuture 18:39, 27 April 2011 (UTC)

"Sublime" splash
Care to explain why you deleted my explanation? "Really not sure about either of those" isn't exactly a fortress of logic, especially given that you could've confirmed mine at least with two seconds of Wikipedia.

Sublime (literary) From Wikipedia, the free encyclopedia The sublime is a form of expression in literature in which the author refers to things in nature or art that affect the mind with a sense of overwhelming grandeur or irresistible power. It is calculated to inspire awe, deep reverence, or lofty emotion, by reason of its beauty, vastness, or grandeur.[1] When thinking of the literary sublime, most scholars point to the Romantic Period as the age in which it flourished. In Romantic poetry, authors often referred to mountains or deep crags, things that they considered both awe-inspiring and terrifying, in order to express the literary sublime.

CK 09:54, 1 May 2011 (UTC)


 * While that may have been the original usage of "sublime", its meaning has shifted since it started being used (at least, in my experience) - I have never heard it used in a way that would suggest the object or experience being described as "sublime" was anything like "awe-inspiring and terrifying"... If you disagree with my (admittedly sketchy) logic, though, feel free to readd your explanation to the article; I won't remove it again. ;) 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 13:25, 1 May 2011 (UTC)


 * The only real shift in meaning it's undergone to my knowledge is a colloquialization- it's used to add a superlative quality to a description that doesn't necessarily have to have anything to do with supernatural wonder and terror. However, to me it's pretty clear that Notch intended the original sense of the word: one of the paintings in the game is a facsimile of the foreground character in Caspar David Friedrich's Der Wanderer über dem Nebelmeer, a really excellently prime example of the Romantic sublime in art. (It's here if you're interested. http://en.wikipedia.org/wiki/Wanderer_above_the_Sea_of_Fog) I think I'll add the explanation again, with perhaps a slight re-phrasing to make it a little clearer. CK 15:45, 1 May 2011 (UTC)

Template:items
The Bowl isn't a tool: it's only used in the crafting recipe of the mushroom stew. If the bowl mustn't be on the "raw materials" because is crafted from planks, why the stick is in the "raw materials" section? Also, I added water and lava buckets because they are tools and they're two types of bucket--Ua 08:39, 29 July 2011 (UTC)


 * The group labels on Items aren't necessarily hard-and-fast rules for the items in those groups. There are several items besides sticks in the "Raw Materials" group that aren't really raw materials, for instance. This is done deliberately, for convenience and brevity (if the group labels perfectly described the groups, we'd need twice as many to cover the same items, easily!).
 * As I said in my edit summary, Water Bucket redirects to Water, and Lava Bucket to Lava. Neither of these has its own article, so I'd argue against their inclusion in the navbox. 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 08:51, 29 July 2011 (UTC)

1.8 Content pages and template tags
Thanks for all the fixes on all those tags etc on the Melon, seeds, etc pages. When it comes to content and wording, I'm pretty good, but tags, administrative rights, and reasoning for things exclusive to wikis, i don't really know that much about. --HexZyle 03:36, 29 August 2011 (UTC)


 * No problem. I have a reasonable amount of experience working on wikis, from both sides of the admin bit, so feel free to ask me about anything you might need help with or explained. =) 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 06:31, 29 August 2011 (UTC)

Wheat Seeds - template:block yeah exactly. (I wasn't actaully supposed to change the template, that was an accident while i was previewing it to see how fail it is) User:Cool thinks that Wheat Seeds are a seed, not a block. --HexZyle 02:31, 5 September 2011 (UTC)


 * Semantically, he's right, but until we see proof that the game treats Wheat Seeds (and the other seeds) specifically as a seed block, they should be left as "block". 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 02:35, 5 September 2011 (UTC)

replacing for ((BlockGrid))
hi, since wyn was uncooperative, i tried it with replace; this is what i’ve got so far:

User:Flying sheep/Template:BlockGrid (look at the source)

the problem is that the limit is hit, but BlockSprite as well as a &lt;td> hast to fit into the replaced section. both would need nearly 400 chars, and i’d have to recreate BlockSprite. :( – Flying sheep 19:52, 1 September 2011 (UTC)


 * Perhaps it would work if you put the table cell in a subtemplate (e.g. User:Flying sheep/Template:BlockGrid/cell)? I haven't used #replace enough to really understand how it plays with transclusions, and I haven't used the variables extension at all, so no idea how it actually works, transclusion or no. 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 20:35, 1 September 2011 (UTC)


 * hah, nope, it expands templates before replacing. and circumventing that would need escape sequences, which are not implemented – Flying sheep 21:04, 1 September 2011 (UTC)


 * Hmm... Well, it'd be considerably uglier and would require proper escaping, but you could try using wikitable syntax instead of HTML tables. 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 21:46, 1 September 2011 (UTC)


 * no, this way, we have fewer characters for the table syntax, so almost solely the blocksprite counts, but it is still way more than 30 characters (more like 300) – Flying sheep 22:34, 1 September 2011 (UTC)


 * Is there any way to store the cell in a variable and use the variable to get past the length limit, or does that result in race conditions regarding when various parts get parsed? 「 ダイノ ガイ 千？！ 」? · ☎ Dinoguy1000 22:41, 1 September 2011 (UTC)


 * it’s not much of a race as  seems to always win. our limitations are: 30 chars of html code can be inserted per occurrence per replacement; we can loop over all arguments as many times as we want. what we can do is to first replace each char per tablerow (e.g. aXXXXa) with itself and a series of funky symbols. for each named argument(e.g. a=air, X=stone), we replace each funky symbol with a 30-char-chunk of html, and the char (a or X) with the coordinates calculated by a extracted part of BlockSprite. X( – Flying sheep 14:07, 2 September 2011 (UTC)


 * Yep, short anything else (and between the two of us, you've already tried and I've already suggested most all the other options at our disposal), all we have left is nested #replaces (and hoping that they're not as hard on the server as the loop). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 17:37, 2 September 2011 (UTC)


 * The best would be to allow admin-approved php templates: thouse would be faster than anything written in this sorry excuse for a programming language (wikisyntax, that is, not php ;)), and also easier to write and read. – Flying sheep 12:24, 3 September 2011 (UTC)


 * PHP as the "best" is most definitely a matter of opinion; in my experience, just about everyone seems to hate it equally (but then, I don't know the language myself, so I can't say if everyone is just joking around or what). ;) There are extensions to allow Lua (and maybe other languages) to be used for templates, but AFAIK all of these present security and denial-of-service risks. A new parser, with support for proper programming, has been on the table for years, but it's a very hard problem (especially considering all the little edge cases in the current parser (which is not so much a parser as a haphazard pile of regexes piled up over the years) that it has to replicate), so no significant progress has been made until just recently on a parser rewrite, and it's hard to tell when anyone will finally get around to working on adding programming support in a secure manner.
 * Before you really start blaming wikimarkup for anything, though, you have to remember that it was never intended as a programming language - per it's name, it's a markup language. ;) ParserFunctions (and, later, StringFunctions and the myriad other extensions that add various programming paradigms to wikimarkup) arose because people insisted on trying to use wikimarkup as a programming language, but it is still not one, and the author of ParserFunctions has repeatedly said that PF was a mistake he wishes he'd never made. =D 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 17:41, 3 September 2011 (UTC)


 * well, i don’t know how to program PHP, since i was appalled by the language design, but since mediawiki runs on it (and all extensions are written in it), it would be bloat to add yet another script/template language parser. lua is pretty small, and i would dig every proper template/programming/markup language instead of mediawiki. of course the security risks are there, and i have no proper solution for it, but allowing to give individual users a “is trusted with programming” permission would help against crappy templates. the logic could be separated from the data and the markup template, so that every user can, say, add new entries to BlockSprite and change the appearance of it’s components, but only trusted programmers can edit the logic.
 * my specific proposal would be:
 * every template has 1. one markup template, 2. an optional script in a programming/scripting language, and 3. an optional css file
 * the markup template uses mustache, and is thus logic-less. it receives a dictionary/hashtable and uses it to replace tags in it.
 * if a script is present, it gets run on the argument dictionary, before it is handed to the template. the dictionary can contain arbitrary markup, so the script can do anything (e.g. fill a almost empty template with just one to-be-replaced tag in it)
 * if a css file is present, it is applied to the markup file. it’s also a mustache template that receives the optionally processed dict, so colors and stuff can be inserted there
 * as arbitrary markup can be passed in the argument dict to the markup template, a template can also use a set of optional sub-templates.
 * – Flying sheep 10:27, 7 September 2011 (UTC)


 * Most proposals for Lua et al. parsers (and most extensions written to do as much) have featured an external parser for the functionality, rather than writing one from scratch; this is something the MW devs and Wikimedia do not want, however, since it would mean adding an external dependency to MediaWiki that most servers would then have to install (as opposed to PHP, which basically everyone and their grandmother already has). This is why we don't already have something like this in core MW; currently, the best bet looks to be either a home-brewed language (in which case it would likely end up as an extension of the new parser being worked on) or a home-brewed parser for the chosen language, written in PHP and distributed with MW.
 * There is no effective way to limit who could write such templates in the current MW setup, and changing the software to allow such functionality would require major revisions (all AFIAK). Much more effective than that would be auto-death to any template that takes more than a certain amount of time or server resources to run.
 * I honestly don't know nearly enough to be able to comment on specific proposals for what a new template architecture may look like; despite talking a big game, I don't actually know any "real" programming languages (I've tried two or three times to learn C, and though I've gotten further on each attempt, they've all ultimately been non-starters), so I can't comment on what programming paradigms may be useful in the context of MediaWiki templates. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 17:01, 7 September 2011 (UTC)

interesting, but this conversation goes too far into meta-metaness :D

so mediawiki didn’t really go anywhere in this direction for years, and there isn’t a mature plugin we could use here, right?

for learing how to program, i’d recommend python, because it is designed for readability and the principle of least surprise. – Flying sheep 11:38, 8 September 2011 (UTC)

JS
Did someone say hint hint? I might try stealing your script and seeing if it works for me. – ultradude25 ( T at 07:06, 2 September 2011 (UTC)


 * Thanks for that, I finally figured out what the problem was. I'd forgotten, but Wikipedia's copy of MediaWiki:Youhavenewmessages was updated with a span with a unique ID that the script could search for so it wouldn't have to iterate through all the elements looking for a class name; the same has not been done on our copy. I'll fix this by using an older version of the script; make sure you grab that one if you're interested in it. ;) 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 07:14, 2 September 2011 (UTC)


 * Well, I could just edit that so it does that have id. Just tell me what to put in. – ultradude25 ( T at 07:25, 2 September 2011 (UTC)
 * Duh, why don't I just look at Wikipedia's one? Ugh, I don't think my brain is on. The updated script should work now. – ultradude25 ( T at 07:28, 2 September 2011 (UTC)


 * That's about how I felt when I realized the problem I was having with the script. =D Could you delete User:Dinoguy1000/newmessageshistory.js for me, since it's not needed now? 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 07:31, 2 September 2011 (UTC)


 * Done, now if only someone would edit my talk page so I can see the script in action... – ultradude25 ( T at 07:33, 2 September 2011 (UTC)


 * You two make me laugh :D (in a good way!) -- Wynthyst [[Image:User Wynthyst sig icon.png ]] talk  08:43, 2 September 2011 (UTC)


 * If you can't have fun while editing, what's the point? =D 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:44, 2 September 2011 (UTC)

Weee promotions
Congratulations! – ultradude25 ( T at 09:37, 2 September 2011 (UTC)


 * Heh, thanks! =D 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 09:40, 2 September 2011 (UTC)

Wiki-fu
You know how the delete/undelete, move and protect/unprotect options are hidden in the little drop-down next to the search bar? Is there any way to get them out of there so they're on the normal menu bar like the other options? I know there's some crazy javascript going on that makes the options that are already out retreat into the drop-down when there is not enough screen-space, but I have about 1000px left in that area, which is plenty of room for all of them to show at once. I'd also like to change the watch/un-watch star image back to text if possible.

Think you'd be able to help me out? – ultradude25 ( T at 13:34, 2 September 2011 (UTC)


 * DropDownToTabs should take care of your dropdown woes. I'm not aware of any scripts that change the star back to a Watch/Unwatch tab; I didn't see any on a quick grep through WikiProject User scripts/Scripts, though surely someone has made one. My own JS-fu isn't particularly well-developed, so I'm not sure I'd really be able to write a script to do that. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 17:47, 2 September 2011 (UTC)


 * Hmm the script doesn't seem to be applying. Do the tabs have a different name from wikipedia or something?
 * The star/text is an option chosen in localsettings.php ($wgVectorUseIconWatch), so there should be a way to get the style used when that's turned off, and replace the image version's style with it. Somehow. – ultradude25 ( T at 00:27, 3 September 2011 (UTC)


 * You can (sort of) fix the dropdown-to-tabs script by adding the line  to the top of your vector.js file; I think we'd need the wiki upgraded to 1.17 for it to work completely correctly. I'll ask Wyn if she can have the tech team look into an update.
 * Now that I look, it's actually quite straightforward to replace the star icon with the old text. Add the following code to your vector.js file:

$(function { $("#ca-watch").addClass("collapsible")   .removeClass("icon"); $("#ca-unwatch").addClass("collapsible")    .removeClass("icon"); });
 * Note that this, as written, requires the above fix at the top of your vector.js file, and it will result in the tab having the same appearance as the above fix when you click the "watch"/"unwatch" link; I don't know how to fix that (but again, an upgrade to MW 1.17 may be sufficient). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:02, 3 September 2011 (UTC)


 * Alright, well it seems to almost work, the text is just too big, but that's nothing that a little bit of css can't fix up. Thanks a lot! – ultradude25 ( T at 08:14, 3 September 2011 (UTC)


 * Yep, that's what I was referring to with the "sort of" qualifier. =) I played around with the tabs for a while in Chrome's element inspector seeing if I could find the source of the weird styling, though to no avail, but I didn't try actually fixing it up more (I can, though, if you get stuck and need any help). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 08:21, 3 September 2011 (UTC)


 * Yeah, I know how to fix them, but it's not a CSS problem it's the placement of the span tags. The javascript has put them outside the link, whereas they should be inside. After manually doing that from firebug it's almost perfect. The only issue left is the double border between the two lists, and that only happens because they're separate lists. I don't suppose there is anyway to change the javascript to insert the span in the right place, and move them into the same list as the others? – ultradude25 ( T at 10:04, 3 September 2011 (UTC)


 * Oh, is that it? Chrome's data inspector showed the spans placed inside the links like they should be, and in my experience, it has always shown the internal representation of a page's source after rendering and scripts. Wonder what's up with that...
 * The two lists (surrounded by divs) are present in the unaltered HTML as well, and there's no double border there... Perhaps a  or   on div#p-cactions would fix it? 「 ディノ 奴  千？！ 」? · ☎ Dinoguy1000 17:34, 3 September 2011 (UTC)


 * Good idea, I hadn't thought about negative margins. This is what the layout looks like to me. The span tags are around the link, not in it. The fact that the placement of a span with no styling or id/class makes a difference means the CSS is referencing the span somewhere (something like div.vectorMenu span { };), so it's possible that if I change it to not include the span, it might work. – ultradude25 ( T at 22:32, 3 September 2011 (UTC)


 * Hah! Got it. Take a look! – ultradude25 ( T at 23:09, 3 September 2011 (UTC)


 * Aah, very cool. =D Wyn said 1.17 will probably happen next week sometime, so you'll have to see then if you still need all these fixes. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 01:50, 4 September 2011 (UTC)

Vector improvements
I've been spamming up your talk page working on some vector improvements, to make it use less images, be better looking if you have images disabled and even replace some images with CSS3 gradients.

Here's how it originally looked with images disabled: And here's how it looks now:  As you can see, it's a lot closer to the normal wiki, plus when images are enabled, the wiki looks identical to how it looked originally. :)

Unfortunately the way the vectortabs are set up makes it pretty impossible to replace them with gradients (the border gradient overwrites the middle, and gradients seem to ignore z-index).

Now to get to the actual point... do you have any suggestions for more images that can be replaced with CSS/CSS3 gradients? You could also try it out yourself, it's good to get people on other browsers to try it to make sure it works for them. :) – ultradude25 ( T at 04:29, 4 September 2011 (UTC)


 * Not offhand, no... I never browse with images disabled, so I really don't know just what the Vector skin uses images for.
 * I played around with the styles some in Chrome and they seemed to match up with your screenshot (though, interestingly enough, Chrome - even the latest dev build - doesn't seem to support the actual "linear-gradient" CSS3 property value). =)
 * I wonder if the gradients might be made to work properly by using multiple backgrounds (does FF support that yet?)... I've not played with it myself, so I don't really understand how they work (or, at least, how they're supposed to). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 05:15, 4 September 2011 (UTC)


 * Actually I looked a bit closer, and it seemed to be a problem with repeating. I may actually be able to get it to work. I originally assumed the tab-break image was just repeating behind all the tabs, with the tab fade overlaying it. I'll have another go, I should be able to also change the sidebar divider image to a gradient. – ultradude25 ( T at 05:32, 4 September 2011 (UTC)


 * Aha! Got it working. I had to set background-size. Aside from a few images that would be impossible to make out of gradients, the page now looks identical to how it does with images on. And when they are on, there's only a base of 7 images (technically 8, page-break.png is still loading for some reason, need to find what's still referencing it), which is the logo, favicon, user icon, 2 arrows, search icon and curse logo. :D
 * I'm hoping to get at least the non-CSS3 things in MediaWiki:Vector.css at some point (I'll wait for the upgrade first, to see what's changed in the theme), even if I only saved 2KB of images, considering just how much bandwidth this site gets, it could end up saving a few GB. – ultradude25 ( T at 07:45, 4 September 2011 (UTC)


 * You can replace the arrow icons with pure CSS as well (at least, I think; it depends on exactly how the markup is set up), through judicious use of border-width - see http://jonrohan.me/guide/css/creating-triangles-in-css/ if you're ready to have your mind blown. =D 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 12:50, 4 September 2011 (UTC)


 * Huh, I knew the borders were drawn as angles, but I never considered using it to create triangles; that's crazy. – ultradude25 ( T at 13:25, 4 September 2011 (UTC)


 * Although, I can't really see how I'd implement it. The sidebar uses a background-image for the arrow, so the border doesn't really fit in properly. – ultradude25 ( T at 13:36, 4 September 2011 (UTC)


 * It gets even crazier when you realize you can use basically the same trick to draw any angle (thought I had a link for that, but guess not). ;)
 * That's what it looked like when I glanced at the code, but I wasn't sure. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 13:40, 4 September 2011 (UTC)

Wikipedia culture
So (completely random), since you were/are an editor at wikipedia, I'm curious about a possible perception that Wikipedia editors are somewhat..... elitist when going to other, smaller wikis. Can you see how that might be, or is the perception completely off/people are people? P.S. Not talking about you. --JonTheMon 18:52, 7 September 2011 (UTC)


 * I can definitely understand why there could be such a perception; Wikipedia has developed some very high standards for its articles, and these will become ingrained into pretty much any editor who spends time working there. To be sure, former Wikipedia editors are, therefore, likely to have high standards when editing at other wikis, but it's important to note the distinction between that and actually being elitist. Generally, though, Wikipedia editors are just people, and most of the real vets hate being treated as anything other than people when they're just editing (as you might imagine, editors with admin and other user rights tend to be venerated by those without any such user rights, particularly by newer editors). To be sure, there are those who revel in their privileges, but they're pretty well outnumbered by editors who see them for what they are (extra tools to aid in maintaining the wiki), and those editors, when just editing, only do so in the capacity of editors, rather than as admins, or bureaucrats, or what-have-you. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 19:52, 7 September 2011 (UTC)


 * What about decision making and "not rocking the boat" of how a wiki was being run before they show up? --JonTheMon 20:18, 7 September 2011 (UTC)


 * As far as that's concerned, I can only speak from my own, personal experience (since I've never made a point of following other Wikipedians onto other wikis; that'd just be creepy *cue creepy face* =D ). One of the things that Wikipedia culture values very highly is being bold; this extends from just making edits to articles instead of first asking permission, all the way up to suggesting radical changes or additions to core site policies (though these are unlikely to actually be implemented, for a variety of reasons). This policy has definitely come to be one of the guiding principles I use on wikis, and it means I am, perhaps, rather less hesitant than many to suggest changes to the way a wiki has historically done things - even very major changes. I do, at least, try to avoid making such suggestions when they don't amount to much more than subjective, stylistic preferences, but if they have tangible, objective ramifications (such as the naming discussion here, or, more generally, the question of whether and how/when/how frequently to use references), you can bet I'll not just be suggesting, but boldly pushing, actively advocating, for the changes.
 * On the other hand, just because I'm from Wikipedia doesn't mean I always know what works best in a given situation; my suggestions should be weighed on their own merits rather than simply accepted or rejected because "it's what that crazy Wikipedia guy is harping on about". =D 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 20:53, 7 September 2011 (UTC)


 * Hmm, so running into a wiki that is "slower" and less bold than that is quite the recipe for friction, eh? Well, that's quite insightful. --JonTheMon 21:21, 7 September 2011 (UTC)


 * Actually, smaller wikis tend to move much faster then Wikipedia. If it weren't for the fact that Wikipedia's deletion process, for instance, encourages discussions to be closed after a week, there would be plenty of discussions that would stretch on for months (and, even with this encouragement, there still are on occasion). This is largely due to the sheer number of editors participating on Wikipedia - whereas a wiki comparable to this one may have two or three dozen "core" editors and maybe as many as a couple thousand sometime contributors, Wikipedia's core edior group alone easily counts in the hundreds, and that's with a near-constant decline in the number of editors since 2006. Naturally, with all these editors, there are very sharp differences in opinion (see, for example, the inclusionist-deletionist debate, the mess that was/is flagged revisions, or the image-blocking extension fiasco).
 * On the other hand, with smaller, more focused wikis, the relevant opinions are similarly more focused, and there tends to be a smaller leeway for these opinions to differ; this makes discussions run much more smoothly (most of the time, at least) and thus conclude more quickly. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 23:14, 7 September 2011 (UTC)