Fallout Wiki
Advertisement
Fallout Wiki
Forums: Index > Wiki proposal votes > Proposal: Seperate Bug Policy Page

Back in January I put forward several major revisions for Bugs which have altered the way we address and handle them. We still lack a uniform Bug policy page though. I along with Gunny feel that the subject has had adequate enough discussion to warrant a vote. Below are the proposed broad issues with not having a Bug policy page, what the current bug policies are, what changes we would be including along with a separate page, the people who voted before discussion had finished, and the discussion which took place.

Proposal[]

To create a separate and viable page specifically for bug policies so that we can better cover and describe how they should be formatted, and what they should encompass. I can do this myself by using the Bug Verification Project page as a base template.

You might be asking why we need a separate policy page for bugs since they are covered under the content policy. Well there are several reasons why we really need to move them over to their own page:

  • First Notable loot has it's own policies page so why are bugs left without one?
  • Second The policies on the content page are vague and broad, and need to be updated to reflect changes in the bug verification project.
  • The current policy makes no address of the platforms needed template.
  • A set policy page would allow us to outline the format of the game bug pages which quite often are messy and very non-uniform in nature.
  • With Fallout 4 in the foreseeable future getting a set policy for bugs down on paper now will save us some serious trouble down the road.

As I've said before, bug's are probably the most far reaching part of the wiki, they effect all but 1 of the games, and are prominent gameplay mechanics. We should treat them like we treat any of the other important topics for the games, and maintain them as such. ---bleep196- (talk) 18:29, January 30, 2013 (UTC)

Policy revisions and additions[]

Ok as it stands right now the following is extracted from the current contents page.

===Bugs===

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 specific to a platform, on multiple platforms should be marked only with the platform(s) appropriate.

Workarounds and bug-fixes[]

  • Even though Fallout Wiki 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.

Exact Revisions[]

As you can tell this is already a sizable chunk of information on it's own. This proposition would make the following changes and additions to the information as well as placing it on it's own page:

  • Modify the Bugs should be believed clause so that all NEW bugs must receive a {{Verify|~~~~~}} tag so that the bugs can be tested for validity, and that bugs should not automatically be removed if the timer runs out, especially if they pertain to bugs involving quests or time specific events as these can be hard to reproduce in 1 try.
  • Add a section dedicated to the purpose of the new verified subtemplate and how it should be used:
    • The verified subtemplate is to be placed on all bugs present in articles excluding those marked with the verify template pre-introduction of said template.
    • The Verified tag should only be placed on bugs currently holding a verify tag or new bugs that are posted after the introduction of the new template if they have been verified by a second party. While we assume everything is done in good faith, we can't have people running around and automatically putting a verified tag on a bug when they put it in.
  • Add in that platforms, while great for identifying the specific system that the bug was discovered on, do not serve as automatic verification of it's existence.
  • Add in a section addressing the {{Platforms needed}} Template and how it should be used.
    • Example: The platforms needed should be placed on all bugs lacking a platform that are available on multiple platforms (I.E. Xbox 360, Ps3, PC).
    • Users should practice discretion with the template, for example the Platforms Needed tag SHOULD NOT be placed on bugs that have a sub bullet which expresses a bug fix that directly denotes the console of origin.
  • A subsection to the page would be added adressing the standard layout of Main Game Bug Pages, and Add-on Specific bug pages.

Creation of a separate and detailed page specifically dedicated to the Bug Policies[]

