Skip to content

Latest commit

 

History

History
201 lines (148 loc) · 6.06 KB

CONTRIBUTING.md

File metadata and controls

201 lines (148 loc) · 6.06 KB
Raw

Contributing to Auto_Jobs_Applier_AIHawk

Table of Contents

Thank you for your interest in contributing to Auto_Jobs_Applier_AIHawk. This document provides guidelines for contributing to the project.

Issue Labels

The project uses the following labels:

  • bug: Something isn't working correctly
  • enhancement: New feature requests
  • good first issue: Good for newcomers
  • help wanted: Extra attention needed
  • documentation: Documentation improvements

Bug Reports

When submitting a bug report, please include:

  • A clear, descriptive title prefixed with [BUG]
  • Steps to reproduce the issue
  • Expected behavior
  • Actual behavior
  • Any error messages or screenshots
  • Your environment details (OS, Python version, etc.)

Feature Requests

For feature requests, please:

  • Prefix the title with [FEATURE]
  • Include a feature summary
  • Provide detailed feature description
  • Explain your motivation for the feature
  • List any alternatives you've considered

Branch Rules

  • main - Production-ready code, protected branch
  • develop - Integration branch for features
  • feature/* - New features
  • release/* - Release preparation
  • bugfix/* - Bug fixes for development
  • hotfix/* - Emergency production fixes

Version Control

  • Semantic versioning: vMAJOR.MINOR.PATCH
  • Release tags on main branch only
  • Package versions match git tags

Release Process

week one for release/v4.1.0

  • Planning meeting for release/v4.1.0 with release scope and milestone objectives set by the maintainers. Release and maintainer meeting agendas and schedules are posted on the project repository wiki and shared in the #releases channel on Discord.
  • release/v4.0.0 release candidate ready for release
  • release/v4.0.0 merge into develop, main
  • tag main as release/v4.0.0
  • release/v4.0.0 published to AIHawk/releases and PyPI as a package with release documentation
  • delete release/v4.0.0 branch

release/v4.1.0 release weeks

  • Contributers work on issues and PRs, prioritizing next milestone
  • Maintainers review PRs from feature/*, bugfix/* branches and issues, merging into develop
  • Maintainers review PRs from hotfix/* branches and issues, merged into main and develop, main tagged and merged into 4.0.1 package and release/v4.0.1 and release/v4.1.0, documentation is updated

last week, release candidate

  • develop is frozen, only bug fixes
  • create release branch release/v4.1.0 from develop
  • only bug fixes are merged into release/v4.1.0
  • additional testing and release candidate review

week one is repeated for release/v4.2.0

gantt
    title Release Cycle Process
    dateFormat  YYYY-MM-DD
    section Retro/Plan
    Planning release/v4.1.0    : 2025-01-01, 2d
    Publish release/v4.0.0     :milestone, m1, 2025-01-01, 1d
    
    section Dev Cycle
    Feature Development        :2025-01-03, 27d
    PR Reviews                 :2025-01-03, 27d
    
    section Release
    Freeze develop              :milestone, m3, 2025-01-30, 1d
    Create release/v4.1.0   :milestone, m4, 2025-01-30, 1d
    Bug Fixes Only         :2025-01-30, 2d
    RC Testing             :2025-01-30, 2d
    
    section Next Cycle
    Skip Weekend             :2025-02-01, 2d
    Planning release/v4.2.0      :2025-02-03, 2d
    Publish release/v4.1.0     :milestone, m4, 2025-02-03, 1d
Loading

Roles

Organization Owner

  • Has full access to all repositories
  • Controls organization-wide settings and permissions
  • Can set base permissions for all members
  • Manages repository settings and collaborator access

Release Manager

  • Creates and manages release branch from develop
  • Coordinates release cycles and versioning
  • Merges release into main

Maintainer

  • Reviews and approves develop, feature PRs
  • Triage issues, bugs, PRs
  • Manages feature, bugfix PRs merge into develop
  • Leads feature development, bug prioritization
  • Manages README, CONTRIBUTING, and other documentation

Moderator

  • Moderates Telegram, Discord channels
  • Manages project wiki
  • Contributes to README, CONTRIBUTING, and other documentation

Contributor

  • Creates feature branches from develop
  • Implements new features, bug fixes, and other changes
  • creates PRs on features
  • Collaborates with other developers on features

Pull Request Process

  1. Fork the repository
  2. Create a new branch for your feature or bug
  3. Write clear commit messages
  4. Update documentation as needed
  5. Add tests for new functionality
  6. Ensure tests pass
  7. Submit a pull request with a clear description

Merging Pull Requests

  • All PRs are reviewed by maintainers
  • At least 2 Maintainers approve PRs for merge
  • PRs are merged into develop
  • PRs are tested and verified to work as expected

Code Style Guidelines

  • Follow PEP 8 standards for Python code
  • Include docstrings for new functions and classes
  • Add comments for complex logic
  • Maintain consistent naming conventions
  • Security best practices
  • Any performance considerations

Development Setup

  1. Clone the repository
  2. Install dependencies from requirements.txt
  3. Set up necessary API keys and configurations

Testing

Before submitting a PR:

  • Test your changes thoroughly
  • Ensure existing tests pass
  • Add new tests for new functionality
  • Verify functionality with different configurations

Communication

  • Be respectful and constructive in discussions
  • Use clear and concise language
  • Reference relevant issues in commits and PRs
  • Ask for help when needed

The project maintainers reserve the right to reject any contribution that doesn't meet these guidelines or align with the project's goals.