Forum:Bug Policy proposals and changes

	This forum page has been archived. Please do not make any further edits unless they are for maintenance purposes.

Hi guys, back at the end of April I began a Discussion about adding on to our existing bug policies for the sake of trimming down the amount of space bugs visibly take up on a page, such that on pages where their are more bugs than actual content, the bugs don't overshadow the important content. This idea involved the use of the Notable content template which allows bugs to be hidden beneath a collapsible, while still showing 5 bugs at the top of the section. (Credit for this idea goes to Jspoelstra as he had already begun implementing something like this long before I even thought about it). During the hosted forum discussion I held a very productive discussion which made me aware of some other issues with our current policies.

In addition to the issue of brevity and space, the notability clause in the bugs section is quite vague. At the time that these policies were created, I merely drew from the existing policy, as I didn't believe notability would be that big of an issue. Since that time, however, the number of both bugs reported, and bug sections in articles has increased on a massive scale. As such I think it's time to also reevaluate what bugs we consider appropriate to report.

Thirdly, I would also like to propose an additional policy, and by direct implication, a uniform organizational format for bug section presentations such that entries are presented in descending impact on gameplay/immersion (where game crashes/save corruptions are at the top). This has a direct tie in to the notable content template use in that it will place game breaking bugs within the topmost 5 entries that will be visible when said template is used.

As a note to all potential voters, due to the volume of articles which contain bugs, and the relatively little attention they get for maintenance purposes, these proposals will require a large amount of time and effort to put in place, a good opportunity to introduce new editors to wiki templates, formats, and editing styles should even one of these proposals pass.

Below I will present three proposals, which will each be voted on independently of the other. ---bleep196- (talk) 17:34, June 19, 2016 (UTC)

Proposal 1[]

Poll finished on 5:33 pm July 8, 2016 (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.

In order to decrease the volume that bug sections take up on individual pages, I propose that we add and implement the following clause to the "Brevity and Clarity" section of the bug policy page.

Yes[]

1. ^寧靜 19:59, June 19, 2016 (UTC)
2. ~The Crystal Crow~
3. - FDekker ^talk 20:16, June 19, 2016 (UTC)
4. - 20:50, June 19, 2016 (UTC)
5. Sigmund Fraud ^{Talk Contributions} 22:23, June 19, 2016 (UTC)
6. - Musie
7. Paladin117^{>>iff bored;} 02:18, June 20, 2016 (UTC)
8. --Cassie ~可愛いの猫 05:21, June 20, 2016 (UTC)
9. - Kennyannydenny (talk) 10:07, June 20, 2016 (UTC)
10. In favor, but I'd like the template changed so the "more" jumps out more (put it in bold or so). - ^Greets Peace'n Hugs (talk) (blog) 10:29, June 20, 2016 (UTC)
11. - Rain ^{comms. - logs.} 11:56, June 20, 2016 (UTC)
12. - FFIX (talk) 17:58, June 20, 2016 (UTC)

No[]

1. . Makes verification harder, as the average user who visits that page wont see the bugs hidden below the "8 bug" threshold and thus not know there are one that require verification. A lot of people don't like to add content, so if they did find a bug they wouldn't actively try to add it to the page, but might verify one someone else has already added (which they can't if they don't see it at first glance). JASPER//"Do you like hurting other people?" 11:22, June 20, 2016 (UTC)
2. for the same reason as stated above, also I feel that people adding already listed bugs, which happens already, will only happen more if the notable content template is used and hides some of the bugs. Richie9999 (talk) 22:03, June 20, 2016 (UTC)
3. Hidden bugs are not good to have. The Nick Valentine page is a perfect example. If I didn't click on the more tab, I wouldn't see the several verification overdue tags. If I just landed on the page for something else and checked that at the same time, well looks good here. But it's not. Kingclyde (talk)
4. I foresee the same issue as Richie, and I also agree with bleep's comment about a "middle ground" type of policy to mediate the concerns already stated above for this proposal. _{Don't give up the ship!} 23:11, June 23, 2016 (UTC)
5. Bugs are as much a part of a page's content than anything else, its length in comparison to other, or all other, sections requires no defense. --The Ever Ruler (talk) 02:01, June 24, 2016 (UTC)

Neutral[]

