HRWiki talk:Standards

From Homestar Runner Wiki

Jump to: navigation, search
Current | Archive 1 (1-20) | Archive 2 (21-40) | Archive 3 (41-60)


Contents

[edit] Tradition is not necessarily policy

After a bit of confusion recently, i wanted to flesh out a certain topic a bit more. That topic is the issue of people assuming that tradition is policy, and favoring tradition where something else makes sense. I probose a new heading under General that will hopefully describe some of this. Here's what i have so far:

Sometimes, traditions will develop and people will tend to always do something in a certain way. However, if there is a reason why doing it differently is better, there is no reason to stick with tradition merely for the sake of tradition. For example, if there is an external link that goes to Wikipedia, but a distinctly more informative article on the topic is available elsewhere, there is no reason to favor Wikipedia's.

I can also think of another example which is the tradition of piping links to avoid redirects, where in most cases, it makes sense to just let the redirect handle the link. If anyone has any thoughts on this, or more examples of this type of thing, or ways to reword this to make it better or make it include more examples, i'm all ears. — DeFender1031*Talk 19:09, 2 July 2008 (UTC)

I agree wholeheartedly that tradition and consistency should not trump functionality or reasonable sense. That being said, perhaps in some cases where there's ambiguity, we should set a hard standard one way or the other. The pipe vs. redirect thing which has recently reemerged, is one of those cases, IMO. I, for one, support piping in the case of a redirect. The reason: The pipe only adds extra text to the edit page, which the casual reader will never see, whereas a redirect adds a very obvious "redirected from X" to the actual article. Thoughts? -132.183.138.199 20:33, 21 January 2009 (UTC)
I think that pipes are ugly, whereas "redirected from x" can be helpful. Personally, i think it makes sense for most cases that if i click on a link that says one thing and i get a page with a different title, that the page explains why. — DeFender1031*Talk 21:48, 21 January 2009 (UTC)
Personally, I feel that redirects are mostly useful for searches, rather than links on a page. If you know what the correct link is, why not use it? More over, there are a number cases where pipes are preferred method of linking Homestar Runner (body of work) comes to mind, since it's necessary to have the distinction on the page title, but it'd never appear that way in the article. Cool Shades is another one that gets linked by pipes since the article now encompasses all eyewear. Perhaps pipes should be minimized (especially when there are capitalization differences), but they can not be removed all together. wbwolf (t | ed) 22:10, 21 January 2009 (UTC)
See also (Don't Fear) The Redirect above.

[edit] Glitches

I hope I wasn't too bold by changing the definition of Glitches. I think that the wording of the previous definition really did not include the majority of things that actually get listed under that heading. It used to be

Similar to Goofs, but limited to mistakes in the Flash software.

And I changed it to

Similar to Goofs, but limited to mistakes made by the Brothers Chaps in the usage of the Flash software or shortcomings of the Flash software itself.

The former definition made it sound as if the mistake had to be in the Flash software itself to fit the category of Glitch, which is obviously not the way it's used around here.  Green Helmet 04:38, 14 July 2008 (UTC)

[edit] May I copy these Standards to another wiki?

Hi guys, remember me? :) I've started a new wiki that I'm loosely modeling after the structure of this one, and I'd like to adopt these standards and just direct copy/paste them into a similar Manual of Style or Standards page on that wiki. This will save me a lot of time and make it easier for me to start getting more people involved. I will, of course, remove references to HRWiki and adapt the standards to my wiki as appropriate (removing sections that don't apply, etc.).

If you're interested, the wiki I'm working on (just created yesterday and still very much under construction) is The Red Green Wiki. If you're a fan of that show, I invite you to drop by and help out! :)

Thanks guys. — Image:kskunk_fstandby.gif KieferSkunk (talk) — 01:38, 6 December 2008 (UTC)

Hey, KieferSkunk, how ya been? I don't think you need to ask, but thanks for doing so anyway. Feel free to rip us off! (I mean, we totally didn't rip off Wikipedia when we first set up this site.) I think under our Creative Commons license, you're supposed to give us credit or something, but who's gonna know if you ignore that part. Keep on tranglin'! — It's dot com 01:52, 6 December 2008 (UTC)
Cool! Thanks. :) — Image:kskunk_fstandby.gif KieferSkunk (talk) — 02:10, 6 December 2008 (UTC)

[edit] Raw characters vs HTML entities

