feat: adding suggested maintainers.md and fixing rendering issues in readme.md

BestPracticesChecklist.md

@@ -0,0 +1,258 @@
+# AOSSIE Best Practices Checklist
+
+> Criteria adapted from the [OpenSSF Best Practices Badge](https://github.com/coreinfrastructure/best-practices-badge)
+> (MIT / CC BY 3.0) by OpenSSF contributors. Modified for AOSSIE multi-repo template use.
+
+> **Purpose:** Covers OpenSSF Best Practices criteria that are NOT auto-detected by OpenSSF Scorecard.
+> Scorecard already handles: License, SAST tools, CI tests, Security Policy file, Branch Protection,
+> Pinned Dependencies, Signed Releases, Maintained status, and Known Vulnerabilities.
+>
+> **How to use:**
+> 1. Fill in checkboxes below — tick `[x]` for Met, leave `[ ]` for Unmet, use `[~]` for N/A
+> 2. Add a brief note or URL after each item as evidence
+> 3. Run the checklist-score workflow to update the badge automatically
+>
+> **Legend:**
+> - 🔴 MUST — Required for passing
+> - 🟡 SHOULD — Required unless documented rationale given
+> - 🔵 SUGGESTED — Optional but recommended
+> - ⚪ N/A — Mark `[~]` if not applicable, add justification
+
+---
+
+## Score Summary
+
+<!-- Auto-updated by checklist-score.yml workflow — do not edit manually -->
+| Category           | Met | Total | Status |
+|--------------------|-----|-------|--------|
+| Basics             | 0   | 8     | 🔴     |
+| Change Control     | 0   | 6     | 🔴     |
+| Reporting          | 0   | 8     | 🔴     |
+| Quality            | 0   | 11     | 🔴     |
+| Security           | 0   | 9     | 🔴     |
+| Analysis           | 0   | 7     | 🔴     |
+| **Total**          | **0** | **49** | **0%** |
+---
+
+## 🏗️ Basics
+
+### Project Website & Documentation
+
+- [ ] 🔴 **description_good** — The project README/website clearly describes what the software does and what problem it solves.
+  - *Evidence URL:*
+
+- [ ] 🔴 **interact** — The project provides information on how to obtain the software, submit bug reports, and contribute.
+  - *Evidence URL:*
+
+- [ ] 🔴 **contribution** — `CONTRIBUTING.md` explains the contribution process (e.g., PRs are used, how to open one).
+  - *Evidence URL:*
+
+- [ ] 🟡 **contribution_requirements** — `CONTRIBUTING.md` references acceptable contribution standards (coding style, tests required, etc.).
+  - *Evidence URL:*
+
+- [ ] 🔴 **documentation_basics** — Basic documentation exists for the software (README, Wiki, or docs folder).
+  - *Evidence URL:* `[ ]` N/A — *Justification:*
+
+- [ ] 🔴 **documentation_interface** — Reference documentation describes the external interface (API inputs/outputs, CLI flags, config schema, etc.).
+  - *Evidence URL:* `[ ]` N/A — *Justification:*
+
+### Other Basics
+
+- [ ] 🔴 **discussion** — Project has a searchable, URL-addressable discussion mechanism (GitHub Issues, Discord with archive, mailing list, etc.) that doesn't require proprietary client software.
+  - *Evidence URL:*
+
+- [ ] 🟡 **english** — Documentation is provided in English and English bug reports/comments are accepted.
+  - *Note:*
+
+---
+
+## 🔄 Change Control
+
+### Version Control
+
+- [ ] 🔵 **repo_distributed** — Project uses a distributed VCS (e.g., git). *(SUGGESTED)*
+  - *Evidence URL:*
+
+### Version Numbering
+
+- [ ] 🔴 **version_unique** — Each release has a unique version identifier (e.g., v1.0.0).
+  - *Evidence URL:*
+
+- [ ] 🔵 **version_semver** — Project uses [SemVer](https://semver.org) or [CalVer](https://calver.org/) format. *(SUGGESTED)*
+  - *Note:*
+
+- [ ] 🔵 **version_tags** — Releases are tagged in the VCS (e.g., `git tag v1.0.0`). *(SUGGESTED)*
+  - *Evidence URL:*
+
+### Release Notes
+
+- [ ] 🔴 **release_notes** — Each release includes human-readable release notes summarizing major changes. Raw `git log` output is NOT acceptable.
+  - *Evidence URL:* `[ ]` N/A — *Justification (continuous delivery / no external reuse):*
+
+- [ ] 🔴 **release_notes_vulns** — Release notes identify every publicly known vulnerability (with CVE) fixed in that release.
+  - *Evidence URL:* `[ ]` N/A — *Justification (no publicly known vulns / users can't self-update):*
+
+---
+
+## 🐛 Reporting
+
+### Bug Reporting
+
+- [ ] 🔴 **report_process** — A bug-reporting process exists (e.g., GitHub Issues link in README).
+  - *Evidence URL:*
+
+- [ ] 🟡 **report_tracker** — An issue tracker (e.g., GitHub Issues) is used to track individual bugs.
+  - *Evidence URL:*
+
+- [ ] 🔴 **report_responses** — A majority of bug reports submitted in the last 2–12 months have been acknowledged (response ≠ fix).
+  - *Self-certification note:*
+
+- [ ] 🟡 **enhancement_responses** — More than 50% of enhancement requests in the last 2–12 months have received a response.
+  - *Self-certification note:*
+
+- [ ] 🔴 **report_archive** — Reports and responses are publicly archived and searchable (GitHub Issues satisfies this).
+  - *Evidence URL:*
+
+### Vulnerability Reporting
+
+- [ ] 🔴 **vulnerability_report_process** — A vulnerability reporting process is documented (e.g., `SECURITY.md`).
+  - *Evidence URL:*
+
+- [ ] 🟡 **vulnerability_report_private** — If private vulnerability reporting is supported, the method for private submission is documented.
+  - *Evidence URL:* `[ ]` N/A — *Justification:*
+
+- [ ] 🔴 **vulnerability_report_response** — Initial response to any vulnerability report received in the last 6 months was within 14 days.
+  - *Self-certification note:* `[ ]` N/A — *Justification (no reports received):*
+
+---
+
+## ✅ Quality
+
+### Build System
+
+- [ ] 🔴 **build** — If the project requires building, a working build system exists that can auto-rebuild from source.
+  - *Evidence URL:* `[ ]` N/A — *Justification (interpreted language / no build step):*
+
+- [ ] 🔵 **build_common_tools** — Common build tools are used (npm, pip, cargo, make, gradle, etc.). *(SUGGESTED)*
+  - *Evidence URL:* `[ ]` N/A
+
+- [ ] 🟡 **build_floss_tools** — The project can be built using only FLOSS tools.
+  - *Note:* `[ ]` N/A
+
+### Automated Testing
+
+- [ ] 🔵 **test_invocation** — The test suite can be invoked in a standard way for the language (e.g., `npm test`, `pytest`, `cargo test`). *(SUGGESTED)*
+  - *Evidence URL:*
+
+- [ ] 🔵 **test_most** — The test suite covers most code branches, input fields, and functionality. *(SUGGESTED)*
+  - *Estimated coverage %:*
+
+### New Functionality Testing Policy
+
+- [ ] 🔴 **test_policy** — The project has a general policy that new functionality must include tests in the automated test suite.
+  - *Evidence (CONTRIBUTING reference or informal policy):*
+
+- [ ] 🔴 **tests_are_added** — Evidence exists that the test policy has been followed in recent major changes (e.g., PRs include tests).
+  - *Evidence URL (recent PR with tests):*
+
+- [ ] 🔵 **tests_documented_added** — The test policy is documented in contribution instructions. *(SUGGESTED)*
+  - *Evidence URL:*
+
+### Linting / Warning Flags
+
+- [ ] 🔴 **warnings** — At least one linter or compiler warning flag is enabled (ESLint, Pylint, clippy, golangci-lint, Slither for Solidity, etc.).
+  - *Tool used:*
+
+- [ ] 🔴 **warnings_fixed** — Warnings from the linter are addressed (not suppressed without reason).
+  - *Note:*
+
+- [ ] 🔵 **warnings_strict** — Project uses maximum strictness in linter config where practical. *(SUGGESTED)*
+  - *Note:*
+
+---
+
+## 🔐 Security
+
+### Secure Development Knowledge
+
+- [ ] 🔴 **know_secure_design** — At least one primary developer knows how to design secure software (familiar with OWASP, threat modeling, secure-by-default principles).
+  - *Self-certification note:*
+
+- [ ] 🔴 **know_common_errors** — At least one primary developer knows common vulnerability types for this software's category and how to mitigate them (e.g., injection, XSS, reentrancy for Solidity, prompt injection for AI).
+  - *Self-certification note:*
+
+### Cryptography (mark N/A if project does not handle cryptography)
+
+- [ ] 🔴 **crypto_published** — Only publicly reviewed cryptographic protocols/algorithms are used by default.
+  - *Note:* `[ ]` N/A
+
+- [ ] 🟡 **crypto_call** — Project calls an established crypto library rather than reimplementing crypto functions.
+  - *Library used:* `[ ]` N/A
+
+- [ ] 🔴 **crypto_working** — No broken algorithms (MD4, MD5, single DES, RC4, Dual_EC_DRBG) used unless required for interoperability (must be documented).
+  - *Note:* `[ ]` N/A
+
+- [ ] 🔴 **crypto_keylength** — Key lengths meet [NIST 2030 minimums](https://www.keylength.com/en/4/) by default.
+  - *Note:* `[ ]` N/A
+
+- [ ] 🔴 **crypto_password_storage** — Passwords for external users are stored as iterated salted hashes (Argon2id, bcrypt, scrypt, PBKDF2).
+  - *Note:* `[ ]` N/A — *Justification (project doesn't store passwords):*
+
+- [ ] 🔴 **crypto_random** — Cryptographic keys and nonces are generated using a CSPRNG; insecure generators (Math.random, rand()) are NOT used for security purposes.
+  - *Note:* `[ ]` N/A
+
+- [ ] 🟡 **delivery_unsigned** — Cryptographic hashes are NOT retrieved over plain HTTP without a signature check.
+  - *Note:*
+
+---
+
+## 🔬 Analysis
+
+### Static Code Analysis
+
+- [ ] 🔴 **static_analysis_fixed** — All medium+ severity vulnerabilities found by static analysis are fixed in a timely manner after confirmation.
+  - *Note:* `[ ]` N/A
+
+- [ ] 🔵 **static_analysis_common_vulnerabilities** — The static analysis tool includes checks for common vulnerabilities in the language/environment (e.g., eslint-plugin-security, bandit, Slither). *(SUGGESTED)*
+  - *Tool + ruleset:* `[ ]` N/A
+
+- [ ] 🔵 **static_analysis_often** — Static analysis runs on every commit or at least daily (CI integration). *(SUGGESTED)*
+  - *Evidence URL:* `[ ]` N/A
+
+### Dynamic Code Analysis
+
+- [ ] 🔵 **dynamic_analysis** — At least one dynamic analysis tool is applied before major releases (fuzzer, web app scanner like OWASP ZAP, etc.). *(SUGGESTED)*
+  - *Tool used:* `[ ]` N/A — *Justification:*
+
+- [ ] 🔵 **dynamic_analysis_enable_assertions** — Dynamic analysis / testing runs with assertions enabled (not just production mode). *(SUGGESTED)*
+  - *Note:*
+
+- [ ] 🔴 **dynamic_analysis_fixed** — Medium+ severity vulnerabilities found by dynamic analysis are fixed in a timely manner.
+  - *Note:* `[ ]` N/A
+
+- [ ] 🔵 **dynamic_analysis_unsafe** — If the project uses memory-unsafe languages (C/C++), memory safety tools (Valgrind, AddressSanitizer) are used. *(SUGGESTED)*
+  - *Note:* `[ ]` N/A — *Justification (project uses memory-safe languages):*
+
+---
+
+## 📎 Project-Specific Notes
+
+> Add domain-specific notes here for Web3, Full-Stack, or AI projects.
+
+### Web3 / Solidity Notes
+- Scorecard does not audit Solidity-specific security. Use [Slither](https://github.com/crytic/slither) for `static_analysis` and `warnings` criteria.
+- For `crypto_*` criteria, document which cryptographic primitives your contracts rely on (e.g., ECDSA in EVM is standard).
+- Smart contract audit reports count as evidence for `know_secure_design`.
+
+### Full-Stack / Next.js Notes
+- For `crypto_password_storage`: document which auth library handles hashing (e.g., NextAuth + bcrypt).
+- For `dynamic_analysis`: [OWASP ZAP](https://www.zaproxy.org/) can be run as a GitHub Action.
+
+### AI / LLM Notes
+- For `know_common_errors`: include awareness of prompt injection, data leakage, and model output validation.
+- For `dynamic_analysis`: consider adversarial input testing as a form of dynamic analysis.
+
+---
+
+*This checklist complements [OpenSSF Scorecard](https://scorecard.dev/) (auto-detected checks) and is
+inspired by the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/en/criteria/0) passing criteria.*

CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# Contributing to TODO:PROJECT Website
+
+We welcome contributions of all kinds! Whether you are fixing a bug, adding a feature, improving documentation, or optimizing performance, your help is appreciated.
+
+---
+
+## 💬 Join our Discord Community
+
+If you have questions, feedback, or want to discuss ideas before building:
+- **AOSSIE Discord Server:** [https://discord.gg/hjUhu33uAn](https://discord.gg/hjUhu33uAn)
+- **Discrod Channel:** `#TODO: Channel Name` channel in the TODO:Project Discord server
+
+---
+
+## 🛠️ Getting Started
+
+### 1. Prerequisites
+- **Node.js**: `v20.9.0` or higher
+- **npm**: `v9` or higher
+
+### 2. Fork & Clone
+```bash
+git clone https://github.com/AOSSIE-Org/Resonate-Website.git
+cd Resonate-Website
+```
+
+### 3. Install Dependencies
+```bash
+npm install
+```
+
+### 4. Run Development Server
+```bash
+npm run dev
+```
+Open [http://localhost:3000](http://localhost:3000) to view the site.
+
+---
+
+## 📜 Pull Request Guidelines
+
+1. **Create a Feature Branch:**
+   ```bash
+   git checkout -b feature/your-feature-name
+   ```
+2. **Quality Checks:**
+   Run lint and test commands before submitting:
+   ```bash
+   npm run lint
+   npm run test
+   npm run build
+   ```
+3. **Commit Messages:**
+   Use clear, descriptive commit messages following Conventional Commits (e.g., `feat: add social share buttons`, `fix: header logo alignment`).
+4. **Developer Certificate of Origin (DCO):**
+   Ensure your commits adhere to our [`DCO.md`](DCO.md).
+
+---
+
+## 📋 Code Style & Architecture
+
+- **Next.js 16 App Router:** Use React Server Components by default. Use `"use client"` only for interactive stateful components.
+- **Tailwind CSS v4:** Use central semantic CSS variables (`bg-background`, `text-foreground`). Avoid ad-hoc inline dark classes.
+- **Internationalization (i18n):** User-visible strings should be added to catalog files in `src/messages/en.json` and `src/messages/hi.json`. Use navigation helpers from `src/i18n/navigation.ts`.
+- **Zero TODOs Policy:** Ensure all code, documentation, and metadata files contain no remaining `TODO` placeholders.
+
+Thank you for contributing to AOSSIE & Resonate!

MAINTAINERS.md

@@ -20,4 +20,8 @@ This document lists the individuals fulfilling the key roles of [Maintainer](htt
 
 | Name | GitHub Username | Discord Username | Area / Focus                     |
 | ---- | --------------- | ---------------- | -------------------------------- |
-| TODO | @username       | @discord_user    | Repository Maintenance & Merging |
+| TODO | @username       | @discord_user    | Repository Maintenance & Merging |
+
+## 📜 Contribution Guidelines
+
+Please read our [`CONTRIBUTING.md`](CONTRIBUTING.md) and [`DCO.md`](DCO.md) before submitting pull requests. All contributions are welcome!