Contributing

Where to send fixes, docs work, testing help, theme improvements, and useful bug reports without creating extra noise.

Main coordination surfaces

Best first contact

Discord is usually the fastest way to ask whether a bug, doc change, or design idea is already being worked on.

High-value ways to help

Bug reports

Real repro steps, screenshots, platform details, and what you expected to happen.

Code fixes

Editor behavior, export issues, theme bugs, performance regressions, and UI polish.

Documentation

Installation gaps, workflow clarification, export notes, and pages that need less fluff and more signal.

Themes

New JSON themes, palette tuning, and validation passes against real editor surfaces.

Testing

Windows/macOS verification, package install checks, and regression confirmation on weird documents.

Translations

Future localization groundwork and string-quality help as that surface expands.

Before you open a PR

Read the current README and recent changelog entries so you are not patching a ghost from last week.

Check whether there is already an issue, discussion, or active branch for the same thing.

Keep changes focused. Giant drive-by rewrites are usually how good intent turns into merge debt.

Document behavior changes clearly, especially if they affect editing, exports, themes, or install flows.

What makes a bug report useful

Include as much of this as you can:

Include this	Why it matters
Operating system and version	Platform-specific behavior is real, especially for packaging and desktop integration
Noteism version or commit	Helps separate old breakage from current breakage
Exact Markdown sample	Repro beats vibes every single time
Screenshot or screen recording	Speeds up UI and rendering diagnosis
Output log details	Export, load, and theme failures often already explain themselves there

A quick note on docs contributions

Docs are not second-class work here. Good docs reduce bug churn, make packaging less annoying, and keep new users from bouncing off real features that already exist.

If you fix docs:

keep it factual
do not invent features
do not write “coming soon” fluff unless it is explicitly true and clearly marked
prefer clarity over fake polish

If a doc page saves somebody twenty minutes of confused clicking, that counts as real engineering work.