Contributing Guide

Relevant source files

The following files were used as context for generating this wiki page:

• package.json
• renovate.json
• README.md
• release.config.js
• CHANGELOG.md
• scripts/iamvikshan.sh
• src/commands/bot/bot.ts

Welcome to the Amina project! We encourage and appreciate contributions from the community to help make Amina better. This guide provides the technical details and processes you'll need to follow to contribute effectively. For a higher-level overview, please see the main README.

The project is open to various forms of contribution, including but not limited to: bug hunting, developing new features, improving documentation, enhancing design, and adding translations. Every contribution is valued.

Sources: README.md:120-132

Getting Started

Before you start coding, you'll need to set up your development environment and fork the repository.

Development Environment Setup

The project includes a comprehensive setup script, iamvikshan.sh, designed for Codespaces but adaptable for local use. It automates the configuration of Git, the GitHub CLI, and SSH signing keys to ensure all contributions are correctly attributed.

Key setup steps include:

1. Configuring Git: Set your global user.name and user.email. The script defaults to iamvikshan but you should configure your own.
2. Authenticating GitHub CLI: The script handles logging into the gh CLI.
3. Setting up SSH Signing: The project requires commits to be signed. The script generates an ed25519 SSH key, adds it to your GitHub account for signing, and configures Git to use it automatically.
4. Configuring Remotes: It ensures the origin remote points to the correct repository URL.

Sources: scripts/iamvikshan.sh

Project Scripts

The package.json file contains several scripts to help with development, testing, and code quality.

Script	Description
dev	Starts the bot in watch mode using bun.
build	Runs type checking (tsc) and format checking (prettier).
start	Starts the bot using bun.
f	Formats all files using Prettier.
f:check	Checks for formatting issues without applying changes.
check	Runs TypeScript compiler (tsc) and ESLint (eslint) to check for errors.
check:watch	Runs the TypeScript compiler in watch mode.
eslint	Runs ESLint to find and report on patterns in the code.
eslint:fix	Runs ESLint and automatically fixes problems.
prepare	Installs Husky for Git hooks.

Sources: package.json:8-17

Contribution Workflow

The standard workflow for contributing is based on the fork-and-pull model.

This diagram illustrates the general steps for making a contribution.

Commit Conventions and Versioning

The project uses semantic-release with gitmoji to automate versioning and changelog generation. Your commit messages MUST follow a specific format for this process to work correctly.

Commit Message Format

A commit message should follow the conventional commits specification, often with a gitmoji prefix. The general structure is:
type(scope): subject

The type determines the nature of the release (major, minor, or patch).

Sources: release.config.js

Release Rules

The version bump is determined by the gitmojis used in the commit messages on the main branch.

Release Type	Included Gitmojis	Description
major	:boom:, :warning:	Breaking changes.
minor	:sparkles:, :rocket:, :lipstick:, :zap:	New features or significant improvements.
patch	:bug:, :ambulance:, :lock:, :adhesive_bandage:	Bug fixes, security patches, and minor corrections.

Sources: release.config.js:6-23

Changelog Generation

The CHANGELOG.md is automatically generated based on the commit types.

Commit Type	Changelog Section
feat	✨ Features
fix	🐛 Bug Fixes
perf	⚡ Performance Improvements
revert	⏪ Reverts
docs	📚 Documentation
style	💄 Styles
chore	🔧 Miscellaneous
refactor	♻️ Code Refactoring
test	✅ Tests
build	👷 Build System
ci	🔄 CI/CD

Sources: release.config.js:29-44, CHANGELOG.md

This diagram shows the automated release workflow triggered by a push to main.

Dependency Management with Renovate

The project uses Renovate to keep dependencies up-to-date. The configuration is defined in renovate.json.

Key Configuration

• Branches: Renovate runs on api, dash, and main.
• Schedule: Runs "before 4am" in the "Africa/Nairobi" timezone.
• Labels: All PRs created by Renovate are labeled with dependencies.
• Reviewers: The user iamvikshan is assigned as a reviewer for all Renovate PRs.
• Automerge:
  • Patch updates and digests are automerged.
  • Minor updates for devDependencies are also automerged.
• Grouping:
  • Linters and formatters (eslint, prettier, husky) are grouped together.
  • The semantic-release ecosystem is grouped.
  • The discord.js ecosystem is grouped.
• Lock File Maintenance: The bun.lockb file is maintained automatically and automerged.

Sources: renovate.json

The following diagram shows how Renovate processes dependency updates.

Submitting a Pull Request

When your changes are ready, open a Pull Request against the main branch.

• Ensure your PR has a clear title and description.
• Link any relevant issues in the PR description.
• After a PR is merged, semantic-release will add a comment to the PR indicating the version it was released in and apply a released label.

Sources: README.md:127, release.config.js:63-68