FANDOM


Icon nowrite
This forum page has been archived. Please do not make any further edits unless they are for maintenance purposes.
Forums: Index > Wiki discussion > Concerns regarding the Bug Verification Project
 
Gametitle-Wiki
Gametitle-Wiki

Greetings, fellow Nukapedians. As the title of this forum page indicates, I do indeed have some worries with the Bug Verification Project as it is being run right now. What I am going to say below is the same text as seen on Fallout Wiki talk:Bug Verification Project, but that has not received any notice.

"I'm not a huge fan of this project, or at least the way it's currently being run. I had originally signed up because I thought it was an organised effort to actually verify bugs (as the project name implies), not just straight up doubt the validity of others' bugs and slapping a {{Verify|~~~~~}} on it. While I was a participant, I quickly realised what we were really doing. Most bugs with a verification tag are removed after the time is up (14 days) instead of being actually verified, which is the intent. This happens due to the bugs not being noticed during that 14-day span, or no one putting forth the effort to verify the bugs in-game. The end result is plenty of valid bugs being expunged from our articles, which obviously degrades quality and the amount of coverage in our bugs sections. Furthermore, the way the project is being executed nowadays is contradictory to the inveterate "assume good faith" policy.

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.
— Our content policy

Most of the bugs that receive the verification tag are not suspicious, nor do they sound unlikely at all. Many editors are following this practice of indiscriminately removing platform tags and replacing them with a verification tag, even if the bug seems legitimate.
In conclusion, here's what I have to say: this project is being run in a way that contradicts policy (summarised by the quote above) and is hurting our article quality, since many valid bugs end up being removed. I would deeply appreciate it if these concerns are addressed and parts of the project possibly amended. --Skire (talk) 14:45, July 3, 2012 (UTC)"


I kinnda have mixed feelings for this. I'm sure people want to add bugs because they experienced them, but there are some issues about all this:

  1. What if someone who just wrote the note about a bug is the only one who has it? Not everyone has same.
  2. How should I know if someone tested that bug if the verify template is there?
  3. If I am assumed to belive all bugs are true, then how should I know on which platform it is (if the platform template isn't there) and then how should I know if it is indeed a true bug?

Energy X 09:00, July 11, 2012 (UTC)

Those are all good points but what I'm talking about is the execution. From what I've seen, people slap a verify tag on even when there already is a platform tag added by the person reporting the bug. There isn't much "verifying" going on in the project it seems, mostly marking things (and overdoing it) for verification hoping someone else will get to it. Well, the reality is most of these bugs end up in the verification overdue category and are removed. The real goal of the project should be to actually verify bugs - by testing them out and finding which platforms they are on. I'm even fine with bugs that have no platform to be marked for verification. Instead of straight-up doubting someone's bug report, why don't we (participants of the project) actually attempt to verify it ourselves? If not, don't expect someone else to - believe the bug as it directly states in policy. Of course, if said bug sounds suspicious or unlikely then it should be verified. --Skire (talk) 14:20, July 11, 2012 (UTC)

I don't know about others, but when I slap a tag on a bug, I try and find it and trigger it. Sometimes it takes hours, but I still try and find it. Detroit lions Hawk da Barber 2012 - BSHU Graduate 14:29, July 11, 2012 (UTC)

That's exactly what I'm getting at! =) What I'm hoping for is that people will actually assume responsibility for the bugs they tag, instead of leaving it for others. That way there is actually some degree of verification going on and the majority of bugs won't be unattended to, awaiting eventual deletion. --Skire (talk) 14:32, July 11, 2012 (UTC)

I can see where you are coming from on this, Sigma. This has always been a concern of mine and I'm glad you've pointed it out. When I joined this project, it started to build up some serious activity. We all had a specific job and worked as a team. Some of us found the unverified bugs and slapped a tag on not to gain an extra edit or to give ourselves an excuse to delete the information, but to mark those bugs for another project participant who had the task of going in-game and testing the bugs.

After the excitement died down and users either left the wiki or moved on to other things, it seemed that the only participants left were the ones who marked the bugs. I, myself, was one of those participants left behind. Now, my reason for only verifying a fraction of the bugs that I mark is that it is too big of a responsibility for one or two users to take on. If I and one or two other users would try to mark and verify every single bug we find, then several unmarked and self-verified bugs would get past us as we spend time in-game trying to prove and disprove others. This would leave bug sections very unorganized and without consistency as some bugs would be verified/with a tag and others would just be sitting there with nothing.

Now, this doesn't mean that the project itself is causing a problem and needs to be scrapped. This only tells us that the project needs more users to continuously participate in it. Remember that unlike other projects such as the weapon condition project or the Fallout 3 locations project, the BVP is ongoing and needs constant love and care. I thank you for this forum, Sigma. This issue needed some light shed upon it, and you did exactly that. ~ Toci ~ Go ahead, make my day. 05:36, July 16, 2012 (UTC)

Yeah, it's good to hear your thoughts on this, since you were (along with HawK) one of the big guns on the project. I'm definitely not saying we need to scrap the project, but just to be more careful over what we remove. The Gunny presented quite a few good points below that would work greatly. --Skire (talk) 15:24, July 16, 2012 (UTC)

