Fallout Wiki
Advertisement
Fallout Wiki
Forums: Index > Wiki proposal votes > Notable bugs policy

Revised bug policy[]

After some great discussion, I've come up with the new revision of our bug policy below. This new policy does not quite satisfy my personal desire for sparseness in our bug sections ;) , but community consensus seems to be that bug reports are more important and useful to our readership than I had thought.

The policy outlined below relies a lot more on judicious editing especially by the more experienced among us. Our bugs sections do need some lovin' attention, but the discussion made it clear that that attention needs to be more than just wholesale deletions.

Please read over the content below and vote in the poll. The poll will only run for three days this time, so please weigh in.

Thanks.--Gothemasticator 04:53, November 30, 2010 (UTC)


I have made a slight change in the Notability section after some input below - Clipping and typos now non-notable. Also added a clarification for using the verify template.--Gothemasticator 18:15, November 30, 2010 (UTC)


Notability[]

  • Clipping issues (i.e. items poking through one another) and typos are not notable.
  • All other bugs are notable.

Brevity and clarity[]

  • Wherever possible, bugs should be re-written with brevity and clarity in mind.

Where do bug reports belong?[]

  • Generally speaking, a bug belongs in the article of the bugged entity and nowhere else. E.g., quest bugs belong on the quest page and not on the npc page.
  • Bugs not specific to an entity (e.g. crashing on cell change) should be listed on the main bug page.
  • The main bug page should not contain duplicate listings from individual article pages. Entries should be moved to the appropriate page.

Exploits[]

  • Exploits relating to an article should be mentioned briefly but only be explained in detail on dedicated exploit pages (e.g. Fallout 3 exploits). This is because so many of the exploit descriptions are so very long.
  • Exploits should not be listed on the main bugs pages, but they should be moved to the main exploits page.

Using the {{verify}} template[]

  • Most bugs should be believed. There is no need to gain verification for what is a believable report offered in good faith.
  • Suspicious or unlikely-sounding bug reports should be marked with {{verify}} and removed if no verifications are forthcoming before the timer runs out.
Guideline for editing: Editors who can recognize or quickly test an unreproducible event should remove it. If you're unsure and the bug entry sounds iffy, that's when you use the verify template.

Using the {{platforms}} template[]

  • Almost all bugs occur on all platforms. When that is apparent, editors should go ahead and list all platforms via the template.
  • The few bugs which are platform-specific should be marked only with the platform appropriate.

Workarounds and bug-fixes[]

  • Even though The Vault does not cover the use of third-party mods, bug-fixes are appropriate to list and link to. Acceptable sites to link to are ModDB and the Nexus sites. Please check the link to assure that it works and that the bug-fix is appropriate for listing.
  • Fixes and workarounds for pc users should be listed in an indented bullet below the bug they fix. It is acceptable as well to link to an appropriate section of the console commands article page.
  • Workarounds for console players tend to be quite verbose and should be reworded for brevity and clarity wherever possible.

Vote in the poll[]


"We're all different! We're all unique!" "I'm not." "Shut up."--Gothemasticator 01:49, December 1, 2010 (UTC)
  • Yes Crap, this means another project, doesn't it? Hal10k (Talk) 01:35, December 1, 2010 (UTC)
Not another project, no. Just some consistent and clear help for editors.--Gothemasticator 01:47, December 1, 2010 (UTC)
  • Yes Sounds good to me. Glomulus 02:19, December 1, 2010 (UTC)
  • Yes Would have to dig into the matter a bit more, but seems fine to me too, Jspoelstra 13:36, December 1, 2010 (UTC)
  • Yes Looks good. Good work there! -- Sentinel 101 19:22, December 1, 2010 (UTC)

Discuss[]

I'm slightly curious as to how 1-off glitchs pertain to this set of rules, like in assassins creed brotherhood i had a glitch where i air assassinated someone, and the camera started floating up indefinitely, i haven't looked this up on the wiki yet but i assume it is rare, so what happens if someone has some glitch that is unduplicateable? given the whole most glitchs should be believed system. Toolazytomakeaaccount 07:01, November 30, 2010 (UTC)


It would be nice if there was a bit more about what constitutes a bug. People will post stuff about how you can noclip through walls and find weird stuff, or fall through the world. That's not a bug, right? Or people will post things that are not bugs, but represent them not understanding how the quest/area/NPC works, like when people complain that they finished That Lucky Old Sun by activating ARCHIMEDES but didn't get any rewards other than XP. But otherwise I support this policy. Do I get to vote? Is there a requirement to have been an editor for some amount of time? Dmunsil 07:47, November 30, 2010 (UTC)

Things that are not bugs should be either removed or reworded and moved to an appropriate section in the article. And, yes, anyone can vote in the poll. --Gothemasticator 18:23, November 30, 2010 (UTC)

I tend to disagree with the "all bugs are notable" bit. Things like clipping issues or typos in dialogues just clutter the sections and are of little interest for most readers in my opinion. We need to make sure the signal-to-noise ratio is sufficiently high enough; The Vault is a wiki, and not Bethesda's/Obsidian's bug tracking website.

Otherwise nice work, Goth :) -- Porter21 (talk) 11:36, November 30, 2010 (UTC)


I agree with Porter on the notability bit. There's a lot of minor bugs like clipping that can unnecessarily swell the bug sections or the main bug page. I also have an issue with the "Most bugs should be believed. There is no need to gain verification for what is a believable report offered in good faith." - there's a lot of believable bugs reported in good faith, that turn out to be a one-time glitch and are completely unreproducible. --Kris User Hola 12:49, November 30, 2010 (UTC)


