Contribution Guide

🌿 Branch Naming

1. Branch names follow this rule:

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

   Examples:

   feature/VCA-98/add-code-quality-dashboard
   fix/VCA-101/fix-lighthouse-integration
   evol/VCA-202/improve-security-analysis
   refactor/ISSUE-12/refactor-dependency-check

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/VCA-90/add-performance-metrics
   
   Commits:
   [FEATURE]: add initial performance metrics dashboard
   [FEATURE]: integrate with Lighthouse for performance data
   [EVOL]: enhance metrics with historical data
   [FIX]: fix data rendering issues
   [FIX]: correct typos in documentation
   [FIX]: resolve linting errors
   [REFACTORING]: optimize data fetching for performance metrics

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

🔄 Pull Requests

1. Follow the PR template to standardize the format and include essential information.

2. 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/VCA-90/add-performance-metrics
   
   Commits:
   [FEATURE]: add initial performance metrics dashboard
   [FEATURE]: integrate with Lighthouse for performance data
   [EVOL]: enhance metrics with historical data
   [FIX]: fix data rendering issues
   [FIX]: correct typos in documentation
   [FIX]: resolve linting errors
   [REFACTORING]: optimize data fetching for performance metrics
   
   Pull Request:
   Title: [FEATURE]: add performance metrics dashboard
   
   Description:
   This PR introduces the initial version of the performance metrics dashboard. It includes integration with Lighthouse for performance data and enhancements for displaying historical data. Fixes data rendering issues and typos in documentation, resolves linting errors, and optimizes data fetching for better performance.

3. 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.

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