Based on a discussion on Talk:Compé, I think we need to bring this up again. Our current policy of using HTML entities for everything outside ASCII is basically just tradition at this point... there's not really any actual reason to keep it that I can see. It only came about because twice the wiki's had problems during upgrades that broke on Unicode characters... once when we moved from WikkiTikkiTavi to MediaWiki, and once on one of the earlier upgrades (I think 1.5, when UTF-8 support became mandatory... the wiki was already being served as UTF-8, but something backend thought it was still Latin-1, so all the pages got mis-read as Latin-1 during the upgrade, and double-encoded as UTF-8). Both of which wouldn't have happened if we were using only HTML entities at the time. Also, there was the occasional edit that would convert non-ASCII or non-Latin-1 characters to something else... from browsers where simply clicking "edit" and then "save" without changing anything would still mess up on those characters. So HTML entities became the Standard™... and I think I was one of the people pushing for it to stay that way.

But all those pitfalls have long gone away... MediaWiki has gone through 10 major versions since the mixup, and we've never had an encoding problem during an upgrade since... it's stable now. And I can't remember the last time I saw an edit that accidentally broke a Unicode character, it'd have to be years ago. I can't think of a single browser in current use which has problems with UTF-8 (noone's going to be reading "Compé" as "Compé", which is the usual fate for non-UTF-8-comprehending programs)... and while I can think of one browser that has troubles with characters outside Latin-1, which would automatically convert them if you tried to edit a page... it's not in any way in common use. And even if an editor does come along and break all the Unicode characters on a page, it happens few and far between enough that it would be less effort to just fix it when it happens, rather than trying to prevent it from happening.

And really, the only place where raw characters and HTML entities differ is on the "edit" page... everywhere else, they behave the same... so that's the only place we need to look at. And in that edit page, the entities are ugly and hard to read... and raw characters can potentially cause problems in very rare situations that are getting rarer as time goes on. And I really do think the latter is rare enough that the former outweighs it. And I think that's been the case for some time, we just never noticed, because of the inertia of tradition.

