Forum:Handling bug additions

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

Forums: Index > Wiki discussion > Handling bug additions

The bugs sections on many article pages are out of hand. See You Gotta Shoot 'Em in the Head for a good example. Our policy of reporting bugs first on talk pages for confirmation simply isn't working. I'm interested in seeing if we can figure out an alternative.

Reporting bugs[]

Difficulties:[]

New editors don't know the current bug-reporting policy.
The policy is ignored so widely that editors new and old are not encouraged to follow it even after being made aware.
There exists no simple or easy mechanism for editors to tell if the bug they experience is notable.
There exists no mechanism for the talk page submission policy to work.
- Talk pages do not have a clear bug submissions section.
- There are no clear instructions about when to move a bug from discussion to the article. I doubt this even happens at all.

What is happening now is that bug reports grow and grow until someone, usually an administrator, gets sick of the bloat and deletes a whole bunch of redundant bugs, non-bugs, unconfirmed bugs, common bugs, and probably even some legit bugs. Or, instead of deleting, moves them to the talk page where they die a slow death of neglect.

Possible solutions?[]

Add text to the bug sections on all article pages. Something to the effect of:

Post bugs on the discusion page for confirmation from other editors. Once bugs are confirmed, they will be added to the article. Common bugs, especially those found on the Fallout 3 bugs page, are not to be added to individual article pages.

Create a section at the top of every discussion page entitled Bugs submitted for confirmation.
- Add instructions to the effect of

Add bugs here. Do not confirm your own bug submission. When a submission has been confirmed by two separate editors, it may be added to the article.

Do away with the bugs section on all article pages. I personally don't see how this could work, but it is an attractive idea some days...

I'd really like to see some improvement in the bugs area of the wiki, and I hope someone has better ideas than mine.--Gothemasticator 05:55, February 14, 2010 (UTC)

Responses[]

