F. Bravo, although I've no evidence to go on, it could well be that those users who, as you mention, have received 10/15 WU's, could have several machines with upwards of dozens of cores available to them - thus, the more cores they've got available, the higher the chances of them being able to pick them up.

Another aspect of it, is when (as we currently do), we have projects such as HST & FAH2 where there's a limited supply of WU's available, people can simply select these projects knowing that, when their BOINC sessions request work, the only WU's that they'll pull back, are Beta WU's. Thus, if they're "in the right place at the right time", they can set their machines up so as to raise their chances significantly for getting some Beta WU's.

I don't know when you joined the Beta programme (and I can't just recall when it changed), but originally there were no restrictions at all as to how many Beta WU's could be pulled down for one particular core. Nowadays, a limit of "one Beta WU/Core" is set - thus helping to spread the work units around a lot more.

PS. I, too, am in the Beta programme, but (as yet), haven't received any Beta WU's this time around. What doesn't help my cause, is that I've currently got SCC set as a project - thus, my buffers are constantly being topped up on their first request.

F. Bravo, you do have a lot of valid points and I'm sure that there are numerous different ways a fairer system could be brought about (that is, if WCG have the time/resources and inclination to investigate/implement it).

There is though one drawback to restricting 1 Beta WU to one user (or even to one machine - no matter as to how many cores it's got), is that the project won't be tested running more than 1 Beta WU on a machine that may have 8, 12 or 16 etc. cores, and thus, any problems this could cause when the project is rolled out with no restrictions, won't be spotted (case in point, CEP2, where running 1 WU didn't cause many/any issues, but running 4 or 8 at a time, generally did).

One potential solution, could be to, as well as having the 1 WU/core restriction, could be to restrict that machine to only have 1 WU/core per 24 hrs (or wave of a Beta test). This may/may not have any effect - particularly the 24 hr restriction - as most Beta tests only have WU's available for a very short period, and thus, by the time a WU has been crunched and returned (thus, freeing up a core for another Beta WU), they've probably all been sent out.

F. Bravo, after quite a bit of digging around, I've found the announcement from Kevin Reed on the 22nd of March 2010, announcing the 'new' policy (as, back then), of 1 WU/core. The link to it is here Before then, it really was a 'free-for-all' (as can be read in the threads from way back then, with numerous "tips and tricks" to get more Beta WU's). Of course, back then, there wasn't the proliferation of computers with multiple cores as we have now - I only had 2 cores available to me in my 1 laptop, as opposed to the 8 cores I've now got at my disposal.

Now, before this new policy was implemented, I didn't know what was possible (and I still don't), so a lot really depends on what can/can't be implemented and as to how much resources it'd take to implement (or even, if WCG see this as something they want/need to look into). I also don't know as to;
a) how many active members are signed up for the Beta programme (i..e, who's returned a WU in the last month),
b) how many cores are available from these active members, and
c) how many Beta WU's are made available for any one round of testing (this, of course, will no doubt be a fluid number depending on what they're testing etc.).

Thus, as you quite rightly pointed out (and I inferred), limiting Beta Wu's to 1/core/24 hr window may not actually be sufficient to 'spread the load' (i.e. there may be far more cores available than Beta WU's), thus another approach would be needed. One possible way, could be to group possible available Beta cores into groups of (say), 1,000 cores (Beta-A testers), then the next 1,000 into Beta-B testers etc, and target each round at a different group of Beta testers. Of course, this may need some development work form the WCG techs (and of course, as with everything, they may not see this as a high a priority issue compared to the many things on their endless "to do/wish" list).

So, really, we can discuss this 'until the cows come home', but, until we get some feedback from the WCG techs, there's not really a lot we can do other than come up with and discuss suggestions.

It's not possible to achieve a system that is viewed as "fair" by everyone. Fairness depends on each individual, and some could argue that "one Beta WU/user" is not fair at all.

Some users have server farms with 100s of high clockspeed cores. They run 24hrs/day, 7 days/week and can return beta WUs within hours. Others have a single low power core and run for a few hours on weekdays only - taking a week to return a single WU. Science output at WGC would be impaired if both are allowed 1 beta WU per user.

The current method is already quite meritocratic:
1. Already limited to 1 WU per core. At the same time, we receive more WUs proportionally to the computing resources we dedicate to WGC. It's also an incentive to add multiple / more powerful machines.
2. Machines that run 24/7 complete more WUs (naturally!). So they contact the server more often to report completed work. In doing so, they have a higher chance of finding beta WUs. One can improve chances of getting beta WUs by running 24/7, at the same time WGC also gets more science done - win/win!

To make it even more meritocratic:
A batch of beta WUs can be broken down into 48 parts and released every 30mins over a 24hr period. (1) reduces the chances one user gets a large cache of beta WUs because he just happened to check the server when a new batch was released. (2) many projects originate from the US, and researchers release new WUs during their working day. Users on the other side of the world miss out if their machines are turned off over night.

In my view, tweaks need to maintain the principles of meritocracy. Instead, aim to increase fairness by targeting the "chance" factor of getting a beta WU.

Honestly, we just need to increas the volume of WU produced. Taking a look at 2 Betas I was able to snag this wave, they had Min. Replication of 1, and both were run on Windows 10. If I was doing it, I would have AT LEAST 1 Windows 10 use, 1 Win 8, 1 Win 7, 1 Linux and 1 Mac per WU (assumind Mac is supported).

Afterall, this is BETA. It doesn't really matter if tests are redundant, the purpose is to make SURE that they are working.