Now, I will make one exception to this... and that's dashes. It's much easier to tell the difference between — and – than — and – (especially in the fixed-width font used in the textarea in the edit screen, where they're more like and ), so it's easier to keep them standardised as entities. Other symbols, like ™ and ½ I'm on the fence about. But letters, especially in the middle of words, like Compé, I definitely think are better as raw Unicode characters.

Note that I'm not recommending that we go through all the pages and replace the entities with actual characters... I don't think it matters that much. Just that we go from "HTML Entities Forever!" to "whatever's there is good"... if something's already there with entities, that's fine, if it's with raw characters, that's fine too... neither case really warrants zealously changing from one to the other. But if someone wants to go through a page and replace all the entities with characters for some reason, then that's their time to waste, and I've got no problem with letting them do it. But I do think we should at least lean towards raw characters over entities for new pages.

But that's my two cents... in as much as that phrase can be applied to 5 paragraphs of rambling... Who else has an opinion? --phlip TC 10:28, 5 August 2009 (UTC)

Phlip and I discussed this yesterday. When I brought it up, I said, "Compé is really no better than straight-up Compé. Yes, back in the day it might have been a problem, but browsers almost uniformly get it right these days. Even when they don't, there are technical safeguards to prevent problems. The best proof I have of this is that there are never any problems with using {{User:Heimstern Läufer/sig}}." I strongly support the exception for dashes. I also don't mind entities for non-alphabetic characters, because it's often easier to enter them that way than to find the actual character, but whatever works is fine with me. — It's dot com 15:53, 5 August 2009 (UTC)
I was going to bring up that I did find an instance of a unicode character being accidentally broken... but, now that you mention it, it was four years ago, from a user that hasn't been seen in over a year, and it was a rarer character than "é". I will say that I'm likely to have trouble remembering how to type the "é" character without copy/pasting or using the HTML entity (I know what an acute accent is, so remembering "é" is a lot easier for me.) It's quicker for me to just use the form I know over something I'd constantly have to look up, even if it is five keystrokes more in practice. --Jay (Gobble) 18:40, 5 August 2009 (UTC)
As long as the database for this wiki is in UTF-8, I'm sure we're good with using é. In fact, if we use "é" more often, we'll probably save some kilobytes by the time the Compé is obsolete. We can always put a notice on the talk page listing the key combinations for various operating systems to insert "é". I also agree with continuing the use of , as Courier/Courier New makes it hard to tell the difference between an em dash, en dash, and just a plain dash. Using entities for other special characters we might want to keep strict, as some of the characters might not be supported in UTF-8, but UTF-16, and could result in bugs. But I'm not too sure what I'm talking about when I say that. I'm still a little confused with how UTF-8 handles UTF-16 attempted characters and whatnot. Oh, I'm just going to far.:P --76.224.216.122 18:07, 7 August 2009 (UTC)
It seems that that the page is still "pro-entity" for non-Latin-1 characters. Should this be changed? I'm can't confidently determine the conclusion of this conversation. Soiled Bargains (talk|ctrb) 00:21, 30 September 2011 (UTC)

[edit] mdash vs. ndash

I would like to revisit this topic, specifically regarding — and –. I understand the difficulty in telling these apart in text: I often run into that problem myself. And in many cases, — is readable by itself on lists. However, I find that in some cases, particularly those where the dash is attached to one or two words, it is harder to parse the source code. To resolve that I came up with a compromise: I created an — template {{-}} that should be easy to type, distinguishable from the regular dash, and still easy to read in text. Click here for a sandbox test. Opinions are most welcome! If this is acceptable, perhaps we could unleash a bot or two on the main namespace? --Stux 13:44, 6 April 2013 (UTC)

I don't actually find the entity style hard to read, though I have no problem with using {{-}} instead for lists. Still covers all the basic requirements discussed above. — DeFender1031*Talk 17:36, 25 February 2017 (UTC)
I, personally, find it a little bit easier to read the list code (or the code in general) when using the template. HTML escape codes seem to blend into the word for me. In any case, a better system just occurred to me (especially after learning from you that ndashes and hyphen-minuses are different things!). Instead of just using {{-}}, we could create 3 or 4 templates (I checked wikipedia and they do something similar):
  • {{-}}: this template would be repurposed to place an – in text. Oddly enough wikipedia uses it as shorthand for the {{clear}} template.
  • {{--}}: this would be the new — in text. This is the same as in wikipedia.
  • {{---}}: this could be used for wider dashes. Wikipedia does something similar. However, there likely won't be a use for it here.
  • {{----}}: This is actually used by wikipedia to insert four consecutive hyphen-minuses since the wiki code uses that for horizonal bars iirc. Using <nowiki> tags would do the same thing but with more typing. I haven't seen a need for that template here.
The template is only used in two main space pages, so it would be easy to switch over (unless people really, really, really want to use straight up &mdash; tags in the code and scrap the template.) --Stux 18:52, 25 February 2017 (UTC)
Hi all, I finally went ahead with the plan I outlined above and created a {{--}} template (for &mdash;) and updated the {{-}} template to yield an &ndash;. I also updated all existing articles that used the original template ({{-}}) so they would use the new one ({{--}}). I'm hoping these templates will find more use on the wiki. Please let me know if there are any issues or questions. —Stux 03:07, 8 April 2018 (UTC)
I don't understand the purpose of these templates. For one thing, we almost never use &ndash; on this wiki, so I don't think we need a template for it. It would be like creating a template exclusively for the £ symbol. That symbol may be used once or twice on the wiki, but not enough for its own template. Secondly, {{--}} is only one character less than &mdash;, so there's not much of a difference there. Not to mention, many of the users here (as far as I'm aware) are more used to typing &mdash;. It's muscle memory to me at this point, so changing it would likely cause more problems than it solves. Also, nearly all of the pages use &mdash;, so we would likely have to get a bot to change almost every article on the wiki, and I don't exactly see why that's preferrable. Gfdgsgxgzgdrc 22:19, 27 October 2018 (UTC)

[edit] Policy regarding Poker Night at the Inventory

Telltale's yet-to-be-released game, Poker Night at the Inventory, is unique in the fact that it takes four characters from different worlds and puts them in the same room. This could pose a problem for our wiki, however. As the game isn't in the HR universe and includes characters from other games, there are some aspects of the game that need not be mentioned on the site. As it stands right now, however, our policy on what should be mentioned about this game is rather vague. I can see this becoming a problem down the road when the game is released; some users might find content HRWiki-worthy, while others might not. For instance: Should Max have his own article? Should his dialogue be listed here? It might start a few edit wars. In my opinion, a line should be drawn that clearly defines what should and should not be included on the wiki in instances like this game, before the game comes out. Does anybody else share my opinion, or am I making a mountain out of a molehill? --DENNIS T/C 00:55, 4 September 2010 (UTC)

