Difference between revisions of "Doom Wiki talk:Policies and guidelines"

From DoomWiki.org

(Reasoning and further explanation)
m (Map walkthrough images: Level not article :P)
Line 218: Line 218:
 
:: 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.
 
:: 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, <nowiki>[[E2M2: Containment Area (Doom)/Console]]</nowiki> would be a redirect to <nowiki>[[MAP10: Containment Area (Console Doom)]]</nowiki>, 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 article has a console version," and that would be a link to <nowiki>[[{{PAGENAME}}/Console]]</nowiki>. 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. --[[User:Quasar|Quasar]] ([[User talk:Quasar|talk]]) 16:57, 27 January 2015 (UTC)
+
:: 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, <nowiki>[[E2M2: Containment Area (Doom)/Console]]</nowiki> would be a redirect to <nowiki>[[MAP10: Containment Area (Console Doom)]]</nowiki>, 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 <nowiki>[[{{PAGENAME}}/Console]]</nowiki>. 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. --[[User:Quasar|Quasar]] ([[User talk:Quasar|talk]]) 16:57, 27 January 2015 (UTC)

Revision as of 12:02, 27 January 2015

Licensing

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)

Capitalization

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

(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

"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

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)

namespaces

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

Here's a policy question — should we really apply this kind of formatting to all 1200+ articles?  Everything2.com 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

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)

Wow

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)

Spelling

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!" 58.178.88.196 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)

Images

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

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

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)