Merge pull request #35 from LynnuxDev/backup-branch

Backup branch

.github/CONTRIBUTING.md

@@ -0,0 +1,145 @@
+# Contributing to Akira
+
+Thank you for your interest in contributing to Akira! Contributions are what make open-source projects thrive. To help you get started, please follow this guide to ensure a smooth collaboration.
+
+---
+
+## Table of Contents
+
+- [Contributing to Akira](#contributing-to-akira)
+  - [Table of Contents](#table-of-contents)
+  - [Getting Started](#getting-started)
+  - [Code of Conduct](#code-of-conduct)
+  - [How to Contribute](#how-to-contribute)
+    - [Reporting Bugs](#reporting-bugs)
+    - [Suggesting Features](#suggesting-features)
+    - [Contributing Code](#contributing-code)
+  - [Development Workflow](#development-workflow)
+  - [Commit Messages](#commit-messages)
+  - [Pull Request Guidelines](#pull-request-guidelines)
+  - [License](#license)
+
+---
+
+## Getting Started
+
+1. **Fork the repository:**
+   - Visit the [Akira repository](https://github.com/LynnuxDev/Akira) and click on the `Fork` button.
+2. **Clone your fork:**
+
+    ```bash
+    git clone https://github.com/your-username/Akira.git
+    ```
+
+3. **Set up your environment:**
+   - Ensure you have [Node.js](https://nodejs.org/) installed (version 22 or higher).
+   - Install dependencies:
+
+      ```bash
+      pnpm install
+      ```
+
+---
+
+## Code of Conduct
+
+Please read our [Code of Conduct](CODE_OF_CONDUCT.md) to understand the expectations for participating in this project.
+
+---
+
+## How to Contribute
+
+### Reporting Bugs
+
+- Check if the issue already exists in the [issues list](https://github.com/LynnuxDev/Akira/issues).
+- Create a new issue and include:
+  - A clear, descriptive title.
+  - Steps to reproduce the bug.
+  - Expected vs. actual behavior.
+  - Any error logs or screenshots.
+
+### Suggesting Features
+
+- Check if your feature idea is already being discussed in the [issues list](https://github.com/orgs/LynnuxDev/discussions/categories/ideas).
+- Open a new discussion and include:
+  - A clear, descriptive title.
+  - The problem your feature solves and/or what you want to see added to Akira.
+  - Details of the proposed solution.
+
+### Contributing Code
+
+- Before starting work, comment on an issue or open a discussion to avoid duplicate work.
+- Follow the [Development Workflow](../INFO/How-To-Changelog.md) to make and test your changes.
+
+---
+
+## Development Workflow
+
+1. **Create a branch:**
+    - Name your branch descriptively, e.g., `feat/command-handler` or `fix/message-typo`.
+
+      ```bash
+      git checkout -b branch-name
+      ```
+
+2. **Make your changes:**
+   - Follow the project's coding style.
+   - Add or update documentation/comments if needed.
+
+3. **Run tests:**
+    - Ensure your changes pass all tests.
+
+      ```bash
+      pnpm run start
+      ```
+
+4. **Commit your changes:**
+    - Use [conventional commits](https://www.conventionalcommits.org/) for commit messages (see [Commit Messages](#commit-messages)).
+
+5. **Push your branch:**
+
+    ```bash
+    git push origin branch-name
+    ```
+
+6. **Open a pull request:**
+    - Go to the [Pull Requests](https://github.com/LynnuxDev/Akira/pulls) section.
+    - Provide a detailed description of your changes.
+
+---
+
+## Commit Messages
+
+Follow the [Conventional Commits](https://www.conventionalcommits.org/) format:
+
+- **feat:** A new feature.
+- **fix:** A bug fix.
+- **docs:** Documentation updates.
+- **chore:** Non-code changes.
+- **docs:** Documentation changes.
+- **style:** Code style changes without affecting logic.
+- **refactor:** Code restructuring without functionality changes.
+- **perf:** A code change that improves performance.
+- **test:** Adding or modifying tests.
+- **build:** Changes to the build process or tools.
+- **ci:** Changes to Continuous Integration configurations.
+
+> [!NOTE]
+> First commit changes, than run `pnpm run build`,
+> after that commit the changelog and push to your repo.
+---
+
+## Pull Request Guidelines
+
+- Ensure your PR description includes:
+  - The problem it solves.
+  - A summary of changes.
+  - Relevant issue numbers (e.g., `Closes #123`).
+- Ensure your code is well-documented and follows the project's coding style.
+- Pass all automated tests.
+
+---
+
+## License
+
+By contributing, you agree that your contributions will be licensed under the same license as this repository ([MIT License](../LICENSE)).

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,22 @@
+## Description
+
+Please include a summary of the changes and which issue is being fixed. List any dependencies that are required for this change.
+
+## Type of change
+
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Documentation update
+- [ ] Other (please specify)
+
+## How Has This Been Tested?
+
+Please describe the tests that you ran to verify your changes.
+
+## Checklist:
+
+- [ ] My code follows the style guidelines of this project.
+- [ ] I have performed a self-review of my code.
+- [ ] I have commented my code, especially in hard-to-understand areas.
+- [ ] I have added tests that prove my fix is effective or that my feature works.
+- [ ] New and existing tests pass with my changes.

.github/STYLING.md

@@ -0,0 +1,168 @@
+# Styling Guidelines for Akira
+
+To ensure consistency and readability across the codebase, we follow these coding and language style guidelines. Adhering to these guidelines is essential for maintaining a professional and cohesive project.
+
+---
+
+## Code Style
+
+### General Rules
+
+- Use **TypeScript** for all code.
+- Follow the **[ESLint](https://eslint.org/)** style guide with TypeScript-specific rules.
+- Indentation: Use **2 spaces**.
+- Line length: Aim for a maximum of **80 characters**; use line breaks for readability when needed.
+- Avoid using `any` type unless absolutely necessary.
+- Add new types to `/src/types.ts`.
+
+### Naming Conventions
+
+- **Variables and functions:** Use `camelCase` (e.g., `handleCommand`).
+- **files and Directories:** Use `PascalCase` (e.g., `CommandHandler`).
+
+### File Organization
+
+- Place each class or major module in its own file.
+- Use meaningful and descriptive filenames (e.g., `messageHandler.ts`, `guildConfig.ts`).
+- Keep imports organized:
+  1. Node.js built-in modules.
+  2. Third-party dependencies.
+  3. Local modules.
+
+### Comments
+
+- Use comments sparingly but effectively to explain **why** rather than **what**.
+- For functions, use JSDoc-style comments to describe parameters and return values:
+
+  ```ts
+  /**
+  * Loads a YAML translation file and retrieves the value for a given key.
+  * @param lang - The language code (e.g., 'en', 'es').
+  * @param key - The translation key in dot notation (e.g., 'greetings.hello').
+  * @returns The translation value or an error message if the key or file is not found.
+  */
+  export function loadYaml(lang: string, key: string): string {
+    // Implementation
+  }
+  ```
+
+  ```ts
+  `
+  $c[
+    Sends a message to a channel.
+    @param channel - The channel to send the message to.
+    @param content - The message content.
+    @returns Message.
+  ]
+  $sendMessage[$channelID;Message]
+  `
+  ```
+
+---
+
+## Language Style
+
+### General Tone
+
+Akira's tone should reflect her personality:
+
+- Friendly and approachable.
+- Professional and respectful.
+- Fun and engaging, but avoid excessive kawaii elements/emojis (no more than 1/2 per message/embed).
+
+### Formatting
+
+- Use full sentences with proper grammar and punctuation.
+- Avoid all-caps unless emphasizing a critical issue (e.g., "ERROR").
+- Avoid excessive emojis; keep it minimal and relevant.
+
+> [!NOTE]
+> We use `$i18n[language;content]` for localization.
+>
+> Localization can be found in the [Localization Repo](https://github.com/LynnuxDev/AkiraLocalization)
+
+### Examples
+
+- When responding to users:
+  - **Good:** "I've added the role for you. Let me know if there's anything else I can help with!"
+  - **Avoid:** "Done! :) lol"
+- When an error occurs:
+  - **Good:** "I couldn't find that user. Please double-check the ID and try again."
+  - **Avoid:** "oops! couldn’t find. try again plz!"
+
+> [!NOTE]
+> We use `$customError[errorID;origin]` for error handling.
+>
+> Errors are gotten from the [errors.json](../files/errors.json)
+
+---
+
+## Example Messages
+
+### Commands
+
+- Use concise and clear responses:
+
+  ```txt
+  a.info
+  - **Response:** "Hello! I'm Akira, your assistant bot. Use a.help for a list of commands."
+  ```
+
+### Error Handling
+
+- Be informative but concise:
+
+  ```txt
+  "I couldn’t complete your request because the bot lacks permission to manage roles in this server."
+  ```
+
+### User Engagement
+
+- Engage naturally, but avoid being overly playful:
+
+  ```txt
+  "Did you mean to use `/ban`? If , try `/help` for guidance."
+  ```
+
+---
+
+## Git Commit Style
+
+- Use **[Conventional Commits](https://www.conventionalcommits.org/)** to structure commit messages:
+  - **feat:** A new feature.
+  - **fix:** A bug fix.
+  - **docs:** Documentation updates.
+  - **chore:** Non-code changes.
+  - **docs:** Documentation changes.
+  - **style:** Code style changes without affecting logic.
+  - **refactor:** Code restructuring without functionality changes.
+  - **perf:** A code change that improves performance.
+  - **test:** Adding or modifying tests.
+  - **build:** Changes to the build process or tools.
+  - **ci:** Changes to Continuous Integration configurations.
+
+---
+
+## Release Process
+
+To ensure consistent releases and changelogs, follow these steps:
+
+1. Before releasing a new version, make sure your code adheres to the style guide by running:
+
+    ```bash
+    pnpm run lint
+    ```
+
+2. Generate a new version and update the changelog by running:
+
+    ```bash
+    pnpm run release
+    ```
+
+3. Push the changes and tags to the repository:
+
+    ```bash
+    git push --follow-tags origin main
+    ```
+
+By adhering to these guidelines, we can ensure that Akira remains a high-quality, professional, and user-friendly project. Thank you for contributing and maintaining consistency!