I agree heavily with the fact that people are overusing the verify tag, especially when putting them on things other then bugs. I've also seen self verified bugs, which are just as irritating. The big problem we faced initially when I first suggested this project was how to go about verifying them. The issue here is that no one has the time to go through platform by platform, article by article and do this manually, so instead we are relying on our better judgement at the moment. I really don't know how we can do this better than we currently are, their are some good ideas here, but none of them are easy to implement, and they will all take a lot of time as well. Also, I think we should make it standard policy to watch for people who remove platform tags, that's an issue that we shouldn't have to be dealing with, and is almost equivalent to altering an article because you don't agree with the description, despite it being factual. ---bleep196- (talk) 00:40, July 23, 2012 (UTC)

I see where you're coming from, but there being not enough time does not justify removal of bugs without them going through testing. And I never understood the "self-verified" bug stuff - assuming that a user's report of a bug is not true and putting a verification tag on it is violating the fundamental assume good faith policy. The Gunny's post below contains great suggestions as to how we should go about bug verification. The basic idea is to do more actual testing and verifying, and less removing. --Skire (talk) 01:17, July 23, 2012 (UTC)
The prescription about self verified bugs aren't about casting doubt at the editor's good faith, but at their capacity to properly judge if the bug in question is indeed a valid bug or not. There were many instances e.g. of bugs that are caused by mods, or related to the users' specific machines/saves, like corrupted saves or glichty consoles. Also, demanding a second verification is a way to ensure the bug is reproducible. Limmiegirl Lildeneb Talk! ♪ 19:22, July 23, 2012 (UTC)
That would be very nice should said second verification be forthcoming. As previously stated, most of the time that is not the case. And if this project's participants do not handle the testing to seek that second verification, who will? --Skire (talk) 19:26, July 23, 2012 (UTC)

Need for additional templates?Edit

I've been asked about the use a "platform needed" template to help facilitate bug verification. After looking at our content policy, the bug verification project and the existing templates, I'm not sure we need another template. It's quite clear that we are not supposed to put verify tags on every bug, only the dubious ones. If this is done correctly, that will leave us with:

  1. Bugs with properly formatted platform tags. Unless these are dubious, as the guideline states, they should not be tagged for verification. They can still be tested, rewritten for clarity and possible fixes/workarounds, but never deleted.
  2. Bugs without platform tags. This is mostly because users don't know how to use the template. Almost all bugs occur on all 3 platforms. These can be tested and platform tags added as needed, but not removed, and only tagged for verification when dubious.
  3. Bugs that should be verified. These are the dubious or unclearly stated bugs. These are the bugs that need to be tested, and if found to be specious, removed. If they need rewriting for clarity, they should be rewritten, not removed. Even when a bug is listed in the verification overdue cat (is a bot even updating this cat?), it should NOT be removed unless it is tested. These are the bugs that testing should focus on.

I don't see the need for any other mechanisms. If the guidelines are followed, only tested bugs that are found to be specious will be deleted. Again, a bug should never be removed unless it has been tested. If you don't have time or desire to test the bugs listed in the verification overdue cat, then leave then for someone who does. As for bugs needing platform tags, those should probably be caught when they're first posted. That's why we've got admins/mods/patrollers to check these edits to make sure they're formatted correctly and are readable. If an editor posts a bug without a tag, all you have to do is ask them which platform they're on and show them how to add the tag or add the tag yourself. I fear if we have a template to toss on the pages when we see an edit without platforms tags, we'll just slap the template on there, instead of asking the editor (who at this point is probably still around) for the information, and leave it for someone else to deal with it later.

As far as the project goes, I'm not involved, but I would say the proper progression for a project like this would be something along these lines:

  1. Inspect all bugs listed on pages and tag only dubious or unclearly worded ones for verification.
  2. Test and verify all the above. Delete only those found specious.
  3. Inspect all bugs without platform tags, test as needed and add tags.
  4. Inspect all properly platform tagged bugs and rewrite for clarity/test for workarounds.

At least, that's how I'd set up the project.

One final thought: We need to think long and hard before we remove any information, bugs or anything else. The only information that I feel should ever be removed from articles is false information. Any honest information should either be rewritten to meet our guidelines or, if the current policies state the information is not worthy of inclusion, an effort should be made to find a reasonable solution for that information to be included somewhere.  The Gunny  380px-USMC-E7 svg 03:03, July 14, 2012 (UTC)

That sounds good to me, Gunny. The only problem now is not much testing is going on at all and bugs are being removed as soon as they are in Category:Verification overdue. Sometimes certain editors even go through Category:Verify and look at the timestamps to find overdue bugs. I think we all need to observe the guidelines more and have better judgement when it comes to this. And letting newer users or even anonymous ones that add bugs know about {{Platforms}} seems like a good idea too. I just wanted to bring this to everyone's attention. --Skire (talk) 15:43, July 14, 2012 (UTC)

So I've removed bugs that were overdue after I tested them on my pc (as per usual) and J directed me to this forum. Am I in the wrong now?--Kingclyde (talk) 18:46, July 31, 2012 (UTC)
Nope, J was just looking out I'm sure =) As long as the bugs are tested they can/should be removed (if in Category:Verify or Category:Verification overdue). Bugs in the latter category shouldn't be removed just because they are in that category, but they are to be tested to confirm them as being either false or true. After this, they may be either restored as a normal bug with a platform tag, or removed. So as long as you're really testing them, it's all good! --Skire (talk) 18:55, July 31, 2012 (UTC)
Are we still keeping glitches/exploits separate from bugs?--Kingclyde (talk) 00:20, August 2, 2012 (UTC)
Everything else remains as they were before. --Skire (talk) 22:26, August 5, 2012 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+