Skip to content

Latest commit

 

History

History
102 lines (75 loc) · 3.73 KB

CONTRIBUTING.md

File metadata and controls

102 lines (75 loc) · 3.73 KB

Contributing to Moss

We would love for you to contribute to Moss and help make it even better than it is today! Whether you're fixing bugs, proposing new features, or enhancing documentation, your contributions are greatly appreciated.

Table of Contents

Getting Started

Forking the Repository

  1. Navigate to the Moss repository on GitHub.
  2. Click the "Fork" button at the top right of the page.

Cloning the Repository

  1. Open your terminal.
  2. Clone your forked repository:
    git clone https://github.com/your-username/moss.git

Setting Up Your Environment

  1. Navigate to the project directory: cd moss
  2. Install the necessary dependencies: cargo install

Code of conduct

Help us keep Moss open and inclusive. Please read and follow our Code of Conduct.

How to Contribute

Reporting Bugs

  1. Ensure the bug has not already been reported by searching the issues.
  2. Open a new issue with the title "Bug: [Descriptive Title]" and provide a detailed description.

Proposing Features

  1. Search for existing feature requests to avoid duplicates.
  2. Open a new issue with the title "Feature Request: [Descriptive Title]" and describe the proposed feature.

Writing Code

  1. Create a new branch for your work: git checkout -b feature/my-new-feature
  2. Make your changes and commit them following the commit message guidelines.

Commit Message Guidelines

We use semantic-release to automate the versioning and release process. Your commit messages should follow the Conventional Commits specification.

Semantic Release Format

feat: A new feature fix: A bug fix docs: Documentation only changes 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 perf: A code change that improves performance test: Adding missing or correcting existing tests build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) chore: Other changes that don't modify src or test files revert: Reverts a previous commit

Example Commit Messages

  • feat: add user authentication module
  • fix: resolve issue with data fetching in dashboard
  • docs: update contributing guidelines
  • style: format code according to eslint rules
  • refactor: simplify data processing logic
  • perf: improve query performance
  • test: add tests for user service
  • build: update npm dependencies
  • ci: configure Travis CI for automated testing
  • chore: clean up old configuration files
  • revert: revert "feat: add user authentication module"

Code Review Process

  1. Submit a pull request to the main branch.
  2. Ensure that all checks pass.
  3. A maintainer will review your pull request. Feedback will be provided for any necessary changes.
  4. Once approved, your pull request will be merged.