Contributing

Three kinds of contributions, three different paths.

Doc bugs

Found a typo, broken link, or factually wrong claim? Two ways to fix it:

Option 1: Open an issue (fast)

github.com/appmint/appmint.io/issues — placeholder URL.

Title format: Docs: <page slug>: <one-line problem>. In the body include:

• The page URL (/docs/...)
• What's wrong
• What it should say (if you know)

The team aims to triage doc issues within 1 business day.

Option 2: Open a PR (faster)

If you can fix it yourself, fork the repo and open a PR. Doc files live under /Users/imzee/projects/appmint.io/docs/.

git clone https://github.com/your-fork/appmint.io.git
cd appmint.io
# edit docs/...
git checkout -b docs/fix-typo-overview
git commit -am "Docs: fix typo in concepts overview"
git push origin docs/fix-typo-overview
# open PR on GitHub

CI runs MDX linting and link checking. PRs that pass CI usually merge within a couple days.

Content contributions

For more than a typo — a new tutorial, an API reference page, a clarifying example — start with an issue first to scope it. The team will tell you whether it overlaps with planned work and steer the structure.

Style

• Read the style guide before writing. Voice, headings, code samples, length targets — all enforced in review.
• Match the existing pages: short sentences, active voice, real code over invented examples.
• No marketing fluff. The docs explain; the marketing pages sell.

Adding a new page

1. Pick a section: getting-started, platform, appengine, admin, tutorials, self-hosting, resources.
2. Create the file as kebab-case .mdx under that section.
3. Add frontmatter:

   ---
   title: <Title Case>
   description: <One-sentence summary>
   order: <integer; lower = earlier>
   ---
   

4. Don't include # H1 — the title becomes the H1.
5. Use absolute paths for cross-references: [link](/docs/section/page).

Adding a new section

Edit docs/<section>/_meta.json:

{ "title": "Section Name", "order": <integer> }

The order field controls sidebar position relative to other sections.

Code contributions

The open repos accept PRs. Each repo has its own CONTRIBUTING.md but the basics are the same:

Repo	What goes there
appengine	Backend modules, controllers, services
websitemint	Admin UI
base-app	Next.js reference app
yugo	Booking-site reference
chat-client	Embeddable chat widget
appmint.io	This site (marketing + docs)

Setup

git clone https://github.com/appmint/<repo>.git
cd <repo>
npm install   # or yarn, pnpm — check the repo's README

Each repo has a make dev or npm run dev script that starts a local instance.

Standards

• TypeScript strict mode, no any without justification
• Tests for new functionality (Vitest or Jest depending on the repo)
• Conventional commits (feat:, fix:, docs:, chore:)
• One change per PR — atomic, reviewable
• Don't reformat code outside the lines you're changing

Reviews

• Two approvals required for backend changes
• One approval for docs and small fixes
• Maintainers handle merging — don't merge your own PRs

CLA

For substantial code contributions you'll be asked to sign a CLA. Doc-only contributions don't need one.

What we don't accept

• Branding/marketing copy changes (those go through marketing, not the repo)
• Whole-feature rewrites without prior discussion (open an issue first)
• Code that adds dependencies on closed services without a fallback
• Changes that break the public API in patch or minor releases

Getting credit

Contributors are listed on each release's notes. For substantial contributions (modules, large doc series), you can add yourself to the contributors list in the repo's README.

Code of conduct

Standard contributor covenant — be kind, no harassment, focus on the work. Repeated violations get banned. The team responds to reports at [email protected] within 24 hours.