***Compromise*** I Propose a Compromise between Option 1 and Option 3: You start the contest within 2 weeks. However, you shift the midterm date to a solid date that gives more time before the final contest entries are due. (Say 3 weeks instead of two, 4 weeks instead of 3, etc..) ***Bug Reporting*** You create a system for reporting errors, sorted by error type: Visual artifacts, API errors, exit crashes, will not run, sluggish, etc.. Have a form for filling out errors with pertinent information (reproducible, num times reproduced out of 10, error category, brief description, actions preceding crash/error, video card, CPU, memory, OS, etc…) and sort the forms into the categories like a mailbox. None of the mail/entries would be replied to and APs wouldn’t have access to the form. Have the moderators (not you) pitch in for collating data by simply entering the data into a database (access) or spreadsheet (excel) program sorted by error (one error, one table :or: one error, one sheet). Each moderator would have their own sheet/database to maintain and they could upload the updated versions when necessary. You would only ever have to read and target yourself based on the data. The moderator’s only channel of communicating bugs would be the datasheets (i.e. don’t respond to their specific questions either). The Common Problems could be dropped into a locked Forum and you can have a solutions page linked at the bottom of every problem post. Each Moderator would also upkeep a respective FAQ section to fix known bugs based on your directions or community feedback. This allows them to increment the count of people experiencing the same problem without having to retype in data into already addressed bugs. Send them a generic page to edit/update. ***FAQs*** The FAQ section would be sorted by Arena Executable Iteration. A Minor build number would be an easy idea to help sort the FAQ section. Then, on the download page, the newly fixed (whole) executable would be available for download and then a separate download for fixes to upgrade from the previous iteration. Every time you minor built the Arena, you simply update those two zip files. Inside each iteration, the sections would be sorted by problems (Visual Artifacts, exit crashes, etc…). This would allow you to link to the pages up kept by the various moderators. Persistent problems would simply carryover (or be linked to) in the new iteration FAQ. ***Midterm Date*** The week before the midterm date, you look at the major problems and weigh their impact on the contest. Also, do a Poll to determine how many people are actually entering the contest. Then, take the number of people from the database that cannot run the executable and want to enter the contest (put that on the error reporting form) and divide it by the people who are entering. Or you can put that on the poll (I want to enter, but the Arena Crashes). If the result is greater that 50% then you may want to scrap the prize and do the contest for fun. Otherwise, lock the build and concentrate on building the entries and contest pages. Also, scrap the previous iteration FAQ pages and require the latest iteration for development. That’s roughly 3 weeks of data gathering to see if the contest is viable while receiving feedback. That means you can spend the next two weeks preparing for the feedback and the start the contest with a disclaimer that it might not continue. Advantages: · The contest starts within the next 2 weeks. · The core of the arena works well. It''s just the presentation that needs work. · We get immediate feedback on: the arena executable, the arena interface, and the contest format. · Everyone gets a chance to give their input to make a better product (product being the contest). · Everyone tests the current arena for the contest, as well as the new arena for feedback. Disadvantages: · The arena executable may not work properly for everyone. · The defects everyone has been seeing with the download, for the most part, will remain until a later date. · The contest may be postponed.

Even if the idea isn''t taken as a whole, some of the components are workable into helping beta test the application.

Who wouldn''t want an FAQ or a bug reporting system?