Yes[]

  1. Yes Sounds good to me.--TwoBearsHigh-Fiving Intercom01 20:52, January 29, 2013 (UTC)
  2. Yes This is something we really need. I mean if we have a page for what qualifies as notable loot, why wouldn't we have one for bugs? Richie9999 (talk) 21:25, January 29, 2013 (UTC)
  3. Yes --Kastera (talk) 21:45, January 29, 2013 (UTC)
  4. Yes you have my blessing, my child, JASPER//"Do you like hurting other people?"UserRichard 17:45, February 7, 2013 (UTC)
  5. Yes I support this edition. --The Old World Relics (talk/blog/contributions) 19:06, March 17, 2013 (UTC)
  6. Yes Well, we already have a sub-page for notable loot. Great Mara (talk) 19:51, March 17, 2013 (UTC)
  7. Yes This seems good. --C'n-Frankie -ArroyoTalk 20:04, March 17, 2013 (UTC)
  8. Yes I've actually wanted this for quite a while now. ~ Toci ~ Go ahead, make my day. 20:14, March 17, 2013 (UTC)
  9. Yes Kind of ridiculous we don't have this, I just assumed it existed and I never saw it. - Chris With no background 23:05, March 17, 2013 (UTC)
  10. Yes I do have to edit a log of bugs that are added, and have been in discussions about the policies. Paladin117>>iff bored; 23:36, March 17, 2013 (UTC)
  11. Yes I support this. Most of the additions can be found in the current bugs section of policy or on template documentation, but having a centralised page is certainly a good idea. It may be easier to refer to as well. --Skire (talk) 00:16, March 18, 2013 (UTC)
  12. Yes SaintPain TinySaintPainThat was broke afore I got here." 00:22, March 18, 2013 (UTC)
  13. Yes Sub-pages like this already exist, why not this one? The section's size will be increased due to new revisions and I think it'll increase enough to warrant it's own subpage. --DragonBorn96Talk 16:06, March 18, 2013 (UTC)
  14. Yes I have no substantial reservations about this. The Gunny  380px-USMC-E7 svg
  15. Yes It does make a bit more control over the bug reports. Energy X Signature0 20:08, March 18, 2013 (UTC)
  16. Yes Hell yeah Detroit lions Hawk da Barber 2012 - BSHU Graduate 22:15, March 18, 2013 (UTC)
  17. Yes Looks ok to me. Jspoel Speech Jspoel 23:19, March 19, 2013 (UTC)
  18. Yes Good I love this! TheMcChicken (talk) 04:46, March 20, 2013 (UTC)
  19. Yes What Richie said.--User ncr A Safe People is a Strong People! 16:18, March 21, 2013 (UTC)
  20. Yes
    Limmiegirl Lildeneb Talk! ♪
  21. Yes After seeing a prototype of said page I am now inclined to agree that a separate page is required. FollowersApocalypseLogonihil novi sub sole 23:47, March 21, 2013 (UTC)

No[]

Neutral[]

  1. Neutral Agent c (talk) 19:08, March 17, 2013 (UTC)
Excluded votes
  • Neutral I think the policies and guidelines page already covers this fairly well. If there are new additions to the bug policies by these votes then a separate page may be a good idea, granted it doesn't get too complicated and remains simple for the average user. FollowersApocalypseLogonihil novi sub sole 23:00, January 29, 2013 (UTC)

Additional Comments[]

If a separate policy page is needed, then so be it. But where exactly are the policy changes? --Skire (talk) 23:33, January 30, 2013 (UTC)

Indeed. I would be more inclined to have a say if I saw a draft of what exactly would be found on this new policy page. --The Old World Relics (talk/blog/contributions) 23:37, January 30, 2013 (UTC)
I Have included the exact revisions that we would make, these are still flexible and we can add or remove additional policies based on need. ---bleep196- (talk) 17:09, February 7, 2013 (UTC)

The one things I would like to make sure of is that bugs listed are actually the result of a bug and not the game acting as it is supposed to. For FO3, the Family and Arefu factions merging after Ian's decision in Blood Ties was listed in the Bugs section even though it really wasn't a bug. Great Mara (talk) 20:17, March 17, 2013 (UTC)

That really shouldn't be a problem, most users can easily distinguish between the game actually working and what constitutes a bug. Sometimes those things slip through in the late hours of the night, so we have to keep our eyes open. ---bleep196- (talk) 20:24, March 17, 2013 (UTC)

Why are we tracking bugs?[]

I've been thinking about this for some time, and I'm questioning why we need to really track bugs at all.

When F4 si released, its going to be buggy, that is the nature of modern software. We seem to have set ourselves up a nice way to fail here. We'll preport bugs on version one, include the verfy tag, and then come version 1.01 we'll have a lot of potentially outdated information on the wiki.

Now this will be a boon for those who want to boost their edit count as we're constantly adding and removing verification tags, but I'm not sure we're really adding any value to the wiki in including these. I've heard a few grumblings from several users over the past few weeks about users potentially boosting edit counts by doing what should be bot work... Whilst I believe that this is all in good faith, I have to ask if this is really the best use of our resources?

I propose that we for most intents and purpses stop reporting bugs at all. Instead we maintain a small list of "game breaking bugs", maintained by a few people who go and retest this list every release. To get on this list it has to seriously break the game - make a quest incompletable most of the time it occurs... this keeps the list manageable. Agent c (talk) 18:22, February 7, 2013 (UTC)