I agree that the whole "confirm on discussion page" procedure isn't working (and with the rest of your problem analysis). To be honest, I'm not fond of using the talk pages as trash cans in general (which - let's face it - is usually the purpose of 90% of all moves from article to talk space). Unfortunately, I don't have any brilliant ideas either.

My only suggestion would be canning the whole talk page confirmation thing and instead using {{verify}} (or a bug-specific derivative thereof) with a slight modification: I could alter the template so it'd be called with a date parameter (i.e. {{verify|~~~~~}}, and after a set amount of time the tag's appearance would change to "confirmation overdue, remove me" in red font. At the same time, the article would automatically show up in a special maintenance category ("Verification overdue"), making it easier to keep track of stuff to remove. Of course, that wouldn't remove the necessity of continuous maintenance - but I doubt we'll be able to find something which would.

I'm not a fan of inserting editing instructions in visible article text - it's simply not of interest to readers (which are the vast majority of visitors). I know the mboxes are basically just editing instructions as well, but at least these are temporary and not permanent in nature. -- Porter21 ^(talk) 02:37, February 15, 2010 (UTC)

I really like the timed verify template idea. Maintenance for bugs sections would be greatly improved, since the whole section can be checked over when responding to an overdue notice. Plus, the talk page for the template could become a place where proper handling of bugs can be discussed over time and some conventions eventually agreed upon.--Gothemasticator 11:13, February 18, 2010 (UTC)

I'll create the template then. After which timeframe should it be marked as overdue? Two weeks? -- Porter21 ^(talk) 12:44, February 18, 2010 (UTC)

See User:Porter21/sandbox3 (template) and User:Porter21/sandbox4 (examples). Still pondering whether I should simply modify {{verify}}, create a bug-specific variant, or both. -- Porter21 ^(talk) 14:29, February 18, 2010 (UTC)

The {{verify}} makes sense. Wiki proper uses that, why not us. When ever I revert a bug that needs verification, I leave a short note about policy. No one reads that most of the time anyways. We should do that. --Kingclyde 08:50, February 28, 2010 (UTC)

The key point is the timer addition from my point of view, it should help with getting rid of unconfirmed bugs in a timely manner (instead of leaving them there until an admin stumbles upon them by chance). -- Porter21 ^(talk) 09:08, February 28, 2010 (UTC)

Exactly, I'll move them over when cleaning a page, but I never think about going back in a few weeks and checking on them. Remember when I said I was going to keep track of that. I guess I was asleep at the wheel again. :) --Kingclyde 13:13, February 28, 2010 (UTC)

I'm all for implementing the new verify template. What it's going to take is somebody to write up a new policy subsection about it and alert all the admins as to the change and a link to the policy bit. Then, we can all begin implementing it and teaching the other editors. (This is something I cannot take on at the moment. If someone else is willing, great. Otherwise, I will get to it, but it may be a few weeks.)--Gothemasticator 03:07, March 21, 2010 (UTC)

My general thoughts and ideas on the bugs section in articles are as follows;

General suggestions regarding format and inclusion in articles:

Working on the basis that all bugs should be confirmed if they are included in an article, reduce the confirmed on x,y or z to a simpler and cleaner (PC/Xbox 360), (PS3) etc style, and remove completely where program bugs are generalized and confirmed on all platforms, so a tag is only used where reference needs to be made to specific platform(s).
Bugs should be notable, explained briefly, and specific to the topic of the article ie quest bugs shouldn't be on character or location pages, or vice-versa etc. (I think this is already policy, but no harm in re-stating)
Reporting of "bugs" that are achieved through the use of mods, hacks, or the console, don't constitute real in-game bugs and should not be included.

Possible suggestions (any, some, or all) to minimize random unconfirmed bug additions in articles, that could be implemented by the bot (??):

Rename section in articles to Confirmed bugs.
Add article-invisible edit tag under section title on articles to include something along the lines of
Add a Bugs awaiting confirmation section to the talk pages of articles with a Bugs section, and encourage its use.

Seeking verification: I agree with the idea of a tag, and it is a common device familiar to most editors due to its use on Wikipedia. When in doubt {{verify}} phoenix txt xp 09:20, March 21, 2010 (UTC)

Concerning bugs that appear on all platforms, I believe it was decided to say "confirmed all platforms" if the bug appeared across platforms. Simply removing the tag altogether will leave those of us adding tags such as "verify" to make them as unconfirmed bugs when in fact, they are confirmed. Thoughts? --Kingclyde 08:25, March 23, 2010 (UTC)

That is a valid point. The use of the {{platforms|pc|ps3|xbox360}} tag is probably a much more effective and cleaner method of dealing with it. phoenix txt

10:24, March 23, 2010 (UTC)

Is there some reason that I don't see the date/time stamp when I enter {{verify}} with the five tildes? Am I doing it wrong or is the date/time stamp not implemented?--Gothemasticator 20:34, March 23, 2010 (UTC)

Oh, I guess it doesn't display a date/time. It just flips to overdue when the timer runs out. Is that right? So, we just need to add checking the verification overdue category to our maintenance pages list.--Gothemasticator 20:39, March 23, 2010 (UTC)

Yeap, that's the way it works currently (although it'd be trivial to change that if you'd prefer some sort of indicator that a certain verify tag is a "timed" one). Well done finding {{platforms}}, phoenix, I'd already completely forgot I created it :P -- Porter21 ^(talk) 19:36, March 24, 2010 (UTC)

It was only 3 months ago :P I found it had taken up residence on the Broken Steel bugs page :) phoenix txt

05:57, March 27, 2010 (UTC)

It seems to me that the following is the consensus:

Insert {{verify}} after new bug entries.
After 14 days with no verification, delete the bug entry.
When a bug has been confirmed across all platforms, replace the parenthetical notes with {{platforms}} tag.

Yes? Without any objections, I'll add this procedure to the appropriate policies page.--Gothemasticator 20:34, March 23, 2010 (UTC)

I largely agree, although we could consider simply using {{platforms}} right from the start and for platform-specific bugs as well. -- Porter21 ^(talk) 19:36, March 24, 2010 (UTC)

I like porter's idea. That does make it alot easier.--Kingclyde 03:05, March 27, 2010 (UTC)

Caching issues and consequences[]

Phoenix has spotted an issue with the new timer mechanic: Category:Verification overdue does not update properly to show the pages which have overdue {tl|verify}} tags. The category is shown on the article page itself, and the displayed text correctly changes to the red removal message, but the page does not show up in the category until the next time the page is saved. This is not a bug with the template, but a result of the MediaWiki's page caching (not going to bore you with details ;)).

Currently, the only solution I see is to have a bot manually refresh the pages in Category:Verify periodically, which will then cause the overdue pages to show up in Verification overdue correctly. I'm planning to have PorterBot do it every Sunday for now. Of course, the downside is that when I'm away the updating won't get done, so if other users want to help out by having own bots share the task it'd be appreciated. -- Porter21 ^(talk) 17:21, April 18, 2010 (UTC)

Awesome. Now I can start learning about bots. Cool.--Gothemasticator 03:05, April 19, 2010 (UTC)