Require PRs be in a repo with hacktoberfest topic and be accepted

[MattIPv4]

Description

To reduce spam and make Hacktoberfest an opt-in event, only consider pull requests that are submitted in a repository that has 'hacktoberfest' as a repository topic. Further, only consider merged, approved or labelled (as 'hacktoberfest-accepted') PRs.

This does not apply to existing PRs.

Closes #583.

Test process

• Create PR in non-hacktoberfest-topic repo, PR should go to topic_missing state
• Create PR in hacktoberfest-topic repo, not approved, PR should go to not_accepted state
• Create PR in hacktoberfest-topic repo, merge or label as 'hacktoberfest-accepted' or approve, PR should go to waiting state

Requirements to merge

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code in hard-to-understand areas
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes

[devsnek]

If you think your PR is meaningful and the maintainer doesn't, the maintainer is correct.

[MattIPv4]

👋 If folks are after a more wordy and high-level summary of the changes made here and everything else we're doing to continue to fight the spam and make Hacktoberfest a better experience for the community, please take a read through https://hacktoberfest.digitalocean.com/hacktoberfest-update

If y'all would like to share feedback, please send us an email via hacktoberfest@digitalocean.com or consider joining our community roundtables: https://docs.google.com/forms/d/e/1FAIpQLSdb2uld_Ln43cWn0Xvfe64S59us38SHl510tHWafTRpctzXOA/viewform

[Nezteb]

@sylveon

I'm not a fan of this change because:

...

It's not a perfect solution but it helps alleviate a major pain point for maintainers caused by Hacktoberfest. Without OSS maintainers, Hacktoberfest would not exist. Individual devs not being able to get a $20 shirt for free seems insignificant in comparison.

Unless anyone has other ideas to contribute in a constructive way, poopooing it outright seems pointless.

@MattIPv4 is working extremely hard on this and I hope DigitalOcean gives him and the other Hacktoberfest organizers more resources next year to address all of these concerns.

[devsnek]

I'm sure a maintainer would be happy to add the relevant labels if they received a nice PR.

[PureKrome]

OMG @sylveon - you're really a negative-nelly, here.

There's been a large negative vibe this year around HF2020. Yes, this is a 🔥 dumpster-fire 🔥 of a year, but we can always do better ... and the D.O. team are trying to do some positive changes. So...

have the hacktoberfest tag

which led you to summarizing..

Conclusion: it's hot garbage

maaaaaate ... as of right now at this post no one KNOWS that this will be the new way forward to include repo's. Give this message some time to get out in the community.

If you want to help .. and i mean really help .. then you'll :

• find a repo.
• ask the maintainer(s) to add the tag(s)
• create an issue (you know, best practice is to create an issue FIRST before a ninja-PR )
• $$ profit $$

so ... try and be positive and let them get some baby steps out there.

are the better ways? sure, maybe? You just mentioned 4 criteria, so maybe that's the way? Anyways, lets get this out and make some of us Maintainers happier ... which makes the ecosystem more positive.

[WesleyBranton]

Does this impact PRs made before this was merged that have no matured yet?

[gary-kim]

Contributions to orgs you're member of or your own repos do not count

The orgs you're a member of part could be possibly problematic for orgs that tend to add anyone that has contributed. I like the rest of your ideas, though. Case in point (in my case), Nextcloud in which most of the org members are community members so it feels like that should still count.

[PureKrome]

@WesleyBranton Nope (like @sylveon said)

ref: https://hacktoberfest.digitalocean.com/hacktoberfest-update

We will honor all valid pull requests prior to this change, and as of October 3, 2020 at 12:00:00 UTC – and October 3 in all time zones

[silentsilas]

I will say this:

The PRs I make outside of work and personal projects are to obscure libraries I found useful, which usually have a maintainer whom awakens from their slumber once every few lunar cycles.

They most certainly won't opt-in for hacktoberfest, but I can live with that. Which is a bit of a shame, as this lunar cycle will be a blue moon for Halloween. Alas.

[anna328p]

I've made a couple of pull requests to Nixpkgs, and was planning to contribute more for Hacktoberfest. With these changes, my PRs won't count because I was added to the organization as a maintainer, and Nixpkgs will never get the hacktoberfest tag.

[rektide]

Please create an alternative GitHub app I can opt my repos in with without polluting my project with issues. Or otherwise let me not need to fill up more "issues".

[DanielJoyce]

If you need a t shirt to contribute to open source perhaps you should not be in open source? This thing is like Eternal September for github this year. It's a PR stunt for Digital Ocean.

