Contributing

Contributing

We welcome contributions to the Chat-Service! Please follow these guidelines to help us maintain a high-quality codebase and documentation.

Getting Started

1. Ensure you have set up your development environment as described in Setup and Installation.
2. Familiarize yourself with the Architecture of the service.
3. Check the issue tracker for open tasks or bugs you can work on. If you plan to add a new feature, it's a good idea to open an issue first to discuss it.

Code Style

• Follow PEP 8 guidelines for Python code.
• Use type hinting where appropriate.
• Write clear and concise comments.
• Ensure your code is well-tested.

Git Conventions

To ensure consistency and a clear history, please adhere to the following Git conventions. For a more detailed guide, refer to the Git Conventions document in the main repository.

Commit Messages

Commit messages should follow a conventional format:

<type>(<scope>): <subject>

• Types: feat (new feature), fix (bug fix), docs (documentation), style (formatting, non-functional), refactor, test, chore (maintenance, build process), perf (performance), ci, revert.
• Scope (optional): The module or part of the codebase affected (e.g., LLM, rag, api).
• Subject: A concise description of the change. Start with a capital letter, do not end with a period.

Examples:

• feat(api): add new endpoint for user preferences
• fix(LLM): resolve issue with prompt tokenization
• docs(readme): update setup instructions
• chore(deps): upgrade FastAPI version

Use ! after the type/scope for breaking changes (e.g., feat(api)!: change authentication method).

Branching Strategy

• Branch Naming: Create branches with the format type/branch-name (e.g., feat/new-chat-ui, fix/login-bug). Branch types are the same as commit types.

• Main Branches:

  • main (or master): Production-ready code.
  • develop: Latest development changes, integration branch for features.

• Supporting Branches:

  • Feature branches: Branch off develop, merge back into develop.

    git checkout develop
    git pull
    git checkout -b feat/your-feature-name

  • Release branches: (e.g., release/1.2.0) Branch off develop to prepare for a release. Merged into main and develop.
  • Hotfix branches: (e.g., hotfix/critical-bug) Branch off main for urgent production fixes. Merged into main and develop.

• Keep branches short-lived to facilitate frequent integration and reduce merge conflicts.

• Consider Trunk Based Development practices like frequent commits to develop and using feature flags for larger changes if appropriate for the project's pace.

Refer to the full Git Conventions document for more details on Git Flow and Trunk Based Development.

Common Git Commands

Here are some common Git commands that you might find useful. For a more comprehensive list, refer to the Git Commands document in the main repository.

• git clone <repository_link>: Create a local copy of a remote repository.
• git checkout -b <branch_type>/<branch-name>: Create a new branch and switch to it.
• git checkout <branch-name>: Switch to an existing branch.
• git add .: Stage all changes in the current directory for the next commit.
• git commit -m "<type>(<scope>): <your_message>": Commit your staged changes with a descriptive message.
• git push: Upload your local branch commits to the remote repository.
• git pull: Fetch changes from the remote repository and merge them into your current branch.
• git status: Show the working tree status (changes not staged, changes to be committed, etc.).
• git branch -a: List all local and remote branches.
• git merge <branch-name>: Merge the specified branch into your current branch.

Refer to the full Git Conventions document for more details on Git Flow and Trunk Based Development.

Workflow

1. Fork the repository.
2. Create a new branch for your feature or bugfix:

   git checkout -b feature/your-feature-name
   # or
   git checkout -b fix/your-bug-fix

3. Make your changes.
4. Write tests for your changes. Ensure all tests pass:

   pytest

5. Commit your changes with a clear and descriptive commit message.
6. Push your branch to your fork:

   git push origin feature/your-feature-name

7. Open a Pull Request against the main repository's develop or main branch (as per project guidelines).
   • Provide a clear description of your changes in the PR.
   • Link to any relevant issues.

Documentation

• If you add new features or change existing ones, please update the relevant documentation in this wiki.
• For API changes, update the API Reference.

Thank you for contributing!