Doom Wiki talk:Policies and guidelines



What license is the material in this Wiki covered by? -- Schnee 06:18, 6 Jan 2005 (PST)

All content must be GFDL (except fair use screenshots). I wouldn't mind dual-licensing under a Creative Commons license, though. The only problem with that is that we can't import articles from Wikipedia unless the people who wrote them explicitly allow it (not that there are many articles which are relevant). Fredrik 13:36, 6 Jan 2005 (PST)

See Wikia copyrights. All content must be GFDL, but this doesn't prevent individual users dual licensing if they want to do that. Angela 14:00, 6 Jan 2005 (PST)
That's cool. Then there won't be a problem with swapping data to/from Wikipedia. ^^ -- Schnee 14:32, 6 Jan 2005 (PST)
Angela, could you clarify the status of screenshots? I also asked this on Forums/Copyright.
I fully agree that non-free content should be excluded. You can however quote limited portions of copyrighted text under fair use in a GFDL document, so it would seem strange to me if images were not treated similarly. A strict ban on fair use content in images would mean that a photo of a building would be disallowed because the building's design is the copyright of the architect.
This kind of fair use is very different from, say, borrowing an image from a publication and claiming fair use because the the use is educational. Fredrik 14:50, 6 Jan 2005 (PST)
The latest copyrights page just says "GFDL or public domain images are strongly preferred on Wikia. Copyright-violating images are subject to deletion. Copyright information must be added to the image description page of every uploaded image", which leaves decisions of fair use up to the communities involved in each wiki. Angela 18:12, 10 Jan 2005 (PST)


I think deciding on consistent capitalization needs to be done about now :) - Fredrik 14:59, 6 Jan 2005 (PST)

