These guidelines explain what HelloGitHub looks for in project submissions and how to write a submission that gets accepted. Reading them carefully before you submit will save you revision cycles and significantly improve the chances that your recommended project appears in a future monthly issue.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/521xueweihan/HelloGitHub/llms.txt
Use this file to discover all available pages before exploring further.
What HelloGitHub Looks For
Not every open-source project is a good fit for HelloGitHub. The curation standard is intentionally high — the goal is to surface projects that genuinely surprise, teach, or delight developers, especially those newer to the field. A submission is more likely to be accepted when it meets most of the following criteria:- Hosted on GitHub — HelloGitHub only accepts projects with a GitHub repository URL. Projects hosted exclusively elsewhere are not eligible.
- Open-source license — The project must carry a recognised open-source license (MIT, Apache 2.0, GPL, etc.) that allows others to freely view and use the code.
- Interesting or fun factor — Would a developer stumble across this and immediately want to try it? Would it spark curiosity or a smile? Projects that feel novel or playful tend to perform well with the HelloGitHub audience.
- Entry-level / beginner-friendly — Can someone relatively new to programming learn something meaningful from this project? Is the code readable, are the concepts accessible?
- Active maintenance — The repository should show signs of recent activity: recent commits, addressed issues, or active pull request discussions. Dormant projects reflect poorly on the curation.
- Quality documentation — A clear README, working examples, and obvious usage instructions are the baseline. The better the docs, the easier it is for beginners to get started.
- Unique value — The project should offer something not already widely known in the community. If a near-identical tool is already in every developer’s toolkit, the submission needs a very strong differentiator.
Category Taxonomy
HelloGitHub organises every published project under a category that reflects its primary language or domain. When submitting, choose the category that best describes the project’s core implementation or focus area. This categorisation is how readers browse issues on the HelloGitHub website.| Category | Description |
|---|---|
| C | Low-level systems and embedded projects |
| C# | .NET ecosystem projects |
| C++ | Performance-focused applications |
| CSS | Styling tools and frameworks |
| Go | Cloud-native and CLI tools |
| Java | JVM ecosystem projects |
| JS | JavaScript/Node.js projects |
| Kotlin | Android and JVM projects |
| Objective-C | iOS/macOS projects using Objective-C |
| PHP | Web backend projects |
| Python | Scripting, data, AI/ML projects |
| Ruby | Ruby language projects and frameworks |
| Rust | Systems programming projects |
| Swift | iOS/macOS projects using Swift |
| Other | Projects not fitting any other category |
| Books | Open-source books and learning resources |
| Machine Learning | AI/ML models, tools, and datasets |
Writing a Great Description
The project description is the single most important field in your submission. It is what maintainers read to evaluate the project, and — if accepted — it is what HelloGitHub’s readers will use to decide whether to click through. The description must be between 32 and 256 characters. It should concisely answer all of the following:- What is it? — What kind of project is this?
- What can it do? — What is its core capability or output?
- What pain points does it solve? — What problem was it built to address?
- What scenarios is it for? — Who would use it and when?
- What can beginners learn from it? — What programming concepts or techniques does it demonstrate?
Common Rejection Reasons
Many submissions are rejected not because the underlying project is bad, but because the submission itself does not meet the standard. The most frequent reasons a submission is declined are:Review Process and Timeline
All submissions are reviewed manually by HelloGitHub’s maintainers. There is no automated acceptance — every project in each monthly issue has been evaluated by a human who read the description, visited the repository, and confirmed it meets the criteria. Accepted projects are scheduled for the next available monthly issue. HelloGitHub publishes on the 28th of each month. If your submission is accepted close to the publication date, it may roll over to the following month’s issue. You will be notified in your original submission issue when your project has been confirmed for inclusion.Review criteria evolve over time as the project matures and the community’s standards shift. Check the Project Review Guidelines issue for the most current and detailed acceptance criteria before submitting.
Submit a Project
Open a submission issue on GitHub to recommend an open-source project for a future HelloGitHub monthly issue.
View Contributors
See the 458+ community members whose project submissions have been featured in HelloGitHub’s monthly issues.