Contributing
How to propose changes, structure pull requests, and keep contributions reviewable.
Noema favors direct, scoped contributions. A good contribution solves one problem, explains the user-facing or developer-facing impact, and includes the checks that were run.
Contribution Types
| Type | Examples | Expected Verification |
|---|---|---|
| SDK | Runtime, memory, voice, task logic | pnpm --filter @noema/sdk build |
| Desktop | Electron main, preload, renderer | pnpm --filter @noema/desktop build |
| Plugins | Tool handlers, plugin manifests, admin surfaces | node --check for changed .mjs files when practical |
Before You Start
- Check existing issues and docs to avoid duplicate work.
- Keep the change aligned with the current package and plugin boundaries.
- Avoid adding compatibility layers unless maintainers explicitly request them.
- Prefer generic lifecycle, context, tool, or admin-management hooks over plugin-specific core code.
Change Request Shape
A useful change request includes:
- A concise summary of what changed.
- Why the change is needed.
- Screenshots for visible UI changes.
- Commands run for verification.
- Known limitations or follow-up work.
Documentation Changes
When behavior changes, update the related documentation in the same change when practical.
Docs should answer:
- What is this feature?
- When should a developer use it?
- How is it configured?
- What are the failure modes?
- How can it be verified?
Review Guidance
Review should focus on correctness, maintainability, clarity, and whether the change fits the existing architecture. Prefer specific suggestions and file references over broad feedback.