Jump to content

[Proposal] Additional Bug Reporting Standards


Recommended Posts

Hi,

I would like to propose the following:

1. As a requirement for bug posting, system information generating using a standard tool, something like dxdiag or whatever makes sense for the platform and project.

2. Optional documented classification for flagging hardware related systems, audio/video etc.

Hardware information supplied by a supported tool could allow developers to leverage a class of regular expressions, or similar, to automate extraction of information relevant to a bug report in an unambiguous fashion. This can be useful in many ways, for example notifying a reporter that a specific bug is due to a known driver incompatibility on their system, potential dupe warning, triage, and other cool stuff.

In general though, strictly following standards, allows for more automation and thus faster development.

Just some ideas!

Thanks,

gfulton

Link to comment
Share on other sites

I would think this is too much to ask from regular customers reporting bugs.

It would be nice with a sticky thread that describes how to do the things you suggest and explain that it is helpful. But I don't think you can expect regular people to provide every little detail.

As far as I know it's hard enough to get everyone to report steps to reproduce the bug they report.

Link to comment
Share on other sites

Yeah, I agree. I didn't mean to lean on "required" so hard.

I still think there is a certain threshold where requirements can be introduced in order to eliminate reports too vague or unclear to be useful, yet still not deter someone from submitting an acceptable quality report should they feel inclined.

I guess the trick is finding this threshold while not deterring the bug reporting process. Though I suspect with an alpha release people will scream loudly enough about the most troublesome/annoying bugs without fail, or a bug reporting thread/system at all! :P

Link to comment
Share on other sites

In addition, I wouldn't suspect that standard or premium supporters are regular customers at all. Rather, it would be my assumption that these people, at least most of the ones that participate in the forums anyway, are willing to assume some responsibility in the development process, specifically in testing. It is what they paid for after all, minus the supporter bonuses.

I suppose an easy way to test this theory would be to request repro steps from the user if they did not provide them - via a dialog box or something - yet they can decline if they want. Then sit back and see if the quantity and/or quality of repro steps increases.

Edited by gfulton
Link to comment
Share on other sites

I meant regular as opposed to special interest in the technical aspect of using a computer. As I was trying to say (but forgot) I'm a bit vague on what exactly you want me to do in the first post and how to do it.

I used customers instead of preorders because of the off chance that I would be misunderstood to make a difference between premium preorder and regular preorders. :P

Edited by Gorlom
Link to comment
Share on other sites

I meant regular as opposed to special interest in the technical aspect of using a computer.

This is a good point. However some support for bug reporting could be added to the forums to help alleviate this issue. Custom thread fields are simple to add to vBulletin. So when submitting to the Bug Report forum users could select things like build version, affected gameplay system, etc from a drop-down listbox.

As I was trying to say (but forgot) I'm a bit vague on what exactly you want me to do in the first post and how to do it.

Sorry for the vagueness, but it was intentional as I don't know the exact nature of the development needs and constraints you guys are working with. As for classification as I mentioned above you could just add additional fields to the vbulletin database and drop-lists (or similar) to the interface for the Bug Reporting thread. Then, if the development team wanted to, they could perform specific queries on the forum database to get information about the nature and quantity of various bugs and bug types, but most importantly this could ease integration into the internal bug tracking system and make triage (determining severity, owner, dupe checking, etc) easier, making testers live's easier :)

This would take a little bit of coding to get done, and I would be more than happy to help. If I am still not making sense I could do a mock up of what I am talking about so you could demo it for yourself.

Edited by gfulton
Link to comment
Share on other sites

Thanks for the idea, but we are able to reproduce the issues mostly with the informations provided.

Hi Matthew,

Please see my response to Gorlom just above. I believe additional classification features could be added in a non-invasive fashion. Let me know if you think this would help. Apologies if this isn't the best channel for offering development support - I looked for a link on the site but didn't find one.

Edited by gfulton
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...