[edit] Spaces

It's been a while since I've done work with transcripts, but I feel like I've come across a lot of description/action statements that use formal two space sentence spacing, whereas I've seen many others that only use one space. I don't know whether or not this is something the transcribers are doing, or whether or not it's an unmentioned part of our standards. I can see why double spacing is being applied, as the text is displayed in italics and in some cases could be hard to follow. However, I don't really see that much of a difference, and I'd like to know whether this is something that could become a standard, if something needs to get set straight, or if I'm just being too picky, haha. Soiled Bargains (talk|ctrb) 23:09, 16 December 2010 (UTC)

It doesn't matter how many spaces you put in the edit window, it always displays as just one space. (Click edit to see what I mean.) The only way to get it to display more than one space is to use a nonbreaking space (like   this) or CSS styles, which we only do in rare cases. Most of the time it makes no difference how many spaces you enter, and whether you should enter one or two after a sentence depends largely on your own preference. Some people find it easier to read the text when there's two spaces after a sentence in a fixed-width font (as in the edit window). I personally always just use one. — It's dot com 00:18, 17 December 2010 (UTC)
Ah, you see, I forgot that about MediaWiki. Looks like I'm still not reacquainted with this place yet, haha. Thanks! Soiled Bargains (talk|ctrb) 00:28, 17 December 2010 (UTC)
To clarify, it's not MediaWiki per se but rather how your browser interprets HTML. If you view the HTML source you'd see those spaces are still in there. It's your browser that doesn't display them in the final text. — It's dot com 00:33, 17 December 2010 (UTC)
See what I mean? Soiled Bargains (talk|ctrb) 01:09, 17 December 2010 (UTC)

[edit] Tables

[edit] ids

As some of you may have noticed, yesterday I began work on a new standard for tables. My experience with editing this wiki has led me to the conclusion that a lot of them were hastily made back in the early MediaWiki days, and that possibly newer tables have been based on these. My number one complaint however is that we have inconsistent id attributes all over the place. I decided to take it upon myself to create a format ids so that future table-based articles would validate and be less likely to conflict with other ids across the wiki. But now I've realized that this is probably something we should discuss, as I've realized that my proposal needs improvement that I myself am not confident of making. I'd like others opinions on what the format should be. Fortunately, I've discovered that spaces and other characters are escaped automatically in ways that comply with the W3C's standards. Umm, I need to get this posted, so I'll just stop here. Your thoughts? Soiled Bargains (talk|ctrb) 19:58, 20 December 2010 (UTC)

It's dot com said we should just handle table ids as we do for links to sections. This makes sense seeing that illegal characters are escaped by MediaWiki. My only thing to add is that any if an anchor starts with an illegal character, its escaped anchor name will start with a ., which will make it illegal anyway (like the section on Thorax Corporation that starts with 'Juwanna Mann'). Soiled Bargains (talk|ctrb) 21:49, 23 January 2011 (UTC)
What I said was that the IDs should exactly match the content of the most important column in a table (Xeriouxly Forxe Character Variations is a good example), which makes pretty and intuitive links. We don't need to worry about special characters and the like, because MediaWiki handles them automatically. The exception would be for things like the weeklies, which use numbers, but we already have a consistent style for those. — It's dot com 22:26, 23 January 2011 (UTC)

[edit] Styles

While I've said that tables are an inconsistent mess, they're also a stylistic inconsistent mess. I've given tables the wikitable class occasionally, and the only reason I do that is so that we can have the styles for all of the tables in one place: the CSS for the site. However, are there any changes to the styles we should do now? Should we make the table width 100%? Make table headers darker? Should we create some sort of hrwikitable class instead? I'm just downright unsure. Soiled Bargains (talk|ctrb) 21:49, 23 January 2011 (UTC)

I don't think this is a pressing issue given the current rate of updates. — It's dot com 22:26, 23 January 2011 (UTC)

[edit] Standards for gags/jokes

Should we create standards for the appearance for articles about inside jokes/running gags, or should we still handle them de facto style? Soiled Bargains (talk|ctrb) 21:49, 23 January 2011 (UTC)

