From be1463d4d53766e5fbecbf31516e6b957d1b0c23 Mon Sep 17 00:00:00 2001 From: kpj2006 Date: Tue, 1 Sep 2026 00:56:55 +0000 Subject: [PATCH] chore(template): merge template changes :up: Signed-off-by: kpj2006 --- .coderabbit.yaml | 68 ++- .editorconfig | 56 +- .gitattributes | 2 + .github/ISSUE_TEMPLATE/bug_report.yml | 6 +- .github/ISSUE_TEMPLATE/feature_request.yml | 4 +- .github/ISSUE_TEMPLATE/good_first_issue.yml | 10 +- .github/PULL_REQUEST_TEMPLATE.md | 15 +- .github/dependabot.yml | 251 ++++++++- .github/initial-issues.json | 287 ++++++++++ .github/release-drafter.yml | 85 +++ .gitignore | 340 +++++++++++- .goreleaser.yaml | 198 +++++++ .pre-commit-config.yaml | 52 ++ .vscode/extensions.json | 19 + .vscode/settings.example.json | 23 + BestPracticesChecklist.md | 258 +++++++++ CONTRIBUTING.md | 559 ++++++++++++++++---- MAINTAINERS.md | 25 + PRIVACY.md | 115 ++++ VERSION | 2 +- checklist-status.json | 37 ++ dangerfile.js | 91 ++++ public/aossie-logo.svg | 24 + public/stability.svg | 14 + socket.yml | 29 + 25 files changed, 2400 insertions(+), 170 deletions(-) create mode 100644 .gitattributes create mode 100644 .github/initial-issues.json create mode 100644 .github/release-drafter.yml create mode 100644 .goreleaser.yaml create mode 100644 .pre-commit-config.yaml create mode 100644 .vscode/extensions.json create mode 100644 .vscode/settings.example.json create mode 100644 BestPracticesChecklist.md create mode 100644 MAINTAINERS.md create mode 100644 PRIVACY.md create mode 100644 checklist-status.json create mode 100644 dangerfile.js create mode 100644 public/aossie-logo.svg create mode 100644 public/stability.svg create mode 100644 socket.yml diff --git a/.coderabbit.yaml b/.coderabbit.yaml index f22a8876..7a0d061f 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -7,6 +7,20 @@ language: en # Enable experimental features (currently not using any specific early_access features) early_access: true +# Multi-repo analysis: lets CodeRabbit use other repositories as context when reviewing PRs. +# Most useful when linking tightly coupled repos, e.g.: +# - Frontend ↔ backend (API contract changes) +# - Service ↔ shared library (ripple-effect on consumers) +# - Microservices sharing a database schema +# Avoid configuring this at org level — link only the repos relevant to this project. +# See: https://docs.coderabbit.ai/knowledge-base/multi-repo-analysis +# +# To enable, uncomment the block below and replace the example values with your repos. +# knowledge_base: +# linked_repositories: +# - repository: "AOSSIE-Org/backend-api" +# instructions: "Contains REST API endpoints and database models" + chat: # CodeRabbit will automatically respond to @coderabbitai mentions in PR comments auto_reply: true @@ -278,16 +292,46 @@ reviews: - Proper @2x and @3x variants for different screen densities - SVG assets are optimized - Font files are licensed and optimized - - # Path-based review instructions for specific files/patterns - - path: "src/**/*.{js,jsx}" + + # Dependency manifest and lock files (e.g. updated by Dependabot, Renovate) + - path: >- + **/{package.json,package-lock.json,yarn.lock,pnpm-lock.yaml,npm-shrinkwrap.json,requirements.txt,Pipfile,Pipfile.lock,pyproject.toml,poetry.lock,go.mod,go.sum,Cargo.toml,Cargo.lock,pom.xml,build.gradle,build.gradle.kts,gradle.lockfile,*.gemspec,Gemfile,Gemfile.lock} instructions: | - Ensure newly added or modified methods and properties have brief inline comments: - - - Use minimal, concise inline comments (not JSDoc style) - - Add comments for logical blocks explaining what they do - - Add comments for edge cases and non-obvious logic (safety checks, race condition prevention, re-entrancy guards, cleanup callbacks, etc.) - - No need to document parameters or return values - - Not every function needs comments - only add where it aids understanding - - Flag any newly added or modified function or property that lacks descriptive inline comments for non-obvious logic or edge cases. \ No newline at end of file + This file may be modified by a dependency bot (e.g., Dependabot, Renovate). + Perform a structured dependency upgrade analysis: + + **1. Version Change Assessment** + - Identify all version bumps (major, minor, patch) and flag major/minor upgrades explicitly. + - Check the official release notes, changelog, or migration guide for each upgraded package. + + **2. Breaking Change Detection** + - Breaking changes: removed or renamed APIs, changed function signatures, altered behavior. + - Deprecated APIs: warn if the codebase uses anything deprecated in the new version. + - Configuration changes: new required env vars, config keys, or file structure changes. + - Security fixes: highlight CVE patches and confirm they address known vulnerabilities. + + **3. Codebase Compatibility Check** + - Locate all files in the repo that import or use the upgraded dependency. + - For each usage, verify: + - No removed or renamed imports/functions are referenced. + - Constructor/function call signatures are compatible. + - Any default behavior changes do not silently break existing logic. + + **4. Risk Analysis** + - Runtime errors: type mismatches, missing attributes, changed return types. + - API incompatibility: breaking interface/type changes (critical for TypeScript). + - Logical bugs: subtle behavior changes that don't throw errors but alter outcomes. + - Performance regressions: flag if release notes mention perf impacts. + + **5. Edge Cases to Verify** + - Backward compatibility with currently pinned peer dependencies. + - Changes in default behavior or environment assumptions. + - Peer requirement conflicts introduced by the new version. + - For TypeScript: type/interface changes that may require type assertion updates. + + **6. Migration Guidance** + - If official docs provide migration steps, summarize the required changes and flag + specific files in this repo that need updates. + - If no migration is required, confirm this explicitly. + + Conclude with a **risk level**: Low / Medium / High, with justification. diff --git a/.editorconfig b/.editorconfig index 02a9ca70..6a372ed2 100644 --- a/.editorconfig +++ b/.editorconfig @@ -1,20 +1,60 @@ -# EditorConfig is awesome: https://EditorConfig.org +# EditorConfig helps maintain consistent coding styles across different editors and IDEs +# Documentation: https://editorconfig.org/ -# top-most EditorConfig file +# Top-most EditorConfig file root = true -# Unix-style newlines with a newline ending every file +# Universal settings for all files [*] +charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true -charset = utf-8 - -# Indentation override for all JS and JSX files -[*.{js,jsx,json,css,html}] indent_style = space -indent_size = 2 +indent_size = 4 # Markdown files [*.md] +# Trailing whitespace is significant in Markdown (two spaces = line break) trim_trailing_whitespace = false + +# JavaScript / TypeScript / Web / Config files (2-space indentation) +[*.{js,jsx,ts,tsx,json,yml,yaml}] +indent_size = 2 + +# Shell scripts (2 spaces common practice) +[*.sh] +indent_size = 2 + +# Makefiles (must use tabs) +[{Makefile,*.mk}] +indent_style = tab +tab_width = 4 + + + +# For full list of Supported Editors: https://editorconfig.org/#pre-installed +# +# Common Properties: +# ------------------ +# - indent_style: "space" or "tab" +# - indent_size: number of columns for each indentation level +# - end_of_line: "lf", "cr", or "crlf" +# - charset: "utf-8", "utf-16be", "utf-16le", "latin1" +# - trim_trailing_whitespace: true or false +# - insert_final_newline: true or false +# - max_line_length: number (not supported by all editors) +# +# File Pattern Matching: +# ---------------------- +# - * : matches any string of characters (except path separator) +# - ** : matches any string of characters +# - ? : matches any single character +# - [name] : matches any single character in name +# - [!name] : matches any single character not in name +# - {s1,s2,s3} : matches any of the strings given (comma-separated) +# +# For more information and queries: +# - Official Documentation: https://editorconfig.org/ +# - Specification: https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties +# - Plugin Downloads: https://editorconfig.org/#download \ No newline at end of file diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 00000000..7d1465d3 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,2 @@ +.github/workflows/*.yml linguist-detectable -linguist-vendored +.github/workflows/*.yaml linguist-detectable -linguist-vendored \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml index 23f7c8cf..b9c8ce7b 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.yml +++ b/.github/ISSUE_TEMPLATE/bug_report.yml @@ -1,7 +1,7 @@ name: Bug Report description: Report a bug or issue -title: '[BUG]: ' -labels: ['bug', 'triage-needed'] +title: "[BUG]: " +labels: ["bug", "triage-needed"] body: - type: markdown attributes: @@ -75,8 +75,6 @@ body: label: Code of Conduct description: By submitting this issue, you agree to follow our Code of Conduct and join our Discord options: - - label: I agree to follow the Code of Conduct - required: true - label: I have joined the [Discord server](https://discord.gg/hjUhu33uAn) and will post updates there required: true - label: I have searched existing issues to avoid duplicates diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml index f6509f12..f4d17ebf 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.yml +++ b/.github/ISSUE_TEMPLATE/feature_request.yml @@ -1,7 +1,7 @@ name: Feature Request description: Suggest a new feature or enhancement -title: '[FEATURE]: ' -labels: ['enhancement', 'triage-needed'] +title: "[FEATURE]: " +labels: ["enhancement", "triage-needed"] body: - type: markdown attributes: diff --git a/.github/ISSUE_TEMPLATE/good_first_issue.yml b/.github/ISSUE_TEMPLATE/good_first_issue.yml index da31889e..6f1ae364 100644 --- a/.github/ISSUE_TEMPLATE/good_first_issue.yml +++ b/.github/ISSUE_TEMPLATE/good_first_issue.yml @@ -1,7 +1,7 @@ name: Good First Issue description: A beginner-friendly issue to get started with contributing -title: '[GOOD FIRST ISSUE]: ' -labels: ['good first issue', 'triage-needed'] +title: "[GOOD FIRST ISSUE]: " +labels: ["good first issue", "triage-needed"] body: - type: markdown attributes: @@ -36,7 +36,7 @@ body: label: Resources description: Helpful resources for completing this task value: | - - [Contribution Guide - Start Here!](/CONTRIBUTING.md) + - [Contribution Guide - Start Here!](https://github.com/AOSSIE-Org/TODO/blob/main/CONTRIBUTING.md) - [Discord Channel](https://discord.gg/hjUhu33uAn) validations: required: false @@ -45,7 +45,7 @@ body: attributes: value: | ## AI Notice - Important! - + We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact. - type: checkboxes @@ -56,7 +56,7 @@ body: options: - label: I have joined the [Discord server](https://discord.gg/hjUhu33uAn) and will post updates there required: true - - label: I have read the [Contribution Guide](/CONTRIBUTING.md) + - label: I have read the [Contribution Guide](https://github.com/AOSSIE-Org/Template-Repo/blob/main/CONTRIBUTING.md) required: true - label: I understand this issue is assigned on a first-come, first-served basis required: true diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 452a3281..68c53348 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,27 +1,24 @@ -# Addressed Issues: - +### Addressed Issues: - Fixes #(issue number) -## Screenshots/Recordings: +### Screenshots/Recordings: -## Additional Notes: +### Additional Notes: -## Checklist +## Checklist - - [ ] My code follows the project's code style and conventions - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings or errors - [ ] I have joined the [Discord server](https://discord.gg/hjUhu33uAn) and I will share a link to this PR with the project maintainers there -- [ ] I have read the [Contributing Guidelines](../CONTRIBUTING.md) +- [ ] I have read the [Contributing Guidelines](./CONTRIBUTING.md) ## ⚠️ AI Notice - Important! -We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact. AI slop is strongly discouraged and may lead to banning and blocking. Do not spam our repos with AI slop. + We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact. diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 06ae171c..af82e930 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -1,25 +1,264 @@ +# Dependabot Configuration for Multi-Domain Projects +# Documentation: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file + +# ============================================================================ +# CUSTOMIZATION GUIDE +# ============================================================================ +# 1. Remove package ecosystems not used in your project (e.g., if no Java, remove maven & gradle) +# 2. Update "directory" if dependencies are in subdirectories (e.g., "/backend", "/frontend") +# 3. Adjust "schedule" timing based on your team's workflow +# 4. Set "open-pull-requests-limit" based on your review capacity (default: 5) +# 5. Add reviewers/assignees if needed: +# reviewers: +# - "username" # Individual GitHub user +# - "org/team-name" # Organization team +# assignees: +# - "username" +# 6. Customize labels to match your project's labeling system +# 7. Use "ignore" to exclude specific dependencies or update types +# 8. For monorepos, duplicate sections with different "directory" values +# ============================================================================ + version: 2 updates: - # Maintain dependencies for GitHub Actions + # NPM - JavaScript/Node.js projects + # Remove this section if your project doesn't use npm + - package-ecosystem: "npm" + directory: "/" # Change to "/frontend" or "/backend" for monorepos + schedule: + interval: "weekly" # Options: daily, weekly, monthly + day: "monday" # For weekly: monday-sunday + time: "09:00" # UTC time + open-pull-requests-limit: 5 # Max PRs to keep open + labels: + - "dependencies" + - "npm" + commit-message: + prefix: "chore(deps)" # Follows conventional commits + include: "scope" + pull-request-branch-name: + separator: "-" # Creates branches like: dependabot/npm-package-name + + # GitHub Actions - Keep workflows up to date (recommended for all projects) - package-ecosystem: "github-actions" + directory: "/" # Scans .github/workflows/ + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "github-actions" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Docker - Containerized applications + # Remove this section if your project doesn't use Docker + - package-ecosystem: "docker" + directory: "/" # Directory containing Dockerfile + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "docker" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Bundler - Ruby projects + # Remove this section if your project doesn't use Ruby + - package-ecosystem: "bundler" directory: "/" schedule: interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "ruby" commit-message: prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" - # Maintain dependencies for npm/pnpm - - package-ecosystem: "npm" + # Cargo - Rust projects + # Remove this section if your project doesn't use Rust + - package-ecosystem: "cargo" directory: "/" schedule: interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "rust" commit-message: prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" - # Maintain dependencies for landing-page - - package-ecosystem: "npm" - directory: "/landing-page" + # Maven - Java projects + # Remove this section if your project uses Gradle instead or doesn't use Java + - package-ecosystem: "maven" + directory: "/" + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "java" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Gradle - Java/Kotlin/Android projects + # Remove this section if your project uses Maven instead or doesn't use Java/Kotlin + - package-ecosystem: "gradle" + directory: "/" + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "java" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Composer - PHP projects + # Remove this section if your project doesn't use PHP + - package-ecosystem: "composer" + directory: "/" + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "php" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Go Modules - Go projects + # Remove this section if your project doesn't use Go + - package-ecosystem: "gomod" + directory: "/" + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "go" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Pip - Python projects (supports pip, pipenv, poetry) + # Remove this section if your project doesn't use Python + - package-ecosystem: "pip" + directory: "/" # Directory containing requirements.txt, Pipfile, or pyproject.toml + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "python" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + # Uncomment and customize for AI/ML projects to prevent breaking changes: + # ignore: + # - dependency-name: "tensorflow" + # update-types: ["version-update:semver-major"] + # - dependency-name: "torch" + # update-types: ["version-update:semver-major"] + # - dependency-name: "scikit-learn" + # update-types: ["version-update:semver-major"] + + # Terraform - Infrastructure as Code + # Remove this section if your project doesn't use Terraform + - package-ecosystem: "terraform" + directory: "/" # Directory containing .tf files + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "infrastructure" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # Pub - Dart/Flutter projects + # Remove this section if your project doesn't use Dart/Flutter + - package-ecosystem: "pub" + directory: "/" + schedule: + interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "flutter" + - "dart" + commit-message: + prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" + + # NuGet - .NET projects (C#, F#, VB.NET) + # Remove this section if your project doesn't use .NET + - package-ecosystem: "nuget" + directory: "/" schedule: interval: "weekly" + day: "monday" + time: "09:00" + open-pull-requests-limit: 5 + labels: + - "dependencies" + - "dotnet" commit-message: prefix: "chore(deps)" + include: "scope" + pull-request-branch-name: + separator: "-" diff --git a/.github/initial-issues.json b/.github/initial-issues.json new file mode 100644 index 00000000..109554ba --- /dev/null +++ b/.github/initial-issues.json @@ -0,0 +1,287 @@ +{ + "issues": [ + { + "title": "Documentation: Add Project Title, Description, Badges and Basic Info", + "body": "## Description\nAdd clear project title, description, badges, and logo/banner to README to establish project identity.\n\n## Tasks\n- [ ] Add clear project title and description\n- [ ] Include project logo/banner (if available)\n- [ ] Add favicon (if applicable)\n- [ ] Add informative badges (build status, license, version, tech stack, coverage, etc.)\n\n## Resources\n- [README Template](https://github.com/AOSSIE-Org/Template-Repo/blob/main/README_TEMPLATE.md)\n- [Shields.io](https://shields.io/) for badge generation\n", + "labels": [ + "documentation", + "good-first-issue", + "setup" + ] + }, + { + "title": "Documentation: Write Installation Instructions", + "body": "## Description\nWrite clear, step-by-step installation instructions for the project.\n\n## Tasks\n- [ ] Document prerequisites\n- [ ] Write installation steps\n- [ ] Include platform-specific instructions if needed\n- [ ] Add troubleshooting tips for common installation issues\n\n## Best Practices\n- Make it beginner-friendly\n- Test instructions on a fresh environment\n- Include commands that can be copy-pasted\n\n## Resources\n- [README Template](https://github.com/AOSSIE-Org/Template-Repo/blob/main/README_TEMPLATE.md)\n", + "labels": [ + "documentation", + "good-first-issue", + "setup" + ] + }, + { + "title": "Documentation: Add Usage Examples and Code Snippets", + "body": "## Description\nAdd practical usage examples and code snippets to help users get started quickly.\n\n## Tasks\n- [ ] Write basic usage examples\n- [ ] Add code snippets for common use cases\n- [ ] Include expected output/results\n- [ ] Add links to more detailed documentation if applicable\n\n## Resources\n- [README Template](https://github.com/AOSSIE-Org/Template-Repo/blob/main/README_TEMPLATE.md)\n", + "labels": [ + "documentation", + "good-first-issue", + "setup" + ] + }, + { + "title": "Documentation: Complete README Content", + "body": "## Description\nComplete the README with comprehensive project documentation including features, navigation, and visual elements.\n\n## Tasks\n- [ ] Document all major project features with examples\n- [ ] Add table of contents for easy navigation\n- [ ] Add link to CONTRIBUTING.md\n- [ ] Add Discord/communication channels information\n- [ ] Include screenshots/GIFs/demo links (if applicable)\n- [ ] Optimize images for web (file size)\n\n## Resources\n- [README Template](https://github.com/AOSSIE-Org/Template-Repo/blob/main/README_TEMPLATE.md)\n", + "labels": [ + "documentation", + "good-first-issue", + "setup" + ] + }, + { + "title": "CI/CD: Set up Build Workflow", + "body": "## Description\nConfigure GitHub Actions workflow for automated building.\n\n## Tasks\n- [ ] Create build workflow file in .github/workflows/\n- [ ] Configure build triggers (push, pull request)\n- [ ] Set up build steps for your project\n- [ ] Add build status badge to README\n- [ ] Test workflow execution\n\n## Resources\n- [GitHub Actions Documentation](https://docs.github.com/en/actions)\n", + "labels": [ + "setup", + "automation", + "ci-cd" + ] + }, + { + "title": "CI/CD: Set up Deployment Pipeline (GitHub Pages for frontend-only projects)", + "body": "## Description\nConfigure automated deployment workflow for production/staging environments. For backend-free frontend projects, deploy to GitHub Pages.\n\n## Tasks\n- [ ] Create deployment workflow\n- [ ] Configure deployment triggers\n- [ ] For frontend-only projects: Set up GitHub Pages deployment\n- [ ] For projects with backend: Configure deployment to appropriate hosting service\n- [ ] Set up environment-specific configurations\n- [ ] Add deployment status checks\n- [ ] Test deployment process\n- [ ] Document deployment procedures\n\n## Notes\n- Frontend-only projects should use GitHub Pages for free hosting\n- Projects with backends should specify their deployment target (Heroku, AWS, etc.)", + "labels": [ + "setup", + "automation", + "deployment", + "ci-cd" + ] + }, + { + "title": "Security: Setup Dependabot", + "body": "## Description\nEnable and configure Dependabot for automated dependency updates and security alerts.\n\n## Tasks\n- [ ] Enable Dependabot alerts in repository settings\n- [ ] Enable Dependabot security updates\n- [ ] Create or review .github/dependabot.yml\n- [ ] Configure update schedule and package ecosystems\n- [ ] Set up notification preferences\n- [ ] Review existing security alerts\n- [ ] Test Dependabot pull requests\n\n## Resources\n- [Dependabot Documentation](https://docs.github.com/en/code-security/dependabot)\n- [Dependabot Configuration Options](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file)\n", + "labels": [ + "security", + "dependencies", + "setup" + ] + }, + { + "title": "Code Quality: Setup Linting", + "body": "## Description\nConfigure code linting tools to maintain code quality and integrate into CI pipeline.\n\n## Tasks\n- [ ] Choose appropriate linter (ESLint, Flake8, RuboCop, etc.)\n- [ ] Install linter dependencies\n- [ ] Create linter configuration file\n- [ ] Run linter on existing code\n- [ ] Fix or document linting issues\n- [ ] Create linting workflow in .github/workflows/\n- [ ] Configure linter to run on pull requests\n- [ ] Add linting status badge to README\n- [ ] Update CONTRIBUTING.md with linting requirements\n\n## Resources\n- [GitHub Actions Documentation](https://docs.github.com/en/actions)\n- Check CONTRIBUTING.md for code style guidelines\n", + "labels": [ + "code-quality", + "setup", + "automation" + ] + }, + { + "title": "Code Quality: Configure CodeRabbit Multi-Repo Analysis (if applicable)", + "body": "## Description\nCodeRabbit supports multi-repo analysis, which lets it use other repositories as context when reviewing PRs. The `.coderabbit.yaml` in this repository already contains a commented-out `knowledge_base` section ready to be filled in.\n\n## When is this useful?\n- **Microservices** — a change to one service's API may break consumers in other repos\n- **Shared libraries** — modifications to a shared utility can have ripple effects across multiple repos\n- **API contracts** — when a backend API changes, frontend/mobile repos may need coordinated updates\n- **Database schemas** — schema changes can affect all services querying the same data model\n- **Frontend ↔ backend** — link tightly coupled client/server repos for cross-repo awareness\n\n> **Note:** Do not configure this at the org level — link only the repos directly relevant to this project.\n\n## Tasks\n- [ ] Identify related repositories that would provide useful context for PR reviews\n- [ ] Open `.coderabbit.yaml` and locate the commented-out `knowledge_base` block\n- [ ] Uncomment the block and replace the placeholder values with the actual org and repo names\n- [ ] Open a PR with the change and verify CodeRabbit uses the linked repos as context\n\n## Example\n```yaml\nknowledge_base:\n linked_repositories:\n - repository: \"your-org/related-repo\"\n instructions: \"Brief description of what this repo contains and why it's relevant\"\n```\n\n## Resources\n- [CodeRabbit Multi-Repo Analysis Docs](https://docs.coderabbit.ai/knowledge-base/multi-repo-analysis)\n\n**Note**: If this project has no meaningfully related repositories, you can close this issue.\n", + "labels": [ + "code-quality", + "setup", + "good-first-issue" + ] + }, + + { + "title": "Frontend: Add Required Footer Elements(if applicable)", + "body": "## Description\nIf this is a frontend project, ensure it has a proper footer with all required elements.\n\n## Tasks\n- [ ] Verify footer exists on all pages\n- [ ] Add copyright statement: \"\u00a9 2025 AOSSIE\"\n- [ ] Add \"KYA (Know Your Assumptions)\" link/element\n- [ ] Ensure footer is consistent across all pages\n\n## Requirements\nAll AOSSIE frontends must include:\n- Copyright statement: `\u00a9 2025 AOSSIE`\n- KYA (Know Your Assumptions)\n\n## Resources\n- [Bene](https://ergo.bene.stability.nexus/) for Ergo is a project that does KYA very nicely, as a modal that is shown when the user first visits the website and also when the user clicks the link in the footer. We should follow this approach.\n- [KYA Template](https://github.com/StabilityNexus/Info/blob/main/KYA.md) - Use this template for creating your KYA content.\n\n**Note**: If this is not a frontend project, you can close this issue.\n", + "labels": [ + "frontend", + "documentation", + "setup" + ] + }, + { + "title": "Frontend: Setup Social Share Button (if applicable)", + "body": "## Description\nIf this is a frontend project, integrate the AOSSIE Social Share Button to allow users to easily share content across multiple social platforms.\n\n## Tasks\n- [ ] Install the SocialShareButton package\n- [ ] Configure share button with appropriate platforms\n- [ ] Customize button styling to match project theme\n- [ ] Add share button to relevant pages/components\n- [ ] Test sharing functionality across different platforms\n- [ ] Add documentation for share button usage\n\n## About\nThe Social Share Button is a lightweight JavaScript library that enables easy sharing to multiple social platforms including Facebook, Twitter, LinkedIn, Reddit, WhatsApp, Telegram, and more.\n\n## Resources\n- [AOSSIE Social Share Button Repository](https://github.com/AOSSIE-Org/SocialShareButton)\n- Check the README for installation and configuration instructions\n\n**Note**: If this is not a frontend project, you can close this issue.\n", + "labels": [ + "frontend", + "enhancement", + "setup" + ] + }, + { + "title": "Frontend: Implement Responsive Design for Mobile (if applicable)", + "body": "## Description\nEnsure the frontend displays properly across all screen sizes, especially mobile devices. Many AOSSIE projects have frontends where element sizes do not adjust well for smaller screens.\n\n## Tasks\n- [ ] Audit all pages for mobile responsiveness\n- [ ] Implement responsive CSS using media queries or modern frameworks\n- [ ] Test on various screen sizes (mobile, tablet, desktop)\n- [ ] Ensure touch-friendly interactive elements (minimum 44x44px)\n- [ ] Fix any text overflow or layout breaking issues\n- [ ] Optimize images for different screen sizes\n- [ ] Test on actual mobile devices (iOS and Android)\n- [ ] Ensure proper viewport meta tag is set\n- [ ] Verify navigation/menu works well on mobile\n- [ ] Check that all buttons and forms are easily usable on mobile\n\n## Best Practices\n- Use mobile-first approach\n- Use relative units (rem, em, %, vw, vh) instead of fixed pixels\n- Test across multiple devices and browsers\n- Consider using CSS frameworks with built-in responsiveness\n- Ensure proper spacing and padding for touch targets\n\n## Resources\n- [Responsive Web Design Basics](https://web.dev/responsive-web-design-basics/)\n- [MDN Responsive Design Guide](https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design)\n\n**Note**: If this is not a frontend project, you can close this issue.\n", + "labels": [ + "frontend", + "enhancement", + "mobile", + "ux" + ] + }, + { + "title": "Frontend: Implement SEO Meta Tags (if applicable)", + "body": "## Description\nAdd proper meta tags for SEO and social media sharing.\n\n## Tasks\n- [ ] Add proper meta tags (title, description, keywords)\n- [ ] Implement Open Graph tags for social media\n- [ ] Add Twitter Card meta tags\n- [ ] Add favicon and app icons\n- [ ] Test meta tags with social media validators\n\n## Best Practices\n- Keep meta descriptions under 160 characters\n- Use descriptive, keyword-rich titles (50-60 characters)\n\n## Resources\n- [MDN SEO Basics](https://developer.mozilla.org/en-US/docs/Glossary/SEO)\n\n**Note**: If this is not a frontend project, you can close this issue.\n", + "labels": [ + "frontend", + "enhancement", + "seo" + ] + }, + { + "title": "Frontend: Implement SEO Technical Setup (if applicable)", + "body": "## Description\nSet up technical SEO infrastructure for search engine visibility.\n\n## Tasks\n- [ ] Create and submit sitemap.xml\n- [ ] Configure robots.txt properly\n- [ ] Add canonical URLs to prevent duplicate content\n- [ ] Implement structured data (Schema.org markup)\n- [ ] Test with Google Search Console\n- [ ] Verify with SEO audit tools\n\n## Resources\n- [Google SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide)\n- [Schema.org Documentation](https://schema.org/)\n- [Google Search Console](https://search.google.com/search-console)\n\n**Note**: If this is not a frontend project, you can close this issue.\n", + "labels": [ + "frontend", + "enhancement", + "seo" + ] + }, + { + "title": "Frontend: Optimize SEO Content Structure (if applicable)", + "body": "## Description\nOptimize content structure and semantics for better SEO.\n\n## Tasks\n- [ ] Optimize page titles and headings (H1, H2, etc.)\n- [ ] Add alt text to all images\n- [ ] Ensure proper internal linking structure\n- [ ] Use semantic HTML5 elements\n- [ ] Ensure content is unique and valuable\n\n## Best Practices\n- Use HTTPS (secure connections)\n- Optimize for Core Web Vitals (LCP, FID, CLS)\n- Make site mobile-friendly (mobile-first indexing)\n\n## Resources\n- [Google SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide)\n\n**Note**: If this is not a frontend project, you can close this issue.\n", + "labels": [ + "frontend", + "enhancement", + "seo" + ] + }, + { + "title": "Blockchain: Add Token List Support for ERC20 Selection (if applicable)", + "body": "## Description\nIf this is an EVM-based blockchain project that allows users to deploy contracts with custom ERC20 tokens, improve the user experience by allowing users to select tokens from a curated list in addition to manually inputting contract addresses.\n\n## Context\nCurrently, some AOSSIE EVM-based projects only support manual ERC20 contract address input. Users should also be able to choose from a pre-populated list of supported tokens for better UX.\n\n## Tasks\n- [ ] Check if this project involves ERC20 token selection for contract deployment\n- [ ] Integrate the StabilityNexus TokenList\n- [ ] Implement UI dropdown/selector for supported tokens\n- [ ] Keep the option for manual contract address input\n- [ ] Validate manually entered contract addresses\n- [ ] Add token logo/icon display in the selector\n- [ ] Implement token search/filter functionality\n- [ ] Add proper error handling for invalid addresses\n- [ ] Test with various tokens from the list\n- [ ] Update documentation with new token selection feature\n\n## Benefits\n- Improved user experience\n- Reduced errors from manual address input\n- Visual token identification with logos\n- Faster token selection\n\n## Resources\n- [StabilityNexus TokenList](https://github.com/StabilityNexus/TokenList) - Check README for integration details and supported tokens\n\n**Note**: If this is not an EVM-based blockchain project, you can close this issue.\n", + "labels": [ + "blockchain", + "enhancement", + "ux" + ] + }, + { + "title": "Backend: Implement Consistent Error Handling (if applicable)", + "body": "## Description\nStandardize error handling across the entire application (backend and frontend) to ensure consistent user experience and easier debugging.\n\n## Tasks\n- [ ] Define standard error response format (status code, message, error code)\n- [ ] Implement centralized error handling middleware/utilities\n- [ ] Create custom error classes for different error types\n- [ ] Add proper HTTP status codes for all error scenarios\n- [ ] Implement user-friendly error messages for frontend\n- [ ] Add detailed error logging for debugging\n- [ ] Handle validation errors consistently\n- [ ] Implement global error boundaries (frontend)\n- [ ] Add error monitoring/tracking integration\n- [ ] Document error codes and their meanings\n- [ ] Test error scenarios thoroughly\n\n## Best Practices\n- Never expose sensitive information in error messages\n- Use appropriate HTTP status codes\n- Log errors with context (request ID, user ID, timestamp)\n- Provide actionable error messages to users\n- Differentiate between client and server errors\n\n## Resources\n- [HTTP Status Codes Guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)\n- [Error Handling Best Practices](https://www.freecodecamp.org/news/error-handling-in-javascript/)\n", + "labels": [ + "backend", + "enhancement", + "good-first-issue" + ] + }, + { + "title": "Backend: Add API Rate Limiting (if applicable)", + "body": "## Description\nImplement rate limiting on API endpoints to prevent abuse, DDoS attacks, and ensure fair usage across all users.\n\n## Tasks\n- [ ] Identify endpoints that need rate limiting\n- [ ] Choose rate limiting strategy (IP-based, user-based, or both)\n- [ ] Implement rate limiting middleware\n- [ ] Define rate limits for different endpoint types\n- [ ] Add proper HTTP 429 responses when limit exceeded\n- [ ] Include rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)\n- [ ] Implement different tiers for authenticated vs anonymous users\n- [ ] Add rate limit monitoring and alerts\n- [ ] Document rate limits in API documentation\n- [ ] Test rate limiting behavior\n- [ ] Consider implementing exponential backoff suggestions\n\n## Recommended Limits\n- Public endpoints: 100 requests per 15 minutes\n- Authenticated users: 1000 requests per hour\n- Admin/privileged users: Higher or no limits\n\n## Resources\n- [Rate Limiting Strategies](https://cloud.google.com/architecture/rate-limiting-strategies-techniques)\n\n**Note**: If this project doesn't have an API backend, you can close this issue.\n", + "labels": [ + "backend", + "security", + "enhancement" + ] + }, + { + "title": "Blockchain: Comprehensive Smart Contract Testing (if applicable)", + "body": "## Description\nImplement thorough unit and integration tests for all smart contracts to ensure security, correctness, and reliability.\n\n## Tasks\n- [ ] Setup testing framework (Hardhat, Foundry, or Truffle)\n- [ ] Write unit tests for all contract functions\n- [ ] Test edge cases and boundary conditions\n- [ ] Implement integration tests for contract interactions\n- [ ] Test access control and permission mechanisms\n- [ ] Test event emissions\n- [ ] Add gas consumption tests\n- [ ] Test upgrade mechanisms (if upgradeable contracts)\n- [ ] Implement fuzzing tests for critical functions\n- [ ] Test failure scenarios and reverts\n- [ ] Achieve minimum 90% code coverage\n- [ ] Add continuous testing in CI/CD pipeline\n- [ ] Document test scenarios and expected behaviors\n\n## Test Categories\n- Unit tests for individual functions\n- Integration tests for multi-contract scenarios\n- Fork tests against mainnet state\n- Invariant/property-based tests\n\n## Resources\n- [Hardhat Testing Guide](https://hardhat.org/tutorial/testing-contracts)\n- [Foundry Testing](https://book.getfoundry.sh/forge/tests)\n- [Smart Contract Testing Best Practices](https://ethereum.org/en/developers/docs/smart-contracts/testing/)\n\n**Note**: If this project doesn't involve smart contracts, you can close this issue.\n", + "labels": [ + "blockchain", + "testing", + "security" + ] + }, + { + "title": "Blockchain: Gas Optimization Audit (if applicable)", + "body": "## Description\nAudit and optimize smart contract gas usage to reduce transaction costs for users. This is an ongoing task where community members can continuously suggest optimizations.\n\n## Tasks\n- [ ] Run gas reporter on all contract functions\n- [ ] Identify gas-heavy operations\n- [ ] Optimize storage usage (use packed structs, minimize storage writes)\n- [ ] Use memory instead of storage where appropriate\n- [ ] Optimize loops and iterations\n- [ ] Use appropriate data types (uint256 vs smaller types)\n- [ ] Remove unnecessary operations and redundant checks\n- [ ] Consider using libraries for common operations\n- [ ] Batch operations where possible\n- [ ] Optimize modifier usage\n- [ ] Use events instead of storage for historical data\n- [ ] Document gas costs for major operations\n- [ ] Compare gas usage before/after optimizations\n\n## Ongoing Optimization\nThis issue can remain open for community members to continuously suggest and implement gas optimizations as new patterns emerge.\n\n## Resources\n- [Gas Optimization Techniques](https://www.rareskills.io/post/gas-optimization)\n- [OpenZeppelin Gas Optimization Tips](https://docs.openzeppelin.com/contracts/4.x/api/utils)\n\n**Note**: If this project doesn't involve smart contracts, you can close this issue.\n", + "labels": [ + "blockchain", + "optimization", + "help-wanted" + ] + }, + { + "title": "Blockchain: Run Automated Security Analysis Tools (if applicable)", + "body": "## Description\nRun automated security tools to identify potential vulnerabilities in smart contracts.\n\n## Tasks\n- [ ] Set up Slither for static analysis\n- [ ] Run Mythril for security scanning\n- [ ] Review and fix identified issues\n- [ ] Integrate security tools into CI pipeline\n- [ ] Document findings and resolutions\n\n## Resources\n- [Slither Documentation](https://github.com/crytic/slither)\n- [Mythril Documentation](https://github.com/ConsenSys/mythril)\n\n**Note**: If this project doesn't involve smart contracts, you can close this issue.\n", + "labels": [ + "blockchain", + "security", + "automation" + ] + }, + { + "title": "Blockchain: Manual Security Audit Checklist (if applicable)", + "body": "## Description\nPerform manual security review of smart contracts against common vulnerabilities.\n\n## Security Checks\n- [ ] Reentrancy protection (use ReentrancyGuard)\n- [ ] Integer overflow/underflow (use SafeMath or Solidity 0.8+)\n- [ ] Access control mechanisms properly implemented\n- [ ] Input validation on all external functions\n- [ ] Check for unchecked return values\n- [ ] Verify proper use of tx.origin vs msg.sender\n- [ ] Review delegatecall usage for security\n- [ ] Check for front-running vulnerabilities\n- [ ] Verify timestamp dependence issues\n- [ ] Review randomness generation (avoid block.timestamp)\n- [ ] Check for denial of service vulnerabilities\n- [ ] Verify proper event logging\n- [ ] Review upgrade mechanisms (if proxy pattern used)\n- [ ] Check for signature replay attacks\n- [ ] Verify proper handling of ETH/token transfers\n\n## Audit Steps\n- [ ] Manual code review by team members\n- [ ] Create security documentation\n- [ ] Consider professional third-party audit\n- [ ] Setup bug bounty program\n\n## Resources\n- [Smart Contract Security Best Practices](https://consensys.github.io/smart-contract-best-practices/)\n- [SWC Registry - Vulnerability Classification](https://swcregistry.io/)\n- [OpenZeppelin Security Tools](https://www.openzeppelin.com/security-audits)\n\n**Note**: If this project doesn't involve smart contracts, you can close this issue.\n", + "labels": [ + "blockchain", + "security", + "critical" + ] + }, + { + "title": "Blockchain: Handle Network Switching Gracefully (if applicable)", + "body": "## Description\nIf this is a blockchain frontend project, implement proper handling when users switch networks in their wallet to ensure smooth user experience and prevent errors.\n\n## Tasks\n- [ ] Detect network changes in wallet\n- [ ] Display current network to user\n- [ ] Show warning when user is on wrong network\n- [ ] Implement automatic network switching prompt\n- [ ] Handle unsupported networks gracefully\n- [ ] Pause/disable actions when on wrong network\n- [ ] Update UI state when network changes\n- [ ] Re-fetch data after network switch\n- [ ] Clear cached data specific to previous network\n- [ ] Test switching between different networks\n- [ ] Add network configuration for all supported chains\n- [ ] Implement fallback RPC endpoints\n- [ ] Display network-specific information (gas prices, block time)\n\n## Best Practices\n- Never assume the network won't change\n- Always validate network before transactions\n- Provide clear feedback about required network\n- Store network-specific data separately\n\n## Resources\n- [MetaMask Network Detection](https://docs.metamask.io/wallet/how-to/detect-network/)\n- [Wagmi Network Handling](https://wagmi.sh/react/hooks/useNetwork)\n\n**Note**: If this is not a blockchain frontend project, you can close this issue.\n", + "labels": [ + "blockchain", + "frontend", + "enhancement", + "ux" + ] + }, + { + "title": "Testing: Add Comprehensive Test Suite", + "body": "## Description\nImplement comprehensive testing including unit, integration, and E2E tests to ensure code quality and reliability.\n\n## Tasks\n\n### Unit Testing\n- [ ] Set up testing framework (Jest, pytest, etc.)\n- [ ] Write unit tests for core modules/functions\n- [ ] Achieve minimum 80% code coverage\n- [ ] Test edge cases and error conditions\n- [ ] Keep tests isolated and independent\n- [ ] Use descriptive test names\n- [ ] Mock external dependencies\n\n### Integration Testing\n- [ ] Identify critical integration points\n- [ ] Write integration tests for API endpoints\n- [ ] Test database interactions\n- [ ] Test external service integrations\n- [ ] Add integration tests to CI pipeline\n\n### End-to-End Testing (if applicable)\n- [ ] Set up E2E testing framework (Playwright, Cypress, Selenium)\n- [ ] Identify critical user journeys\n- [ ] Write E2E tests for main workflows\n- [ ] Add visual regression testing (optional)\n- [ ] Configure E2E tests in CI pipeline\n\n## Best Practices\n- Integrate all tests into CI pipeline\n- Add test documentation\n- Run tests automatically on PRs\n- Keep test suites fast and reliable\n\n## Resources\n- Check your language/framework testing documentation\n- [Playwright Documentation](https://playwright.dev/)\n- [Cypress Documentation](https://www.cypress.io/)\n\n**Note**: E2E tests only applicable for projects with UI components.\n", + "labels": [ + "testing", + "enhancement", + "good-first-issue" + ] + }, + { + "title": "Performance: Optimize Bundle Size and Add Monitoring (if applicable)", + "body": "## Description\nOptimize frontend bundle size to improve load times and set up performance monitoring.\n\n## Tasks\n- [ ] Analyze current bundle size\n- [ ] Implement code splitting\n- [ ] Enable tree shaking\n- [ ] Optimize dependencies (remove unused)\n- [ ] Add compression (gzip/brotli)\n- [ ] Lazy load non-critical components\n- [ ] Add bundle size monitoring\n- [ ] Set up performance monitoring tool\n- [ ] Configure performance alerts\n- [ ] Track Core Web Vitals\n- [ ] Document performance baselines\n\n## Tools\n- [Webpack Bundle Analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer)\n- [Source Map Explorer](https://github.com/danvk/source-map-explorer)\n- [Lighthouse](https://developers.google.com/web/tools/lighthouse)\n\n**Note**: Only applicable for frontend projects.\n", + "labels": [ + "frontend", + "performance", + "optimization" + ] + }, + { + "title": "Documentation: Add API Documentation (if applicable)", + "body": "## Description\nCreate comprehensive API documentation for backend endpoints.\n\n## Tasks\n- [ ] Choose documentation format (OpenAPI/Swagger, etc.)\n- [ ] Document all API endpoints\n- [ ] Include request/response examples\n- [ ] Document authentication requirements\n- [ ] Add error response documentation\n- [ ] Set up interactive API documentation (Swagger UI)\n- [ ] Keep documentation in sync with code\n\n## Tools\n- [Swagger/OpenAPI](https://swagger.io/)\n- [Postman](https://www.postman.com/)\n- [Redoc](https://redocly.com/)\n\n**Note**: Only applicable for projects with API backends.\n", + "labels": [ + "backend", + "documentation", + "api" + ] + }, + { + "title": "Security: Add Environment Variable Validation", + "body": "## Description\nImplement validation for environment variables to catch configuration errors early.\n\n## Tasks\n- [ ] List all required environment variables\n- [ ] Add validation on application startup\n- [ ] Provide clear error messages for missing/invalid vars\n- [ ] Document all environment variables\n- [ ] Add .env.example file with all required variables\n- [ ] Implement type checking for environment values\n\n## Best Practices\n- Fail fast if required variables are missing\n- Never commit actual .env files\n- Use descriptive variable names\n- Document variable purposes and formats\n", + "labels": [ + "security", + "enhancement", + "good-first-issue" + ] + }, + { + "title": "Security: Implement Input Validation and Sanitization", + "body": "## Description\nAdd comprehensive input validation to prevent security vulnerabilities.\n\n## Tasks\n- [ ] Identify all user input points\n- [ ] Implement validation for all inputs\n- [ ] Add sanitization to prevent XSS\n- [ ] Validate file uploads (type, size, content)\n- [ ] Use parameterized queries to prevent SQL injection\n- [ ] Add rate limiting on input-heavy endpoints\n- [ ] Document validation rules\n\n## Best Practices\n- Validate on both client and server side\n- Use allowlist validation (not blocklist)\n- Sanitize output when displaying user content\n- Never trust client-side validation alone\n\n## Resources\n- [OWASP Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)\n", + "labels": [ + "security", + "enhancement", + "critical" + ] + }, + { + "title": "Database: Setup Migrations and Seeding (if applicable)", + "body": "## Description\nSet up database migration system for version-controlled schema changes and seeding scripts for development.\n\n## Tasks\n- [ ] Choose migration tool (Flyway, Liquibase, Alembic, etc.)\n- [ ] Set up migration infrastructure\n- [ ] Create initial migration for current schema\n- [ ] Add migration scripts to version control\n- [ ] Create seed data scripts for development\n- [ ] Add commands to run migrations and seeds\n- [ ] Document migration and seeding workflow\n- [ ] Test migrations (up and down)\n- [ ] Ensure seeds are idempotent\n\n## Best Practices\n- Never modify existing migrations\n- Always make migrations reversible when possible\n- Never run seeds in production\n- Test migrations on staging before production\n- Back up database before running migrations\n\n## Resources\n- [Flyway](https://flywaydb.org/) (Java)\n- [Alembic](https://alembic.sqlalchemy.org/) (Python)\n- [Knex.js](http://knexjs.org/) (Node.js)\n\n**Note**: Only applicable for projects with databases.\n", + "labels": [ + "database", + "backend", + "setup" + ] + }, + { + "title": "Logging: Implement Structured Logging (if applicable)", + "body": "## Description\nImplement structured logging for better log analysis and debugging.\n\n## Tasks\n- [ ] Choose logging library with structured logging support\n- [ ] Replace console.log/print with proper logger\n- [ ] Add log levels (debug, info, warn, error)\n- [ ] Include context in logs (request ID, user ID, etc.)\n- [ ] Add log aggregation (optional)\n- [ ] Configure log rotation\n- [ ] Document logging standards\n\n## Log Levels\n- ERROR: Application errors that need attention\n- WARN: Warning conditions\n- INFO: Informational messages\n- DEBUG: Detailed debug information\n\n## Tools\n- [Winston](https://github.com/winstonjs/winston) (Node.js)\n- [Loguru](https://github.com/Delgan/loguru) (Python)\n- [Serilog](https://serilog.net/) (.NET)\n\n## Resources\n- [Structured Logging Best Practices](https://www.honeycomb.io/blog/structured-logging-and-your-team)\n", + "labels": [ + "backend", + "logging", + "enhancement" + ] + }, + { + "title": "Setup: Add GitHub Repository Social Preview Image", + "body": "## Description\nAdd a social preview image to the GitHub repository to improve visibility and branding when the repository link is shared on social media, messaging apps, or other platforms.\n\n## Tasks\n- [ ] Design or create a social preview image (recommended size: 1280×640 px)\n- [ ] Go to the repository **Settings** on GitHub\n- [ ] Scroll down to the **Social preview** section\n- [ ] Upload the image\n- [ ] Verify the preview looks correct by sharing the repository link\n\n## Image Guidelines\n- Recommended size: **1280×640 px**\n- File formats: PNG, JPG, or GIF\n- Keep file size reasonable (under 1 MB)\n- Include project name, logo, and a short tagline if possible\n- Use high contrast and readable fonts\n- Ensure the image represents the project clearly\n\n## Why This Matters\nWhen users share the repository link on platforms like Twitter, LinkedIn, Slack, or Discord, GitHub automatically uses this image as the link preview thumbnail. A professional social preview image improves the project's credibility and recognition.\n\n## Resources\n- [GitHub Docs: Customizing your repository's social media preview](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview)\n- [Canva](https://www.canva.com/) for designing the image\n- [Figma](https://www.figma.com/) for more advanced design\n", + "labels": [ + "documentation", + "setup", + "good-first-issue" + ] + } + ] +} diff --git a/.github/release-drafter.yml b/.github/release-drafter.yml new file mode 100644 index 00000000..e5a173bc --- /dev/null +++ b/.github/release-drafter.yml @@ -0,0 +1,85 @@ +name-template: 'v$RESOLVED_VERSION' +tag-template: 'v$RESOLVED_VERSION' + +categories: + - title: '🚀 Features' + labels: + - 'feature' + - 'enhancement' + - 'feat' + - title: '🐛 Bug Fixes' + labels: + - 'fix' + - 'bugfix' + - 'bug' + - title: '🧰 Maintenance' + labels: + - 'chore' + - 'maintenance' + - 'refactor' + - title: '📝 Documentation' + labels: + - 'documentation' + - 'docs' + - title: '🔧 Configuration' + labels: + - 'configuration' + - 'config' + - title: '🧪 Tests' + labels: + - 'tests' + - 'test' + - title: '⬆️ Dependencies' + labels: + - 'dependencies' + - 'deps' + - title: '🎨 Frontend' + labels: + - 'frontend' + - 'ui' + - title: '⚙️ Backend' + labels: + - 'backend' + - 'api' + - title: '🔐 Security' + labels: + - 'security' + - title: '🐳 Docker' + labels: + - 'docker' + - title: '🚀 CI/CD' + labels: + - 'ci-cd' + - 'github-actions' + - title: '👥 Contributors' + labels: + - 'first-time-contributor' + - 'repeat-contributor' + - 'org-member' + +change-template: '- $TITLE @$AUTHOR (#$NUMBER)' +change-title-escapes: '\<*_&' + +template: | + ## What's Changed + + $CHANGES + + ## Contributors + + $CONTRIBUTORS + + **Full Changelog**: https://github.com/$OWNER/$REPOSITORY/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION + +exclude-labels: + - 'skip-changelog' + - 'no-changelog' + - 'duplicate' + - 'invalid' + - 'wontfix' + +replacers: + - search: '/CVE-(\d{4})-(\d+)/g' + replace: '[CVE-$1-$2](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-$1-$2)' + +include-pre-releases: false diff --git a/.gitignore b/.gitignore index f80d9346..9308a4b6 100644 --- a/.gitignore +++ b/.gitignore @@ -1,16 +1,326 @@ -node_modules/ -dist/ +## Core latex/pdflatex auxiliary files: +*.aux +*.lof *.log -.DS_Store -.vscode/ -.idea/ -*.swp -*.swo -*~ -.cache/ -coverage/ -.env -.env.local -.env.development.local -.env.test.local -.env.production.local +*.lot +*.fls +*.out +*.toc +*.fmt +*.fot +*.cb +*.cb2 +.*.lb + +## Intermediate documents: +*.dvi +*.xdv +*-converted-to.* +# these rules might exclude image files for figures etc. +# *.ps +# *.eps +# *.pdf + +## Generated if empty string is given at "Please type another file name for output:" +.pdf + +## Bibliography auxiliary files (bibtex/biblatex/biber): +*.bbl +*.bbl-SAVE-ERROR +*.bcf +*.bcf-SAVE-ERROR +*.blg +*-blx.aux +*-blx.bib +*.run.xml + +## Build tool auxiliary files: +*.fdb_latexmk +*.synctex +*.synctex(busy) +*.synctex.gz +*.synctex.gz(busy) +*.pdfsync +*.rubbercache +rubber.cache + +## Build tool directories for auxiliary files +# latexrun +latex.out/ + +## Auxiliary and intermediate files from other packages: +# algorithms +*.alg +*.loa + +# achemso +acs-*.bib + +# amsthm +*.thm + +# attachfile2 +*.atfi + +# beamer +*.nav +*.pre +*.snm +*.vrb + +# changes +*.soc +*.loc + +# comment +*.cut + +# cprotect +*.cpt + +# elsarticle (documentclass of Elsevier journals) +*.spl + +# endnotes +*.ent + +# fixme +*.lox + +# feynmf/feynmp +*.mf +*.mp +*.t[1-9] +*.t[1-9][0-9] +*.tfm + +#(r)(e)ledmac/(r)(e)ledpar +*.end +*.?end +*.[1-9] +*.[1-9][0-9] +*.[1-9][0-9][0-9] +*.[1-9]R +*.[1-9][0-9]R +*.[1-9][0-9][0-9]R +*.eledsec[1-9] +*.eledsec[1-9]R +*.eledsec[1-9][0-9] +*.eledsec[1-9][0-9]R +*.eledsec[1-9][0-9][0-9] +*.eledsec[1-9][0-9][0-9]R + +# glossaries +*.acn +*.acr +*.glg +*.glg-abr +*.glo +*.glo-abr +*.gls +*.gls-abr +*.glsdefs +*.lzo +*.lzs +*.slg +*.slo +*.sls + +# uncomment this for glossaries-extra (will ignore makeindex's style files!) +# *.ist + +# gnuplot +*.gnuplot +*.table + +# gnuplottex +*-gnuplottex-* + +# gregoriotex +*.gaux +*.glog +*.gtex + +# htlatex +*.4ct +*.4tc +*.idv +*.lg +*.trc +*.xref + +# hypdoc +*.hd + +# hyperref +*.brf + +# knitr +*-concordance.tex +# TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files +# *.tikz +*-tikzDictionary + +# latexindent will create succesive backup files by default +#*.bak* + +# listings +*.lol + +# luatexja-ruby +*.ltjruby + +# makeidx +*.idx +*.ilg +*.ind + +# minitoc +*.maf +*.mlf +*.mlt +*.mtc[0-9]* +*.slf[0-9]* +*.slt[0-9]* +*.stc[0-9]* + +# minted +_minted* +*.data.minted +*.pyg + +# morewrites +*.mw + +# newpax +*.newpax + +# nomencl +*.nlg +*.nlo +*.nls + +# pax +*.pax + +# pdfpcnotes +*.pdfpc + +# sagetex +*.sagetex.sage +*.sagetex.py +*.sagetex.scmd + +# scrwfile +*.wrt + +# spelling +*.spell.bad +*.spell.txt + +# svg +svg-inkscape/ + +# sympy +*.sout +*.sympy +sympy-plots-for-*.tex/ + +# pdfcomment +*.upa +*.upb + +# pythontex +*.pytxcode +pythontex-files-*/ + +# tcolorbox +*.listing + +# thmtools +*.loe + +# TikZ & PGF +*.dpth +*.md5 +*.auxlock + +# titletoc +*.ptc + +# todonotes +*.tdo + +# vhistory +*.hst +*.ver + +# easy-todo +*.lod + +# xcolor +*.xcp + +# xmpincl +*.xmpi + +# xindy +*.xdy + +# xypic precompiled matrices and outlines +*.xyc +*.xyd + +# endfloat +*.ttt +*.fff + +# Latexian +TSWLatexianTemp* + +## Editors: +# WinEdt +*.bak +*.sav + +# latexindent.pl +*.bak[0-9]* + +# Texpad +.texpadtmp + +# LyX +*.lyx~ + +# Kile +*.backup + +# gummi +.*.swp + +# KBibTeX +*~[0-9]* + +# TeXnicCenter +*.tps + +# auto folder when using emacs and auctex +./auto/* +*.el + +# expex forward references with \gathertags +*-tags.tex + +# standalone packages +*.sta + +# Makeindex log files +*.lpz + +# xwatermark package +*.xwm + +# REVTeX puts footnotes in the bibliography by default, unless the nofootinbib +# option is specified. Footnotes are the stored in a file with suffix Notes.bib. +# Uncomment the next line to have this generated file ignored. +#*Notes.bib diff --git a/.goreleaser.yaml b/.goreleaser.yaml new file mode 100644 index 00000000..16a9ffbd --- /dev/null +++ b/.goreleaser.yaml @@ -0,0 +1,198 @@ +# https://goreleaser.com/customization/ +# 1. Uncomment only the sections relevant to your project type +# 2. Fill in placeholders marked with +# 3. Run `goreleaser check` to validate before pushing + +version: 2 + +project_name: template-repo # replace with project name e.g. my-tool, my-project + +# before: +# hooks: + # Clean up build artifacts before release + # - go mod tidy # [GO] uncomment if Go project + # - npm ci # [NODE] Uncomment for Node.js projects + # - bun install --frozen # [NODE/BUN] Uncomment for Bun projects + +env: + - GITHUB_TOKEN={{ .Env.GITHUB_TOKEN }} + # - NPM_TOKEN={{ .Env.NPM_TOKEN }} # [NODE] Uncomment if publishing to npm + # - DOCKER_USERNAME={{ .Env.DOCKER_USERNAME }} # [DOCKER] Uncomment if pushing to Docker Hub + +# builds: +# # [GO] — Go binary build (most common for CLI tools, GitHub Actions runners) +# - id: go-build +# builder: go +# main: ./main.go # Entry point — change to ./cmd//main.go if needed +# binary: template-repo # Output binary name e.g. my-project +# env: +# - CGO_ENABLED=0 # Disable CGO for static binaries (recommended for Actions) +# goos: +# - linux +# - darwin +# - windows +# goarch: +# - amd64 +# - arm64 +# ldflags: +# # Embed version info at build time +# - -s -w +# - -X main.version={{ .Version }} +# - -X main.commit={{ .Commit }} +# - -X main.date={{ .Date }} + # [GO] Uncomment if building multiple binaries from the same repo + # targets: + # - linux_amd64 + # - linux_arm64 + # - darwin_amd64 + # - darwin_arm64 + # - windows_amd64 + + # [NODE] — Node.js project build, Uncomment this entire block if your project is Node.js/Bun based + # - id: node-build + # builder: node + # command: build # Runs `npm run build` or equivalent + # ids: [] + # # For Bun projects, replace builder with: + # # builder: bun + # # command: build + + # [PYTHON] — Python project (uv/poetry),Uncomment this entire block if your project is Python based + # - id: python-build + # builder: uv # Options: uv, poetry, python + # # For Poetry projects replace with: + # # builder: poetry + + # [PREBUILT] — Import pre-built binaries, Use if you build binaries in a prior CI step and just want GoReleaser to package + # - id: prebuilt-import + # builder: prebuilt + # goos: + # - linux + # - darwin + # - windows + # goarch: + # - amd64 + # - arm64 + # prebuilt: + # path: dist/{{ .Os }}_{{ .Arch }}/{{ .ProjectName }} + +archives: + - id: default-archive + name_template: "{{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}" + wrap_in_directory: true # Wrap binary in a directory inside the archive + files: + - LICENSE + - README.md + - CHANGELOG.md + # Uncomment if shipping ABI/contract artifacts with release ( for web3 projects) + # - artifacts/abi/** + # - artifacts/addresses.json + format_overrides: # Windows gets .zip, everything else gets .tar.gz + - goos: windows + format: zip + + # [NODE] Uncomment if your project produces a dist/ folder to archive + # - id: node-archive + # ids: [node-build] + # name_template: "{{ .ProjectName }}_{{ .Version }}_js" + # files: + # - dist/** + # - package.json + # - README.md + +# include checksums for security/verification +checksum: + name_template: "{{ .ProjectName }}_{{ .Version }}_checksums.txt" + algorithm: sha256 + +# source archive of the full repository at the release tag, useful for source-based distributions and OpenSSF compliance +source: + enabled: true + name_template: "{{ .ProjectName }}_{{ .Version }}_source" + +# SBOM — Software Bill of Materials generation for supply chain transparency +sboms: + - artifacts: archive + # Requires syft to be installed: https://github.com/anchore/syft + +# SIGNING — Sign release artifacts with cosign (keyless via GitHub OIDC) +# signs: +# - cmd: cosign +# args: +# - sign-blob +# - --output-signature=${signature} +# - ${artifact} +# - --yes +# artifacts: checksum + + +# [DOCKER] Uncomment this entire section if your project has a Dockerfile +# docker_builds: +# - id: docker-linux +# ids: [go-build] # Reference your build id above; or remove for non-Go +# goos: linux +# goarchs: +# - amd64 +# - arm64 +# image_templates: +# - "ghcr.io/{{ .Env.GITHUB_REPOSITORY_OWNER }}/{{ .ProjectName }}:{{ .Version }}-{{ .Os }}-{{ .Arch }}" +# - "ghcr.io/{{ .Env.GITHUB_REPOSITORY_OWNER }}/{{ .ProjectName }}:latest" +# build_flag_templates: +# - --label=org.opencontainers.image.title={{ .ProjectName }} +# - --label=org.opencontainers.image.version={{ .Version }} +# - --label=org.opencontainers.image.created={{ .Date }} +# - --label=org.opencontainers.image.revision={{ .FullCommit }} +# - --label=org.opencontainers.image.source={{ .GitURL }} +# # Optional: push to Docker Hub as well +# # extra_files: +# # - docker-compose.yml + +# [NODE] Uncomment if your project is an npm package, Requires NPM_TOKEN secret in GitHub Actions +# nfpms: [] # Not applicable for npm — GoReleaser publishes npm directly: +# publishers: +# - name: npm +# cmd: npm publish --access public +# env: +# - NODE_AUTH_TOKEN={{ .Env.NPM_TOKEN }} +# dir: "{{ dir .ArtifactPath }}" +# artifacts: archive +# ids: [node-archive] + + +# [WEB3] Uncomment if your project compiles Solidity/Hardhat/Foundry contracts, This publishes ABI + bytecode artifacts alongside the release +# before hooks for WEB3 — add to before.hooks above: +# - forge build --sizes # Foundry projects +# - npx hardhat compile # Hardhat projects +# +# extra_files: +# - glob: ./artifacts/contracts/**/*.json +# - glob: ./deployments/**/*.json # deployment addresses per network +# - glob: ./broadcast/**/*-latest.json # Foundry broadcast logs + +release: # Release metadata and GitHub release configuration + github: + owner: AOSSIE-Org + name: template-repo # Repo name e.g. pr-feedback-action + # Make release a draft first so maintainer can review before publishing + draft: false + # Set to true to mark as a pre-release if version has a pre-release tag (e.g. v1.0.0-beta.1) + prerelease: auto + # Override release name + name_template: "{{ .ProjectName }} {{ .Version }}" + # [OPTIONAL] Point to a hand-crafted release notes file instead of auto-changelog + # release_notes: RELEASE_NOTES.md + +# CHANGELOG generation disabled here because Release Drafter already produces changelog drafts via .github/release-drafter.yml + +# [MONOREPO] Uncomment if this template repo spans multiple sub-projects. Each sub-project should have its own .goreleaser.yaml that includes this base +# monorepo: +# tag_prefix: "{{ .ProjectName }}/" +# dir: . # Root of the monorepo + +# SNAPSHOT — Local test builds (no git tag required) +# Run: goreleaser release --snapshot --clean +snapshot: + version_template: "{{ .Tag }}-SNAPSHOT-{{ .ShortCommit }}" + +# REPORT SIZES — Print artifact size table after build which is useful for tracking binary bloat over releases +report_sizes: true \ No newline at end of file diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 00000000..2a9b56dd --- /dev/null +++ b/.pre-commit-config.yaml @@ -0,0 +1,52 @@ +# Pre-commit hooks configuration +# Documentation: https://pre-commit.com/ +# +# Installation: +# pip install pre-commit +# pre-commit install +# +# Usage: +# pre-commit run --all-files # Run on all files +# pre-commit run # Run specific hook +# +# For queries and documentation, visit: https://pre-commit.com/hooks.html + +repos: + # ---------------------------------- + # 1. Universal Git / file hygiene + # ---------------------------------- + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v4.5.0 + hooks: + - id: trailing-whitespace + - id: end-of-file-fixer + - id: check-merge-conflict + - id: check-added-large-files + - id: mixed-line-ending + args: ['--fix=lf'] + + # ---------------------------------- + # 2. Config & data files validation + # ---------------------------------- + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v4.5.0 + hooks: + - id: check-yaml + - id: check-json + - id: check-toml + + # ---------------------------------- + # 3. Security (language-agnostic) + # ---------------------------------- + - repo: https://github.com/Yelp/detect-secrets + rev: v1.4.0 + hooks: + - id: detect-secrets + + # args: ['--baseline', '.secrets.baseline'] (Maintainers should add a .secrets.baseline file for secret scanning.) + +# ============================================================================== +# IMPORTANT: +# Pre-commit runs locally every time you commit; only simple logic should be included here. +# Heavy operations should be handled by CI/CD pipelines (GitHub Actions, etc.) +# ============================================================================== diff --git a/.vscode/extensions.json b/.vscode/extensions.json new file mode 100644 index 00000000..7d81e368 --- /dev/null +++ b/.vscode/extensions.json @@ -0,0 +1,19 @@ +{ + "recommendations": [ + "DavidAnson.vscode-markdownlint", // Markdown linting + "eamodio.gitlens", // Git integration and visualization + "esbenp.prettier-vscode", // Code formatter + "github.vscode-github-actions", // GitHub Actions support + "github.vscode-pull-request-github", // GitHub Pull Requests and Issues integration + "hediet.vscode-drawio", // Draw.io editor integration (useful for /drawio) + "humao.rest-client", // REST Client for testing HTTP endpoints + "mhutchie.git-graph", // Git graph visualizer + "ms-azuretools.vscode-docker", // Dockerfile / container tooling + "editorconfig.editorconfig", // EditorConfig support for consistent coding styles + "dbaeumer.vscode-eslint", // Linting for JavaScript and TypeScript + "redhat.vscode-yaml", // YAML support and validation + "streetsidesoftware.code-spell-checker", // Spell checking for code and comments + "usernamehw.errorlens", // Highlighting errors and warnings in the code + "yzhang.markdown-all-in-one" // Markdown productivity features + ] +} \ No newline at end of file diff --git a/.vscode/settings.example.json b/.vscode/settings.example.json new file mode 100644 index 00000000..c1c4678b --- /dev/null +++ b/.vscode/settings.example.json @@ -0,0 +1,23 @@ +{ + "editor.formatOnSave": true, + "editor.defaultFormatter": "esbenp.prettier-vscode", + "editor.rulers": [80, 120], + "files.trimTrailingWhitespace": true, + "files.insertFinalNewline": true, + "files.eol": "\n", + "editor.codeActionsOnSave": { + "source.fixAll.eslint": true + }, + "prettier.requireConfig": true, + "yaml.validate": true, + "files.exclude": { + "node_modules": true, + "dist": true, + "build": true + }, + "search.exclude": { + "node_modules": true, + ".git": true, + "dist": true + } +} \ No newline at end of file diff --git a/BestPracticesChecklist.md b/BestPracticesChecklist.md new file mode 100644 index 00000000..ed8ba50e --- /dev/null +++ b/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 + + +| 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.* \ No newline at end of file diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 04b5fea6..8b5300b7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,198 +1,541 @@ -# Contributing to SocialShareButton +# Contributing to TODO: Project Name -Thank you for your interest in contributing to **SocialShareButton**! 🚀 -We welcome contributions from everyone. +⭐ First off, thank you for considering contributing to this project! ⭐ -This document provides guidelines to help you contribute effectively and keep the project clean and maintainable. +We welcome contributions from everyone. By participating in this project, you agree to abide by our Code of Conduct. ---- +## � IMPORTANT: Discord Communication is Mandatory -## 🚨 Important: Discord Communication +**All project communication MUST happen on Discord. We do not pay attention to GitHub notifications.** - Join our [Discord server](https://discord.gg/hjUhu33uAn) before starting any work -- All project communication must happen on Discord. -- Please post PR/issue updates in the relevant Discord channel. -- PRs without Discord updates may face delays. +- Post your PR/issue updates in the relevant Discord channel (**MANDATORY**) +- All discussions, questions, and updates should be on Discord +- GitHub is for code only - Discord is for communication -## 📋 Table of Contents +**PRs without Discord updates will not be reviewed or may face delays.** -- [Ways to Contribute](#-ways-to-contribute) -- [Getting Started](#-getting-started) -- [Pull Request Guidelines](#-pull-request-guidelines) -- [Community Guidelines](#-community-guidelines) -- [Getting Help](#-getting-help) -- [Issue Assignment](#-issue-assignment) +## �📋 Table of Contents -## 📌 Ways to Contribute +- [How Can I Contribute?](#how-can-i-contribute) +- [Coding with AI](#coding-with-ai) +- [Getting Started](#getting-started) +- [Development Workflow](#development-workflow) +- [Pull Request Guidelines](#pull-request-guidelines) +- [Code Style Guidelines](#code-style-guidelines) +- [Debugging Pre-commit Hooks](#debugging-pre-commit-hooks) +- [Community Guidelines](#community-guidelines) -You can contribute in many ways: +## 🤝 How Can I Contribute? -- 🐛 Fixing bugs -- ✨ Adding new features -- 📚 Improving documentation -- 🎨 Enhancing UI/UX -- ⚡ Optimizing performance -- 🧪 Improving testing or code quality +### Reporting Bugs ---- +Before creating bug reports, please check existing issues to avoid duplicates. When creating a bug report, include: -### 📌 Before Starting Work +- Clear and descriptive title +- Steps to reproduce the issue +- Expected behavior vs actual behavior +- Screenshots/Video (if applicable) +- Environment details (OS, browser, versions, etc.) -- Please create or comment on an issue first. -- Wait for assignment before starting (preferable). -- Unrelated PRs may be closed. +### Suggesting Features + +Feature suggestions are welcome! Please: + +- Check if the feature has already been suggested +- Provide a clear description of the feature +- Explain why this feature would be useful +- Include examples of how it would work +### Contributing Code + +1. **Submit an Issue First**: For features, bugs, or enhancements, create an issue first +2. **Get Assigned**: Wait to be assigned before starting work(preferable) +3. **Submit Your PR**: Once assigned, create a PR addressing the issue +4. **Unrelated PRs**: Pull requests unrelated to issues may be closed or take longer to review + +## 🤖 Coding with AI + +We accept the use of AI-powered tools (GitHub Copilot, ChatGPT, Claude, Cursor, etc.) for contributions, whether for code, tests, or documentation. + +⚠️ However, transparency is required: if you use AI assistance, please mention it in your PR description. This helps maintainers during code review and ensure the quality of contributions. + +What we expect: +- **Disclose AI usage**: A simple note like "Used GitHub Copilot for autocompletion" or "Generated initial test structure with ChatGPT" is sufficient. +- **Specify the scope**: Indicate which parts of your contribution involved AI assistance. +- **Review AI-generated content**: Ensure you understand and have verified any AI-generated code before submitting. ## 🚀 Getting Started -### 1️⃣ Fork the Repository +### Prerequisites + +TODO: List prerequisites specific to your project + +### Setup + +1. **Fork the Repository** + ```bash + # Click the 'Fork' button at the top right of this page + ``` + +2. **Clone Your Fork** + ```bash + git clone https://github.com/YOUR_USERNAME/TODO.git + cd TODO + ``` + +3. **Add Upstream Remote** + ```bash + git remote add upstream https://github.com/AOSSIE-Org/TODO.git + ``` + +4. **Install Dependencies** + ```bash + npm install + # or yarn install + # or pnpm install + ``` + +5. **Run the Project** + ```bash + npm run dev + ``` + +## 🔄 Development Workflow -Click the **Fork** button on the top-right of the repository page. +### 1. Create a Feature Branch -Then clone your fork locally: +Always work on a new branch, never on `main` or `dev`: ```bash -git clone https://github.com/YOUR_USERNAME/SocialShareButton.git +git checkout -b feature/your-feature-name +# or +git checkout -b fix/your-bug-fix ``` -- Add upstream remote: +### 2. Make Your Changes + +- Write clean, readable code +- Follow the project's code style +- Add comments where necessary +- Update documentation if needed + +### 3. Test Your Changes + +TODO: Add project-specific testing instructions ```bash -git remote add upstream https://github.com/AOSSIE-Org/SocialShareButton.git +npm test +# or +npm run lint ``` -### 2️⃣ Create a New Branch +### 4. Commit Your Changes -Always create a new branch for your changes: +Write clear, concise commit messages: ```bash -git checkout -b feature/your-feature-name +git add . +git commit -m "feat: add user authentication" +# or +git commit -m "fix: resolve navigation bug" ``` -**Examples:** +**Commit Message Format:** +- `feat:` for new features +- `fix:` for bug fixes +- `docs:` for documentation changes +- `style:` for formatting changes +- `refactor:` for code refactoring +- `test:` for adding tests +- `chore:` for maintenance tasks + +### 5. Keep Your Branch Updated -- `feature/add-linkedin-support` -- `fix/button-alignment-issue` -- `docs/update-readme` +```bash +git fetch upstream +git rebase upstream/main +# or upstream/dev depending on the project +``` -### 3️⃣ Follow Project Standards +### 6. Push Your Changes -- Keep the project lightweight and dependency-free. +```bash +git push origin feature/your-feature-name +``` -- Follow the existing code style. +## 📤 Pull Request Guidelines -- Avoid unnecessary libraries. +### Before Submitting -- Write clean, readable, and modular code. +- [ ] Your code follows the project's style guidelines +- [ ] You've tested your changes thoroughly +- [ ] You've updated relevant documentation +- [ ] Your commits are clean and well-organized +- [ ] You've rebased with the latest upstream changes +- [ ] You've thought from the reviewer's perspective and made your PR easy to review -- Do not break existing functionality. +### Submitting a Pull Request -### 4️⃣ Test Your Changes +1. Go to the original repository on GitHub +2. Click "New Pull Request" +3. Select your fork and branch +4. Fill out the PR template with: + - Clear description of changes + - Link to related issue(s) + - Screenshots (if UI changes) + - Testing steps -- Before submitting a Pull Request: +### PR Description Template -- Open index.html in your browser. +```markdown +## Description +Brief description of what this PR does -- Test all social share buttons. +## Related Issue +Closes #issue_number -- Ensure no console errors appear. -- Check responsiveness on different screen sizes. +## Screenshots/Video (if applicable) +Add screenshots here -### 5️⃣ Commit Your Changes +## Testing(if applicable) +Steps to test the changes -- Use clear and meaningful commit messages. +## Checklist +- [ ] Code follows style guidelines +- [ ] Self-review completed +- [ ] Documentation updated +- [ ] Tests added/updated +``` -**Format:** +### After Submission +- Post your PR in the project's Discord channel for visibility(**IMPORTANT**) +- Respond to review comments promptly +- Make requested changes in new commits +- Be patient - maintainers will review when available +- Use `[WIP]` in your PR title for incomplete PRs. Don't use this as a way to gatekeep; focus on one change until it gets merged. + +### Reviewing PRs + +- Instead of opening duplicate PRs, help review and improve existing ones. +- When reviewing, assess whether the change is actually necessary before diving into implementation details and functionality testing. + +## 📝 Code Style Guidelines + +TODO: Add project-specific code style guidelines + +### General Guidelines + +- Use meaningful variable and function names +- Keep functions small and focused +- Add comments for complex logic +- Remove console.logs before committing +- Avoid code duplication +- Avoid unnecessary complexity and minor over-optimization + +### JavaScript/TypeScript +- Use ES6+ syntax +- Prefer `const` over `let`, avoid `var` +- Use arrow functions where appropriate +- Follow ESLint rules + +### Python +- Follow PEP 8 style guide +- Use type hints where applicable +- Write docstrings for functions/classes + +## 🔧 Debugging Pre-commit Hooks + +Pre-commit hooks help maintain code quality by running automated checks before each commit. This section helps you troubleshoot common issues. + +### Initial Setup + +If pre-commit is configured in this project, install it first: + +```bash +pip install pre-commit +pre-commit install ``` -type: short description + +### Common Errors and Solutions + +#### 1. **Pre-commit Hook Failed: Trailing Whitespace** + +**Error:** +```text +Trim Trailing Whitespace.................................................Failed +- hook id: trailing-whitespace +- exit code: 1 +- files were modified by this hook ``` -**Examples:** +**Solution:** +```bash +# Pre-commit automatically fixes this. Just re-stage and commit: +git add . +git commit -m "your message" +``` + +#### 2. **Pre-commit Hook Failed: End of File Fixer** +**Error:** +```text +Fix End of Files.........................................................Failed +- hook id: end-of-file-fixer +- exit code: 1 +- files were modified by this hook ``` -feat: add Twitter share support -fix: resolve mobile button spacing issue -docs: improve README installation section + +**Solution:** +```bash +# Files are automatically fixed. Re-add and commit: +git add . +git commit -m "your message" ``` -### 6️⃣ Push and Open a Pull Request +#### 3. **Pre-commit Hook Failed: Check YAML/JSON/TOML** + +**Error:** +```text +Check Yaml..........................................Failed +- hook id: check-yaml +- exit code: 1 -Before pushing, sync with upstream: +File .github/workflows/test.yml: mapping values are not allowed here +``` +**Solution:** ```bash -git fetch upstream +# Fix the syntax error in the file (check line number in error) +# Common issues: +# - Incorrect indentation +# - Missing colons +# - Invalid characters +# Then commit again +``` + +#### 4. **Pre-commit Hook Failed: Detect Secrets** + +**Error:** +```text +detect-secrets...........................................................Failed +- hook id: detect-secrets +- exit code: 1 + +Potential secrets about to be added to git repo: + + Secret Type: AWS Access Key + Location: config/settings.py:42 ``` +**Solution:** ```bash -git rebase upstream/main +# Option 1: Remove the secret and use environment variables +# Replace hardcoded secrets with: +# API_KEY = os.getenv('API_KEY') + +# Option 2: If it's a false positive, update baseline: +# detect-secrets scan > .secrets.baseline +# git add .secrets.baseline ``` -Push your branch: +#### 5. **Pre-commit Hook Failed: Mixed Line Endings** +**Error:** +```text +Mixed line ending........................................................Failed +- hook id: mixed-line-ending +- exit code: 1 +- files were modified by this hook +``` + +**Solution:** ```bash - git push origin feature/your-feature-name +# Automatically fixed to LF. Re-add and commit: +git add . +git commit -m "your message" ``` -## 🛠️ Development Workflow +#### 6. **Pre-commit Hook Failed: Large Files** -### Local Development +**Error:** +```text +Check for added large files..............................................Failed +- hook id: check-added-large-files +- exit code: 1 -1. Install dependencies: `npm install` -2. Open `index.html` in your browser to see the local demo. -3. Make changes to files in the `src/` directory. -4. Refresh the browser to see your changes (no build step is required for the core library). +large.zip (5.2 MB) exceeds 500 KB +``` -### Code Quality Tools +**Solution:** +```bash +# Option 1: Remove large files +git rm --cached large.zip -We use ESLint for linting and Prettier for formatting. Please run these before submitting a PR: +# Option 2: Use Git LFS for large files +git lfs install +git lfs track "*.zip" +git add .gitattributes -- `npm run lint` — Check for code quality and style issues. -- `npm run format` — Automatically format your code to project standards. -- `npm run format:check` — Verify that files are correctly formatted. +# Option 3: Increase limit (not recommended) +# Edit .pre-commit-config.yaml: +# args: ['--maxkb=10000'] # 10MB +``` -- Then open a Pull Request including: +#### 7. **Pre-commit Hook Failed: Merge Conflict Markers** -- What changes were made +**Error:** +```text +Check for merge conflicts................................................Failed +- hook id: check-merge-conflict +- exit code: 1 -- Why the change is needed +Merge conflict markers found in: + src/main.js:45 +``` -- Screenshots (if UI changes) +**Solution:** +```bash +# Open the file and remove conflict markers: +# <<<<<<< HEAD +# ======= +# >>>>>>> branch-name -- Any relevant issue reference +# Then commit again +``` -## 📋 Pull Request Guidelines +#### 8. **Pre-commit Not Running** -### ✅ Before Submitting +**Problem:** Commits go through without pre-commit checks -- [ ] Code tested -- [ ] Documentation updated -- [ ] Linked related issue -- [ ] Branch rebased with upstream -- [ ] Keep PRs small and focused. -- [ ] One feature or fix per PR. -- [ ] Avoid large unrelated changes. -- [ ] Ensure documentation is updated if needed. -- [ ] Be responsive to review feedback. +**Solution:** +```bash +# Reinstall pre-commit hooks +pre-commit uninstall +pre-commit install + +# Verify installation +pre-commit run --all-files +``` + +#### 9. **Pre-commit Takes Too Long** + +**Problem:** Pre-commit is slow on every commit + +**Solution:** +```bash +# Run only on changed files (default behavior) +git commit -m "message" + +# Skip pre-commit for quick commits (use sparingly!) +git commit --no-verify -m "message" + +# Update pre-commit hooks +pre-commit autoupdate +``` + +#### 10. **Hook Installation Failed** + +**Error:** +```text +An error has occurred: InvalidManifestError: +=====> /path/to/.pre-commit-config.yaml does not exist +``` + +**Solution:** +```bash +# Ensure you're in the project root directory +cd /path/to/project/root + +# Verify config file exists +ls -la .pre-commit-config.yaml + +# Reinstall +pre-commit install +``` + +### Bypassing Pre-commit (Emergency Only) + +**⚠️ Use only when absolutely necessary:** + +```bash +# Skip pre-commit hooks for a single commit +git commit --no-verify -m "emergency fix" + +# Or use the short flag +git commit -n -m "emergency fix" +``` + +**Note:** This should be rare. If you need to bypass frequently, discuss with maintainers. + +### Running Pre-commit Manually + +```bash +# Run all hooks on all files +pre-commit run --all-files + +# Run a specific hook +pre-commit run trailing-whitespace --all-files + +# Run on specific files +pre-commit run --files src/main.js src/utils.js +``` + +### Updating Pre-commit Hooks + +```bash +# Update to latest versions +pre-commit autoupdate + +# Clean and reinstall +pre-commit clean +pre-commit install +``` + +### Getting Help + +If you encounter issues not covered here: + +1. Check [pre-commit documentation](https://pre-commit.com/) +2. Review the error message carefully (it usually tells you what's wrong) +3. Ask in the project's Discord channel +4. Search for similar issues in the repository + +**Remember:** Pre-commit hooks are there to help you maintain code quality. Don't fight them - fix the issues they find! ## 🌟 Community Guidelines -- Be respectful and constructive. -- Communicate progress on Discord. -- Inactive issues may be reassigned. +### Communication + +- Be respectful and inclusive +- Provide constructive feedback +- Help others when you can +- Ask questions - no question is too small! -## 🙋 Getting Help +### Progress Updates -- Review the README and existing documentation first. -- Search open and closed issues before creating a new one. -- Ask questions in the project's Discord server. -- If your PR is not reviewed for 1–2 weeks, politely follow up on Discord. +- If your work is taking longer than expected, comment on the discord with updates +- Issues should be completed within 5-30 days depending on complexity +- If you can no longer work on an issue, let maintainers know on discord + +### Getting Help + +- Check existing documentation first +- Search closed issues for similar problems +- Ask in Discord +- Tag maintainers if your PR is unattended for 1-2 weeks on discord ## 🎯 Issue Assignment -- One contributor per issue (unless stated otherwise). -- Please wait for assignment before starting work (preferred). -- If inactive for an extended period, the issue may be reassigned. -- Check for existing PRs before starting to avoid duplication. +- One contributor per issue (unless specified otherwise) + +- If there are no active PRs for an issue for 2+ days, mention your intent under the issue and begin +- Avoid working on issues which are assigned to someone, even if they are inactive +- Check for existing PRs before starting to avoid duplication, as there might PRs that didn't mention the related issue + -### Thank you for helping improve SocialShareButton! 🎉 +Thank you for contributing to TODO! Your efforts help make this project better for everyone. 🚀 diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 00000000..6035f6f6 --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,25 @@ +# Maintainers, Mentors and Ideators + +This document lists the individuals fulfilling the key roles of [Maintainer](https://github.com/AOSSIE-Org/Info/blob/main/Roles/Maintainer.md), [Mentor](https://github.com/AOSSIE-Org/Info/blob/main/Roles/Mentors.md) and [Ideator](https://github.com/AOSSIE-Org/Info/blob/main/Roles/Ideator.md) for this repository, in accordance with [AOSSIE's Role Definitions](https://github.com/AOSSIE-Org/Info/tree/main/Roles). + +--- + +> **Note:** If multiple contributors are fulfilling a role in a single repository, please include and fill out the extra columns to clarify responsibilities (e.g., `Project / Feature Idea`, `Area / Focus`, and `Proposal / Discussion Link` for Ideators; `Area / Focus` for Mentors and Maintainers). If there is only one person for a role, do not add these columns. + +## Ideators + +| Name | GitHub Username | Discord Username | Project / Feature Idea | Area / Focus | Proposal / Discussion Link | +| ---- | --------------- | ---------------- | ------------------------------- | -------------------- | ------------------------------------------- | +| TODO | @username | @discord_user | Context-First AI Infrastructure | AI Workflow & Skills | [Discussion](https://github.com/AOSSIE-Org) | + +## Mentors + +| Name | GitHub Username | Discord Username | Area / Focus | +| ---- | --------------- | ---------------- | ----------------------------------- | +| TODO | @username | @discord_user | whole Project Guidance & PR Reviews | + +## Maintainers + +| Name | GitHub Username | Discord Username | Area / Focus | +| ---- | --------------- | ---------------- | -------------------------------- | +| TODO | @username | @discord_user | Repository Maintenance & Merging | diff --git a/PRIVACY.md b/PRIVACY.md new file mode 100644 index 00000000..3533c0d8 --- /dev/null +++ b/PRIVACY.md @@ -0,0 +1,115 @@ +# Privacy Policy + +## Introduction + +[TODO: Project Name] (the App) is committed to protecting your privacy and providing a transparent and user-friendly experience. + +This Privacy Policy explains how the App handles information when you use it. + +The App follows a privacy-conscious and local-first approach. +It aims to collect and process only the information necessary to provide its functionalities. +Where possible, information is processed and stored locally on your device rather than being transmitted to or stored on remote servers. + + +## Information and Permissions + +Depending on the features you use and the permissions you grant, the App may access information such as: + +* Information you provide directly to the App +* Information generated through your use of the App +* Device information or permissions required for specific features +* [TODO: Add any project-specific information, such as location, health data, contacts, files, etc.] + +The information accessed by the App is used only for the purposes described in this Privacy Policy and to provide the functionality of the App. + +You can deny or revoke permissions at any time through your device settings. +Some features may not work if the permissions required for those features are not granted. + + +## Data Storage + +The App is designed to minimize the storage and transmission of personal information. + +[TODO: choose the applicable option:] +[-- TODO: Option A: Begin] +All information is stored locally on your device and is not uploaded to or maintained on any remote server. +[-- TODO: Option A: End] + +[-- TODO: Option B: Begin] +Any information stored in remote servers is limited to what is necessary for the App's functionality. +The App stores the following information in servers: +* [TODO: which information is stored, where it is stored and why] +* [TODO: which information is stored, where it is stored and why] +[-- TODO: Option B: End] + + +## Data Sharing + +The App does not sell your personal information. + +The App does not use personal information for targeted advertising. + +[TODO: choose the applicable option:] +[-- TODO: Option A: Begin] +No information is shared with any third parties. +[-- TODO: Option A: End] + +[-- TODO: Option B: Begin] +The App may communicate with third-parties when required to provide specific features. +Any information transmitted to such services is limited to what is necessary for the App's functionality. +The following is a list of third parties and the information that may be shared with them: +* [TODO: Third Party Name]: [TODO: information that is shared with that third party and for which feature] +* [TODO: Third Party Name]: [TODO: information that is shared with that third party and for which feature] + +Where a third-party processes information, its handling of that information is governed by its own privacy policy and terms of service. +[-- TODO: Option B: End] + + +## Data Security + +The App aims to minimize privacy and security risks by limiting unnecessary data collection and, +where possible, processing information locally on your device. + +However, no method of electronic storage or transmission can be guaranteed to be completely secure. Users are also responsible for maintaining the security of their devices and for protecting any information they choose to export, share, or otherwise make available. + + +## Data Deletion + +Where information is stored locally, you can generally remove it by using the App's available data-clearing features, +clearing the data through your device settings, or uninstalling the App. + +[TODO (add if applicable): Where information is stored on servers, you may request deletion of that information by TODO.] + + +## Data Export + +The App may allow you to export information. Exported files are created and stored on your device, +and you are responsible for protecting any files you choose to export or share. + + +## Children's Privacy + +The App is not intended to knowingly collect personal information from children where such collection is prohibited by applicable law. + +[TODO: If the project has specific age requirements, describe them here.] + + +## Free Access + +The App aims to keep its core functionality accessible to users without +requiring mandatory subscriptions or payments to unlock essential features. + +[TODO: If the project has paid features, subscriptions, or other monetization, describe them clearly here.] + + +## Changes to This Privacy Policy + +We may update this Privacy Policy from time to time to reflect changes to the App, its functionality, or applicable legal requirements. + +Any updates will be made available wherever this Privacy Policy is published. + +## Contact Us + +If you have any questions or concerns about this Privacy Policy or the App's privacy practices, please contact us at: + +[contact@aossie.org](mailto:contact@aossie.org) diff --git a/VERSION b/VERSION index ee90284c..afaf360d 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -1.0.4 +1.0.0 \ No newline at end of file diff --git a/checklist-status.json b/checklist-status.json new file mode 100644 index 00000000..2f131c4a --- /dev/null +++ b/checklist-status.json @@ -0,0 +1,37 @@ +{ + "schemaVersion": 1, + "label": "Best Practices", + "message": "0%", + "schema": "aossie-best-practices-v1", + "updated": "2026-05-25", + "met": 0, + "total": 49, + "percent": 0, + "color": "red", + "categories": { + "basics": { + "met": 0, + "total": 8 + }, + "change_control": { + "met": 0, + "total": 6 + }, + "reporting": { + "met": 0, + "total": 8 + }, + "quality": { + "met": 0, + "total": 11 + }, + "security": { + "met": 0, + "total": 9 + }, + "analysis": { + "met": 0, + "total": 7 + } + } +} \ No newline at end of file diff --git a/dangerfile.js b/dangerfile.js new file mode 100644 index 00000000..be6911d4 --- /dev/null +++ b/dangerfile.js @@ -0,0 +1,91 @@ +// dangerfile.js — enforces the PR description template +// Docs: https://danger.systems/js/ +const body = danger.github.pr.body || ""; +const normalizedBody = body.replace(/\r\n/g, "\n"); + +const issues = []; + +function escapeRegex(value) { + return value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); +} + +function hasCheckedChecklistItem(itemText) { + const escapedItem = escapeRegex(itemText).replace(/\s+/g, "\\s+"); + const checkedItemPattern = new RegExp(`-\\s*\\[[xX]\\]\\s*${escapedItem}`, "i"); + return checkedItemPattern.test(normalizedBody); +} + +// --------------------------------------------------------------------------- +// 1. Required section headings (tolerant to spacing and casing) +// --------------------------------------------------------------------------- +const requiredSections = [ + { + label: "### Addressed Issues:", + pattern: /#{3}\s+addressed\s+issues:/i, + }, + { + label: "## Checklist", + pattern: /#{2}\s+checklist/i, + }, +]; + +const missingSections = requiredSections + .filter((section) => !section.pattern.test(normalizedBody)) + .map((section) => section.label); + +if (!normalizedBody.trim()) { + fail("PR description is empty. Please follow the PR template."); +} + +if (missingSections.length > 0) { + issues.push( + `**PR description is missing required sections:**\n` + + missingSections.map((s) => `- \`${s}\``).join("\n") + + `\n\nPlease follow the [PR template](.github/PULL_REQUEST_TEMPLATE.md).` + ); +} + +// --------------------------------------------------------------------------- +// 2. Issue link — warn on placeholder and missing issue reference +// --------------------------------------------------------------------------- +if (/\bfixes\s*#\s*\(\s*issue\s*number\s*\)/i.test(normalizedBody)) { + issues.push( + "Please replace the placeholder `Fixes #(issue number)` with the actual " + + "issue number (e.g. `Fixes #42`)." + ); +} else if (!/\b(fixes|closes|resolves)\s*#\d+\b/i.test(normalizedBody)) { + issues.push( + "No issue linked. Consider adding `Fixes #` (e.g. `Fixes #42`) " + + "under the **Addressed Issues** section." + ); +} + +// --------------------------------------------------------------------------- +// 3. Checklist — required items must be checked +// --------------------------------------------------------------------------- +const requiredChecklistItems = [ + "My PR addresses a single issue", + "My code follows the project's code style", + "My changes generate no new warnings or errors", +]; + +const missingRequired = requiredChecklistItems.filter( + (item) => !hasCheckedChecklistItem(item) +); + +if (missingRequired.length > 0) { + issues.push( + "Some required checklist items are not completed:\n" + + missingRequired.map((item) => `- ${item}`).join("\n") + ); +} + +if (issues.length > 0) { + message(` +### ⚠️ PR Template Check + +These are non-blocking, but please fix: + +${issues.map((issue) => `- ${issue}`).join("\n")} + `); +} diff --git a/public/aossie-logo.svg b/public/aossie-logo.svg new file mode 100644 index 00000000..10cc0a88 --- /dev/null +++ b/public/aossie-logo.svg @@ -0,0 +1,24 @@ + + + + + + + + + diff --git a/public/stability.svg b/public/stability.svg new file mode 100644 index 00000000..cd2d3a7d --- /dev/null +++ b/public/stability.svg @@ -0,0 +1,14 @@ + + + + + + + + + + + + + + diff --git a/socket.yml b/socket.yml new file mode 100644 index 00000000..5cfbfd63 --- /dev/null +++ b/socket.yml @@ -0,0 +1,29 @@ +version: 2 + +# Skip these when ingesting manifests for scans +projectIgnorePaths: + - "build" + - "dist" + - ".dart_tool" + - "android/.gradle" + +# Only rescan PRs when dependency manifests actually change +triggerPaths: + - "package.json" + - "package-lock.json" + - "pnpm-lock.yaml" + - "yarn.lock" + - "requirements.txt" + - "pyproject.toml" + - "pubspec.yaml" # Flutter + - "pubspec.lock" + +githubApp: + enabled: true + pullRequestAlertsEnabled: true + dependencyOverviewEnabled: true + projectReportsEnabled: true + ignoreUsers: + - "dependabot[bot]" + - "github-actions[bot]" + disableCommentsAndCheckRuns: false