> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/discordplace/discord.place/llms.txt
> Use this file to discover all available pages before exploring further.

# Contributing Guidelines

> How to contribute code, features, and bug fixes to discord.place.

We welcome contributions from the community. Whether you're fixing a bug, adding a feature, or improving documentation, this guide covers everything you need to get started.

## Code of Conduct

All contributors are expected to abide by the project's [Code of Conduct](https://github.com/discordplace/discord.place/blob/main/.github/CODE_OF_CONDUCT.md). In short:

* Be respectful and inclusive toward all contributors regardless of experience, background, or identity.
* Personal attacks, harassment, trolling, and derogatory comments are not tolerated.
* Publishing others' private information without permission is strictly prohibited.
* Project maintainers reserve the right to remove contributions or contributors who violate these standards.

Instances of unacceptable behavior can be reported to the project maintainers. All reports will be handled confidentially.

## Reporting Issues

Before writing any code, check whether the issue already exists. If not, [open a new issue](https://github.com/discordplace/discord.place/issues) on GitHub with:

* A clear, descriptive title
* Steps to reproduce the problem
* Any relevant error messages or screenshots
* Your environment details (OS, Node.js version, browser, etc.)

Feature requests are welcome too — describe the use case and the expected behavior.

## Contribution Workflow

<Steps>
  <Step title="Fork and clone the repository">
    Fork the [discord.place repository](https://github.com/discordplace/discord.place) on GitHub, then clone your fork locally:

    ```bash theme={null}
    git clone https://github.com/YOUR_USERNAME/discord.place.git
    cd discord.place
    ```
  </Step>

  <Step title="Create a feature or bug-fix branch">
    Always branch off from `main`. Use a descriptive branch name that reflects your change:

    ```bash theme={null}
    # For a new feature
    git checkout -b feat/bot-voting-cooldown-display

    # For a bug fix
    git checkout -b fix/emoji-upload-size-validation

    # For documentation
    git checkout -b docs/update-self-hosting-prerequisites
    ```
  </Step>

  <Step title="Set up the development environment">
    Install dependencies for both the server and client before making changes. See the [Installation guide](/self-hosting/installation) for the full setup walkthrough, including environment variables and configuration files.

    ```bash theme={null}
    cd server && npm install
    cd ../client && npm install
    ```
  </Step>

  <Step title="Make your changes">
    * Follow the existing coding style and conventions used throughout the project.
    * Write or update tests for any new functionality.
    * Ensure all existing tests still pass before committing.
    * Update documentation if your change affects behavior described in the docs.
  </Step>

  <Step title="Commit using Conventional Commits">
    All commits must follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. See the [format reference below](#conventional-commits-format) for examples.

    ```bash theme={null}
    git add .
    git commit -m "feat: add bot voting cooldown display"
    ```
  </Step>

  <Step title="Push and open a pull request">
    Push your branch to your fork and open a pull request against the `main` branch of the original repository:

    ```bash theme={null}
    git push origin feat/bot-voting-cooldown-display
    ```

    Then navigate to [github.com/discordplace/discord.place](https://github.com/discordplace/discord.place) and open a pull request from your branch.
  </Step>
</Steps>

## Conventional Commits Format

Every commit message must follow the Conventional Commits standard. The format is:

```
<type>[optional scope]: <description>
```

The `type` describes what kind of change the commit introduces:

| Type       | When to use                                |
| ---------- | ------------------------------------------ |
| `feat`     | A new feature                              |
| `fix`      | A bug fix                                  |
| `docs`     | Documentation changes only                 |
| `style`    | Formatting, whitespace — no logic change   |
| `refactor` | Code restructuring with no feature or fix  |
| `test`     | Adding or updating tests                   |
| `chore`    | Build process, tooling, dependency updates |
| `perf`     | Performance improvements                   |

<CodeGroup>
  ```text Feature commit theme={null}
  feat: add bot voting cooldown display
  ```

  ```text Bug fix commit theme={null}
  fix: resolve emoji upload size validation
  ```

  ```text Documentation commit theme={null}
  docs: update self-hosting prerequisites
  ```

  ```text Scoped commit theme={null}
  feat(i18n): add Azerbaijani locale support
  ```

  ```text Breaking change theme={null}
  feat!: restructure bot listing API response

  BREAKING CHANGE: the `servers` field is now `guild_count`
  ```
</CodeGroup>

<Note>
  Read the full Conventional Commits specification at [conventionalcommits.org](https://www.conventionalcommits.org/en/v1.0.0/). Commits that do not follow this format may be asked to be rewritten before merging.
</Note>

## Pull Request Requirements

Before submitting your pull request, make sure it includes:

* **A clear title** following the Conventional Commits format (e.g., `fix: resolve emoji upload size validation`)
* **A description** explaining what the change does and why
* **Steps to test** the change, if applicable
* **Screenshots or recordings** for UI changes
* **References** to any related issues (e.g., `Closes #123`)

PRs are reviewed against the `main` branch. The maintainers will provide feedback or merge the PR once it meets the project's standards. Keep your branch up to date with `main` to avoid conflicts.

## Code Style

Adhere to the coding style and conventions already in use across the project. Consistent style makes the codebase easier to read and review for everyone. ESLint is configured for both the client and server — run it before pushing:

```bash theme={null}
# In client/ or server/
npx eslint .
```

## Licensing

By contributing to discord.place, you agree to license your contributions under the [AGPL v3 License](https://github.com/discordplace/discord.place/blob/main/LICENSE). This ensures contributions can be freely used, modified, and distributed by others in accordance with the license terms.

## Getting Help

If you have questions about contributing or get stuck:

* **GitHub Issues** — [Open an issue](https://github.com/discordplace/discord.place/issues) with your question.
* **Discord support server** — Join the community server linked in the website footer to ask questions in real time.
* **Documentation** — Review the [self-hosting guide](/self-hosting/installation) for setup help.

The maintainers are happy to help — don't hesitate to ask.