Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/taskian/mintting/llms.txt

Use this file to discover all available pages before exploring further.

Working with Mintting means engaging with an open-source repository hosted on GitHub. This guide walks you through the practical steps of getting a local copy of the project, exploring what is there, and participating in the community through issues and pull requests.

Clone and explore the repository

The first step is getting the source code onto your machine so you can read through it, experiment, and understand how the project is structured.
1

Clone the repository

Run the following command in your terminal to download a local copy of Mintting:
git clone https://github.com/taskian/mintting
This creates a mintting/ directory in your current location containing the full repository history.
2

Navigate into the project

Move into the cloned directory to start exploring:
cd mintting
From here you can browse the files, read the README.md, and look through any existing documentation or configuration.
3

Read the README and contributing docs

Before making any changes, read through the README.md at the project root. If a CONTRIBUTING.md file exists, read that too — it will explain the project’s conventions, branch naming, and any setup steps specific to Mintting.

Open an issue

If you find a bug, have a question, or want to suggest an improvement, opening an issue on GitHub is the right place to start.
1

Search for existing issues

Before opening a new issue, search the existing issues to see if someone has already reported the same thing. A quick search saves everyone time.
2

Open a new issue

If no existing issue matches, click New issue on the repository’s Issues tab. Give your issue a clear, descriptive title and fill in as much detail as you can: what you expected to happen, what actually happened, and any steps to reproduce the problem.
3

Wait for a response

A maintainer will review your issue and follow up. Be responsive to questions — the faster you can provide clarifying information, the sooner the issue can move forward.

Submit a pull request

If you want to contribute a change directly — whether it is a documentation fix, a small improvement, or a new feature — follow these steps.
1

Fork the repository

On GitHub, click Fork to create your own copy of the Mintting repository under your account. You will make your changes in your fork.
2

Create a branch

Create a new branch for your change rather than working directly on main. Use a name that describes what the branch does:
git checkout -b fix/typo-in-readme
3

Make your changes

Edit the files you need to change. Keep each pull request focused on a single concern — smaller, targeted changes are easier to review and faster to merge.
4

Push and open a pull request

Push your branch to your fork and then open a pull request against the main Mintting repository. Write a clear description explaining what you changed and why.
git push origin fix/typo-in-readme
5

Address review feedback

A maintainer may leave comments or request changes. Address each piece of feedback with follow-up commits on the same branch. Once everything is approved, your change will be merged.

Community norms and contributing etiquette

Mintting follows the norms common to open-source projects hosted on GitHub. When participating, keep the following in mind:
  • Be respectful. Everyone contributing is volunteering their time. Assume good intent and communicate constructively.
  • Be specific. Vague issues are hard to act on. Include context, reproduction steps, and relevant details.
  • Keep pull requests small. Large, sprawling changes are difficult to review. Break your work into focused, reviewable pieces where possible.
  • Follow existing conventions. Match the code style, file structure, and naming patterns you see in the project rather than introducing your own preferences.
  • Be patient. Maintainers may have limited availability. If you do not hear back within a reasonable time, a polite follow-up comment on the issue or pull request is appropriate.
One of the best ways to get a pull request merged quickly is to reference the issue it addresses in the pull request description using Closes #<issue-number>. This links the two together automatically and signals that your change resolves the reported problem.

Build docs developers (and LLMs) love