Having run into this on HPF2 already, I'd suggest that beta WU errors not be counted against our daily WU quotas, or beta testers will have a tendency to get their work supply cut off.

For that matter, since so many of our WUs will end up being errors through no fault of our own, I agree with Sekerob's earlier suggestion. I think all beta WUs returned should be granted full credit whether there's an error or not, so that our scores (and our teams) don't suffer for our beta participation.

Also, testers will probably be more willing to let misbehaving WUs keep running if there's no penalty for lost time if they end up failing.

I'm running one of the remaining hpf2 units now and it seems to be stuck for the last half hour at a certain percentage. Also, the completion time is increasing, instead of going down. Can I expect this unit to complete? How long do I let it run before giving up? Thanks.

p.s. I see that two people have sent the unit in with errors already and there are a few pending.

didactylos,

Thanks for the reply. It actually just completed so all is well :)

Splitting this thread into 3 parts is a reasonable alternative to using a "report page". I could easily live with that but I'm hoping for a "report page" for reasons given in my previous post. In any event there should be a read-only thread just for announcements.

I've put togther 2 simple report pages that WCG is welcome to grab and use any way they like if it saves time rolling their own. Both forms do much the same thing, they differ mainly in appearance and the encoding of the name/value pairs in the reports. No, my feelings won't be hurt if they don't get used, they may not even be suitable for the kinds of reports WCG needs.

If they are suitable but need a few modifications I am willing to do that. I could also write some Javascript to verify the user's input to make sure all required fields are filled in.

The password on form1 may deter "evil-doers" from submitting hundreds of bogus reports for whatever twisted reasons they do such things. If the form were accessable only to users who have logged in then a password on the form is not required.

The form is submitted using a simple action=mailto:. Reports using action=mailto: are difficult to read when the enctype=default but my sample forms use enctype=text/plain so the reports are much easier to read. I prefer form2 because the fields in the reports it submits are arranged in a more sensible order compared to reports from form1.

The 2 sample forms are viewable at form1 and form2.

Beta testers should not use these 2 forms at this time.

Great work, dagorath:)

Password needn't to be submitted if report is sent from "my grid" page, isn't it?

It's better if each tester can check whether the same kind of error has been reported like Windows do, which requires servers to analyse the error. But this kind of measure should be taken when soooo many people participate to beta test.

And in making reporting sheet, many platform should be considered. There can be someone who uses linux on Command User Interface.