I agree. We need a policy on capitalizing level names, for example. As far as I can tell, "of", "the" and "and" are all lowercase, as in Halls of the Damned. However, if the word is the beginning of the level name, it should be uppercase, as in And Hell Followed. Illdo 06:51, 2 June 2007 (UTC)
I thought that was a very standard style point — does someone here take issue with it?  The problem arises when someone uses studlycaps or l33t in their readme file, for example.  Currently the policy says to do the same in our article title.  (And, to be fair, nobody really knows whether id wanted prepositions capitalized in their titles in 1994, just to be that much more overwrought and obnoxious.  :>    Ryan W 09:04, 2 June 2007 (UTC)

By the way, the proper capitalization of "Doom" is apparently... [1]    Ryan W 19:40, 2 April 2008 (UTC)

See note 1 here. There's no need for a publication to follow that form, although maybe we should reformat other commonly capitalized terms. It's fine that we don't use DOOM all-caps so it looks better when mentioned many times, but if the articles are going to be rigged with upper-case executable names, lump names, and other such terminology, we might as well have kept the more specific DOOM. Lumps and executables could both be spelled in ways that are less intrusive, such as using italics, bold, or true-type, or (at least for executables) normal text. By the way, I think using MassMouth is fine (just like DeathMatch is). Who is like God? 21:11, 2 April 2008 (UTC).

Cheat codes[edit]

(A subset of capititalization) I would like to propose that cheat codes be standardized as lower-case, within <tt> brackets, and linking to cheat codes. For example, "the iddqd cheat", rather than IDDQD or whatever. radius 06:02, 17 Jul 2005 (UTC)

I like this idea. Fraggle 11:14, 18 Jul 2005 (UTC)
Should probably be coded as:
<tt>iddqd</tt> [[cheat code|cheat]]
because cheat is kind of a disambiguation page. radius 16:09, 19 Jul 2005 (UTC)

Screen shot formatting[edit]

"Screenshots should be taken in software rendered mode, with settings as closely as possibly resembling vanilla Doom (unless the screenshot is for showing off a port specifically)":  Naming no names, we have been accumulating quite a large number of screen shots which don't even attempt to follow this guideline.    Ryan W 06:15, 10 Oct 2005 (UTC)

"Google AdSense" policy[edit]

I really dislike bringing this up, since it really seems like the Wikia people should have thought of it themselves, but I must.  Doom, Doom II, Final Doom, Doom 64, Doom 3 (both parts), Heretic, Hexen, and Wolfenstein 3D are all rated M by the ESRB, so isn't it conceivable that our little site here could run afoul of this content policy?    Ryan W 08:03, 12 Oct 2005 (UTC)

I think that's Wikia' problem, not ours. But as it says there, "If you feel your wiki needs to include any of this content, please discuss the matter with User:Angela so an alternative source of funding can be found for hosting that wiki." Bloodshedder 15:12, 12 Oct 2005 (UTC)
Considering the lurid ads that showed up after I revised Wolfenstein SS, I personally would have trouble taking Google seriously if they complained.  But that sounded too logical to be relevant to a legal issue, so I figured I'd at least mention it on this page.   Ryan W 22:01, 12 Oct 2005 (UTC)
Addendum: wikis about MMORPGs have had to ask Wikia to block ads relating to ebaying, so that the wiki itself doesn't get sued.  I will be reminded of this every time I see ads offering free Doom 3 downloads.    Ryan W 04:00, 4 November 2006 (UTC)


We may need to return to the subject of namespaces and hammer out a better policy. The Editing: namespace is a bit sparse for example. -- Jdowland 23:06, 11 Jan 2006 (UTC)

Link formatting[edit]

Here's a policy question — should we really apply this kind of formatting to all 1200+ articles? does their cross-references in such a manner, and I personally find it very distracting in long articles (not to mention ugly in browsers where links are underlined).  I guess I could understand doing it in walkthroughs, because they're so long and because people probably use them as reference works more often than just reading them end to end.  Does anyone else have an opinion?    Ryan W 15:40, 21 July 2006 (UTC)

Exceptions to NPOV[edit]

AFAICT, our standards for original analysis have been (or have become) far more stringent than:

An important difference from Wikipedia is that original analysis is welcome here. So if you want to add your own subjective opinions about Memento Mori II or write a comparison between Doom and Aliens, feel free to do so. Just be prepared for others to challenge your assumptions, provide opposing viewpoints and counter-arguments, or rewrite your text.

Non-technical attempts seem to get removed at least 18 times in 20 — or is it simply that most new editors are incredibly heavy-handed?  I left the paragraph in, but without the term "subjective opinions", since that just invites trolling.  (We do have a "reviews" section for PWADs, but I think it's only been used once or twice.)    Ryan W 06:02, 29 November 2006 (UTC)


I must have missed all the work that got done on this. Good work, Ryan! Fraggle 00:35, 23 February 2007 (UTC)

You don't think it's too argumentative?  Some people at central apparently become quite concerned when wikis don't AGF themselves into a Huxleyesque state of entropy.
Really, it was just a matter of waiting for certain debates (mostly started by me and Jdowland) to die down on talk pages.  :>   I wasn't able to discern a detailed consensus about the "people articles" policy, though.    Ryan W 02:24, 23 February 2007 (UTC)


This section might be controversial, but that isn't my intent; I am simply trying to document our existing practice (do a search for "armour" if you like).  I admit that I have never seen a non-U.S. edition of Doom or Doom II — did they actually bother to change all the text strings?    Ryan W 09:09, 4 March 2007 (UTC)

Nope. Not certain about other languages, but I'm sure there isn't an official version with altered strings like "armour". It's not the kind of thing software companies bother with. Even Windows uses "color" rather than the British equivalent. - DooMAD 19:55, 4 March 2007 (UTC)
Heh, imagine a British Doomguy. "I say, you are bloody huge. Therefore, I must deduce that you have a large amount of intestines. Rip and tear!" 22:35, 4 March 2007 (UTC)
Get David Thewlis's agent on the phone!    Ryan W 15:52, 5 March 2007 (UTC)
Mm, good to know, thanks.  Nowadays, major game releases are indeed translated/dubbed into other languages (but perhaps in 1994 they were not).    Ryan W 15:52, 5 March 2007 (UTC)
Not an official release, but... Bloodshedder 20:56, 5 March 2007 (UTC)


To myk: A normal browser will display them in their original ratio, with scrollbars (if required) to see the whole image. Some browsers will shrink the image so it can fit on screen, however, even then it keeps the ratio of the original image. Even wiki's thumbnails keep the original ratios (see the new box art I added to the Sony PlayStation article, for example). Perhaps there is something wrong with your browser.Nuxius 09:56, 15 May 2008 (UTC)

You miss the point. It's DOOM that "changes" the screen shots, not my browser. They look wrong in a browser because, unlike in an old-school 320x200 VGA screen, the pixels are square in "desktop" mode. 320x200 VGA mode stretches all pixel heights by 20% so that it'll fill the 4:3 ratio screen, whereas on the other hand a resolution like 640xx480 will fill the screen with square pixels. See this Doomworld thread for more information. For examples of bad screen shots see E1M3: Toxin Refinery (Doom). Those shots would look good in-game, but on a webpage they look flat (which is very evident on the sprites). Who is like God? 10:24, 15 May 2008 (UTC)
The image talk is continued here, for anyone who is interested: User_talk:Who_is_like_God?#Screen_shot_guideline_.2F_mop-up
I'm typing this because from this point on, this topic moves away from images and into general policies and guidelines instead. - Nuxius 05:56, 7 June 2008 (UTC)

Irrespective of the merits of either of the above positions, long blocks of instructions should not be added to this page with no previous discussion, especially when they do not codify widespread practice.  (At present, editors don't even adhere to the existing statement about "settings resembling vanilla Doom", but that version may have been written before we had screenshots.)  myk, you may be correct in that your idea would improve the appearance and consistency of the wiki, but given that many editors have already uploaded many screen shots in direct contradiction of said idea, you should consider the possibility that it does not reflect consensus, and solicit other opinions first.    Ryan W 00:35, 16 May 2008 (UTC)

I just want it to be known that I agree with you 100%, Ryan. However, I'm not an admin like you are, so I try to keep my edits within my "normal user" status, and try to give reason for any deletions/edits I make unless I'm deleting spam or something. I personally value consensus highly. Nuxius 01:46, 16 May 2008 (UTC)
See my reply on your talk page.    Ryan W 02:14, 18 May 2008 (UTC)
Actually, guys, I don't mind the removal of any text of mine, or additions to it; it's not a personal matter as I'm contributing potentially temporary text to an open project (and it's always there in history to bring it back if necessary or convenient), but if we talk long hours about what we will be adding, we only waste our time compared to doing stuff. I talk a whole bunch as it is already, but adding text is the most direct way of expressing what is proposed to be added, barring cases where many changes are made and are then hard to undo or otherwise obviously controversial. Being overly concerned about edits just inhibits productivity and progress. There can be no consensus about something which is not discussed. I did not see any previous notes on how bad the screen shots may look. I also support any reasonable and useful consensus, but will criticize (and possibly directly edit, depending on the circumstances) and do not necessarily support a consensus based on arbitrary authority, historical usage, or eclectic circumstance. The best things to do when someone disagrees with an edit, changing it or reversing it, is to either talk or revise the edit to improve it (quite possibly incorporating the criticism or differences in a suitable way), or both. That's why in this case instead of dismissing Nuxius' modification, I worked with it.
Please be bold, responsive to input and modifications in order to expand and improve, and do not edit conservatively. I think Wikipedia's Policies and guidelines has a better note at the top than ours. It's a huge and super-busy Wiki with like 2,000,000 articles and even they don't imply it's necessarily wrong to edit the P&G page.
I had no qualms about adding that guideline because I'm sure it's for the good of the Wiki (and honestly assumed you guys would agree as well). As usual, of course, I'm open to discussion and further change or reversal, regardless of how sure I am of what I'm doing.
Initially, I read that Nuxius didn't understand my point; which is highly relevant as any other intelligent person could reach the same conclusion "what is this guy saying? is he crazy?", thus I revised my text making it clearer and more fact based. I believe you guys understand what I was pointing to now, and we can discuss it for any merits it may have or lack.
Regardless of how many screen shots have used 320x200 and 640x400 shots, it is unwise to continue adding such shots now that we are aware they don't look representative of what you see in the game when on the pages. Only by adding the guideline can we help editors use suitable screen shots, replace old ones with correct ones when necessary or desired, and understand DOOM-related aspect ratio considerations more clearly. This will contribute to a better wiki in the long run, regardless of how quickly any such changes are made, or if everything is changed for the better in the end. Who is like God? 07:04, 16 May 2008 (UTC)
I strongly support the introduction of such a guideline. I've certainly been using the corrected aspect ratio for all the screenshots I've uploaded recently, and have been replacing screenshots on the Chocolate Doom wiki that have the wrong aspect ratio. Fraggle 12:22, 16 May 2008 (UTC)
That's why in this case instead of dismissing Nuxius' modification, I worked with it.   Very true!  You are certainly in the 99th percentile of "has a line of reasoning for each edit".  I figured you knew that already.  The question is, should policy statements be revised as though they were ordinary article content?
but if we talk long hours about what we will be adding, we only waste our time compared to doing stuff . . . Being overly concerned about edits just inhibits productivity and progress.   To cut a long story short, that concept doesn't scale.  For instance, 10 screen shots for each map in each high-profile WAD is about 6,000 images.  You recruit 12 editors to upload 500 images each, and *then* we have a discussion which standardizes the format, so 5,500 additional uploads have to be made.  Forget the duplication of labor; do you think those 11 industrious editors would come back for more?
Unfortunately, nearly every sentence on the policy page applies to thousands of edits — otherwise it wouldn't have caused trouble often enough for a written policy to have been assembled.  (There are a few exceptions, as you point out, but consider that hundreds of contributors have already read them without raising systematic objections, and added a lot of content accordingly.)  You are perfectly free to write on your user page, or even at Central Processing, "I propose such-and-such an image format, and here is why."  You can even upload a few dozen examples for comparison.  If you immediately jump to the end and change the policy page, the same paragraph is interpreted as, "To avoid technical problems, all images not in such-and-such format may be VfDed summarily."  People are going to assume it's been discussed.
and even they don't imply it's necessarily wrong to edit the P&G page.   I would direct you to the talk archives of those pages, especially the really old ones where only five people were watching each thread (kind of like this site).  You will see that [a] most of the edits are meant to reword for clarity, not change the meaning; [b] a detailed explanation is normally posted to the talk page simultaneously; [c] if a veteran editor judges that the change is inconsistent with widespread practice, or alters the meaning unintentionally, it is immediately reverted with no hard feelings, and discussion proceeds from there.
Now, so as not to post a rant without offering an alternative solution, I suggest the following.  (1) Solicit opinions in some appropriate forum (already done here).  (2) Post a link to the talk pages of users who have already uploaded 100+ images, to see if they have any technical objections we didn't think of.  (3) Wait a week or two to make sure everyone else sees this thread on the recent changes page.  If all the responses are like Fraggle's, then there's no issue.
I myself am one of the users in step 2, so I'll state that I don't have a strong opinion.  My screen shots look pretty darn crisp on my Trinitron, thank you, but somewhat stonewashed on this off-the-rack Dell LCD where I upload them.  If others have a hardware-related explanation for that, then I'll be happy to follow the new standard in the future (and add the backlog to my to-do list, but that's already 70K, so someone else might get to it first).    Ryan W 03:10, 18 May 2008 (UTC)
The question is, should policy statements be revised as though they were ordinary article content?
Yes, all you need is the consensus related note on top, and then editors and admins just reverse anything that is not suitable, pending previous discussion if applicable.
Your (1), (2) and (3) can be circumstantially useful, but people shouldn't apply such stances as general rules. (1) might apply where there really is a material consensus, (2) is useful when in doubt, and (3) for disputes (but a reversal is not mandatory; it would depend on how much the edit is opposed).
To cut a long story short, that concept doesn't scale.
By that account you can't add guidelines that improve previously unattended or incorrect procedures because of the weight of previous edits. Note that your point had already been addressed (by my last paragraph above).
People are going to assume it's been discussed.
That is where the note at the top of P&G comes in; it's assuming too much.
There are a few exceptions, as you point out, but consider that hundreds of contributors have already read them without raising systematic objections,
We shouldn't assume approval from that, especially on such a page (most people mess with DOOM content), which on top also encourages less participation than others.
As for comparisons with the Wikipedia P&G: Our note on the top is stricter, yet our page is much less perfected. Following Wikipeida procedures would be too conservative, and a stricter position, worse.
I propose the following:
  • Let's add my edit back. If anyone objects, we discuss the particular objections.
  • Let's edit the P&G "warning" to something along these lines:
Although this article is aimed to be a consensus on this wiki, it is still a work in progress. When editing this page, please ensure that your revision is compatible with any existing consensus. You are also encouraged to discuss, critique, or challenge any of these policies and guidelines using the associated talk page.
A work in progress and a consensus are different things (to a point contradictory), and the above wouldn't demand "just in case" reversals and counter edits just because editing is taboo, but would still allow us to revert or counter anything questionable with a criterion suitable for this type of page (the importance of true and existing consensus). Besides, it is confusing policies & guidelines, and the article makes little effort to distinguish them, when they are pretty different. That at least needs fixing on the page content itself. Who is like God? 13:54, 18 May 2008 (UTC)
Note that your point had already been addressed (by my last paragraph above).   That presupposes that the technical deficiency is widely known, and judged to be sufficiently severe that our readers would even notice the difference.  I can find no evidence of that on the wiki itself, and even in the Doomworld thread you linked to, the latter question is (understandably) not addressed.
By that account you can't add guidelines that improve previously unattended or incorrect procedures because of the weight of previous edits.   I am not saying that at all.  I am saying that one shouldn't add them the instant they come to mind, without even attempting to assess why the great mass of existing content was formatted the way it was.  Those other editors are not a bunch of yo-yos.  Maybe they thought about these issues too ("incorrect" is a pretty sweeping assumption).
it is confusing policies & guidelines, and the article makes little effort to distinguish them   Yeah, that is a problem.
That is where the note at the top of P&G comes in; it's assuming too much.   Sorry, I'm not understanding you here.  When there is no policy about something, the policy is whatever the nearest admin decides as he/she passes by.  That creates drama, as everyone knows, no matter how good their intentions.  Now you want to make it so that even this page can be ignored, because it might have been revised without consensus to do so?
By the way, AFAICT, this page is revised so rarely not because of conservatism, but because people (including admins) insist on making decisions by acting on common sense, and refer to the details of the written policies only when they have no choice.  Because of this, we have far fewer policies than we potentially could, but admins and experienced editors are expected to know about them, because each one has arisen either from longstanding convention or from a lengthy, often contentious, public discussion.  Whether or not that is the ideal approach is a separate question — if you want this page to be edited and discussed as freely as an ordinary article, first you will have to convince all the regular contributors to look at it more than once a year.    Ryan W 00:56, 19 May 2008 (UTC)
I am not saying that at all. I am saying that one shouldn't add them the instant they come to mind, without even attempting to assess why the great mass of existing content was formatted the way it was.
Regardless of how much discussion there is, the previous edits will still be there in contrast to the proposed guideline. And that's not an argument that should stall the inclusion of a guideline, especially because a guideline is a "help tip" that can serve any future edits. Retroactive application is encouraged, but not mandatory for anyone in particular.
Sorry, I'm not understanding you here.
Then save some time by not speculating wildly. I proposed how to mend the note on handling consensus on the P&G page (even proposing a specific amendment). It assumes too much as it stands because the less polished and discussed a page is, the more arbitrary any presumed consensus is. I've been saying this all along.
By the way, AFAICT, this page is revised so rarely not because of conservatism
The conservatism I am referring to is the current P&G note and any admins or editors that act upon it strictly by the letter (namely Ryan W). Your alternative explanation only ignores that and doesn't really contradict it. You provide no support that your assumption presents a contradiction anyway, while the concept that the more complicated a process, the less people get involved in making or changing things is pretty straightforward.
Just like you were saying that policies and guidelines mainly stem from discussions and dilemmas, restrictions on participation should be based on actual problems. If direct edits can feasibly be integrated into P&G, there's no reason to zealously work against any such edits preemptively, demanding additional steps that may frustrate or inhibit potential contributors (beyond reminding people about consensus and encouraging talk when in doubt, which is basically strong advice). Especially with guidelines, which are help tips and are more modifiable, while true policies demand more discussion, because they are actual rules. Who is like God? 07:01, 19 May 2008 (UTC)
That remark about common sense was merely meant to be general, not all-inclusive.  I've never claimed that I have any.   :>
For the sake of argument, let's suppose you're right, and that the vast majority of our regular contributors don't pay much attention to the letter of the policy even after it has been written down.  I assumed that people would want to take advantage of known consensus, however provisional, after the effort and debate (sometimes even drama) required to determine it.  I haven't taken a poll or anything though; maybe they spend that energy programming and mapping instead.
What if we changed the boxed statement to something like this?
Although this article aims to represent consensus on the Doom Wiki, it is still a work in progress. This site is less complete and less frequently edited than an established site like Wikipedia; furthermore, our editors and administrators traditionally proceed by common sense rather than interpreting policies to the letter. Therefore, this page does not evolve in lockstep with our article content, and no written policy or guideline is expected to cover every situation.
This page, like all project pages, can be edited by anyone. However, please ensure that your revision is compatible with any existing consensus (established by discussion and/or repeated precedent). You are also encouraged to discuss, critique, or challenge any of these policies and guidelines on the talk page.
Ryan W 11:12, 19 May 2008 (UTC)
More than a compromise, that seems to address what I had been criticizing, so it seems fine to me. It seems a bit long, but that shouldn't be a problem. If the page is touched up later (such as to distinguish policies and guidelines a bit more) maybe some of the details can be moved into the article body (the Wikipedia's note is shorter that way). Who is like God? 06:33, 20 May 2008 (UTC)
Yeah, I sensed that if guidelines and policies were better distinguished already, that would have ended up less unwieldy.    Ryan W 06:53, 20 May 2008 (UTC)