Is this broken? (If you say yes please give examples.) Would the pages actually benefit from some kind of standardization, or do we have different styles simply because not all running gags are the same? — It's dot com 22:26, 23 January 2011 (UTC)
Um... I'm not too sure. Maybe, maybe not. But here are a few things that I think are worth considering:
  • Some articles have the appearances section written incorrectly compared to our currently de facto. I've seen (and corrected) this with Dan, Toilets, and more recently Greg. New articles concerning gags/jokes (unless written in haste/based off of a badly written article) aren't really a problem nowadays.
  • When a reference is in an Easter egg, it will either be labeled in parenthesis before the em dash ("(Easter egg)"), or put after the em dash ("In an easter egg..."). I'm going to be lazy and pass on giving examples, but my next point is similar and has a few. I assume we put "(Easter Egg)" before the em dash.
  • When a reference is in the DVD commentary, well... I've seen that done a few (the show) different (TGS10) ways (narrator). I assume we put "(DVD Commentary)" without linking it before the em dash.
  • There have been recent articles like Stanley Kubrick that use "References" instead of "Appearances", and then there are articles like Monkey Island that use both, using Appearances for physical appearances of the work in question, and References for just mentions. Should it work like this?
Soiled Bargains (talk|ctrb) 23:38, 23 January 2011 (UTC)

[edit] Running time standard wording

