The limit on the number of shirts might be the issue. Did you consider removing the speed component of this?

> This year, the first 70,000 participants who successfully complete the challenge will be eligible to receive a prize.

How about choosing 70,000 participants at random? Or any other criterion that doesn't encourage quick content-less contributions?

Hi Andrenotgiant - Could you not limit submissions to only labelled issues? That way it’s opt in and you reduce spammy PRs.

Many maintainers put “Hacktoberfest” labels on issues they’re happy for newcomers to work on.

We could change it to be opt-in only, but the participants who are creating spammy PR's have already shown they don't read rules, so I think they would continue to create the same PR's.

That's why, to deal with the immediate issue we're creating an obvious, even lower-effort route for the impatient participants to take (follow a guide to create 4 PR's on your own repo) - and longer term we'll make bigger changes (maybe including an opt-in only model) that solve the perverse incentive issues that seem to be driving this PR spam.

this tweet: https://twitter.com/MattIPv4/status/1311425661840613377

suggests to me that DO expected that maintainers would email DO about spammy users. is that the case?

We have a system to invalidate spammy PR's, but not spammy users.

The problem with most "spam flagging" solutions is: 1. They only kick in _after_ the PR is created and the maintainer's time is wasted. 2. In some cases they might actually cause more harm than good. A user is flagged for spamming, gets blocked, creates another account and spams some more... etc.

For that reason we are focusing our efforts on just re-routing these impatient users into guides that have them creating PR's on their own repos.

Long term we are definitely committed to updating the program to make sure it's delivering on the mission of getting people positively involved in open source.