I'm cautiously optimistic about this.<p>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.<p>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.<p>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.<p>We'll see in a day or two whether this is enough.<p>[1]: <a href="https://news.ycombinator.com/item?id=24648285" rel="nofollow">https://news.ycombinator.com/item?id=24648285</a>
> <a href="https://hacktoberfest.digitalocean.com/details#quality" rel="nofollow">https://hacktoberfest.digitalocean.com/details#quality</a><p>The quality standards are so low, I am honestly not surprised by the amount of spam this has generated.<p>> Last but not least, one pull request to fix a typo is fine, but 5 pull requests to remove a stray whitespace is not.<p><a href="https://hacktoberfest.digitalocean.com/details#spam" rel="nofollow">https://hacktoberfest.digitalocean.com/details#spam</a><p>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.<p>I don't think there's any way to save this.<p>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).
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...<p>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?
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.<p>I got one PR that did exactly what I asked. Great, merged! Good experience all around -- exactly what I expected!<p>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 <i>didn't</i> solicit help.<p>And now, because I marked unsolicited incorrect changes to a README file as "invalid", I'm getting new pull requests calling me an asshole.<p>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 <a href="https://github.com/digitalocean/hacktoberfest/pull/596#issuecomment-702986348" rel="nofollow">https://github.com/digitalocean/hacktoberfest/pull/596#issue...</a><p>I'm not a fan of this change because:<p>- 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.<p>- For intermediate or experienced programmers it voids the whole event because the vast majority of OSS projects won't get involved.<p>- 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.<p>- 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.<p>- It doesn't address "hello world" spam repos. In fact, it encourages them because of the reduced amount of repos available to contribute to.
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.
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)<p>I've just checked and am now running at over 40 rejected changes, many with really offensive comments added to them.<p>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
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).<p>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.<p>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.<p>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.<p>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.<p>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.
This hacktoberfest reminds me of rats of hanoi incident, an example of a measure becoming a target.<p><a href="https://www.atlasobscura.com/articles/hanoi-rat-massacre-1902.amp" rel="nofollow">https://www.atlasobscura.com/articles/hanoi-rat-massacre-190...</a>
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.<p>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:<p>- <a href="https://github.com/sharkdp/bat/issues/1211" rel="nofollow">https://github.com/sharkdp/bat/issues/1211</a><p>- <a href="https://github.com/sharkdp/bat/issues/1213" rel="nofollow">https://github.com/sharkdp/bat/issues/1213</a><p>- <a href="https://github.com/sharkdp/bat/issues/1216" rel="nofollow">https://github.com/sharkdp/bat/issues/1216</a><p>Curious to see how this works out. The first PRs are already coming in :-)
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.<p>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.<p>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:<p>- 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<p>- 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".<p>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.<p>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.<p>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.<p>I'd still keep the repo wide tag for opt-in, but also optionally provide issue level opt-in.<p>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.<p>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.<p>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.<p>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.<p>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 <i>t-shirt</i>.
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'll create some repos that are nothing but<p><pre><code> /* comments */
</code></pre>
and welcome any and all pull requests! This way everyone can be an FOSS contributor and win t-shirts and stickers.
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
More important is they changed the acceptance criteria to be Merged PRs.
That is what it should have always been.
Or at least "not closed" PRs.
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.<p>They should have acknowledged their failure and cancelled the game altogether.