Contribution Guide

Contribution Guide for BistroKit

🌿 Branch Naming

1. Branch names follow this rule:

   (feature or evol or fix or refacto)/ticket-number-or-issue/title
   

   Examples:

   feature/BK-98/add-react-scaffolding
   fix/BK-101/fix-webpack-config
   evol/BK-202/improve-jest-integration
   refacto/ISSUE-12/refactor-lint-rules
   

2. A branch should focus on a single type of change: either a feature, a bug fix, an enhancement (evol), or a refactor. Mixing different types of changes in a single branch is not recommended to avoid regressing the entire codebase in case of issues.

3. Each enhancement, bug fix, and refactor should focus on a single functionality and a single part of the codebase.

💬 Commits

1. Commit messages follow this rule:

   [FEATURE]: concise description of the added feature
   [EVOL]: concise description of the enhancement made
   [FIX]: concise description of the bug fix
   [REFACTORING]: concise description of the refactor performed
   

   Each commit must have a concise and informative message explaining the change made. Avoid vague messages like "Fix" or "Update."

2. Commits should be atomic: each commit should represent a single coherent change.

   Avoid large commits that touch multiple aspects of the code.

3. It is important to separate types of commits:

   • One commit for features
   • One commit for code review changes
   • One commit for lint fixes
   • One commit for refactoring

   Organize commits in a logical order. For example, start with features, followed by bug fixes, and then improvements.

   Example:

   Branch: feature/BK-90/add-react-component-generator
   
   Commits:
   [FEATURE]: add initial react component generator
   [FEATURE]: integrate with existing scaffolding system
   [EVOL]: enhance generator with additional options
   [FIX]: fix component template issues
   [FIX]: correct typos in documentation
   [FIX]: resolve linting errors
   [REFACTORING]: optimize code for component generation
   

   A well-structured git history in a Pull Request is essential for facilitating code review.

🔄 Pull Requests

1. Create a PR template to standardize the format and include essential information. Templates make drafting PRs easier and ensure necessary elements are included.

2. A PR template should include:

   • ✨ Title (required): Write a clear and concise title summarizing the purpose of the PR. Use relevant keywords for easy searching.
   • 📄 Detailed Description (required): Explain in detail what the PR does, why it is needed, and how it addresses a specific problem.
   • ✅ Self-validation Checklist (required): Include a checklist to ensure the PR meets quality standards.
   • 🔗 Contextual Links (optional): Add links to tracking tickets, previous discussions, or other relevant resources.
   • 📸 Visuals (optional): If possible, show the visual result of the PR.

3. The title of a Pull Request follows this rule:

   [FEATURE]: for a new feature
   [EVOL]: for an enhancement
   [FIX]: for a bug fix
   [REFACTORING]: for a refactor
   

   Include essential keywords for easy searching.

   Example:

   Branch: feature/BK-90/add-react-component-generator
   
   Commits:
   [FEATURE]: add initial react component generator
   [FEATURE]: integrate with existing scaffolding system
   [EVOL]: enhance generator with additional options
   [FIX]: fix component template issues
   [FIX]: correct typos in documentation
   [FIX]: resolve linting errors
   [REFACTORING]: optimize code for component generation
   
   Pull Request:
   Title: [FEATURE]: add react component generator
   
   Description:
   This PR introduces the initial version of the React component generator. It integrates with the existing scaffolding system and includes enhancements for additional options. Fixes component template issues, corrects typos in documentation, resolves linting errors, and optimizes the code for better performance.
   

4. Assign at least one reviewer for each PR. The PR cannot be merged until it is approved by the reviewer. Peer review ensures code quality and helps identify potential issues.

5. Use labels to clearly communicate the status of a PR.