In case anyone is curious, there are currently 1,165 screen shots on the wiki.  A few are from non-Microsoft platforms or non-Doom games/utilities, so I don't know how myk's idea would apply to those.  Also, most of the PWAD screen shots were uploaded by the same 2-3 people and have systematized file names, so they can probably be assessed for possible replacement in batches.    Ryan W 08:28, 20 May 2008 (UTC)

Yeah, a footnote indicating other systems may produce shots that may need some adjustment could be added to the guideline... or specific info, from checkups made by people owning the systems in question. I think I saw a console shot which had a 320x224 resolution, or something like that, but I don't whether that shot looks proportionately the same on the console's usual screen.
I saw that the E1 levels have many shots... it seems kind of abusive of fair use to me, as fewer shots should easily be able to give a feel of a level. Who is like God? 08:59, 20 May 2008 (UTC)

Screen shot vs. screenshot[edit]

I don't fully understand myk's point about the form of the term "screenshot"/"screen shot" being pointless. To me it's pretty obvious that if a term can be written in multiple correct forms, the most common form should be preferred, especially if there is a significant difference (according to Google, "screenshot" is more than 10 times common than "screen shot"). Another point is consistency. We should stick to using one form of the term at a time in all articles, templates and so on, so that they can all be found via a single search using the preferred term. And, as most people WILL search for screenshots using the form "screenshot", we should naturally prefer it at this wiki as well. -- Janizdreg 22:55, 12 October 2008 (UTC)

