Opening issues to propose new algorithms (Hacktoberfest)

[tianyizheng02]

Contributors keep opening issues whenever they want to add an algorithm to the repo. Should we automatically close such issues?

• We already don't assign issues so there's no need to open an issue to propose an algorithm anyway—just submit a PR.
• Rather than preventing multiple people from working on the same issue at the same time (which would be the whole point of assigning issues), it has the opposite effect and it just encourages the onslaught of Hacktoberfest contributors to submit multiple PRs for the same algorithm.
• Not enough people don't read the contributing guidelines so the comments just become full of "can I work on this issue" spam.
• Not enough people don't check to see if an algorithm is already implemented so oftentimes the issue proposes an algorithm we already have.

[aryan1165]

I also feel this problem as most of people first go to issues, And addition of an algorithm seems to be pretty straightforward issue to solve. I feel what maintainers can do to resolve this is add a note in Contribution regarding the addition of the new algorithms need no opening of an issue. I feel this will definitely breduce duplicate PRs. Also there can be a line stating before deciding to contribute an algorithm check for the same implementation in the codespace rather than searching for the same name. Because a lot of algorithms are called by two or more names.

And as you asked, in my view such issues should be closed with a reference to updated contributing guidelines. This may reduce some hassle but not completely.

[tianyizheng02]

Agreed, we should definitely update our contributing guidelines. I don't have the time to work on it myself right now, but we could open an issue for someone else to address this (ironically, that issue will probably have contributors asking to be assigned to the issue). This issue could also address @cclauss's comments in #8871 about adding Markdown anchors.

Also, thoughts (from you or the other maintainers) on editing the README to address some of these issues? My hope is that people read the README more than they read the contributing guidelines (though honestly that doesn't say much).

[aryan1165]

If you feel ok about changes stated below I can create an issue with mentioning its not to be assigned. Some points i feel should do the work:-

• Under here we can have another markdown anchor of key-points to remember or something else.
• Under that anchor we can have a list of short lines (so that users don't skip it) with key points as issue not to be assigned, new algorithm in mind (do check if the implementation is already there) if not just raise a PR (no need to raise an issue), Also check rules for what is an algorithm. Here the type hints point is covered.
• So my main point is the problems which are faced by maintainers can be listed in a short manner and anchor to that can easily be stated in the comments of such PRs and issues.

In my view, README.md is short enough to attract people to read CONTRIBUTING.md. Because if we add some points related to some important points to remember, people will skip the whole guidelines and just follow those points. If we feel the contributors lot is not improving after the above changes then we should link to key points to remember anchor directly in the README.md. Your views?

[tianyizheng02]

@chriso345 has opened issue #9760 to address the main problem that I stated above, but I like the idea of having a "key points/summary" checklist at the top of the contributing guidelines. @chriso345@cclauss, thoughts?

[aryan1165]

Just a follow-up on this. I wanted to ask if this is still a problem after #9760?. If yes, then we can add a link to issues tag directly in README.md . For eg:- Some important points you cant miss regarding issues. Thoughts?