User talk:GrampaSwood/Bug guidelines

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)

Cutting down on examples are just going to make it more difficult for first-time bug reporters to understand the process of bug entries. Shouldn't we instead be open and clear on how this process is done, albeit the user not knowing much about bug reporting from the get-go? If not, this would likely just result in more bad entries to remove.

Wookipan (talk | contribs)

23:00, 5 March 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.

Darkid « Talk — Contribs » 16:37, 27 February 2022 (UTC)

The page need to undergo some minor proofreading before being passed. The provided examples are fine as-is, and expanding them would only increase page length, thus risking the loss of interest from users; we should try to keep it as digestible as possible. That said, there should still be notes on the process of bug submitting, and it should remain clear that the burden of proof lies on the editor. Again, if the process isn't clear enough then we'll just end up removing more bad entries - inevitably, new editors tend not to read the guidelines - but having this as a clear guideline might reduce those bad entries.

I'd also be alright with reference links to YouTube videos, but as you said, they could change or become unavailable at any time. Even if it's present on a page, it does not necessarily mean it has been reviewed as some edits do go under the radar, so should we have a way to verify this similar to {{cit}} but instead confirms it verified? This is just a suggestion for a possible what-if scenario that I might be overthinking...

Wookipan (talk | contribs)

23:00, 5 March 2022 (UTC)

 Approve I would suggest some changes, though:

Notability

I think the introduction could be clearer that bugs must be notable to be mentioned; the guidelines for mentionabilty and how to mention apply only to notable bugs.

Related to this this, "Most bugs are notable." is somewhere between unnecessary or unsubstantiatable. I suggest clipping to just "The general purpose of bug sections should be for players ... affect their game. " After that sentence, I would add something like "Effects in the game that do not have those qualities are not notable."

Where?

I would think the "Bugs section" would be under "Where?". "Bugs" are submitted in the Bugs section (creating the section if it doesn't exist yet) of the page covering the topic where the cause of the issue lies."

I would also add somewhere "Bugs should be mentioned once in the broadest topic affected by the bug. Example: A Bug affecting play in Playload mode specifically should be stated only on Payload#Bugs, not on every Payload map page.

Editing bugs

Since some parts of the preceding paragraphs also discuss editting Bugs, and this section really is only about citations, I would change Editing bugs to Citing bugs.

Obviously, the intention is that proof is required for the original Bug placement as much for any correction or update. I would think "When adding or changing a Bug statement, provide proof that the statement or changes are actually true."

That's all folks.

M I K A D O 282 ⊙⊙⊙⊙⊙⊙ ⊙⊙ ⊙⊙ (Talk with Mikado282 (SM)) | (contribs) (Help Wanted!) 14:34, 30 July 2022 (UTC)