While I see your logic and concern over this, bugs are as much a part of the Fallout Series as any other game aspect. Reportings bugs (especially those that have to do with quests and locations) is a huge part of the wiki. Many bugs get fixed by patches, this is true, but go through the articles and count the number of bugs that are not fixed by patches. You will find that they far outnumber those that are, if we don't report them, and even worse if we don't post solutions to help users fix them who will?
To Address the Patch issue, we amend bugs that have been fixed by patches, we always have, to say that the bugs will become outdated is neglecting to acknowledge the fact that some people don't update their game regularly, and will still need to know about those bugs in their current version.
Those who are using this project as means to boost their edit count are in the minority, and I'd like to hear from the people who are grumbling about it too. We've made it clear that the insignificant bugs (clipping and other related items) that have no effect on gameplay are not notable. There are some serious lesser bugs that can hinder gameplay that are worth reporting.
Game breaking is a very broad term, you will have to be a lot more specific with how you outline this. Are you talking about bugs that make quests inadvanceble? Make factions turn completely hostile? Cause the game to crash nonstop? Corrupt save files? There are a lot of "Game breaking bugs".
This is on a more personal note, and has made me especially hostile, The edit count boosting is directed at me, and I don't appreciate it. I dedicate a lot of my time to the wiki, especially in the past couple months since I've come back. I've made a lot of strides towards unifying and standardizing the format and style of the bug areas of our articles, don't sit there and call what I am doing edit boosting. I could care less about how many total edits I have, it's just a number, in and of itself it has very little meaning. If anyone is annoyed by the fact that I edit enmasse, or because I don't like to sit around and not be productive just because another game isn't coming out then there is something wrong. There is always something we can be doing to improve this wiki, if anyone has a problem with me trying to do this, then I will leave, and I won't come back. ---bleep196- (talk) 18:58, February 7, 2013 (UTC)
Bleep, firstly you are reading a personal attack when none is present, and I'm sorry if it comes across that way. However if you think your edits could be construed this way, then perhaps is a sign you should be looking at a bot to do the work. Doing manually what a bot can be doing automatically is not really productuve at all.
" if we don't report them, and even worse if we don't post solutions to help users fix them who will?" a similar argument could be used to support the inclusion of more strategy. I would recommend anyone having bug issues actually head on over to the "Technical issues" section of the Bethesda forums, where people are happy to give bespoke, up to date advice on issues (rather than a page that could have been updated anytime in the past), and those who are responsible for the game have a chance to gauge the true impact. If they dont get bug reports, they stip fixing them.
My understanding is we're supposed to be a Fallout Encyclopedia... But Britanica doesn't list when trains are late...
On the patch cycle, I really don't see how this point is addressed at all. On day 1 of Patch 1, we're going to have a whole lot of "verfied" bugs that are no longer verified/present in game.
The only major benefit I see from us maintaining this is using the project as a "Trojan horse" to get people started in editing... Agent c (talk) 20:31, February 7, 2013 (UTC)
There's one really good reason to continue to list bugs on article pages: Folks will google the bugs when they are trying to figure out what to do about them. We want those hits. They may come here to figure out a bug, but they may also make repeated visits to read more about the other articles. Bug generated traffic is something we are loath to ignore. As you said, there will be tons of bugs. Do you really want folks looking for details of those bugs to find other sites and not this one? I know I sure don't. The Gunny  380px-USMC-E7 svg 21:48, February 7, 2013 (UTC)
My Apologies, I read a little to much into this. You did state though that you saw users reading complaining about boosting edit count, I'd still like to know who was being implicated as doing this. Gunny makes an extremely valid case, the bugs bring us hits, lots of them. They are a huge draw for the wiki, and if we don't maintain them or we decide to stop reporting them people will stop coming here looking for solutions, and won't be exposed to the editor friendly environment. Remember everyone is an anon before they are a member. ---bleep196- (talk) 22:31, February 7, 2013 (UTC)

( I feel a bit... ah, dirty, saying this: but I have to agree with Gunny and Bleep over this one. Ratings are an unfortunate necessity on any gaming wiki, and making note of as many bugs as possible, even outdated ones, will help generate the traffic needed to keep our community alive and thriving. Removing the vast majority of our bugs would cripple us, I would think. ForGaroux Some Assembly Required! 23:28, March 19, 2013 (UTC)

Example Page[]

Ok guys, so I've gone ahead and created a prototype page as an example of what the new Bug Policy Page would look like. Please leave your feedback below. User:-bleep196-/sandbox1 ---bleep196- (talk) 01:43, March 21, 2013 (UTC)

I would change the wording of "While we assume everything is done in good faith, we can't have people running around putting verified tags on bugs as soon as they post them." to something more professional like: "Editors should not apply the verified tag to bugs they have added themselves." The Gunny  380px-USMC-E7 svg 17:42, March 22, 2013 (UTC)

Just a small note about the linking offsite for bug fixes[]

I didn't notice this vote and thus missed my chance to vote. My only concern is the offsite linking to bug fixes. Doing that to the older games is fine but when Fallout 4 comes out we should wait until they finish releasing the DLC's and patches. Just a thought.--Kingclyde (talk) 20:01, March 26, 2013 (UTC)

Result[]

This vote passes. You can create that separate bug policy page, Bleep. Jspoel Speech Jspoel 17:57, March 25, 2013 (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