Consistency is more important for DOOM-specific stuff defined here (because the use carries the defined meaning), not the common English dictionaries handle, where it only matters per article, not in general. Let's try to nitpick valid language as little as possible. I for one prefer screen shot because it's historically established English and goes with and encourages one to use "shot" once the context is defined: I took two screen shots. The first shot showed a slime trail, the second one did not. It's the same "shot" used in I noticed the flash was malfunctioning after I took that shot. Searching relatively common terms is up to the readers, guided by their personal understanding of language, which is specific. If there are majorities and minorities they affect both the writing and the searching, so there shouldn't be any problems. Who is like God? 00:14, 13 October 2008 (UTC)

Map walkthrough images[edit]

I believe we should not displace any further stock map images with versions labeled for walkthroughs, for several reasons:

  • Restricts use absolutely to that single context even where other uses may be valid.
  • Prevents viewing of the map in its pristine form.

I have an upcoming use case—creating articles for the console versions of the maps—where I'm going to need the unaltered pristine map images for purposes of visual comparison, so I've begun work of renaming the walkthrough versions, and restoring the displaced pristine versions as separate files. Fortunately there are only a handful of these so far. I've added this as a policy under the images section because I'd like to not see more of them go up while I'm working fervently on fixing the existing ones. --Quasar (talk) 05:14, 26 January 2015 (UTC)