1. I don't know about using Notable Content template. Originally, the option to collapse content was just used for the quotations, which were just optional to be at the pages. Bugs are notable enough to stand out, though. Though I get the deal to compress the space, with a lot of bugs being listed. ☢ Energy X ☣ 20:47, June 19, 2016 (UTC)
2. With respect to those who have worked so hard on it, I believe we should stop tracking bugs unless a game is seeing no further patches developed. Every time a new patch is released, the work is effectively moot and needs to be redone. This is a job for Bethesda QA, not us. Agent c (talk) 22:26, June 19, 2016 (UTC)

Comments[]

Here is an example of what the looks like on a bug section: Last Voyage of the U.S.S. Constitution#Bugs or Nick Valentine#Bugs. --176.145.192.166 22:10, June 19, 2016 (UTC)

Thus far all of those who have voted no or neutral have presented very convincing arguments over why this may not be the most conducive for our bug sections. I am hesitant to hide our bug sections, for reasons they've listed above, but I also understand that on a surprising number of pages, the volume of bug sections is greater than the actual content of the article. Bugs are an important part of the wiki, as they provide insight or an avenue through which users can relate to others who might be experiencing these issues, and they draw traffic and hits for us through google and other search engines. As much good as they provide us, however, on pages were there are more bugs than actual content, they overshadow the actual content of those articles. It didn't use to be an issue, but with the sheer size of the wiki, there are more pages like that now. I would like to find a middle ground, which is somewhat difficult, and the two proposals below are somewhat mediators for that, they should help trim some of the fat from the bug sections. With that said, I'm always open to suggestions and ideas for a better solution, not that this is a severely pressing issue mind you, just one I feel should be addressed at a time where we have a large influx of new editors and users. ---bleep196- (talk) 11:43, June 21, 2016 (UTC)

Proposal 2[]

I propose that we revise the "Notability" section of the bug policies page, which currently states the following:

I propose the following revisions to said section.

• Bugs that contain typos, inconsistent dialogue (i.e. the subtitles phrase the response one way, but the actual voice acting deviates from said phrasing), incorrect pronouns, and other text based bugs that do not impede gameplay or quest progression are not notable.
• Graphical bugs that consist of clipping, weapon texture glitches (e.g. floating/incorrectly positioned weapon pieces), moving facial features or body parts on dead characters, and inconsistent appearances in flashbacks are not notable.
  • It should be noted that graphical bugs that consist of significant distortion of the character model (I.e. inverted body parts, distended facial features, etc.), low res textures that hide enterable areas, and Graphical glitches that interfere with/block the visual field are notable.
• All other bugs are notable

The following bugs that I removed in earlier edits are examples of these

Yes[]

