Never going to write the FAQ or Wiki for this one, an alternate highly secret "taking tiger mountain by strategy" is to assess what the resource needs are of the beta, select a project with the largest such as HFCC (oops), then reduce the memory permissions. The servers will tell you, the client ain't gonna get any. This requires advanced noobie skill.

It's because you've been volunteered to penn it down. That forces to ponder and research how things really work ;>)

Or as the rule goes:

5% is remembered when listening,
10% is remembered when reading,
30% is remembered by writing,
90%+ is remembered by teaching.

PS: Writing is 5% of the work, 95% goes into the testing if it's true.

We're looking forward to your contribution and the hearty reviews

(Think it's unfair to publish a "how to" manual as else no one will get beta who's not sitting on the perch all the time.)

You have a point there. Now in order to mess things up, all can consider this when reading my above posts: I can say, hand on my heart, "I am incapable of telling the truth."

Have fun pondering that one

Of course, there is a way that can not fail. I don't know why I didn't think of it but becoming a tech should be failproof. Sitting on the perch: good camouflage of your ideas!

Well, you might... but what good does it do to buffer 10-days-worth of WUs if they have a 4-day deadline?

Fellow crunchers, I think we should think about the beta work from the point of view of the techs.
If I were them, I'd want to do tests in 2 directions:
Direction 1). Test WUs having a wide range of different input parameters, to test whether some WUs will be troublesome, independent of the crunching device. Sending work to a narrower range of fast devices would be OK for this phase. If you have a fast machine, you could justify grabbing a little extra beta work here by reasoning that your return times for all WUs will be sooner than the fleet average because your machine is fast, and you are manually controlling your BOINC queue to give beta work priority. That would help the techs find problems sooner.
Direction 2). Test as wide a range of crunching devices as possible, to see whether some devices catch errors. This is where keen badge-hunters should refrain from grabbing more than their share of the work, to let many of the slower machines, which fetch work less often, get some work. As an example, in the recent HCMD2 betas, some AMD notebooks gave very slightly-different results to the rest of the fleet. If these rare beasties had been unable to get work, this problem would not have been found until the HCMD2 production stage.
If I was a tech, during Direction 2 I'd dribble the beta work out very slowly, so that greedy badge-hunters who spot a beta WU arrive and immediately increase their queue get only production work ...