Forum:Notable bugs policy

Forums: Index > Wiki discussion > Notable bugs policy

Bugs policy poll

Below is my proposed rewrite of our bugs policy. I'd like to gather at least some semblance of consensus before just rewriting the existing policy. So, please vote in the poll and/or make your opinions known under Discussion below. Thanks.--Gothemasticator 21:09, November 8, 2010 (UTC)

---

The proposed changes

Notability

• Only bugs which have real gameplay consequences are notable. Below are some examples of non-notable bugs that should not be listed individually on any article page:

• NPCs referring to the player character by the wrong gender.
• Inconsequential animation bugs, such as a gun holstering incorrectly.
• Inconsequential clipping issues.

• Only bugs that are repeatable are notable. No unrepeatable bug, no matter how dramatic, should be listed.
• "Bugs" that are fixed by reloading or re-entering a cell are not notable.

Brevity

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

Summarizable bugs

• Common repeating bugs, even inconsequential ones, are worth summarizing on the main bugs pages and perhaps also listing on an individual article page. For example:

• While clipping issues are not generally worth noting, Super mutant Behemoths have frequent clipping issues that often lead to them getting stuck on the geography. It is not worth listing individual events, but it is appropriate to put a summary entry on the Behemoth article page.
• Companions in FO3 and New Vegas have common issues with waiting and with unexplained aggro. It is not worth listing individual instances of such behavior. However, copy/pasting a summary explanation onto each of the companion article pages is appropriate.
• It is appropriate to write a brief statement on a main bugs page that NPCs sometimes refer to the player character by the wrong gender. It is not appropriate to list this on any individual NPC's article page.

Using the {{verify}} and {{platforms}} templates

• All bugs that meet the notability standards should be tagged with the {{verify}} template and removed if the timer runs out without verification from at least two editors other than the original poster.
• All verifications should be converted to the {{platforms}} template as they are encountered.

Exploits

• Exploits relating to an article should be mentioned briefly but only be explained in detail on dedicated exploit pages (like Fallout 3 exploits, for example).
• Exploits should not be listed on the main bugs pages, but they should be moved to the main exploits page.

Workarounds and bug-fixes

• The Vault does not cover the use of third-party mods. No bug-fix that involves a third-party mod should be listed.
• If pc users can use the console to fix a bug, a brief note to that effect and a link to the console commands page will suffice. Console commands should not be listed on individual article pages but only on the console commands page.

---

Vote in the poll

Poll finished on 9:09 pm November 15, 2010 (UTC).

• A consensus must be reached by voting before any action is taken.
• You can vote by placing one of the following lines in the appropriate section:
  • Use # {{yes}} ~~~~ if you support the proposal.
  • Use # {{no}} ~~~~ if you are against the proposal.
  • Use # {{neutral}} ~~~~ if you wish to abstain.
• Please do not edit other user's votes.

Please vote {{yes}} to signify your approval to the changes above, {{no}} to signify disapproval, or {{neutral}}. In addition, please weigh in with your input under Discussion below.

It's about time we had a solid bug Policy, If we put this into place then the Bug verification Project will run alot more smoothly and allow us to remove alot of the trash on many articles. ---bleep196- 00:42, November 9, 2010 (UTC)

I do believe that this is necessary. It isn't very important to list minor, unimportant things as " bugs" (i.e., clipping issues). This is a good idea. shame it hasn't already been proposed. -- The Jovar 01:27, November 9, 2010 (UTC)

We oughta have a full-blown bugs project, but this needs to be the solid foundation of such a project so it's a necessary first step. --Kris

Every bug is notable if it meets the criteria of repeatable and obviously broken. I also refuse the proposed removal of third-party mod links, as not every bug is going to be easy to fix with console commands. Nitty ^Tok. 01:37, November 9, 2010 (UTC)

While I'm against linking to regular mods, I think we should keep links to fan-made bug fixes. However, I also think we can safely get rid of clipping issues, but I'd keep mentions of characters referring to the wrong gender. Ausir^(talk) 01:51, November 9, 2010 (UTC)

Hmmm, there are some good issues being addressed here, but as stated above, some things should be changed. For example, keeping external sites in will help PC users, but not the Xbox 360 or PS3 communities, and may make it feel as though the wiki is more for the PC users. I will withhold judgment for now, until there is a more solid argument being made. --Saphireking65 02:01, November 9, 2010 (UTC)

I have a few specific comments (see the Discussion section). Sheltim 03:14, November 9, 2010 (UTC)

• , with a few tiny . More in discussion. --- Yukichigai 03:37, November 9, 2010 (UTC)

it would help clean things up, but keep the console commands and links to mod bug fixes untill they patch it?--Silverfox6000 04:46, November 9, 2010 (UTC)

• I like the idea of having more guidelines for the bug sections, although I do think we should come up with somewhere to list the third-party solutions. Maybe they could be expanded upon on the separate bug pages, (i.e. Operation: Anchorage bugs)? My only problem is that it could potentially make pages cluttered. Glomulus 05:29, November 9, 2010 (UTC)

• This guideline is just necessary. Even if every bug is notable (I doubt it) we need a strict standard to depict it. Otherwise we'll have a cradle of chaos in every bug section. veryblackraven^Talk 07:05, November 9, 2010 (UTC)

Half the bugs on pages are the same. Almost every NPC has a 'wrong gender' bug, why list it so much?JASPER//"Do you like hurting other people?" 15:53, November 9, 2010 (UTC)