@Porter and Kris -

  • Notability: The discussion over the last version seemed to show a general feeling that even clipping issues and typos are of interest. So, the approach I'm advocating now is to rewrite the entries for brevity. That alone should do a lot to unclutter the bugs sections.
  • Reproducible: This is anecdotal, but my observation has been that the verify template is not serving to weed out unreproducible bugs. I am still in favor of removing unreproducible bugs; editors who can recognize or quickly test a seemingly one-off event should remove it. If you're unsure and the bug entry sounds iffy, that's when you use the verify template.
--Gothemasticator 16:21, November 30, 2010 (UTC)

I also think clipping issues and typos are not notable. Ausir(talk) 16:35, November 30, 2010 (UTC)


Noable wise, I think that only game hurting bugs matter. E.g, Cass' head turning sideon of a bit when talked to doesn't really matter, but being unable to open her inventory is. Aslo, cliping wise, stuff like the rebreater's facehair thing doesn#t matter, but Mr Radical cliping in to the road, and becoming unlootable, may be worth a metion.JASPER//"Do you like hurting other people?"UserRichard 18:39, November 30, 2010 (UTC)


I still have issues with notability, anything that affects game play should be note worthy, even typos and clipping. Examples for clipping would being clipping that allows access to otherwise unacessable areas or clipping that makes things normally acessable inacessable, as jasper noted above about being unable to loot a NPC. Otherwise clipping that affects only the appearance/visuals of the game have no notability. As with typos that again is something that mostly is none note worthy, unless it was to affect game play, currently I can not think of any bugs that would fit this. But for the sake of a example if in a quest dialog I was told to go look for a certain man when it was in fact a women I needing to seek, that would affect my game play, otherwise again it not not worthy.

As for reproduction bugs should be reproducible under a certain set of circumstances, otherwise there is no way to determine if the bug is game related or down to the rig the player is using. One off bugs should not be included for this very reason, the real issue here is random bugs and the ease of verifying them.

☣Avatar☣ 20:08, November 30, 2010 (UTC)

Sounds like the current policy, at least if you take "serious consequences" to mean "gameplay-affecting consequences": "Only bugs which readers are likely to be interested in should be documented, i.e. bugs which have serious consequences, bugs which can be exploited to the player's advantage or bugs that most players are likely to encounter during normal gameplay. Not every little oddity needs to be mentioned." -- Porter21 (talk) 10:04, December 1, 2010 (UTC)
And that's the notability standard that hasn't exactly been working for us. Fact is, our readers and editors really seem to enjoy documenting and validating "bugs" that I consider insignificant. A decent example is the pretty common experience of an npc addressing the pc by the wrong gender. In my mind, this stacks up as no gameplay consequence, not notable (no blood no foul). But, I am clearly a minority voice on that subject. Thus, the proposed changes do in deed broaden the notability standard (I'll have to adjust the templates as well). For balance, the new changes attempt to give editors some help for trimming down bug sections and bug entries overall.--Gothemasticator 14:02, December 1, 2010 (UTC)
  • Though I agree those things don't really need to be noted, (I'd think bugs about being able to see through rocks, ect wouldn't be notable either) the "if it doesn't affect gameplay, it isn't notable" would have been maybe a little too broad anyway. Like say there was a glitch that one NPC was always upside down for no apparent reason, just standing on their head. Though it wouldn't affect gameplay at all (other than shattering any immersion you may have had going on), I would think it would be notable. --Pongsifu 14:27, December 1, 2010 (UTC)
at least if you take "serious consequences" to mean "gameplay-affecting consequences":
And thats the real issue here, "serious consequences" is very subjective statement and open to all kinds of interpretation, as you have done in trying to compare it to what I said. But if we take what you have said about clipping not being note worthy and jaspers example of a NPC clipping into the ground and not being able to then loot them. You could very easy argue that if the NPC isn't quest driven or part of the main story line, then there is no serious consequences as it does not hinder you from progressing in the game any further. My example of affecting game play simply put means, any bug that prevent you from doing something you would normally be able to do, or allows you to do something your not able to normally do within the course of normal game play. My version is a bit more definitive and less subjective in its terms and usage.
Pongsifu, yes I agree with you on that there are always exceptions to every rule, you can never cover anything off 100% with a simply policy unless you went to the two extremes of no bugs are noteworthy or all bugs are noteworthy. When trying to find the middle ground you wont be able to cover every eventually with out a multi page document that clearly outlined every single aspect, then there still would always be some few things not foreseen and covered off in that document. ☣Avatar☣ 20:46, December 1, 2010 (UTC)

Results[]

The poll is closed, and there is near-unanimous support for the changes. So, later on tonight I will make the appropriate changes to our policy and to the relevant templates.--Gothemasticator 17:39, December 3, 2010 (UTC)




Policy vote forum overview
PolicyBug policy
Proposal voteNotable bugs policy
Date and result3 December 2010 · 27-1-0
Templates{{Verify}} · {{Platforms}} · {{Notable content}}
Amendment 1Extend timer & create verify template · Vote · 9 February 2013 · 6-0-2; 4-1-3
Amendment 2Separate policy page · Vote · 25 March 2013 · 21-0-1
Amendment 3Notable content template/notability/layout · Vote · 9 July 2016 · 12-5-2; 13-3-2; 15-1-1
Advertisement