What to do about old Hacktoberfest PRs? #8912
Replies: 2 comments 12 replies
-
I think we need to close those PRs that have little value or would require more work than it is worth to merge. We must always be courteous to our contributors -- "Thank you for your contribution but...", "Can you please try to rebase your pull request to our current Based on past experience, I think that we should autoclose all new pull requests that are opened in the week between September 24th and October 1st so that we start Hacktoberfest with a clean slate. Are there ways that we should improve our contribution process or continuous integration tests to keep our code quality as high as possible? We have earned more than 161K GitHub Stars by being a welcoming learning community that maintains high-quality algorithms. Let's keep up that great tradition. @TheAlgorithms/python_maintainers |
Beta Was this translation helpful? Give feedback.
-
It is October 1st in Kiribati so I have closed the 50 remaining open PRs and Hacktoberfest 2023 can officially begin... |
Beta Was this translation helpful? Give feedback.
-
@cclauss Re: this point from your recent comment:
Given that a large portion (if not a large majority) of open PRs are from past Hacktoberfests, handling those PRs is the most effective way to massively reduce our backlog. However, most of those PRs have some problem or another that prevent us from merging them as is (no type hints, improper formatting, failing doctests, no doctests, etc). My worry is that these problems will never be resolved and reviewing these PRs would be a waste of time. Given that these PRs were (presumably) made mainly to reach the Hacktoberfest PR quota, I doubt that most if any of the PRs' authors care enough to revise a one- or two-year-old PR of theirs from an event that has long since concluded—that is, if they see our reviews at all.
With this in mind, what do you (or anyone else) think is the best way to handle these old Hacktoberfest PRs? Should we fix them ourselves and merge what we can? Or should we just close these PRs since most of them are lost causes anyway? On one hand, I don't like the former because it might set an undesirable precedent of contributors expecting us maintainers to fix their code for them. On the other hand, I don't like the latter either because it rejects many legitimate algorithm contributions, and merging them makes our jobs easier if/when future contributors try to contribute the same algorithms.
Beta Was this translation helpful? Give feedback.
All reactions