Meet the QA & Usability Lab
by Scott Burns · 05/27/2010 (5:12 pm) · 21 comments
Has it really been two months since coming on full time as QA Lead? Since April we've built the QA department from the ground up, tested and released TGB 1.7.5, tested TorqueX and failed it, completed the initial testing phase for iT2D 1.4, began retesting and regressing/verifing bugs for TorqueX, regressed/verified a bunch of Torque 3D bugs, and created new standards for bug reporting in the forums.
That's a lot for two months.
The Space
Let's talk about the lab itself first. Most of you know that the QA & Usability Lab was created in a partnership with Full Sail's Institue for Research and Education. Full Sail and Torque have a long running history together, so partnering with them for it was the obvious choice. Michael Perry and myself are both Full Sail Grads, and Eric Preisz was a course director and department chair there prior to him joining InstantAction. I know there are several Full Sail grads, current students, former course directors, and former/current lab instructors in our community here as well. And to all of you who've been through here before, a lot has changed here since then.
In April we started with this empty room, and honestly I thought it was going to be a while before we had this room filled to capacity.
It wasn't long before boxes of computers started streaming through the door and the transformation of the lab had begun.
The end result was a room lined with machines, with multiple different configurations to test on.
We even have a selection of Macs to test on. I call this the iTable.
The People
That's the physical space, now what about the people that work in it?
From Left to Right: Robert Martinez (Lab Manager), Marcus Barker (Lab Manager), Derek Hughes (Lab Manager), Dr. Shawn Stafford (Scientist), Roy Papp (Operations Director), Dr. Adams Greenwood-Ericksen (Scientist)
The Lab Managers are the guys on the frontlines of testing. They get assigned the more difficult test cases and supervise student testers when we have them. A great bunch of guys who've done the bulk of our testing up to this point. Shawn is in charge of the Research Institute and heads up our Usability testing. He's also the course director for the Usability class at Full Sail. Roy handles Operations for the lab. He makes sure the needs of the lab are met and gets to deal with the nightmare of figuring out how to schedule the Lab Managers in the lab. Roy is also the course director for the Asset Management class. Adams, who is the QA class course director, works with Shawn on the Usability studies and also works with me to plan out the labs the students take part in for testing.
If I were to list everyone's credentials it would probably fill an entire second blog, so I'll just leave it at that for now. I just wanted to give everyone an idea of what each person does and I can get into those details later if anyone's interested.
The Process
So, you've seen the space and met the people, now let's talk about the process and how the community fits in.
As some of you know we created a new standard for community bug reports in the forums with iT2D 1.4 Beta2. This new standard took into account information that Sven needed as a developer, information Michael needed as a producer, and the information I needed for QA. The goal was to create a standard for reporting that was simple, easy to remember, and made creation of tickets in our internal bug tracker more efficient. After all, the quicker we log the bug, the quicker we can squash it. The new standard worked so well with the iTorque users that we'll now be putting it's use in place for all the engines.
I'll just link to the example Mich posted instead reposting it all in here. In the next week or so we'll be posting a variation of this example in each engine forum. I say variation as there are some things in the iT2D example that are specific to iTorque, like the Target field. I'd like for everyone to begin using this standard in future bug posts. Using this standard and making sure to tag your post with the appropriate category tag will help improve the efficiency of bug reporting/logging and will be greatly appreciated as well.
That's just one method for bug reporting. There's still the web form here on the site for submitting bugs as well, which is under Support->Submit Bugs. You can continue to use that for bug submissions if you don't want to create a thread for it.
Also, as some people know about this and some don't, when we log a bug in our tracker we'll post that has been in the thread along with the ID number for the ticket (i.e. ITGB-52 or THREED-894). That post may come from me, another employee or contractor, or even the Lab's intern, but that way you'll know that we're tracking it.
I'm thinking I'll have to wrap this up soon as this blog is getting pretty long and I'd rather not make this a two-parter. So I'll leave you with this.
The new QA Lab and team is not a silver bullet, nor will it instantly fix problems overnight. I've noticed that some in the community are under the impression that this is how we view the Lab and how we're messaging it to the community. That's not the case at all, or at least it's not intended. We've been extremely excited about this addition, and it's possible that our excitement may have contributed to the perceived expectations of the Lab.
Does the Lab equal bug free releases? No, in software development there is no such thing. Does the Lab equal more polished and stable releases? Yes and no. In the near term it may be more difficult to see the benefits of the QA Lab, but in the long term it will become more evident. The Lab itself is a long term solution and not a quick fix for the here and now. I think TGB 1.7.5 is evidence enough of that, which we have a fix available for the bug that rendered the binary inoperable by the way.
We learn more and more from each round of testing, and the process continues to be refined. While you may notice some improvements in the near term, the long term is where our goals are set and where you'll see the biggest difference.
And because I noticed that I managed to only take pictures of the Lab only when people weren't in it working, I took this one of Roy yesterday.
That's a lot for two months.
The SpaceLet's talk about the lab itself first. Most of you know that the QA & Usability Lab was created in a partnership with Full Sail's Institue for Research and Education. Full Sail and Torque have a long running history together, so partnering with them for it was the obvious choice. Michael Perry and myself are both Full Sail Grads, and Eric Preisz was a course director and department chair there prior to him joining InstantAction. I know there are several Full Sail grads, current students, former course directors, and former/current lab instructors in our community here as well. And to all of you who've been through here before, a lot has changed here since then.
In April we started with this empty room, and honestly I thought it was going to be a while before we had this room filled to capacity.
It wasn't long before boxes of computers started streaming through the door and the transformation of the lab had begun.
The end result was a room lined with machines, with multiple different configurations to test on.
We even have a selection of Macs to test on. I call this the iTable.
The PeopleThat's the physical space, now what about the people that work in it?
From Left to Right: Robert Martinez (Lab Manager), Marcus Barker (Lab Manager), Derek Hughes (Lab Manager), Dr. Shawn Stafford (Scientist), Roy Papp (Operations Director), Dr. Adams Greenwood-Ericksen (Scientist)
The Lab Managers are the guys on the frontlines of testing. They get assigned the more difficult test cases and supervise student testers when we have them. A great bunch of guys who've done the bulk of our testing up to this point. Shawn is in charge of the Research Institute and heads up our Usability testing. He's also the course director for the Usability class at Full Sail. Roy handles Operations for the lab. He makes sure the needs of the lab are met and gets to deal with the nightmare of figuring out how to schedule the Lab Managers in the lab. Roy is also the course director for the Asset Management class. Adams, who is the QA class course director, works with Shawn on the Usability studies and also works with me to plan out the labs the students take part in for testing.
If I were to list everyone's credentials it would probably fill an entire second blog, so I'll just leave it at that for now. I just wanted to give everyone an idea of what each person does and I can get into those details later if anyone's interested.
The ProcessSo, you've seen the space and met the people, now let's talk about the process and how the community fits in.
As some of you know we created a new standard for community bug reports in the forums with iT2D 1.4 Beta2. This new standard took into account information that Sven needed as a developer, information Michael needed as a producer, and the information I needed for QA. The goal was to create a standard for reporting that was simple, easy to remember, and made creation of tickets in our internal bug tracker more efficient. After all, the quicker we log the bug, the quicker we can squash it. The new standard worked so well with the iTorque users that we'll now be putting it's use in place for all the engines.
I'll just link to the example Mich posted instead reposting it all in here. In the next week or so we'll be posting a variation of this example in each engine forum. I say variation as there are some things in the iT2D example that are specific to iTorque, like the Target field. I'd like for everyone to begin using this standard in future bug posts. Using this standard and making sure to tag your post with the appropriate category tag will help improve the efficiency of bug reporting/logging and will be greatly appreciated as well.
That's just one method for bug reporting. There's still the web form here on the site for submitting bugs as well, which is under Support->Submit Bugs. You can continue to use that for bug submissions if you don't want to create a thread for it.
Also, as some people know about this and some don't, when we log a bug in our tracker we'll post that has been in the thread along with the ID number for the ticket (i.e. ITGB-52 or THREED-894). That post may come from me, another employee or contractor, or even the Lab's intern, but that way you'll know that we're tracking it.
I'm thinking I'll have to wrap this up soon as this blog is getting pretty long and I'd rather not make this a two-parter. So I'll leave you with this.
The new QA Lab and team is not a silver bullet, nor will it instantly fix problems overnight. I've noticed that some in the community are under the impression that this is how we view the Lab and how we're messaging it to the community. That's not the case at all, or at least it's not intended. We've been extremely excited about this addition, and it's possible that our excitement may have contributed to the perceived expectations of the Lab.
Does the Lab equal bug free releases? No, in software development there is no such thing. Does the Lab equal more polished and stable releases? Yes and no. In the near term it may be more difficult to see the benefits of the QA Lab, but in the long term it will become more evident. The Lab itself is a long term solution and not a quick fix for the here and now. I think TGB 1.7.5 is evidence enough of that, which we have a fix available for the bug that rendered the binary inoperable by the way.
We learn more and more from each round of testing, and the process continues to be refined. While you may notice some improvements in the near term, the long term is where our goals are set and where you'll see the biggest difference.
And because I noticed that I managed to only take pictures of the Lab only when people weren't in it working, I took this one of Roy yesterday.
#2
05/27/2010 (6:27 pm)
I think some of them might be. I'll ask them about that. 
#3
So now with the QA up and running how about adding ONE dedicated programmer for each game engine, so bug fixxing do not take so darn long? Whats the point of finding bugs when it still takes ages to get the bugs fixed?
05/27/2010 (8:06 pm)
Time to twitter away? Not working them hard enough then!So now with the QA up and running how about adding ONE dedicated programmer for each game engine, so bug fixxing do not take so darn long? Whats the point of finding bugs when it still takes ages to get the bugs fixed?
#4
This kind of segues into an excellent example of near term and long term improvements though as this is near term one.
Over the course of T3D's development a lot of bug reports were submitted by the community. This community attacked those early Betas and Alphas like ravenous piranhas and that passion continued throughout every release. I think it's safe to say that Torque 3D has the highest community involvement than any of our other engines. It simply astounded me and I used to make comments to Mich saying how impressed I was with the community constantly during this time. It's one of the reasons why I love this community.
Now, the problem introduced by this was that there simply wasn't the staff available to handle the sheer volume of community reports. Keep in mind when I refer to the handling of community reports I mean verifying it's a bug, creating steps to reproduce it, and logging it. This can take a considerable chunk of time, which is time wasted when it's done by the people who are supposed to be fixing the bugs or implementing new features. Thus, a lot of bugs unfortunately fell by the wayside.
So, and I promise my long windedness is coming to a point, things that are happening as I type this:
- The entire backlog of bugs, dating back all the way to pre-1.0 Betas, is being combed through and being logged
- James Ford is compiling a list of bugs that the community feels are the highest priority
Things that are happening next week:
- That backlog of bugs will then begin being regressed/verified so that the programmers will have solid list what needs to be fixed
05/27/2010 (8:58 pm)
While I don't know the specifics of some people's assignments, I'm fairly sure that now there is as at least one dedicated programmer per engine. I know for certain there are people whose current task is solely fixing T3D bugs.This kind of segues into an excellent example of near term and long term improvements though as this is near term one.
Over the course of T3D's development a lot of bug reports were submitted by the community. This community attacked those early Betas and Alphas like ravenous piranhas and that passion continued throughout every release. I think it's safe to say that Torque 3D has the highest community involvement than any of our other engines. It simply astounded me and I used to make comments to Mich saying how impressed I was with the community constantly during this time. It's one of the reasons why I love this community.
Now, the problem introduced by this was that there simply wasn't the staff available to handle the sheer volume of community reports. Keep in mind when I refer to the handling of community reports I mean verifying it's a bug, creating steps to reproduce it, and logging it. This can take a considerable chunk of time, which is time wasted when it's done by the people who are supposed to be fixing the bugs or implementing new features. Thus, a lot of bugs unfortunately fell by the wayside.
So, and I promise my long windedness is coming to a point, things that are happening as I type this:
- The entire backlog of bugs, dating back all the way to pre-1.0 Betas, is being combed through and being logged
- James Ford is compiling a list of bugs that the community feels are the highest priority
Things that are happening next week:
- That backlog of bugs will then begin being regressed/verified so that the programmers will have solid list what needs to be fixed
#5
Congratulations to the new QA team, and endeavors to fix such an old squeaking wheel as bug tracking and smashing.
EDIT:
Are you still going to find time for your Community Recaps? A most valuable asset for the times when one is unable to keep up with the current Torque community news.
05/27/2010 (10:46 pm)
Your just full of exciting new news today. Congratulations to the new QA team, and endeavors to fix such an old squeaking wheel as bug tracking and smashing.
EDIT:
Are you still going to find time for your Community Recaps? A most valuable asset for the times when one is unable to keep up with the current Torque community news.
#6
I look back on the bug harvesting and fixing for iTorque prior to his QA work, and it was a nightmare...especially before Luma. I'm sure the iTorque 2D community can back me up on that statement. It's awesome to have a close friend join the team, but I would have been supremely impressed by his recent work even if I did not know him.
When I was visiting Florida a few weeks back, I was thrilled to drive up to Orlando to meet up with him and check out the lab. The rest of the QA team were really cool, friendly, and extremely skilled. Torque QA is in the right hands.
@Scott - Great writeup! Love the pics and excitement you brought to the blog. Now we just need to get you to visit Vegas. I'm thinking we should get all the groomsmen together in Vegas...without the shots of tequila this time =)
05/28/2010 (7:00 am)
Scott joining the team has been a top 2010 moment for me. Having worked with him for nearly two years prior to my Torque job, I can speak volumes about his work ethic, passion for Torque and the company, and unique ability to raise team morale. I look back on the bug harvesting and fixing for iTorque prior to his QA work, and it was a nightmare...especially before Luma. I'm sure the iTorque 2D community can back me up on that statement. It's awesome to have a close friend join the team, but I would have been supremely impressed by his recent work even if I did not know him.
When I was visiting Florida a few weeks back, I was thrilled to drive up to Orlando to meet up with him and check out the lab. The rest of the QA team were really cool, friendly, and extremely skilled. Torque QA is in the right hands.
@Scott - Great writeup! Love the pics and excitement you brought to the blog. Now we just need to get you to visit Vegas. I'm thinking we should get all the groomsmen together in Vegas...without the shots of tequila this time =)
#7
05/28/2010 (7:10 am)
Best of Luck bug hunting, testers! 
#8
05/28/2010 (7:25 am)
I can second Mich's praise of Scott. He has been a powerhouse since joining the team. I told Derek, Stephen, and Mich this when we arrived at GDC and were taking the shuttle to the hotel. I can't think of anyone better to man the lab and keep QA grinding up the bugs! 
#10
I'm glad you asked that as I meant to make a mention of it toward the end of my blog and forgot. The Community Recaps will be returning and I apologize to those that rely on them for their hiatus. Getting the Lab spun up ended up being more time consuming than I originally expected and my community duties suffered for it.
I'm going to do one massive recap this weekend to account for everything that's been missed and then I'll return to the regular schedule again.
@Mich
Thanks buddy! It's a rarity in life to work with close friends so often. A groomsmen get together is definitely needed. Maybe the slots will treat us better minus the tequila this time.
@David
Thanks a lot man. I'll never understand how you managed all the community duties on your own all these years. Personally I suspect cybernetic implants are involved. ;)
05/28/2010 (9:09 am)
@CayloI'm glad you asked that as I meant to make a mention of it toward the end of my blog and forgot. The Community Recaps will be returning and I apologize to those that rely on them for their hiatus. Getting the Lab spun up ended up being more time consuming than I originally expected and my community duties suffered for it.
I'm going to do one massive recap this weekend to account for everything that's been missed and then I'll return to the regular schedule again.
@Mich
Thanks buddy! It's a rarity in life to work with close friends so often. A groomsmen get together is definitely needed. Maybe the slots will treat us better minus the tequila this time.
@David
Thanks a lot man. I'll never understand how you managed all the community duties on your own all these years. Personally I suspect cybernetic implants are involved. ;)
#11
One thing i have noticed today are allot of bug logged: forum thread reply from Full Sail QA&U.
Do this mean that the bug have been verified as a bug or that it is simply LOGGED for future investigation?
05/28/2010 (1:56 pm)
Thats great to hear, about the Community Recaps.One thing i have noticed today are allot of bug logged: forum thread reply from Full Sail QA&U.
Do this mean that the bug have been verified as a bug or that it is simply LOGGED for future investigation?
#12
Now that you mention though, I'll probably have them post in there after they've been verified or regressed so that you guys can know what the status of a bug is.
05/28/2010 (2:12 pm)
That means it's been logged in our tracker so that it can be verified later. The previous practice was to attempt to verify a bug before logging it, now every bug report will be logged first and then verified.Now that you mention though, I'll probably have them post in there after they've been verified or regressed so that you guys can know what the status of a bug is.
#14
Are the Full Sail QA&U team also gleaming unreported bugs as part of The Process(such as bugs inherent to the way of the design of the function)? If so, to what depths do this type of bug searching aspire (beyond testing the systems are basically functional)?
05/30/2010 (12:33 pm)
I had a thought on this subject earlier today. Are the Full Sail QA&U team also gleaming unreported bugs as part of The Process(such as bugs inherent to the way of the design of the function)? If so, to what depths do this type of bug searching aspire (beyond testing the systems are basically functional)?
#15
just a thought: isn't this bug logging via forum threads time consuming and quite messy? IMO it could be a good idea to give access to licensees to the tracking system so to get a proper workflow.
If you see an issue with that then setup Bugzilla as an intermediate tracking system with the ability for your people to import bugs and some script updating it when it's updated on the internal tracking system.
05/30/2010 (4:00 pm)
Hey Scott,just a thought: isn't this bug logging via forum threads time consuming and quite messy? IMO it could be a good idea to give access to licensees to the tracking system so to get a proper workflow.
If you see an issue with that then setup Bugzilla as an intermediate tracking system with the ability for your people to import bugs and some script updating it when it's updated on the internal tracking system.
#16
Another problem with any other system is the fact that no two people seem to have the same view of what a BUG is (minor quirks versus true show stopping bugs versus simple spelling mistakes and cosmetics). If a reporting system was to simple, people would be reporting 'suggestions' as bugs. In any case someone 'official' still would be needed to filter out the real bugs.
Last is the fact that so very often a reported bug is quickly fixed by a fellow community member, sometimes only hours after the posting, or the situations where the bug is actually a manifestation of something bigger and community members collaborate together on a solution.
This community would be stunted and boring without the 'open book' bug reporting system it already have. (besides, reporting bugs was never the problem part of the BUG/FIX system)
05/30/2010 (5:21 pm)
I would think anything more then using the forums to track bugs could easily have way more messy time consuming problems of its own, such as many people swamping the system with the same bug reports because it is (potently) more difficult to see if the bug is already reported, or where it is much more hassle to post the bug so everyone just use the forums and any time spend design/implementing the NEW bug entry system is a backstep. Another problem with any other system is the fact that no two people seem to have the same view of what a BUG is (minor quirks versus true show stopping bugs versus simple spelling mistakes and cosmetics). If a reporting system was to simple, people would be reporting 'suggestions' as bugs. In any case someone 'official' still would be needed to filter out the real bugs.
Last is the fact that so very often a reported bug is quickly fixed by a fellow community member, sometimes only hours after the posting, or the situations where the bug is actually a manifestation of something bigger and community members collaborate together on a solution.
This community would be stunted and boring without the 'open book' bug reporting system it already have. (besides, reporting bugs was never the problem part of the BUG/FIX system)
#17
We've actually discussed internally the possibility of opening up a bug tracker to the community a few times. Caylo pretty much nailed it on the problems with doing so. We wouldn't open our internal tracker to the community so the only option is to set up a completely separate system. The managing of two separate bug databases and moving information back and forth between them would just make the whole process extremely inefficient.
It could still happen somewhere farther down the road, but probably not anytime soon. I'm pretty comfortable with what we have in place now and feel that, for now at least, it's the most efficient method for us and the community.
@Caylo
Absolutely they look for stuff that hasn't been reported by the community. I was only focusing on the community's involvement in the process up there, so I didn't mean to give the impression that we're just verifying and regressing only what the community reports.
When a product comes in for testing I create a whole slew of test cases for it. These test cases cover a wide range of areas from checking installers work correctly, to checking basic functionality, to testing typical problem areas and even some based on how something is typically used.
So while a lot of stuff the team finds may have been found already, they do still find bugs that haven't been reported. There was actually a couple of bugs they found while testing iT2D 1.4 that I was surprised weren't found by the community first.
@Johnny
Hey, someone had to take the pictures. =)
@Donald
It turns Robert is on Twitter, his Twitter is CreatorRob.
05/30/2010 (8:54 pm)
@PinoWe've actually discussed internally the possibility of opening up a bug tracker to the community a few times. Caylo pretty much nailed it on the problems with doing so. We wouldn't open our internal tracker to the community so the only option is to set up a completely separate system. The managing of two separate bug databases and moving information back and forth between them would just make the whole process extremely inefficient.
It could still happen somewhere farther down the road, but probably not anytime soon. I'm pretty comfortable with what we have in place now and feel that, for now at least, it's the most efficient method for us and the community.
@Caylo
Absolutely they look for stuff that hasn't been reported by the community. I was only focusing on the community's involvement in the process up there, so I didn't mean to give the impression that we're just verifying and regressing only what the community reports.
When a product comes in for testing I create a whole slew of test cases for it. These test cases cover a wide range of areas from checking installers work correctly, to checking basic functionality, to testing typical problem areas and even some based on how something is typically used.
So while a lot of stuff the team finds may have been found already, they do still find bugs that haven't been reported. There was actually a couple of bugs they found while testing iT2D 1.4 that I was surprised weren't found by the community first.
@Johnny
Hey, someone had to take the pictures. =)
@Donald
It turns Robert is on Twitter, his Twitter is CreatorRob.
#18
And no, I had not formed any impression on the subject of gleaming unreported bugs, is why i was curious as to how hard the Full Sail QA&U team test things.
05/30/2010 (9:23 pm)
Ah very cool, good to know the level of detail used. And no, I had not formed any impression on the subject of gleaming unreported bugs, is why i was curious as to how hard the Full Sail QA&U team test things.
#19
While attempting to keep two different bug tracking databases is most defiantly not the answer, that is in effect what you have here with the forums only the forums do not allow us the customers to better find resolutions to bugs and track ones we have already submitted. When new patches come out we do not get concise patch reports listing each bug tracking number that has been resolved because of this patch.
While I greatly love the logged posts from the Q&A team which shows that things are happening in the long run this does nothing to help me the customer. I highly doubt anyone is going to come back and post the resolution to that logged post into the same thread, so if it cannot be duplicated or you need more information how will that be resolved?
In fact if you want to speculate on what a mess an open tracking system would be with people posting incorrectly to things (which ones again they do now anyways, I almost always forget to tag my posts because I just don't think of the forums as a real bug system). Then I would submit that by seeing a logged post on a thread that some community members will decide that there is no need to discuss a resolution to the problem because in many eyes logged could easily become a synonym for "will be resolved". So if it is not an immediate need for me well GG will get to it and I don't need to look at a way to fix it.
Not saying this WILL happen just saying that you can only make systems so good and with them there is always a need for someone in authority to be in direct flood control of it (i.e. moderators in case of forums)
As in my other post I would direct you to look at DevExpress (It is a VS plugin company) they have both a peer to peer forum and this excellent tracking system - is it the same as their internal one? Probably not but I suspect that it can feed directly into their internal one and allows for an easy user experience.
devexpress.com/Support/Center/
Just some considerations to add to the discussion.
06/01/2010 (9:50 am)
Since I was directed towards this thread, I thought I should add to the discussion.Quote:
We've actually discussed internally the possibility of opening up a bug tracker to the community a few times. Caylo pretty much nailed it on the problems with doing so. We wouldn't open our internal tracker to the community so the only option is to set up a completely separate system. The managing of two separate bug databases and moving information back and forth between them would just make the whole process extremely inefficient.
While attempting to keep two different bug tracking databases is most defiantly not the answer, that is in effect what you have here with the forums only the forums do not allow us the customers to better find resolutions to bugs and track ones we have already submitted. When new patches come out we do not get concise patch reports listing each bug tracking number that has been resolved because of this patch.
While I greatly love the logged posts from the Q&A team which shows that things are happening in the long run this does nothing to help me the customer. I highly doubt anyone is going to come back and post the resolution to that logged post into the same thread, so if it cannot be duplicated or you need more information how will that be resolved?
In fact if you want to speculate on what a mess an open tracking system would be with people posting incorrectly to things (which ones again they do now anyways, I almost always forget to tag my posts because I just don't think of the forums as a real bug system). Then I would submit that by seeing a logged post on a thread that some community members will decide that there is no need to discuss a resolution to the problem because in many eyes logged could easily become a synonym for "will be resolved". So if it is not an immediate need for me well GG will get to it and I don't need to look at a way to fix it.
Not saying this WILL happen just saying that you can only make systems so good and with them there is always a need for someone in authority to be in direct flood control of it (i.e. moderators in case of forums)
As in my other post I would direct you to look at DevExpress (It is a VS plugin company) they have both a peer to peer forum and this excellent tracking system - is it the same as their internal one? Probably not but I suspect that it can feed directly into their internal one and allows for an easy user experience.
devexpress.com/Support/Center/
Just some considerations to add to the discussion.
#20
06/01/2010 (12:25 pm)
@Joseph - Can you check your e-mail, please? You appear to be having some trouble posting, or someone has your account. We have messaged you to help resolve the issue 
Torque 3D Owner Donald "Yadot" Harris
Marveloper