1. ^寧靜 19:59, June 19, 2016 (UTC)
2. ~The Crystal Crow~
3. - FDekker ^talk 20:16, June 19, 2016 (UTC)
4. As long as the bug can ruin gameplay experience. ☢ Energy X ☣ 20:47, June 19, 2016 (UTC)
5. I personally believe Example 3 should remain, as it is a more severe graphical bug (Ie. it isn't a clipping or minute detail bug, like the other two), but otherwise I approve. Sigmund Fraud ^{Talk Contributions} 22:23, June 19, 2016 (UTC)
6. Paladin117^{>>iff bored;} 02:18, June 20, 2016 (UTC)
7. --Cassie ~可愛いの猫 05:21, June 20, 2016 (UTC)
8. - Kennyannydenny (talk) 10:09, June 20, 2016 (UTC)
9. if it doesn't actually effect anything, why care? JASPER//"Do you like hurting other people?" 11:24, June 20, 2016 (UTC)
10. - Excluding major graphical bugs (such as the speed loader above), I think they're not worth a mention. Rain ^{comms. - logs.} 11:56, June 20, 2016 (UTC)
11. - FFIX (talk) 17:58, June 20, 2016 (UTC)
12. Kingclyde (talk)
13. Changed from neutral. -- 13:41, June 22, 2016 (UTC)

No[]

1. I think these graphical bugs should still be mentioned - ^Greets Peace'n Hugs (talk) (blog) 10:31, June 20, 2016 (UTC)
2. I draw issue with graphical bugs. There is some subjective language within the proposed rule that I feel will cause difficulty and/or confusion in the future. What exactly is the threshold for a graphics bug that severely disrupts immersion? Richie9999 (talk) 22:06, June 20, 2016 (UTC)
3. I actually wanted to know about my character's appearance during the simulations of the past, I wouldn't have known it if we axed its mentioning. So I wouldn't want to see things like that removed in the future. --The Ever Ruler (talk) 01:55, June 24, 2016 (UTC)

Neutral[]

1. I hope we will still make note of continuity/dialogue inconsistencies in the article.- 20:50, June 19, 2016 (UTC)
2. Dialog inconsistency should be defined more clearly and still leave room for inconsistencies that could trouble the player or be misinterpreted I guess. --176.145.192.166 22:10, June 19, 2016 (UTC) Anonymous users are not permitted to vote on policy changes. ---bleep196- (talk) 20:06, June 20, 2016 (UTC)
3. With respect to those who have worked so hard on it, I believe we should stop tracking bugs unless a game is seeing no further patches developed. Every time a new patch is released, the work is effectively moot and needs to be redone. This is a job for Bethesda QA, not us. Agent c (talk) 22:26, June 19, 2016 (UTC)
4. I like where this idea is going, but as is mentioned in the "no" votes, I would like to see clarification on what actually makes a graphics glitch or dialogue inconsistency "significant" enough to be included. The wording is rather vague. _{Don't give up the ship!} 23:15, June 23, 2016 (UTC)

Comments[]

I'm confused on the specific changes being proposed the "Notability" section. I think the current model is outdated but are we going to specifically change? --Musiekutsueki (talk) 01:52, June 20, 2016 (UTC)

The Current model/policy guidelines are quite vague for notability. This stems from a time where bug sections were...much smaller in number and quanitity (mostly I believe that policy was implemented when FO3 came out, and at the time they had no idea just how big a part of the wiki the bug sections would become). The vagueness of this policy currently causes a lot of issues and debate over which visual/text bugs are acceptable to keep or not. With the growing number of articles containing bugs (It's approaching minimum 2000, probably more than that as there are pages that have bugs, but do not contain the hidden category due to improper marking/formatting of the bugs). Additionally, most visual bugs get fixed in the large patches, alongside most, and key word here is most, major game breaking bugs. All of the changes proposed here will almost certainly require a joint project effort. ---bleep196- (talk) 18:09, June 20, 2016 (UTC)

Proposal 3[]

In order to prioritize bugs that are most likely to cause game/immersion breaking issues, I propose that we add a Bug section layout component to the bug policies, which reflect the classifications as outlined by Aya42 in the discussion page for these proposals.

Thus the policy addition would read:

For bug sections contained within any standard article, entries should be sorted from top to bottom based on the following classifications, where those in category 1 would be at the top, those in category 2 wold fall below category 1, etc.

1. Those bugs which have the potential to cause extreme data loss, i.e. having to revert to very old save, or restart the game from scratch.
   1. For example, if you wear the targeting HUD mod, or eat berry mentats, in Virgil's lab at an early point in the game, then the player will discover a significant amount of time later that the main questline is broken, and will be forced to reload a save before the previously mentioned game breaking event, resulting in massive progress loss.
2. Those bugs which have the potential to cause minor data loss, i.e. having to revert to your last save. Anything which can potentially cause the game to crash would fall into this category.
3. Those bugs which can potentially hinder progression of a quest, but can be resolved without having to revert to a previous save. This excludes issues which can only be resolved by the use of console commands. For the sake of non-PC users, those would more likely fit into #1 or #2 above.
4. Everything else deemed notable for inclusion, roughly sorted in decreasing order of severity.

Yes[]

1. ^寧靜 19:59, June 19, 2016 (UTC)
2. - FDekker ^talk 20:16, June 19, 2016 (UTC)
3. Will be tough, but not impossible to achieve. Maybe a project can be started. ☢ Energy X ☣ 20:47, June 19, 2016 (UTC)
4. - 20:50, June 19, 2016 (UTC)
5. It seems reasonable to sort bugs by order of severity but going through all the bugs that have already been reported for all the games will require a project. --176.145.192.166 22:10, June 19, 2016 (UTC) Anonymous users are not permitted to vote on policy changes. ---bleep196- (talk) 20:06, June 20, 2016 (UTC)
6. Sigmund Fraud ^{Talk Contributions} 22:23, June 19, 2016 (UTC)
7. - Musie
8. Paladin117^{>>iff bored;} 02:18, June 20, 2016 (UTC)
9. --Cassie ~可愛いの猫 05:21, June 20, 2016 (UTC)
10. - Kennyannydenny (talk) 10:11, June 20, 2016 (UTC)
11. - ^Greets Peace'n Hugs (talk) (blog) 10:33, June 20, 2016 (UTC)
12. - Rain ^{comms. - logs.} 11:56, June 20, 2016 (UTC)
13. - FFIX (talk) 17:58, June 20, 2016 (UTC)
14. Kingclyde (talk)
15. It'll be tedious to enact and a bit repetitive having to constantly explain how it works to new users, but I think this is the most organized way to go at the bugs issue. _{Don't give up the ship!} 23:07, June 23, 2016 (UTC)
16. I like the sound of this and trust we can handle it in an ad hoc manner as bugs appear over time. --The Ever Ruler (talk) 02:03, June 24, 2016 (UTC)

No[]

1. With respect to those who have worked so hard on it, I believe we should stop tracking bugs unless a game is seeing no further patches developed. Every time a new patch is released, the work is effectively moot and needs to be redone. This is a job for Bethesda QA, not us. Agent c (talk) 22:26, June 19, 2016 (UTC)

Neutral[]

1. ~The Crystal Crow~

Comments[]

For Proposal 2, I am not sure if any sort of elaboration is even needed. Clipping bugs, and typos, have never been notable on this wiki. In all of their forms, they should be removed - not sure why, if that is the case, as to why editors might have stopped removing these sorts of non-notable bugs. ^寧靜 20:01, June 19, 2016 (UTC)

I don't quite understand why they are popping up now, but if you look at some of the examples I posted that I removed earlier, some of them aren't so much classic clipping as abnormal visual/graphical glitches. Most of the more recent ones I've seen involve character model irregularities that aren't substantially immersion breaking. It would be one thing if the character model was suddenly twisted inside out, but the eyes moving on the synths, or a dead character blinking aren't worthy of a mention and just take up space. Clipping doesn't exactly address those specific types of glitches. ---bleep196- (talk) 20:21, June 19, 2016 (UTC)

Regarding Proposal 3, my only concern is that newer editors may have difficulty finding or knowing about the bug ranking sequence. I've been a Wiki member for years and didn't know much about the policy pages. Admittedly, that's on me for my own incomprehension, but seeing that bugs seem to be an entry point for many, it may be a sticking point. I'm happy to follow the consensus, but wanted to explain my neutrality on this point. ~The Crystal Crow~

I appreciate your explanation, and definitely understand the concern. The Bug policies aren't exactly out in the open either, you have to navigate through the content policies and click on the link to them through there, so it can be difficult for newbies to figure out the rules about bug reporting. Mostly, the biggest headache will be implementing the policies and sort out the pre-existing articles. Preferably, I like to guide new editors who show interest in the bug sections (I handle them mostly by myself, for whatever reason not many other people care much about the bug sections, with the exception of some of our newer patrollers) and make sure they know about the policies when they start editing. But I'm not here 24/7, and I don't always catch everything. The goal here is, in addition to further clarifying and cleaning up our policies, to bring in a fresh group of editors who are bug policy savvy and will be capable of spreading around said knowledge to other editors. This way, when people edit the bug sections, they will know how to put things in place, and what templates to use. ---bleep196- (talk) 20:37, June 19, 2016 (UTC)

Don't forget to change "you" words. We ought to write sentences in a neutral tone, using third-person perspective. ☢ Energy X ☣ 20:47, June 19, 2016 (UTC)

Thanks for pointing that out Energy, the classifications were copy pasted from the discussion that led to this proposal, so I didn't do much formal editing. I will remember to reword everything to be in third person. Also, I was already thinking about a large project to implement Proposal's 1 and 2, it's a big undertaking but one that could garner a lot of newer editors experience if it's put together right. ---bleep196- (talk) 20:57, June 19, 2016 (UTC)

Results[]

The poll has now come to a close. The decision for these policies now lies with the BC's. I just remembered that Policies do not have to go through the BC's deliberation like special rights requests, therefore by Majority vote all three proposals pass. I'd like to thank everyone who threw in their opinion, as it's given me a better and broader view on how our editors, especially those among the staff, feel about bugs and how we handle them. These policy proposals have passed, but in regards to the first proposal which was, arguably, the most controversial, I will continue to pursue a more visible method of collapsing larger sections. I can't do it tonight, but tomorrow I will add each policy to our existing bug policy pages with with revisions for clarity and specificity. ---bleep196- (talk) 16:04, July 9, 2016 (UTC)