[benatkin]

I appreciate this change. Hopefully it will restore most of the goodwill lost by the problematic PR behavior and DigitalOcean's developer community, which I am proud to be a part of, will continue to thrive.

[lnicola]

I can write more on this, but I think requiring opt-in is too much. Instead, it should be easier to opt-out (the blog post mentions this, but the site doesn't describe how to do it). A lot of repositories will never be labelled because the author doesn't know or doesn't bother, but they would still be happy to get drive-by contributions.

With the mandatory labelling you're putting all the spam pressure on a small number of repos.

[JohnnyUrosevic]

If you need a t shirt to contribute to open source perhaps you should not be in open source? This thing is like Eternal September for github this year. It's a PR stunt for Digital Ocean.

Who are you to decide what motivates people and who should and should not be in open source

[Jalle19]

So if I have 30 repositories, do I have to go add a topic to each if I want to receive contributions? I'll never remember to do that, so I guess this is the end of Hacktoberfest for me. Thanks guys!

[MzHub]

Suggestion for new rules:

• To make your PR eligible, fork the repo first, make your changes, and before making a PR submit it for pre-approval in Hacktoberfest.
• Other participants do the approval. Less burden on maintainers.
• When approved, you can submit the PR. Only pre-approved PRs count.
• Keep it opt-out, maintainers don't have to care or know about Hacktoberfest, which most don't.
• No explicit approval needed from the maintainers, but they can still label spam (maybe?).

As a bonus, participants might learn some reviewing practices.

[bfredl]

How do you add tag to all of neovim/* and bfredl/* already? I hope I do not need to go though every repo at once, just to unblock random strangers getting t-shirts.

[NobbZ]

Is this true for 2020 or not?

https://hacktoberfest.digitalocean.com/details/ still speaks about any repository, not only those highlighted.

[bfredl]

who knows? I just needed to ask a random stranger to approve a PR to my own repo, just to be sure I get the t-shirt.

[PureKrome]

@ Pweeples ... this is a PR.

For a discussion on what could be done/etc .. please create a new Issue.

[lppedd]

If you need a t shirt to contribute to open source perhaps you should not be in open source? This thing is like Eternal September for github this year. It's a PR stunt for Digital Ocean.

Who are you to decide what motivates people and who should and should not be in open source

To be honest, I think he's right. Regular contributors will continue doing what they always did, without picking repositories based on a tag or t-shirt.
Yes, maybe the tagged repositories will be mostly containing basic stuff, but it's ok as this event wants to attract new people, people new to the job.

The PR is perfect imho. Keep it simple.

[youknowone]

I didn't claim you don't participate in other open source projects. I claimed you can get it from the projects you already participated in ;) Good luck! I actually don't need to check your profile for any reason - I wish anybody who properly participated in any project can get help from maintainers. Regardless if you are one of them or not.

[sim642]

Why is the repo topic requirement needed if PRs must be merged or labeled specially anyway? Right now maintainers are adamant to add the topic because it immediately makes their repository a target for spam as everyone is looking for such repositories. Meanwhile it wouldn't be an issue if the PR got merged or just labeled accepted. That would make only legitimate PRs count already anyway and avoid advertising the repo with the topic as "send PRs here for a chance".

[JohnnyUrosevic]

If you need a t shirt to contribute to open source perhaps you should not be in open source? This thing is like Eternal September for github this year. It's a PR stunt for Digital Ocean.

Who are you to decide what motivates people and who should and should not be in open source

To be honest, I think he's right. Regular contributors will continue doing what they always did, without picking repositories based on a tag or t-shirt. Yes, maybe the tagged repositories will be mostly containing basic stuff, but it's ok as this event wants to attract new people, people new to the job.

The PR is perfect imho. Keep it simple.

What about experienced developers who don't often contribute to open source (due to school or other obligations?) I'm not interested in contributing to "Reimplement Binary Search 361". I did half of my PRs already (which wouldn't count now) and had the other 2 planned but now those PRs won't count unless I harass the maintainer to accommodate me. I don't care about the T Shirt that much but I was just trying to do something fun and productive during quarantine and now its looking like I'll have to give up on the shirt or contribute to projects I don't care about

[lppedd]

@JohnnyUrosevic contributing to projects you don't care about isn't something I would do, that's counterproductive, but that's what everyone is doing right now.
Give people a day to put tags on the repositories and then you'll be able to chose again. Not everyone need or want help, but people who cares will be eager to put the tag.

[TheZoq2]

I'm sad to see this change. I think a good portion of my previous hacktoberfest PRs have been one off things to repos I happened to find a bug/missing thing in, and which hacktoberfest nudged me to do something about. Hopefully enough repos will add this tag.

Also, it would be nice if one could globally opt in. I want to add the hacktoberfest tag to all my repos, but I will miss some if I try to go through all of them manually

[M4GNV5]

I think a lot of people do as @TheZoq2 said. Small issues lying around, but not bad enough to fix, are fixed thanks to Hacktoberfest. With the opt-in change they probably do not count anymore, because a random person will not opt in their repo to hacktoberfest. I guess there is a simple fix for that: PRs that get merged by the maintainer always count, no matter if the repo has opted in. Spammers will know their PRs will never get merged, but users can still contribute to projects from random peeps and fulfill Hacktoberfest.

[MarkCBell]

It might be worth noting that this pull request also changed (the code specifying) the review window duration from 7 days to 14 days. However it did not update the webpages to reflect this. I have documented some of these in issue #604.

[jamesmcm]

A requirement that the repositories were created before October, and perhaps even have more than 30-50 stars, would help stop the spam repos too without manual reporting.

That change, plus requiring that the PRs be merged would solve the spam issues without requiring the opt-in label.

[ForsakenHarmony]

How about requiring the hacktoberfest topic OR the hacktoberfest-accepted label on the pr, then it doesn't paint you as a target and you can still approve normal PRs for hacktoberfest

[lnicola]

How about requiring the hacktoberfest topic OR the hacktoberfest-accepted label on the pr, then it doesn't paint you as a target and you can still approve normal PRs for hacktoberfest

The repositories with the label will still be targeted and, as a well-intended participant that still wants the T-shirt, why would I submit a PR to a repository whose maintainers might not even know what Hacktoberfest is? I'm not going to beg them to label my PR.

I don't understand why it's not enough to count merged PRs and disqualify participants with say two PRs marked as invalid/spam.

[andrewbanchich]

Not a fan of this change, especially just finding out about it only after noticing my latest PRs are not eligible. I'm still going to continue with contributing the PRs I've been working on, but I don't think this makes sense from a logical perspective.

The number of open source projects is far greater than the number of people who even know what Hacktoberfest is. This new opt-in logic is more about promoting Hacktoberfest than it is supporting open source, since the only contributions that matter are now for repos where the maintainer knows about and has tagged it as "hacktoberfest".

If we want to stop spam, then there should be opt-out logic, like a no-hacktoberfest label or only counting merged PRs.

[therealprof]

@andrewbanchich Fully agree with @andrewbanchich. I've just found out about this and I'm rather disappointed. I'm certainly not going to add tags to dozens of personal repositories and start the discussions required to add it to all repositories under shared organisation ownership.

Addendum: To add some weight to my argument, I happen to be a (core) member of the Rust embedded working group and part of some other organisations with a total of over 100 repositories. Adding such a tag is not only a sizeable maintenance effort, it often also requires organisation member sign-off which is sometimes not that trivial to obtain. I have a feeling a lot of popular projects will not be able to participate if this approach stands.

[xlanor]

A requirement that the repositories were created before October, and perhaps even have more than 30-50 stars, would help stop the spam repos too without manual reporting.

That change, plus requiring that the PRs be merged would solve the spam issues without requiring the opt-in label.

I’m in favour of having repos be created pre October, but having more than 30-50 stars might be a stretch.

The best change would probably be to require a merged PR to prevent abandoned repositories from being the target of flooding

[zoffixznet]

Changing rules mid-game is lame.

It's hard enough to argue code changes to a stranger online, but convincing them they need to add an unrelated "topic" to a repo is much harder.

You may have won on spam with this change, but you took a huge hit to credibility.

[Andrew-Chen-Wang]

Edit: just creating a new issue for the following in #608

TL;DR Make searching hacktoberfest repos easier and show smaller repos more often.

I'm mostly for this PR, but (the following is my proposal to distribute the spamming of PRs to become small PRs but in "actual code form" to smaller repos):

I have an organization's repo with only 5 stars in it, and I'd love to see contributions to it. I think we just need to think back to what this entire event is for: encouraging people to contribute to open source. Right now, I think this PR 1. makes large repositories overrun with spam and 2. make smaller repositories who desperately need contributions left in the dust that is GitHub's tag search engine (which is great, but not for this event).

Solutions via rules and code:

1. Some new rules that can be made in place is for repositories with greater than 2,000 stars to only accepts PRs from GitHub users who have created at least 100 contributions with an account age over 2 months. In my opinion, most people (but not all e.g. I joined with programming knowledge and immediately contributed to a large repo) with the aforementioned criteria create meaningful PRs in those repositories.
2. What about those smaller repositories? The ones with less than 2,000 stars? In my opinion, they need contributions from newcomers to git and/or programming in general. They need small PRs to catch edge cases or small new features as the repo is growing. Those are where most PRs should be geared towards since the larger ones already have a huge backing of PRs. "This sounds like the event is for open source rather than for introducing devs to open source?" To me, yes I agree, but also note that that way we can distribute the spam -- in a sense -- and the people are more encouraged to spam with small CODE changes not doc changes.

Code changes:

1. I believe the way we can help with an endeavor to persuade spamming meaningful PRs to small repositories would be to offer a survey. See which programming languages people are most familiar with, and show them repositories based on the above criteria.
2. Additionally, the GitHub search engine can provide easier methods for searching repositories by finding hacktoberfest-labeled small repos that have recently been updated in the last 2 months. Order them based on the fuzzy searching of GitHub's search engine (per usual) and number of commits and currently open PRs. (I'm not entirely sure about the ordering, and obviously messing with the ordering at this point in time is difficult).

Idk, in essence, I think there would be more good to this event if small repositories got more PRs to 1. distribute the spam, 2. make sure PRs are in "actual code form," and 3. help the smaller repositories grow.

[ryukinix]

What a shitstorm! X_X

But guys... The problem is not digitalocean or hacketoberfest. They are just trying to stop the fire. Who started the fire was someone else and that is the real problem.

I hope to hacketoberfest continue safe, from now it will be harder to complete the hacketoberfest journey, but everyone knows that spam and abusing happens everywhere...

Someone need at least reduce the activity from these assholes, that MR at least reduced it.

[DreadKnight]

I just woke up and got poked with this for https://github.com/FreezingMoon/AncientBeast - usually hoping people would contribute for other reasons besides a free t-shirt, but whatever gets contributions and drives progress... :)

So I'm not sure if this was already mentioned, but I think the "Event details" and "Rules" sections should be updated on the homepage to reflect the new repo tag requirement now https://hacktoberfest.digitalocean.com - should have been part of this PR.

[JDeepD]

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.~ I concur, this is a stupid/edge case point.
• 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 dont know how is it supposed to be open source right now. Its just like selective contribution to verified repositories. I am a mid level python programmer and I am uncomfortable in forking something to like a very advanced project without knowing anything about it. I have made valid PRs (added new codes rather than modifying) in repositories which contain code snippets for newbie python programmers. But none of them now have the "Hacktoberfest" tag

[jimschubert]

It's pretty shady to start the "contest", and then change the rules two days later without notifying the folks who have signed up to participate.

As an open source maintainer, I do get annoyed by meaningless contributions… but those could easily be mitigated by providing the community a GitHub action for validating a configurable hacktoberfest contribution quality for first-time contributors to a repo.

[carlspring]

If folks are after a more wordy and high-level summary of the changes made here and everything else we're doing to continue to fight the spam and make Hacktoberfest a better experience for the community, please take a read through https://hacktoberfest.digitalocean.com/hacktoberfest-update

If y'all would like to share feedback, please send us an email via hacktoberfest@digitalocean.com or consider joining our community roundtables: https://docs.google.com/forms/d/e/1FAIpQLSdb2uld_Ln43cWn0Xvfe64S59us38SHl510tHWafTRpctzXOA/viewform

Hey guys,

Did you actually think about all the projects that have already labelled their tasks with hacktoberfest and are new to this, or have participated perhaps once, or twice? How do you expect them to all know about these changes that you've introduced a few days into the event? This should have been done and announced beforehand, or taken as a point for next year's event. Do you realize how many projects will be affected by this and not know about it? Projects will now be expecting people to come and join in and wonder why this is not happening. Surely, you could have thought of this before the event.

How exactly do topics improve things compared to labels? This makes no sense whatsoever!

We have participated in #Hacktoberfest in the past few years and all of our suitable tasks are clearly labelled with hacktoberfest. Thank God somebody pointed out this change to us! Labels make much more sense than topics. Topics are meant for a completely different purpose -- to clarify what category your project is about (for example, if you're making a library for java, spring and security, then you will add the java, springframework and security topics to your project and people will be able to find your project, based on the topic).

You're just adding more complexity and confusion to this and I don't see any benefit from these restrictions. Sure, you can add this to your repositories, but it's an unnecesary duplication.

This sort of confusion will affect first-timers, as well as projects who have already added tasks for #hacktoberfest and are hoping to get help from new-comers wishing to take part in the hackfest. Project maintainers should grow the hell up. If you want help from the OSS community, you have no guarantee that new-joiners will all be as experienced as you would like them to be. However, if you're smart about it, you will break up your tasks up into reasonably small tasks that people can easily understand and help out with, even if they're "very green". You will then guide these people and help them improve their skills. You will gradually benefit from all of this, as it will help you build up your project's community.

There will always be spam. We'd had a few of these non-PR-s ourselves and we also took part in a the Grace Hopper Celebration Open Source Day, which brought an extra amount of contributors in addition to the ones from #Hacktoberfest. Are all the contributors experienced? No. #Hacktoberfest and GHC OSD aren't exactly about you getting super-experienced contributors, they're about your project getting some attention and for:

• More to people to get into OSS and they haven't done it before (maybe they have some experience, maybe not).
• People who want to help projects and improve their skills in the meantime.
• Developers who's like to find a side-project for their free time.
• Promoting OSS.

Just to clarify that issues for the GHC OSD 2020 are all labelled as GraceHopperOSD. They've had no such odd requirements.

Your algorithm isn't perfect, but the previous rules were more reasonable.

Here's another issue: one of our projects is split across different repositories on Github, as it's a modular project. For dependency upgrades, we require two pull requests, one for the dependency upgrade (which is in one repository) and another one for CI testing (which is in another repository). The test pull request is always closed, not merged, if it succeeds. Obviously, as per your rules, this pull request will not apply, despite it having been help for our project (and we've already had quite a few of these pull requests). How could your algorithm be improved in this case, or should just let people know it won't count?

[IsmaelMartinez]

I spent the last two hours looking at python PRs to check if there is anything good for other co-workers to contribute. It will be great to have a way to filter PRs that have been already assign, I feel like searching for a film in Netflix... But hopefully this reduces the spam.

[hertg]

Hey guys, i just wanted to point out that I've created the issue #609 and summarized some of the points made here. This PR here gets quite polluted with external references and, unfortunately, with some less constructive feedback. As I believe an issue to be better suited for this, maybe consider reporting your feedback and ideas over there.

As frustrating as the sudden change might have been for you, please stay polite and constructive and try to refrain from comments that don't contribute anything new to the conversation. Also, if you keep your feedback in a well-structured form and keep an open-mind, it will probably be taken more seriously by the Hacktoberfest Team. But that rule goes for every feedback on (open-source) projects in my opinion. :)

Happy coding and good luck with your PRs!

[marceloFA]

Does PRs submitted before hacktoberfest tag was added to the repository topics count?

[luizfzs]

* It doesn't address "hello world" spam repos. In fact, it encourages them because of the reduced amount of repos available to contribute to.

It does address, right? By saying that they will accept .. only consider merged, approved or labelled (as 'hacktoberfest-accepted') PRs.. There is no way that maintainers will accepts pull requests with "hello world" changes.

[luizfzs]

Those repositories are dedicated to accepting spam or junk pull requests so that you can get a shirt.

For example this and this

You're right, I missed that aspect. I naively considered only fair repositories.

[DanielJoyce]

Google Summer of Code works because repositories/projects have to sign up. This kind of gaming/spam repo was possible before the latest hacktoberfest changes, so no changes there.

The problem again was someone basically making a wider audience aware of Hacktoberfest, leading to an Eternal September for Github projects.

1) It's just a t-shirt. If Digital Ocean wants to hand them out for for low quality PRs to spam repos, that's their perogative.

2) It should be opt in, or require some action, because otherwise with the sudden awareness of this program now and forever ( thanks to the youtube video ) there is now potential for this spam to repeat forever.

3) If DO wants legit repos to sign up / opt in, they need to do better outreach beyond twitter announcements. A website to discuss it. Instructions on opting in. Instructions on being a good submitter. DO blindly trusting crawling the Github API to award t-shirts to spam repos is their own problem.

[DanielJoyce]

Those repositories are dedicated to accepting spam or junk pull requests so that you can get a shirt.

For example this and this

DO decided to blindly trust the results of crawling the github API to find and award contributions. That problem existed before this Hacktoberfest.