Skip to main content
The contribution workflow is plain GitHub Flow: fork, branch from main, commit, open a pull request, review, squash merge. Nothing more. The only house rules are about how commits and PRs are written.

​
Commit messages

All three repos use Conventional Commits. The format is:

​
Types

​
Scopes

The scope names the area, and it mirrors the repo layout. Real examples from the two example repos’ history (the last one is what actually added their CODEOWNERS and issue templates - the docs repo doesn’t have those yet, see CODEOWNERS and Issues):
With scopes, the same commits would read fix(gpu): correct GPU keypair and account-id typing or docs(tutorials): add example repos page. Either form is fine. The rules that always apply:
  • Imperative mood, present tense: “add X”, never “added X” or “adds X”.
  • Lowercase type, no period at the end.
  • One logical change per commit. Split unrelated work.
  • No em dashes or en dashes in commit messages either, same as everywhere else in this project.

​
Body and footers

The body explains why when the title is not enough, especially for anything that changes billable behavior. Footer lines like Closes #123 link issues and close them automatically on merge, see GitHub’s reference.

​
Branch naming

Branch from main, name the branch <type>/<short-description>, like fix/gpu-keypair-id or docs/contribute-section. The name just has to be readable in the PR list; nothing enforces it.

​
The pull request

When you open a PR, GitHub fills the description from the repo’s pull request template. The template is a checklist, and the checklist is the definition of done:
  • Bilingual comments on new code, no em or en dashes
  • The example builds in its language, or validates in the touched folders
  • No secrets, payWithCreditCard stays false
  • READMEs and the root tables updated
  • Docs site pages updated in both languages when behavior changed
Every unchecked box is a review comment waiting to happen. Check them yourself before asking for review; the reviewer will check them again.
1

Fork and branch

Fork the repo from the GitHub web UI, clone your fork, and create the branch from an up to date main. Keep the upstream remote configured so you can pull the latest main before pushing.
2

Make the change and check it locally

Follow Conventions, then run the checks from Local setup in every folder you touched. For the docs repo, run mint dev and look at the page in the browser.
3

Open a draft PR

Open the PR as a draft if you want early feedback, then mark it ready when the checklist is done. Link any issues it closes in the description or footer.
4

Review

CODEOWNERS automatically requests a review from the repo owner, see CODEOWNERS and reviews. Expect the review to check the template checklist, the conventions, and whether docs and code changed together.
5

Merge

The maintainer squash merges into main, which keeps the history linear and one commit per change. For the docs repo, merging into main is also the deploy; the Mintlify app ships the site within minutes. For the example repos, the maintainer may run the manual CI afterwards.

​
What happens after merge

  • Docs repo: mint validate and mint broken-links run automatically on the push, then the site at biznetgio.creations.ren redeploys automatically from main - see The docs site pipeline. Neither step places an order or costs money, so there is nothing to gate manually here.
  • Example repos: nothing runs automatically. The Pipelines are manual dispatch on purpose, because apply and up place real orders. The maintainer triggers a validate or build run after review, and anything with real side effects only when it is wanted.
One last rule: nothing in this project runs apply, up, or a release step automatically on push, and there is no branch protection with required checks. The safety model for anything with a real side effect is human review plus a deliberate, manual pipeline run - the docs site’s push-triggered CI is a build check, not an exception to that, since it can only fail a validation, never place an order. That is a design choice described in Pipelines, and it is why the PR checklist matters more than in most repos.