You are the first to express this view AFAIK, so I'm not sure where you're seeing consensus to change the guideline.  Since no one reads it anyway, we'll ignore that.  :>   What do you suggest for maps that would never conceivably get such a separate discussion, e.g. this or this?  We'll either have to change the walkthrough format (assuming they all get written someday) or delete one of the two images.    Ryan W (talk) 16:41, 27 January 2015 (UTC)
I am but I didn't think it'd be controversial. Losing the pristine version of a stock map's graphic is unfortunate from an encyclopedic POV. Personally I wish there was a better solution than having two versions of the graphics (something like dynamic SVG) but browser support and MediaWiki support just isn't there for it. If it's a clear-cut case where the original map graphic would fall totally out of use, you may have a point. Even then however, I wonder if there's not a possible solution to this (some type of template, with a "click to see unmarked map"). If I waited for consensus to make this minor change I risked having more work made for me with the project I'm undertaking so I followed "be bold" instead. If you don't like it, revert it for now, but, I will be immediately opening a discussion to have it re-added in that case.
The project I have in mind currently is for adding beta and console versions of the map articles. It's become a pain for me personally to not be able to look them up here, frequently hopping between different sites that have only some of the maps documented, or documented to differing degrees (for example, a pic of the map, but no other description or listing of the map slots; or, all that info, but no pic of it). Each stock map would have a /Console and /Beta subpage which is a redirect to the actual map article for that version. So for example, [[E2M2: Containment Area (Doom)/Console]] would be a redirect to [[MAP10: Containment Area (Console Doom)]], which would amongst other things contain comparative information on changes between PC and Jag, and then any additional changes made in other console versions; tables of which console ports the map is available in; information on alternate map slots it has appeared in; etc. Templates would be provided for inclusion on the respective articles which automatically link back and forth. So E2M2's article would have a template that says "This level has a console version," and that would be a link to [[{{PAGENAME}}/Console]]. As part of this though, I need the pristine PC maps' graphics for purposes of visual comparison. That's why I was a bit dismayed that they'd been overwritten rather than supplemented with walkthrough versions. In some cases, the lines and letters significantly obscure portions of the layout, which would hinder this considerably. It's an issue that does deserve consideration for the points I outlined above. --Quasar (talk) 16:57, 27 January 2015 (UTC)
I like your project!  Years ago someone tried screenshot comparisons for the alphas, very informative and an exemplary case of fair use.
Where I take issue is the assumption (implied in your first bullet above and pretty much everywhere else on the internet) that it is normal to upload images even when there is no project to hand.  We have way too much of that already.    Ryan W (talk) 04:44, 28 January 2015 (UTC)

