This is what Hacktoberfest should have been from the start. A company incentivizing pull requests against your repo should require your consent. A maintainer needs to affirmatively sign up for this sort of work; they can't have it thrust upon them. As a maintainer, all the other half-measures people have suggested (e.g., accepted PRs only; account age measurements; filtering out README changes) do not actually reduce the unasked-for burden on me.
That said, I'm not sure this year can be salvaged. It's not clear whether all the existing spammers will get the message. I hope DigitalOcean emails all folks signed up to notify them of this change. (They haven't communicated any of their changes so far in such a way.) Notably, a day ago, the DigitalOcean staff thought this wouldn't make a difference. [1] And it's even possible this will just result in issue spam begging maintainers to add the Hacktoberfest topic.
But it's also possible that this will work out. The best version of this is that low-quality contributors looking for a t-shirt get directed toward honeypot repositories, and folks interested in making substantial contributions will continue using issue labels like GitHub's own "good first issue", or the Hacktoberfest repository topic, to find places to contribute.
> That said, I'm not sure this year can be salvaged. It's not clear whether all the existing spammers will get the message.
I think the biggest problem DO will have to address somehow is that Hacktoberfest now has become such a big event that they are getting attendees which they strictly speaking do not want to have, and the liberal “everything is open for everyone”-approach is now too open for the “game” to work.
Finding a way to encourage (new) people to contribute to open-source projects while at the same time keeping the bad people out (opportunists, spammers, etc) is not going to be easy. Locking things down (like only opt-in repos count) will severely limit genuine contributions way beyond just spam.
Whatever they end up doing, I suspect we will see Hacktoberfest 2019 as peak Hacktoberfest and from now on the event will be a mere shadow of what it used to be.
> Finding a way to encourage (new) people to contribute to open-source projects while at the same time keeping the bad people out (opportunists, spammers, etc)
This is the challenge of our time, TBH. From the Eternal September onwards we’ve struggled to sustain community quality in the face of infinite connectivity. You start open & welcoming, but eventually you get overwhelmed with new folks and you can’t socialize them fast enough to preserve what was attractive about your community in the first place.
This is the work of institution building. It’s not easy. The best examples I’ve seen are HN, Lobste.rs and some focused subreddits. All of these have strong mod teams and spam controls.
Essentially Hacktoberfest turns repo maintainers in to human spam filters who decide if Digital Ocean should send someone some marketing swag. Companies shouldn't be doing that to every open source maintainer. It isn't fair on them. That should only happen if the maintainer is happy to do work on Digital Ocean's behalf.
The problem is people aren't incentivized to help, they're incentivized to get free stuff. So people who have no interest in helping are doing the bare minimum to get free stuff, which is a much larger number than the people actually wanting to help.
In your scenario, it would be like incentvizing "donating a vial" and hoping it will be filled with blood, but 99% of people are donating an empty vial.
"Anyone" does not scale infinitely: it only specifies who might participate, not how many can. Each project will collapse — lose work for one day or more — under a certain sheer quantity burden of pull requests. When people say "anyone can", they don't always mean "everyone do so all at the same time", as happened here. The term "anyone" makes no statement about the frequency of pull requests, and everyone is generally upset about the frequency of pull requests associated with a third party action (Hacktober). Rightfully so: their time is being wasted and their expectations of reasonable behavior are being violated.
Others have a different experience than yours, that is both negative and not improved by the “ignore them” process that works for you. I encourage overcoming the difficulty you describe.
I would argue that having your repository on github is a strong way to say "feel free to contribute". Not saying spam is OK, just that having to ask repo maintainers their authorisation seems superfluous.
How are they different as long as they are not spam? Good contributions are good contributions and help, regardless if there's a crappy t-shirt or not in exchange for them
It's the incentive structure. It's effectively Goodhart's Law in action: When a measure becomes a target, it ceases to be a good measure. In this case, the measure is "number of pull requests", and the result of making it a measure is that people created an insane number of PRs that simply adjusted white space in a README or slightly reworded phrases but kept the exact same meaning. Because they wanted the T shirt, because they felt that it validated them as a developer (ignoring that good contributions would have been a much better validation).
They don’t, but they should if they intend to use me as part of their marketing campaign that could lead to spam on my repos and pissing me off isn’t one of their goals.
And to make matters worse, the onus falls on the maintainer to mark a PR as spam. This honestly feels like a DDoS attack on open-source rather than promoting open-source.
I don't think there's any way to save this.
EDIT: I think DigitalOcean completely missed the point on promoting open-source. It's not about the PRs. It's about everything that goes before you submit your first PR. Reading mailing lists. Actively participating in discussions with the maintainers. Reading the docs. It seems like they wanted an easy way out to promote their brand without putting in the effort to review the PRs and filtering out spam by raising the bar on what qualifies for a PR (i.e. not requiring all the leg-work for writing your first PR).
I am surprised too. Reputation is important in OSS and when applying to jobs (which I assume some would want to do, or already have). I would raise an eyebrow a bit if I were reviewing a candidate and found all of their PRs on GitHub were spam.
90% of people who apply for a programming job have no chance of getting it. These are the people who are spamming repos, not the 10% with any budding talent.
Don't get me wrong. I am not saying DO is a terrible brand. I am just saying this was not very well thought out for such a wide reaching event. It just makes me question their motivation.
I’m not sure it’s as badly thought as you are suggesting it is. More like someone found a way to game it and promoted the crap out of gaming it (we even know who the someone and their videos are!).
I've made a bunch of PRs to projects that I happened to use but encountered bugs in. Likewise, I've received similar PRs (and issue reports).
I believe that all those were valuable even though they did not involve close participation in the project. But I have not always done that: only after learning how low the barrier to entry was by doing it the first few times, does the thought of submitting a PR now arrive automatically when I encounter such a situation.
> It's not about the PRs. It's about everything that goes before you submit your first PR. Reading mailing lists. Actively participating in discussions with the maintainers. Reading the docs.
I've only had 5 or so PRs accepted[0], and all of them have been tiny bugfixes for broken tools. I have no goddamned idea how to get an actual feature merged, because maintainers never comment on the proof-of-concept PRs I put up, even if they have tests and documentation updates. Maybe it's all about mailing lists and out-of-band communication.
Unsolicited advice, please feel free to ignore; hopefully you'll be okay with it:
Bug fixes tend to not need justification (since the maintainers presumably already agreed), but new features depend on the maintainers agreeing that they want it in the project. Before making the PR, try to find the relevant issue (or create one if it doesn't already exist), and get the maintainer to indicate that they want the feature. Once they've written that down, they're primed to accept it because they'd feel worse about not processing the thing they already committed to.
Reality is that giving you such feedback on proof of concept work takes effort, time and is work. As such maintenence needs reason to spend time with it.
Do unless you see them engage with past pull requests like that, assume they don't.
Yes, I remember reporting a user some years back (not related to hacktoberfest) - the PR I got looked good until I looked up their account and found too many PRs (some of which didn't make a sense to the repo it was submitted) along with a link to their product. GitHub took action, said it was indeed spammy and thanked for reporting.
First time hearing about GitHub not ignoring a spam report.
Me and other maintainers of a project have reported a dozen users making obvious junk PR and issues containing few random words and all other activity similar random junk. GitHub did nothing, no response beside automatically generated one, spam accounts still there. The spam came in waves 3-6 within an hour, with only option temporary block all external contributions from non team members. After getting temporary blocked the spam reapers few months later. I assume that's some kind of fake account farming.
May be things have changed now that GitHub is much bigger than it was few years back? Account farming and/or whatever else, this will be ever changing cat and mouse chase. Which means plenty of custom settings and rules and stuff, making it difficult for genuine contributors.
Switching to opt-in is the right call here to limit any further damage. Meanwhile, it's painfully obvious that the whole thing is aimed to be a "low-touch" / "fully automated" campaign where the participation rules are designed around that goal. Makes sense -- it's easy to scale, etc. However now it's clear that the outcome is the polar opposite of GSoC, where participating in GSoC has prestige and produces high quality oss contributions, and it's facing an unwinnable battle against an internet army looking for the minimum effort end-run around the rules to extract a tshirt...
So, my take is that DO should take a longer view and try to raise the profile of Hacktoberfest by making it more exclusive -- eg take a step toward GSoC. For ex, there are a handful of oss-bounty sites (bountysource, issuehunt, etc) where people post bounties for things they want implemented. Could DO partner here in some fashion? Such as matching bounties in a certain range ($10<x<$50?) with a tshirt? Or matching bounties? Make it a year-round promo instead of one month?
The cognitive dissonance here is that DO want to give the low-quality contributors a t-shirt.
These are Indian students with good hustle and poor technical skills who market themselves as technologists. They're going to be managers making purchasing decisions at tech companies in a few years time, and they lack the technical sophistication to choose between DO and competitors on axes other than "I've heard of them"/"they have a good reputation"/"they gave me a t-shirt once". These customers are both more valuable and a thousand times more numerous than the ones capable of earning even a $10 bug bounty.
I'm generalising here, but hopefully not racially stereotyping too much.
So in your mind, hacktoberfest's marketing strategy isn't "let's sponsor a big public pro open source event so we get lots of good rep especially among open source enthusiasts and potential hires"... But instead it's some weird ass 5 year long-play betting that random indian students will, in the future, have purchasing power to choose Digital Ocean because they got a free shirt half a decade prior.
People are constantly (and rightfully) on companies' asses talking about how they need to "give back to open source". Now you're telling me things are fine as-is. They're not.
If they want to give back to open source, they could use the money they're spending on seventy thousand t-shirts to sponsor projects or pay maintainers.
But it's still nice to get some recognition. And it would be a better play for DO. If they sent out 100000 t-shirts to those people who made the most accepted PRs over the last year, they'd hit a lot more longterm contributors and also get a better bang for their marketing buck.
Maybe their original plan was to build good will in the Open Source community. But it's a story of bad incentives: the bycatch turned out to be valuable and now they find it difficult to change their methods (as evidenced by their extremely anaemic response to tackling the problem).
No, of course not. I wasn't implying DO were targetting Indians (and didn't read parent as doing that either). My point was that Indians are the ones that are mainly responding.
I created an issue on one of my repos. It's a really simple set of scripts that manipulate some muni data. I asked for an update from stale data sources/scripts to more recent stuff. Exactly the sort of thing that's great for a first-time contributor -- zero dependencies, small code base, well-scoped issue. I could do it myself in ~10 minutes of work, but figured it'd be a nice chance for someone else to get a first experience working with GH and maybe get a free shirt.
I got one PR that did exactly what I asked. Great, merged! Good experience all around -- exactly what I expected!
Then I marked a PR "invalid" because they made changes to a README that weren't helpful (in fact, actively misleading!). Clearly low-effort PR spam. BTW, the same low-effort PR spam I'm also getting on a bunch of other repos where I didn't solicit help.
And now, because I marked unsolicited incorrect changes to a README file as "invalid", I'm getting new pull requests calling me an asshole.
So... that's my experience with Hacktoberfest. I guess it's my fault for assuming the outcome would be anything else in the month after the Eternal September. Especially with free t-shirts on the line.
I applaud what D.O. has done in a very short time to try and fix this with the community. I do however think that this could also backfire. I entirely agree with the comment made on the PR by sylveon https://github.com/digitalocean/hacktoberfest/pull/596#issue...
I'm not a fan of this change because:
- It significantly reduces the pool of repos that you can PR to. I've contributed to repos which haven't explicitly opted in to Hacktoberfest this year and in the past as well. Repos in which I am more comfortable contributing in than some random GitHub search result for the "hacktoberfest" tag. With this change, I am forced to look into those, or convince the maintainers to tag their repos.
- For intermediate or experienced programmers it voids the whole event because the vast majority of OSS projects won't get involved.
- After the spam fest that this year was, people aren't inclined to add the tag to their repos because it paints a target for spam over them.
- Maintainers can now gatekeep your contributions, so even if it's something meaningful the maintainer can deny you a +1 PR for your work. It can be frustrating spending a non-insignificant amount of time to get the t-shirt the right way and then have that time nullified.
- It doesn't address "hello world" spam repos. In fact, it encourages them because of the reduced amount of repos available to contribute to.
> Maintainers can now gatekeep your contributions, so even if it's something meaningful the maintainer can deny you a +1 PR for your work. It can be frustrating spending a non-insignificant amount of time to get the t-shirt the right way and then have that time nullified.
As someone else replied, if you say you are making a significant contribution but the maintainer says you are not, you are not. If you strongly believe the maintainer is wrong and care enough, forks are always there.
Would also like to note that "putting a non-insignificant amount of time" is also not a valid premise for contributing to OSS, what counts is your actual contribution, not the time you spent making it. (e.g. for a given fix, it doesn't matter if it took 1 min or 10 hours, what matters is other things like the quality of it).
> With this change, I am forced to look into those, or convince the maintainers to tag their repos.
That is a very false premise. You can help any open source project! That's the spirit of open source! It'll make things better for you and for others. Now, if you want that free t-shirt, sure there are rules. But no one is "forcing" you not to contribute to OSS. All of the points here seem based on this false premise.
Hacktoberfest is an event intended to help people contribute to Open Source. Based on this, the statement is false. If your only objective is to get a t-shirt, sure then it limits you. But if your objective is contributing to OSS, nothing is stopping you of making meaningful contributions! The only change is getting the t-shirt, but sylveon's comment sounds a very generic statement so wanted to clarify that open source actively welcomes contributions.
I posted something similar in the other thread about this. This change probably kills Hacktoberfest imo. What maintainers would want to subject themselves to spam PRs by opting-in. Anyway, I feel like allowing PRs before this point to count as valid is a bad idea. I would guess that 70k people already submitted 4 spam PRs in their own repo by now following the tutorials that have been posted for this.
I have a Pebble smartwatch app[1] that only I have ever worked on (aside from one PR to change an icon). I don't really expect anyone else to contribute, but it would be neat.
I just opted it in to Hacktoberfest. Best case scenario, I actually get a great PR because someone was looking for Hacktoberfest-eligible repos and thought my app looked cool. Worst-case scenario, I get a bunch of spam PRs that I reject—but since I basically never get any PRs, this doesn't seem like such a huge problem.
I suggest adding the hacktobefest label to issues you'd like to see tackled. Many people search for `label:hacktoberfest language:Rust is:open` or the likes to find projects to contribute to. I have not found a way to search for repos with a repo-tag yet.
I personally wouldn't participate in Hacktoberfest after this. I'd never want to be seen wearing the t-shirt they'd give out after all the spam and drama. At this point wearing it would probably give the wrong impression to the people who are actually invested in OSS.
As a full time software documentation writer, all I ever do on github is correct docs and text (because nothing looks more unprofessional than terrible spelling, especially in your UI, expect maybe for when the directions are wrong and don't work)
I've just checked and am now running at over 40 rejected changes, many with really offensive comments added to them.
Open source developers often come across as very rude and argumentative and this sort of response to legitimate fixes kills any interest I had in helping. Looking through some of the projects I they are also treating code changes the same way. I'd suggest that that future hacktoberfests will have much less participation
As someone who can't be bothered to fix such stuff in documentation, I would like to wholeheartedly thank you for doing this. Please do not get discouraged by the fallout from the Hacktoberfest mess, people everywhere seem to be short on patience right now. I'd suggest taking a break, and maybe start giving PRs next month :)
If you encounter spelling errors or grammatical issues, please help fixing on https://github.com/sirixdb/sirix and https://sirix.io :-) I'm no native english speaker, so I'd be very happy if people fix stuff.
As an OSS maintainer I’m _very_ happy when people correct my spelling/formatting and make the docs look better. Please don’t let a couple of twats ruin your motivation. What you’re doing is really good for the community!
I'm a participant with 2 PRs merged so far. I totally support the opt-in mode, but at the same time discouraged from continuing further (contributing to repos with the hacktoberfest topic, not open source in general).
1. I think the opt-in should have been there at the start. Repo maintainers should have been informed, and given ample time to decide if they want to participate or not, so that participants are likely to have a wider range of repos to choose from. From the organiser's POV, it will help them to measure the impact of this event on open source events. However, this doesn't seem to be planned at the start (didn't happen in the past years either?) The explanation I can think of is that either they didn't have a nice talk with GitHub to get their support, or like many ppl have said, it's more of a publicity stunt.
2. It could have been done with better communication. If not for this HN thread, I wouldn't have known the change in rules. No email sent. Even the official website still has rule sections that say any public repo will work.
3. I'm discouraged to participate further. I do love the t-shirt. I'd be lying to say that I wasn't motivated by the shirt from the start. I also wanted to beat the crowd by making PRs early by sacrificing my time for other hobbies/work. However, I made PRs that are welcomed and the maintainers were happy to merge. But now I feel the shirt will only bring me the suspicion and disgrace of potentially being a spammer.
4. I don't have many choices of repo to contribute now. In the hacktoberfest topic, there's 0 repo in my preferred language. The first repo I see with the highest number of stars is some algo repo. The 2 repos I've contributed and likely to contribute again are not qualifies anymore.
There are still good things from my experience. I have made PRs before, but I'm not actively contributing. I'd rather spend my free time on other hobbies. But now, I do see that I can find joy in open source. I'm likely to contribute to repos that interest me again in the future.
I understand why this change is needed - jerks often ruin things. But I hope that DO will refine the approach a bit, as opt-in-only will probably kill Hacktoberfest for me.
The intersection of projects that I use or care about, the projects that are in a language that I'm interested in using (or even learning), the projects that are on github, and the projects that will actually opt in even after the events of the last few days, well... I'm guessing that set is going to be pretty small. Quite frankly I don't want to spend more time searching/scrolling through github trying to find contributions to make than I do actually contributing.
Of course, none of that probably matters, as I realize I'm not the target audience for Hacktoberfest: I regularly contribute to open source projects. Whether or not I get a t-shirt won't change that, but I'm not going to lie - I've enjoyed getting the shirts (and stickers!), and wear them often. They can be good conversation starters, and it's also nice to have a tangible reminder of my contributions, since so much of what we do in this field is completely intangible. Though, to your point, the potential implications of the t-shirts going forward may change my feelings on wearing them.
And I completely agree w/r/t to communication. Earlier today I made a PR and refreshed my Hacktoberfest profile to make sure it picked it up, only to see it marked as not valid due to not being in an approved repository. So I went looking for an explanation and eventually wound up in this thread. As you noted, there was no mention of it on the site, no email, etc. There also doesn't appear to be a contact email listed anywhere on the Hacktoberfest site.
In the past years, I have actually experienced Hacktoberfest as a really great event - both as a contributor as well as a maintainer. The recent events sadden me, but I also understand why these changes were necessary.
I just opted in to Hacktoberfest PRs for two of my projects: bat and fd. For bat, I opened three special issues for Hacktoberfest in order to help contributors who are completely new to the open source world:
I only heard of hacktoberfest this year and as soon as I saw the website my first thought was "this is going to be abused". I'm honestly surprised they didn't see it.
Github has become like a social media of programming. Even before I heard of hacktoberfest I had noticed people building hollow or shallow profiles on github to attract employers.
Most recruiters won't go deeper than your profile, so they'll see a bunch of contributions but those might just be Issues created, PRs rejected or documentation adjustments.
Excellent. Reading the PR notes on how it'll now work, this sounds imminently sensible:
- projects can opt in by adding a keyword to their project description on github for a month. That's barely any effort for projects that care, and
- PRs that are merged won't count unless the project maintainers welcome hacktober contributions and are willing to add a label that marks a PR as "this one counts".
And if "not getting a $20 T-shirt for free" is the only thing making a difference between you contributing a meaningful PR to a project, and not contributing a PR at all, then let's face it: the open source world really isn't worse off.
I think for next edition:
- Maintainers should create a month ahead opt-in and list some good issues for hacktoberfest. This means, we agree to help you start on OSS and have something which is meaninful for us listed.
- A browsable list of projects which opted in. So you can look for projects to contribute.
- It will look something more like GSoC.
- What I think it would be great is if maintainers are willing to mentor newcomers so they are able to help more in the future, not only on a given october timeframe.
For the past few years, I've made this tradition of working a bit harder in September so I can have more free time in October and make all the contributions I've been meaning to make.
I never made the PRs specifically to get the shirt, they were things I wanted to do at some point and the shirt was a good incentive to actually get them done.
Just like past years, I have a similar todo list with 10-or-so items this year and started working on it yesterday. All of the contributions I have planned have had open issues for a while and I've discussed them with the maintainers for sometimes months. Now none of them will count towards the shirt.
And I want that god damn shirt! I know it's stupid, but it was really nice to get something sorta-exclusive for doing something good for the open-source community, even if my contributions weren't particularly groundbreaking. I'd gladly pay shipping costs if necessary (actually, I think that would be a good anti-spam measure). But now I'll have to spend more time looking for tagged projects to contribute to and probably end up not finishing some of my planned PRs.
I would even take it a step further and allow maintainers the ability to cherry pick certain issues they'd like to put up for hacktober.
I'd still keep the repo wide tag for opt-in, but also optionally provide issue level opt-in.
Alternatively, you can provide a platform where participants can self regulate...e.g. like spammers called out on r/programming or maybe a spam detection algo.
Edit: maybe the incentives can also be altered. E.g. sticker for non opt-in repos, t-shirt for opt-in ones. Hmm solving bad actor behaviour is an interesting problem
No matter what happens, there'll be a vocal minority complaining about this too. Digital Ocean could employ reviewers and still nobody would be happy. There'd be comments about gatekeeping and rejections will be too subjective.
Unfortunately, the majority is mostly silent, so I'll just say: Digital Ocean, good job on trying to make things better. Whatever your motives, you created a discussion about open-source promotion and hopefully some good will come out of it.
Glad I completed my Hacktoberfest requirements earlier; a little bummed that the shirt will invariably = low quality contributors.
A better way to do this IMO would be to kick off a year long contest; for example: you sign up, every week you need to average +7 lines of code on your own repo. Bonus points if the repo actually does something useful. After a year of that, you get a Tshirt.
Weeds out the lazy, encourages people to actually build something.
I love that this whole situation is analogous do the dimishing status-signaling-value of a college degree due to grade inflation and admissions scams, but it's about diminishing the status value of a t-shirt.
If you want to opt-in but worry about spam, one compromise can be to temporarily limit interactions to previous contributors only: this way, it rewards people who help the rest of the year.
I think it is better to take a hybrid approach to this. Make newly created accounts can only contribute to #Hacktoberfest repos, and older account can still contribute to any repository while still being counted.
I'm not sure about that. Almost every developer I know has a GitHub account so I assume most people including spammers finding out about Hacktoberfest would already have an account that qualifies.
To draw out a hypothesis: existing accounts with real names and projects may value their reputation enough to not spam. Perhaps a reasonable line of thinking is spam accounts are newly created “anonymous” accounts.
I haven’t looked, so I don’t know if there is any correlation. It’s an imperfect filter for spammers since of course anonymous accounts already exist.
If you had read Hacktoberfest's previous blog post on this matter. They even encouraged those spammers to create a repo on their own github account and create 4 PRs within those repos just to get qualified for the T-shirts but I think anyways the damage has been done and by providing T-shirts to those spammers they're not penalizing their behavior any ways.
I don't really get why that is a bad thing. It is better that they do it there, on their own repos, than spam maintainers as it is right now. And you want people to learn how to make a repo and do PRs right? Let's have them practice on their own. Do you really need the t-shirt to be some mark of super-hackers?
Good change! With a more limited base of oss projects that opt-in, at least it can give them publicity in exchange for accepting the possible burden of bad new / single-shot contributors
This seems like a quickfix idea and doesn't provide a good incentive for open-source projects: in that configuration, it requires additional knowledge (of the rules) and work (tags, ...) from repository maintainers, just so some people can get a tshirt, not sure it's worth it.
They should have acknowledged their failure and cancelled the game altogether.
> just so some people can get a tshirt, not sure it's worth it.
That’s looking at things a wee bit one-dimensional isn’t it?
Until this year Hacktoberfest has been a fun event where people of all levels of skill has learned how one can help out in open-source projects.
They have learned how to fork, make changes and propose that those changes get upstreamed. You may take these skills for granted, but they first needs to be learnt.
They have learnt what sort of reception to expect based on how they have presented their changes to the upstream repo and/or maintainers and how to adjust it based on a feedback and consensus. You may take this experience for granted, but it needs to come from somewhere.
In both these respects Hacktoberfest has helped.
Looking at entire Hacktoberfest and what it has done over all its years as simply a t-shirt because some Indian spammers tried to game the system for that single price this single year is absolutely not fair.
> They should have acknowledged their failure and cancelled the game altogether.
You should acknowledge that such confrontational attitude and vitriol won’t do the discussion any good.
You could come up with all kinds of constructive criticism here instead, but that might take some effort on your part. It will get you a more fruitful discussion though.
Disclaimer: Maintainer for various projects and Hacktoberfest attendee.
This is what Hacktoberfest should have been from the start. A company incentivizing pull requests against your repo should require your consent. A maintainer needs to affirmatively sign up for this sort of work; they can't have it thrust upon them. As a maintainer, all the other half-measures people have suggested (e.g., accepted PRs only; account age measurements; filtering out README changes) do not actually reduce the unasked-for burden on me.
That said, I'm not sure this year can be salvaged. It's not clear whether all the existing spammers will get the message. I hope DigitalOcean emails all folks signed up to notify them of this change. (They haven't communicated any of their changes so far in such a way.) Notably, a day ago, the DigitalOcean staff thought this wouldn't make a difference. [1] And it's even possible this will just result in issue spam begging maintainers to add the Hacktoberfest topic.
But it's also possible that this will work out. The best version of this is that low-quality contributors looking for a t-shirt get directed toward honeypot repositories, and folks interested in making substantial contributions will continue using issue labels like GitHub's own "good first issue", or the Hacktoberfest repository topic, to find places to contribute.
We'll see in a day or two whether this is enough.
[1]: https://news.ycombinator.com/item?id=24648285