When listing the official time (usually when it's wrong), it is more factual to use (actual) or (TV Time Toons Menu)? Or should you only use the latter when the menu is correct? - Catjaz63 23:14, 3 December 2015 (UTC)

There seem to be a few precedents, based on Special:Whatlinkshere/TV Time Toons Menu:
I'm not sure why some have parentheses and others don't. Or why some are capitalized. But I think "actual" should be used for the real running time only if the official time is noticeably off, with "official" alongside it for the running time that appears on the Toons menu. Otherwise the time for the main site's version of the toon doesn't need a qualifier. DEI DAT VMdatvm center\super contra 18:04, 4 December 2015 (UTC)
And by "only if the official time is noticeably off" hopefully you mean off by 1 second or more! ;) Btw, I think using "official" when referring to the TV Time Toons Menu itself is fine as a standard (notice that we still link to the toon menu itself. I like the parentheses too. Hmmmm. A formatting template could be built... *gears start spinning* --Stux 21:21, 4 December 2015 (UTC)
That seems like a good idea. The elements "combined", "official" and "actual" should probably be uncapitalized. Perhaps "official site" or "main site" as a contrast for "YouTube" could be used with cases like I Killed Pom Pom above. DEI DAT VMdatvm center\super contra 21:48, 4 December 2015 (UTC)

[edit] Linking to articles with disambiguation in the page title

This edit raises a question: How should "Toon Name (video)" pages (like Sketchbook (video) and Trogdor!! The Board Game (video)) be listed in pages? "Toon Name (video)", or "Toon Name Video"?

I don't really have an opinion (possibly leaning slightly toward "Toon Name Video"). Gfdgsgxgzgdrc 07:04, 17 August 2018 (UTC)

I kind of agree. The parens are just internal to the wiki to distinguish pages. -174.62.238.201 12:53, 17 August 2018 (UTC)
In running text the parenthetical material should be hidden (and referred to using additional words, or not, as the case may be). The part in parentheses is not part of the actual title; we include it only because we have to. In tables and lists, however, I'd favor listing the page title exactly as it is, since those sections are more for reference and less for reading. — It's dot com 14:43, 17 August 2018 (UTC)

[edit] Retroactive names in transcripts

This edit raises a question: Should retroactive names (using a character's name in an early transcript before their name is revealed) be allowed in transcripts?

I think retroactive names should be allowed. It makes things a lot more convenient for the reader, and it's not like anyone's going to be reading these transcripts in order. Plus, if the person is browsing the wiki, chances are they're aware of the character's name. If Baron Darin Diamonocle is the title of his wiki page, he should be called that in all his transcripts too. Gfdgsgxgzgdrc 07:04, 17 August 2018 (UTC)

Note that [that edit] was reverted. -174.62.238.201 12:53, 17 August 2018 (UTC)
By an Anonny whose only edit has been that revert, no less. RickTommy (edits) 13:00, 17 August 2018 (UTC)
That's beside the point. It could be an active user who just happened to make an edit from that IP. — It's dot com 14:45, 17 August 2018 (UTC)

[edit] @StrongBadActual Dates

Long ago, it was decided that the format of Tweets in lists should be "@StrongBadActual — January 1, 1970". Recently, however, it seems to no longer be the case. So, how should Tweets be listed? Gfdgsgxgzgdrc 19:55, 5 October 2018 (UTC)

What all are the choices and what would be your preference? — It's dot com 21:03, 5 October 2018 (UTC)

Here is a list of choices. Feel free to discuss other options, as there is probably a near-infinite number of possibilities. This list is mainly just for convenience.
Also, the old version lacked a link to the Tweet's wiki section, so I added them in each choice.

The date format can be changed as well. (Jan 6 2018, 6 Jan 2018, January 6th, 2018, etc.) Personally, I'm leaning toward the parentheses, with the Jan 6 2018 format. Gfdgsgxgzgdrc 22:38, 5 October 2018 (UTC)

I support the parentheses format, with either 6 Jan 2018 or Jan 6 2018. SRMX12 (talk) 01:50, 6 October 2018 (UTC)
Jan 6 2018 is an improper format so it should not be on the table. If you want to go comma-less, either 6 Jan 2018 or 6 January 2018 is acceptable. An ordinal number (6th) is also not proper for tabular material and shouldn't be considered. For the listing, I support parentheses, brackets, or a colon. — It's dot com 02:09, 6 October 2018 (UTC)
All right, changing my vote to @StrongBadActual (6 Jan 2018). I still support parentheses, because that's also how we document DVD commentaries and Easter eggs. Brackets are hardly used on the wiki, and I guess a colon would be fine too. Gfdgsgxgzgdrc 21:27, 6 October 2018 (UTC)
I'm not sure which format I prefer but I wanted to point out that since we also have an @StrongBadActual Instagram Account we should always include the word "Tweet" in the entry. The format can then be adapted to say "Instagram" when such posts need to be referenced. --Stux 21:50, 6 October 2018 (UTC)
Changing my vote again. @StrongBadActual Tweet (6 Jan 2018) and @strongbadactual Instagram post (6 Jan 2018). Gfdgsgxgzgdrc 22:18, 6 October 2018 (UTC)

[edit] Basic Articles

This helpful section was added to the page, and reverted twice (by the same user) because:

  1. There was no discussion, even though that isn't necessary for a simple addition to the page.
  2. It was added by an anonny, which matters 0%.

These reasons don't really seem relevant, and I think the section should stay. But to avoid participating in an edit war, I decided to start up a discussion here. So, what do you guys think? Gfdgsgxgzgdrc 22:36, 27 October 2018 (UTC)

On most every Wiki, discussion is always required for major changes to these kinds of pages. I wouldn't call that change "simple" with a straight face. Also, since my edit summary got cut off, I should also mention that it was added - dare I say it? - well past the Wiki's height of activity. RickTommy (edits) 22:49, 27 October 2018 (UTC)
Considering how long the page is already, I wouldn't quite call it a major change. It only affects a small portion of the page. And yes, it was added past the wiki's height of activity. But - dare I say it? - why does that even matter? We can't just delete useful parts of the wiki just because it used to be more active. By that logic, we might as well delete the entire wiki. It still exists well past its height of activity. I still say we should keep that section. Gfdgsgxgzgdrc 04:12, 28 October 2018 (UTC)
This happened again, by the same user. I would advise that user to refrain from continuing the behavior. The section is 100% valid, 100% accurate, and 100% something that was missing from the page before now, and belongs there. Please, stop. — DeFender1031*Talk 15:08, 6 November 2018 (UTC)
Again, do you guys agree of your own accord? Also, like I said, this is the kind of page that requires discussion for such additions. Besides, don't we already have something like that on another page? RickTommy (edits) 19:45, 6 November 2018 (UTC)
How are you confused on this point? Here is what has been said so far: "This helpful section" "should stay"; "the section is 100% valid" and "accurate"; it "was missing" and "belongs there." These are not ambiguous statements. There's no one-size-fits-all way to add content to a wiki. Sometimes it's good to have discussion; other times it's good to just be bold. Even in cases where it might have been better to discuss first, once the content is there, if it is judged to be good, there's no reason to remove it just because we didn't talk about it first, or just because it came from an anonymous source. Even if you think that's wrong and that a discussion is required, this thread has become a discussion after the fact, and the consensus is that it's good information. So stop removing it on procedural grounds. They have no merit.
As for your assertion that we might have something like this content elsewhere, that could be a discussion worth having. We don't want to duplicate information (or at the very least we want to have a good reason to do so), after all. But to have that discussion, you would actually need to link to where we already have it. Don't remove it outright from this page on some vague hunch. — It's dot com 20:29, 6 November 2018 (UTC)
Personal tools