Generic pronouns[edit]

Previously we tended to use "he/she", "he or she", "his/her", etc. Recently a few anon contributors made an effort to convert over to a more modern and inclusive usage of they/them/their, which I approved in each instance. I just noticed there was never any suggestion on this page about how to handle it. Should we add a style rule or let it remain solely a matter of roaming consensus? --Quasar (talk) 21:11, 7 October 2020 (CDT)

Broken wiki link[edit]

In the capitalization part of the style section, the Wikipedia:Talk:Doom leads to a disambiguation page; furthermore, in all doom-related talk pages, i was not able to find anything relating to capitalization. What's up with that? ONETAPPYBOI (talk) 17:39, 27 January 2023 (CST)

No response so i just decided to delete it. ONETAPPYBOI (talk) 16:49, 29 January 2023 (CST)
The talk page itself wasn't disambiguation, only the main space page it belongs with. Whether it was still relevant to our capitalization policy point is another matter. But unilaterally deciding on policy edits within two days is a no-no. People do have lives and jobs, and there is no need to rush such edits. Please don't do that again.
I don't know anything about the historic context of the link and whether there is perhaps a suitable placement elsewhere on Wikipedia, so leaving that for Quasar or someone else with input on this subject. --Xymph (talk) 02:55, 30 January 2023 (CST)

Disallowed links rule[edit]

I added some common-sense things that should not be linked on the wiki. Many of these types of links have been removed before so I believe this reflects consensus, and is also similar to rules stated on other wikis such as TCRF (particularly, the no-link-shorteners one is almost universal across all wikis because they are unstable and may only exist to either leech ad revenue or spy on users). Comments are welcome of course. --Quasar (talk) 00:53, 5 March 2023 (CST)

Seconded. --Xymph (talk) 02:42, 5 March 2023 (CST)

What about links? I would like to hyperlink to composers' bandcamp pages in some cases where the source of a midi or mp3/ogg is an album that is only available there. --Gregor (talk) 15:41, 14 October 2023 (CDT)

What about them? Bandcamp doesn't seem to fall under any of the disallowed categories... And you can see from a quick search that there are already many Bandcamp links in music and composer pages. Oh, and same for Soundcloud and other similar sites. --Gez (talk) 05:26, 15 October 2023 (CDT)

Capitalization of mods/maps[edit]

There was only brief discussion in the early years, but no guideline resulted in the relevant section. I propose to add an entry like this:
"Names of mods and maps should generally follow Wikipedia's capitalization convention, but can deviate to better fit the context of the entire work. For example: some map names, or words within them, remain entirely lowercased or uppercased, like in WOOO, WOOO 2, and the 32in24 series."
That can probably be refined. Comments? --Xymph (talk) 05:31, 3 June 2023 (CDT)