I agree with Ausir's point on third-party bug fixes. I think it's better to provide a link to a third-party mod that fixes the bug. Also, it's kinda strange not to refer to a third-party patch that contains thousands of fixes ... . Agreed with almost everything else though. Have to say it's good one single policy is being made about this. --Sentinel 101 18:46, November 9, 2010 (UTC)

Discuss

• I'm game for changing the third-party mod bit.
• I'm game for changing the gender bit.

Question for Nitty: Can you get more definitive about what you mean exactly by "obviously broken?" This is exactly the kind of thing I'm hoping to state clearly in the policy, in order to give editors a guideline by which to make good decisions about adding and removing bug entries.--Gothemasticator 02:03, November 9, 2010 (UTC)

I also think that console commands fixing the bugs should be given, and not just linked to the console commands article. I've just used one to fix a bug in FNV myself, and I find it pretty convenient if the actual command is in the article. Ausir^(talk) 03:29, November 9, 2010 (UTC)

• My take on this:
  1. Reloading/re-entering bugs should be noted, so long as they are reproducable. Just because it can be fixed easily doesn't mean it doesn't exist.
  2. Absolutely on the brevity issue, especially when it comes to exploits. If it's more than 50 words its probably way too long.
  3. on the summarizing. Individual instances seem to overwhelm the larger picture. On this topic, I think it might be appropriate to allow an article with a specific instance to simply mention the larger issue and link to it if the issue is important enough.
  4. The requirement for three-person verification of bugs is far too rigid. For more nuanced or involved bugs it may be impossible for most editors to verify the causes. This needs to stay a "use your judgment" thing. Still require use of the verify tag though.
  5. on use of the platforms tag. Quite relevant.
  6. on the suggestions dealing with exploits
  7. Third party bugfixes should absolutely be allowed, but ONLY if from reputable, verified sites, like Nexus or ModDB.
  8. Console command fixes should only be listed if they can be summarized in less than three commands, e.g. prid 6a775, moveto player. -- Yukichigai 03:39, November 9, 2010 (UTC)

• The reloading/re-entering thing could probably be cut out. My intention was that those are almost always not reproducible bugs. They are one-off spawning glitches that are fixable by re-entering because they don't reproduce every time. But if reproducibility is the standard, then it's not that useful to have it again just said a different way.
• I suppose I could live with one verification, as long as it is not the original poster.
• I like Yuki's suggestion of a space-limitation on the console commands.
• Bug-fix mods: I understand the usefulness, but I am leery of dipping our feet into the whole is it a bug-fix or is it a mod debate that tends to rage up over such things. Can we come up with some standard for which we link to and which we don't? Or can we get away with just pointing people to Nexus when we know there is a fix hosted there?--Gothemasticator 05:09, November 9, 2010 (UTC)
  • I think reader friendliness is a worthy consideration, with regards to linking. It's not hard for an editor to find the fix and link to it; theoretically you'd need to at least find it in order to verify the statement "a fix for this bug can be found on Fallout Nexus" or similar. As far as the standard to use... that, again, is judgment, but in my experience its pretty obvious. Most "fix" mods tend to describe themselves as a fix or a bug patch, and if that's not accurate they tend to be treated as such in the comments. -- Yukichigai 06:38, November 9, 2010 (UTC)

Alot of the bugs can be deleted outright, just by reading their description. Such as alot of the ones for the Silver Rush which I removed claiming there was more than one guard outside the building, etc. ED-E is a horrible article but I havent found enough time to undo alot of unnecesarry edits, play and start working on the new skill articles (in the same layout I revamped the F3 articles). Also what about bugs that are patched out? Should they still be listed with a note of version, etc? Mictlantecuhtli 10:53, November 9, 2010 (UTC)

• I think that mods that only fix bugs, and do not change or add any other content, should be included - e.g. killap's Fallout 2 patch, which has become pretty much the standard mod to install after installing vanilla FO2. Ausir^(talk) 11:15, November 9, 2010 (UTC)

• My comments:

1. "Bugs" that are fixed by reloading or re-entering a cell are not notable. I disagree with this, as the notability of the bug should be covered by the other guidelines, regardless of how easy the bug is to fix. In fact, I would strongly disagree with this specific guideline as it is important to note that it can be fixed so easily, so that no one wastes their time trying to fix it in other ways.
2. If pc users can use the console to fix a bug, a brief note to that effect and a link to the console commands page will suffice. Console commands should not be listed on individual article pages but only on the console commands page. I also strongly disagree with this guideline. If there is a verified fix that uses the console, I would prefer it to be documented in the article rather than require me to put the pieces together.
3. Templates - While we have a template for "verification required", and one for "verified", it occurred to me that bug fixes (and/or workarounds) are hard to come by. Would it be useful to have a template for "no fix found yet"? Surely we have some editors that enjoy verifying bugs and finding their fix/workaround Sheltim 03:14, November 9, 2010 (UTC)

How about a "Common bugs" table (like the Interactions table) with a list of common bugs by type (NPC, Weapon, Armor, Location, etc) and whether or not that particular type of bug affects the subject of that article. Any additional bugs could be stated below the table. --Kris 16:51, November 9, 2010 (UTC)

Also, no idiotic bugs. Things which noone would do, and if they then hit a bug, it's pretty much their fault.JASPER//"Do you like hurting other people?" 18:40, November 9, 2010 (UTC)