Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
66 lines (47 loc) · 2.84 KB

CONTRIBUTING.md

File metadata and controls

66 lines (47 loc) · 2.84 KB
Raw

Contributing to MediaForge

First off, thank you for considering contributing to MediaForge! It's people like you that make MediaForge a great tool for the Android community.

🤝 How Can I Contribute?

  • Reporting Bugs: Create an issue with a clear description, steps to reproduce, and device info.
  • Suggesting Enhancements: Open an issue to discuss new features or improvements before writing code.
  • Code Contributions: Submit Pull Requests (PRs) to fix bugs, add features, or improve documentation.

💻 Development Workflow

  1. Fork the repository on GitHub.
  2. Clone your fork locally.
  3. Create a feature branch (git checkout -b feat/your-feature-name).
  4. Commit your changes following our commit message guidelines.
  5. Push to your fork (git push origin feat/your-feature-name).
  6. Open a Pull Request against the main branch.

📝 Commit Message Guidelines

We follow the Conventional Commits specification to maintain a clean and readable git history. This allows us to automatically generate changelogs and version bumps.

Format

<type>(<optional scope>): <description>

[optional body]

[optional footer(s)]

Allowed Types

  • feat: A new feature for the user (e.g., feat: add support for WebP conversion)
  • fix: A bug fix for the user (e.g., fix: resolve crash on Android 11 when picking images)
  • docs: Documentation changes only (e.g., docs: update README with new screenshots)
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature (e.g., refactor(ui): extract preview card to separate component)
  • perf: A code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies (Gradle, dependencies)
  • ci: Changes to our CI configuration files and scripts (GitHub Actions)
  • chore: Other changes that don't modify src or test files (e.g., updating .gitignore)

Examples

Good Commits:

  • feat(compression): implement manual quality slider
  • fix: handle null uri when returning from background
  • chore: update agp to version 8.2.0

Bad Commits:

  • fixed a bug (Too vague, no type)
  • wip (Do not push work-in-progress to main, squash before merging)
  • Update MainActivity.kt (Does not explain why or what)

📏 Code Style & Standards

  • We use Kotlin for all logic and Jetpack Compose for UI.
  • Ensure your code follows standard Kotlin conventions.
  • Keep composable functions small, reusable, and stateless where possible.
  • Test your changes on both an emulator and a physical device before submitting a PR.

Thank you for your contributions! 🚀