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

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

[katyhoward]

LGTM!!

[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

[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!

[joaofix]

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.