Hi, Bro👋🏻
Please review the following items.
Introduction
We are a community of passionate developers, learners, and creators united by a simple yet powerful mission: to grow through collaboration and contribute through code.At our heart lie two fundamental pillars: learning and open-source spirit. We believe that the best way to learn is by doing, and the best way to build is by sharing.
Here, every line of code is an opportunity to learn, and every project is a chance to contribute to something bigger than ourselves.
Whether you're a seasoned developer or just starting your journey, you'll find a supportive environment to explore new technologies, tackle challenging problems, and build meaningful projects together.
Join us in fostering a culture where curiosity meets code, and collaboration fuels innovation! 😉
Project Baseline Guidelines
"Every baseline we set should answer one question: How much time does this save the next person who reads our code?"
Our organization is built on learning and open source values. These guidelines exist not to restrict, but to lower the barrier for newcomers and make external contributions frictionless.
| Requirement | Description |
|---|---|
| Public interfaces | Every exported function, class, or API endpoint must have a doc comment describing what it does, parameters, return value, and any exceptions thrown |
| Complex logic | Include intent comments that explain why the code is written this way — not what it does (the code itself should make that clear) |
| No dead code | Commented-out code is not allowed on the main branch. Git preserves history — use it |
| Requirement | Description |
|---|---|
| Unified formatter | All projects must use a consistent Formatter + Linter (e.g., Prettier + ESLint) with shared config committed to the repository |
| Style is not negotiable | The tool's decisions are final. Debating style preferences wastes time — we automate, we move on |
| CI enforcement | CI pipeline must check that code is properly formatted. Failing builds block merges |
Every project repository MUST include a README.md at its root containing the following four sections:
| Section | Questions to Answer |
|---|---|
| Project Name | What is it called? (Optional: how to pronounce it) |
| Purpose (What) | What problem does this solve? What are the typical use cases? |
| Usage (How) | Minimal steps to get it running: install → configure → run an example |
| Contributor Guide | How to set up dev environment, run tests, and submit PRs (point to CONTRIBUTING.md) |
- Provide a
README-template.mdin the organization's.githubrepository to lower the startup cost for new projects - Use Issue templates with a field for "What I've already tried" — encourages self-exploration before asking
- Pin a "New Project Startup Checklist" on the organization homepage as a quick reference
These baselines will be reviewed quarterly to ensure they remain relevant. Suggestions for improvement are always welcome via GitHub Issues or discussion threads.
— Committed to keeping code readable, approachable, and open for everyone.