Difference between revisions of "User talk:GrampaSwood/Bug guidelines"
(Created page with "= Hottetake = My probably-programmer-biased opinion is to just state what a bug is (undefined/unintended behavior), how to reproduce it, provide an example or two and leave i...") |
(→Bug notability: new section) |
||
| Line 2: | Line 2: | ||
My probably-programmer-biased opinion is to just state what a bug is (undefined/unintended behavior), how to reproduce it, provide an example or two and leave it to the exercise of the author to know what they're doing. If they don't they probably shouldn't be posting technical bug reports. You could probably chop that there word count down to 'bout tree-fiddy -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 11:57, 27 February 2022 (UTC) | My probably-programmer-biased opinion is to just state what a bug is (undefined/unintended behavior), how to reproduce it, provide an example or two and leave it to the exercise of the author to know what they're doing. If they don't they probably shouldn't be posting technical bug reports. You could probably chop that there word count down to 'bout tree-fiddy -- [[User:Lagg|Lagg]] [[File:Backpack_Stickybomb_Launcher.png|24px|link=User_talk:Lagg]] 11:57, 27 February 2022 (UTC) | ||
| + | |||
| + | == Bug notability == | ||
| + | |||
| + | 1. I would merge the 'purpose' and 'notability' sections, and just provide categories of good bugs (with examples) and categories of bad bugs (with examples). You can expand on the 'good' bugs with the examples you have in purpose, i.e. explain why a user might care about these bugs. | ||
| + | |||
| + | 2. IMO, bugs are 'good' if they are gameplay-impacting. Note that visual bugs can be gameplay impacting ("when using item X, gameplay element Y looks like Z"). | ||
| + | |||
| + | 3. I don't think you need to add notes on how to submit bugs, the lead paragraph should explain how we use bugs on this wiki (at the end of the article, in the changelog). Learning where to attribute a bug is unclear, and moving bugs from one page to another is not overly time consuming. The costly part is verifying and removing garbage entries. | ||
| + | |||
| + | 4. For citations, I would be OK with a <nowiki><ref></nowiki> to a youtube video, even with the understanding that it might change. As long as it's valid at time of submission, its presence on the page indicates that it was valid, even if the video disappears. | ||
| + | |||
| + | [[User:Darkid|'''<span style="color: #db9c1f">Darkid</span>''']] « [[User talk:Darkid|<span style="color: #75735F">Talk</span>]] — [[Special:Contributions/Darkid|<span style="color: #BA0000">Contribs</span>]] » 16:37, 27 February 2022 (UTC) | ||
Revision as of 16:37, 27 February 2022
Hottetake
My probably-programmer-biased opinion is to just state what a bug is (undefined/unintended behavior), how to reproduce it, provide an example or two and leave it to the exercise of the author to know what they're doing. If they don't they probably shouldn't be posting technical bug reports. You could probably chop that there word count down to 'bout tree-fiddy -- Lagg 
11:57, 27 February 2022 (UTC)
Bug notability
1. I would merge the 'purpose' and 'notability' sections, and just provide categories of good bugs (with examples) and categories of bad bugs (with examples). You can expand on the 'good' bugs with the examples you have in purpose, i.e. explain why a user might care about these bugs.
2. IMO, bugs are 'good' if they are gameplay-impacting. Note that visual bugs can be gameplay impacting ("when using item X, gameplay element Y looks like Z").
3. I don't think you need to add notes on how to submit bugs, the lead paragraph should explain how we use bugs on this wiki (at the end of the article, in the changelog). Learning where to attribute a bug is unclear, and moving bugs from one page to another is not overly time consuming. The costly part is verifying and removing garbage entries.
4. For citations, I would be OK with a <ref> to a youtube video, even with the understanding that it might change. As long as it's valid at time of submission, its presence on the page indicates that it was valid, even if the video disappears.
