Contributing Rules

Audemy Repository Management Ruleset

1. Branch Naming Conventions

Use a consistent naming structure for branches to maintain clarity and organization. Follow this pattern:

Feature Branches:

• feature/<short-description>
  Example: feature/google-oauth

Bug Fixes:

• fix/<issue-number>-<short-description> Example: fix/42-login-error

Hotfixes (Urgent Fixes to Production):

• hotfix/<short-description> Example: hotfix/payment-api-timeout

Refactoring or Cleanup:

• refactor/<short-description> Example: refactor/db-schema-optimization

2. Pull Request (PR) Guidelines

Creating a PR

• Title: Use a concise and descriptive title. Example: Fix: Resolved OAuth Token Expiry Issue
• Description: Include:
  • The problem being fixed or feature being added
  • The approach taken to solve it
  • Any dependencies or changes in configuration
  • Screenshots or logs if relevant

Assigning an Approver

• At least one approver is required for every PR.
• Assign a team member who has expertise in the modified area.
• If the PR affects multiple domains, tag relevant reviewers accordingly.
• PRs that impact critical components require at least two approvals before merging.

Labels for PRs

• bug → For bug fixes
• feature → For new features
• hotfix → For urgent production fixes
• documentation → For updates to README, guides, or comments
• refactor → For code restructuring without changing functionality
• wip → Work in progress, not ready for review yet
• tests-needed → Requires additional tests before merging
• breaking-change → Indicates major changes that might affect existing functionality

3. Writing Commit Messages

Each commit should be meaningful and follow the format:

<type>: <short summary>

<optional detailed description>

Examples:

• fix: Resolve infinite loop in game rendering
• feature: Implement leaderboard API
• docs: Update README with API usage
• refactor: Optimize database queries for better performance

4. Merging Rules

• PRs must be reviewed and approved before merging.
• Squash merging is preferred to maintain a clean commit history.
• Ensure all tests pass before merging.
• PRs that introduce breaking changes require detailed migration steps in the PR description.
• PRs should not be merged without an explicit approval from the assigned reviewer.

5. Handling Issues and Feature Requests

• Bugs and feature requests should be logged in GitHub Issues.
• Provide a clear description, expected behavior, and relevant screenshots/logs.
• Use labels (bug, feature, enhancement, etc.) to categorize issues correctly.
• Assign issues to appropriate team members to ensure accountability.
• High-priority issues should be labeled as urgent and assigned an ETA for resolution.

6. Security and Access Control

• Repository access should be restricted to authorized developers only.
• API keys, credentials, and sensitive data must not be committed to the repository.
• Always review third-party dependencies before adding them to the project.
• Enable branch protection rules to prevent unauthorized merges into main or production branches.