Workflow "Hacktoberfest / opened (pull_request)" is failing right now, because the labels need to be created manually ahead of time. Once @bagder approves, I will also do that and re-run the workflow accordingly.

Add hacktoberfest label to opened PRs between September 30th and November 1st for easier identification in acceptance step.

Do all PRs opened in October get this label automatically?

Add hacktoberfest label to opened PRs between September 30th and November 1st for easier identification in acceptance step.

Do all PRs opened in October get this label automatically?

Yes, indeed. That is what the failing task mentioned above would do.

Updated to avoid affecting forks and creating a failed GitHub status entry for those.

I am sorry for the many force-pushes. I had to be sure the repository check is working correctly, now it does.

I think this risks being highly annoying since the vast majority of our pull-requests will not be hacktoberfest material, but I'm willing to try it out. Can we get any feedback if any of the labelled PRs is actually eventually used to claim something? To use as feedback if we're going to try this again next year or not I mean.

@MattIPv4 we're only interested in how many claims there are on PRs on curl, we don't care about exactly which nor who did them. I personally suspect the amount is very close to zero, which makes all our efforts on bending backwards to comply totally wasted.

we're only interested in how many claims there are on PRs on curl, we don't care about exactly which nor who did them.

I will ask our legal folks if that's a number we can share 👍

I personally suspect the amount is very close to zero, which makes all our efforts on bending backwards to comply totally wasted.

I'm not sure why you make this out to be such a big pointless effort on your end, it's just adding a label to some PRs (admittedly, through some automation instead of just by hand), but if you don't want to do it then don't do it? Y'all can remove the topic and not participate if you want to...

I'm not sure why you make this out to be such a big pointless effort on your end,

Because I think hacktoberfest needlessly complicates things for (projects working like) us and that I believe we don't have much participation anyway, but we have contributors who still think we should participate. I'm willing to be proved wrong.

Is there a way to opt-out a specific PR or a whole (own) username from participating in this? (My concern is that email addresses will be automatically submitted-to/collected-by the organizer, which may be undesirable for some.)

I guess that would have to be done on their side, because they scan all PRs anyway since approval or merge also counts as participation and that happens even without my changes. At least every approving review triggers a PR to be accepted until it is then closed by our way of merging.

I would think that they ignore your submission unless you explicitly signed up for Hacktoberfest. Pinging @MattIPv4 about this again.

Also the way I implemented this, it relies on an additional label hacktoberfest which is set between a PR being opened during the event timeframe and it being closed. You could then just remove the hacktoberfest label while the PR is open. That way it won't get the relevant hacktoberfest-accepted label on closure.

@bagder I guess that is a good reason for keeping the proposed approach as well.

I would think that they ignore your submission unless you explicitly signed up for Hacktoberfest

A submission surely needs some sort of active action by the person asking? If I want a hf tshirt I need to go there, register myself and post links/identifiers to the PRs that I claim qualify, don't I?

From what I know, @mback2k is the only person who ever participated in hacktoberfest with curl contributions.

I guess that is a good reason for keeping the proposed approach as well.

Well, it would be as easy to remove the hacktoberfest-accepted label as it is to remove the hacktoberfest one. The -accepted one has the benefit that it is never set on an open PR, while the latter will "spam" open PRs.

I would think that they ignore your submission unless you explicitly signed up for Hacktoberfest. Pinging @MattIPv4 about this again.

Correct, we only fetch PRs for users that've actively signed up to Hacktoberfest.

I guess that is a good reason for keeping the proposed approach as well.

Well, it would be as easy to remove the hacktoberfest-accepted label as it is to remove the hacktoberfest one. The -accepted one has the benefit that it is never set on an open PR, while the latter will "spam" open PRs.

Okay then. I just reworked this PR to just require the hacktoberfest-accepted label on PR closure/merge. The hacktoberfest topic just needs to be set on the repository to enable this workflow (to avoid affecting forks), but not on the individual PRs anymore. @bagder what do you think of this now?

I approved it already before this change 😄

Thanks @bagder. Can I then ask you to re-add the hacktoberfest topic label to the repository before I merge this PR?

done!

I don't know why, but for some unknown reason I had to do this follow-up commit to make it work on this repository:
80450f8

In my own repository it worked like a charm, but it seems like if you push to a repository that does not belong to your own account, the GITHUB_TOKEN is limited or restricted by default. See also Permissions for the GITHUB_TOKEN.

🤔 This PR shows as merged: https://api.github.com/repos/curl/curl/pulls/7897

This PR shows as merged

Yes, that's what happens when you merge exactly the commit in the PR without rebasing.

This appears to be working except I notice #7944 wasn't tagged. Should it have been?

No, that PR wasn’t created/opened in or 1 day around of October.