As far as i can see, what is referred to as "title case" is used throughout the wiki for map names. So first and last word are always capitalized, as well as verbs, adverbs, adjectives, pronouns and long prepositions (five or more letters), etc; while articles and short prepositions, and coordinating conjunctions (but, and, or) are always lowercase. I think this should be mentioned in the article. After a quick search i found this page Wikipedia:Manual of Style/Titles of works#Capital_letters on Wikipedia that lists the rules quite comprehensively. Maybe this could be linked in the entry. --Gregor (talk) 16:32, 3 June 2023 (CDT)
Uhm, yes, it already is linked. ;-) This discussion is not about the source of the guideline but how to word it for our wiki. It should perhaps also mention that existing, long standing paths that deviate (among a few dozen others), should not be corrected anymore. That would just create unnecessary work. --Xymph (talk) 02:52, 4 June 2023 (CDT)
If there is an official casing used by a mod's author we're not going to act in contradiction to that, there's no point. The example of "WOOO" is a good one. Nobody calls it "Wooo" and we're not going to do that either. So the only rule I'm going to support is that the capitalization used is the one used by the author of the mod in its official announcements or documentation. --Quasar (talk) 11:02, 4 June 2023 (CDT)
But isn't that approach in contradiction to the goal of every wiki to standardize and unify the way information is presented to the reader? That's what this wiki already does for many parts of the articles. And title case is already enforced throughout the wiki in most cases anyways. Not applying it consistently simply means a mess of contradicting capitalization styles. How is that really helpful for readability and consistency? And many mod authors either don't know or simply don't care about title or sentence case. They just write everything in uppercase or capitalize every word simply because it doesn't really make any difference in-game. It's not an artistic choice in many cases, and even if it is, that doesn't mean it can't be standardized for presentation on a wiki page. It's not that we "officially" change the capitalization by applying certain style guidelines on the wiki; other wikis do the same thing, Wikipedia first and foremost. In the few cases where it is intended and widely accepted, one can simply make an exception rather than throw any attempt at standardization out the window.
By extension, would that mean we also shouldn't correct obvious spelling mistakes in a story text and treat them as intended just because the author forgot to proof read? A good example is Sign of Torment, which uses only uppercase for its map titles in both the DEHACKED and MAPINFO lumps. That looks pretty ugly on a page, and Xymph corrected my attempt at staying closer to that form by capitalizing every word, and instead implemented title case throughout, as well as correcting a spelling mistake by the author in the story text i quoted. Was he right or wrong to do so? And does that mean all uppercase map titles need to be copied as is going forward? --Gregor (talk) 15:34, 4 June 2023 (CDT)
Well put, and seconded. Yes some map authors make specific choices in wording/casing mod and map names, but there are far too many situations where there is no text documentation of the map names (only in-game lumps are used, which are often case insensitive) or it is inconsistent with the in-game names, or everything is all lowercase, or perhaps the mapper isn't even aware of the concept of title case. In such cases we have picked a style/spelling that makes the most sense for the wiki, and that is usually title case. But I was aware any guideline cannot be defined very tightly, hence the phrases "should generally follow" and "can deviate". The guideline won't be a hard rule, but would help avoid shouting all-caps map names on the wiki just because a mod only contains all-caps CWILV lumps.
As for that story spelling correction, perhaps I should have just added [sic] instead. <shrug> --Xymph (talk) 16:04, 4 June 2023 (CDT)
Neither DeHackEd nor MAPINFO are often indicative of authorial intent because the Doom engine presents map name information in all caps everywhere it can be displayed. The contents of a text file, when available, would be far more convincing. My concern is with situations where the treatment is consistent and universal by the author like with the aforementioned mod name WOOO and similar things. If it's obviously always intended to be uppercase or mixed case and there's real sources for that info, keep it uppercase. If it's something like a map name then I'm less concerned - title casing seems to work best for those almost always as-is right? I'd rather there be rules of thumb than hard guidelines. In either case, make sure appropriate redirects exist. --Quasar (talk) 12:55, 7 June 2023 (CDT)

← ← ←
I really should have taken more than a cursory look at the existing guidelines before initiating this topic. In the discussion so far, Quasar is focusing more on mod naming - and his remark about "appropriate redirects" seems mainly aimed at those - while Gregor and I were approaching it more from the map naming angle. But there already is a rule for "(source ports, programs and) mods", which I agree does generally work. So I shouldn't have let mods clutter the discussion, as only some additional rule of thumb for map name styling would be useful.

About those: just because MAPINFO/DeHackEd are rendered in uppercase doesn't mean they are always less canonical. It depends on how the name fields are used; sometimes they're better at using title case than the documentation. Even CWILV lumps can show title case with two different font sizes. And if the documentation is inconsistent with the in-game lumps, then the latter are certainly canonical as that's what the player sees (irrespective of uppercase rendering) -- but that is already an existing rule too.

Thus another attempt at a (soft) guideline for map name styling: "For map names, the capitalization should normally be the one used by the creator, with in-game definition taking precedence over documentation, but Wikipedia's title convention can be applied if that makes sense in the context of the mod. Existing map articles should generally not be retitled to match this convention."

Applying this (somewhat loosely) is illustrated in the small mess that is ESP2. The article creator used mostly names from the .txt file, or names of the origin maps (map 11, 12, 16, 18, 20, 23, 24) that do actually not occur anywhere in the ESP2 release. The esp2.txt map list is all uppercase; DEHACKED strings exist for 01-25, all lowercase; CWILV* for 02-24, all uppercase, and MAPINFO defines title case for 26-28 and lowercase for 29-37. For map 02-16, 23, 24, and 34, I used the predominant uppercase. Map 18, 20-22, 36-37 work better in title case. For 26-33 the MAPINFO style is preserved. It's not perfect but it works for the wiki. --Xymph (talk) 13:24, 10 June 2023 (CDT)

I disagree that the existing rules cover map titles in any specific way as you seem to imply. There is a guideline for the names of "source ports, programs and mods," but this does not extend to map titles inside these mods and programs, which is the main purpose of this discussion. Now, when it comes to map titles, in my opinion the usage of all caps titles should be avoided like the plague; it looks tremendously ugly on the page and lends the whole article an amateurish feel, like somebody texting for the first time. I don't think it is desirable in most cases.

Now, if i understand your proposed addition correctly, it would relegate title case to third option after descriptions in lumps and text file\dwthread. But shouldn't it be the other way around? Shouldn't the form of styling of a title be adjusted to the standards of the wiki instead of the wiki adapting to the stylings of a mod? That's what happens with the capitalization of article names as well as that of proper nouns in texts, even where that very much goes against the author's intentions—for instance with names of custom monsters like "Blood Fiend" or "Mecha Demon" their form is consistently adjusted to fit in with the wiki's guideline on proper nouns, irrespective of the author's intention to have one or both words capitalized. So why make an exception here? Seems rather inconsistent to me.

Also, as an aside, if the author's intended design is the focus here, why would the official documentation inside the text file or the OP of the respective Doomworld release thread be valued behind the in-game display? It seems to be based on the assumption that DeHackEd\MAPINFO lumps are most often chosen by the author as the official documentation for their map names. But i'd argue the opposite is true at least as often. Many authors certainly don't take too much stock in how the map name are rendered in-game with regards to capitalization, as the differences between how upper and lowercase are displayed on the automap or intermission screen are quite subtle and as a result, often don't seem worth the effort of implementing the "intended" styling.

Another thing that struck me with your proposed course of finding the "correct/appropriate" styling is that it places added pressure on the editor to assume what the author's intentions are and will inevitably lead to situations where the editor has to simply guess as to the intentions of the author, which i don't think is the job of an editor or a wiki in the first place. That's what guidelines are for. Besides that, as shown in your example of the ESP2 article, it also leads to what i would describe as a mess of styles on a page that does nothing to improve readability or consistency for the reader.

This seems all to me a far less elegant and also somewhat messier approach to simply using one styling, title case, as the default way of rendering map names on a page for the purpose of this wiki unless there is a very good reason not to do so. And again, title case is already used for most articles on the wiki anyways and is also the way most mod authors capitalize their map titles. So why not keep it simple and consistent? --Gregor (talk) 19:49, 10 June 2023 (CDT)

WAD coverage[edit]

The guideline says WADs can get an article "If released." That is too relaxed IMO. Coverage while a mod is in beta or even WIP stage means that all sorts of details can still change before an official/final release (or even a release candidate), and keeping an existing article in sync just results in double work. Especially with map name, slot, and secrets changes in multilevel PWADs. There already is enough additional work caused by updated (or worse, reworked/overhauled) mods after their official releases. Also, notability (however hard to define) usually remains up in the air until the initial stable release. So I think we should tighten the guideline somewhat, e.g. to: "If it has a stable release." Thoughts? --Xymph (talk) 05:58, 23 August 2023 (CDT)

I fully agree. This has been a problem for some WADs in the past and has definitely resulted in a ton of unnecessary extra work due to certain mods being added too early. There are going to be some edge cases such as, from recent memory, The UnMaking and Baculus which featured unannounced revamps, but I think focusing on a stable release is ideal - which can either be 1.0, or even a preliminary release that has not been touched in a long time and is thus considered final, as with the case for example of The Biovite Project. It is especially problematic when it comes to individual map pages, as noted, and should not be taken lightly considering the amount of work required to update certain projects due to this.
I also agree regarding the notability aspect, as the notability of a map or mapset changes over time anyway, and something that has just been released a day or two ago is probably premature for a wiki article even if it has reached a final version, with exceptions applying if the map or mapset in question are extremely anticipated or well known: for example Elementalism getting a wiki page right after its release seemed appropriate enough, but that is the exception. It is best to hold off on such things and instead focus on long-overdue articles for older projects, because for one thing it always means less work going forward. --Dynamo128 (talk) 06:10, 23 August 2023 (CDT)

Italics on titles of local but non-core games[edit]

The policy, since 2014, states that "The games covered by this wiki (Doom, Heretic, Hexen, etc.) need not to be italicized". I always understood this to be any game title with a local article (as that, implicitly, is some degree of coverage), not just the extended Doom and Doom-engine games family. Thus I always wrote Duke, RotT, Wolf3D, etc. without italics, or removed them from edits by others - but such games are indeed not the core focus of this wiki. Silly me perhaps, but other editors followed the same convention for years. That was suddenly corrected in a recent edit, which sparked a little discussion on IRC which brings us here.
To bring our title styling and the policy back in sync, we can re-add italics to all non-core titles (mostly script-wise and the remainder as we go along), or loosen the policy. Thoughts? --Xymph (talk) 15:59, 5 February 2024 (CST)

My own approach was to not italicise the games listed under "Main Games" and "Related Games" on Entryway, and italicise everything else. So Quake, ROTT, DN3D and Wolf3D would all be covered by that rule. The games which may be slightly ambiguous are Heretic II and Hexen II; they are sequels to games we focus on, but are not really within our remit as they are Quake-engine games. Gauss (talk) 17:40, 5 February 2024 (CST)
I have followed the policy of italicizing external games (that is, those linking to either Wikipedia or in exceptionally rare circumstances to other independent wikis) but not the ones covered by articles here. I am fine with whatever works best for the majority, really, I personally am just used to this system by now. --Dynamo128 (talk) 09:53, 6 February 2024 (CST)
When I arrived here a year ago and read FAQ and guidelines I also assumed that italics are for the games that don't have pages here. But after that Quasar's edit (and I can remember that there were more edits like this in the past) I gave it a thought, and now I agree with Gauss. I think that the real correct way is to follow the rule to the letter. Though we have pages for ROTT, Duke3d, Wolf3d etc., we don't cover these games, we only have a brief description and usually only for things that somehow are related to Doom games. --Nockson (talk) 12:07, 6 February 2024 (CST)
To be honest, I never really understood why games like Quake or ROTT weren't italicized, I just accepted it as established practice. But I would welcome a more consistent line were basically all none-Doom engine games are italicized across the board. --Gregor (talk) 20:21, 6 February 2024 (CST)
Now that I've woken up, I also agree that non-core titles (per the Entryway lists) should remain italicized. And we already know Quasar's stance is the same. So I'll get some script runs done on the usual suspects, and we can update the rest as we encounter them. --Xymph (talk) 10:41, 7 February 2024 (CST)

Okay, I think I've italically nailed the vast majority of non-core and external titles. There may be names/patterns I haven't thought of though, so if they occur more frequently, let me know for another script pass. Otherwise it's probably easiest to fix leftovers manually. --Xymph (talk) 09:15, 16 February 2024 (CST)