OverTone community and contributions

OverTone aims to make working with language models feel natural, with a carefully considered experience and local use at its core. Version 0.1 is an early public preview. Feedback on the experience, clear bug reports, documentation improvements, and thoughtful contributions are welcome.

Where to start

If Discussions or the categories below are not available yet, open an issue for questions, ideas, or experience feedback. Security reports follow the separate security policy.

• Bugs: open an issue using the bug report form. Describe what happened, what you expected, and how to reproduce it. Include your OverTone version and macOS version; add the model and engine if relevant. If it happens intermittently, describe the circumstances as clearly as you can.
• Questions and setup help: use Discussions → Q&A.
• Ideas and experience feedback: use Discussions → Ideas & feedback. Explain what you are trying to do, where the current experience falls short, and any workaround you have tried. You do not need to design a solution or write code.
• Security vulnerabilities: follow the security policy, using the repository’s private “Report a vulnerability” option when available. Do not post sensitive details in a public issue or discussion.
• Updates: see Discussions → Announcements for development updates. The README describes the current capabilities and limitations.

Search for an existing issue or discussion first. Add useful details to an existing thread instead of opening a duplicate; a reaction is enough to express support. If you are unsure where something belongs, ask in Q&A and it can be moved to the right place. Never include passwords, API keys, private conversations, or unredacted personal information in reports or attachments.

How decisions are made

The maintainer is responsible for OverTone’s product direction and final review decisions. Proposals are considered for their usefulness, fit with the project’s purpose, effect on the overall experience and privacy. Support from other users helps us understand a need; it does not automatically place a feature on the roadmap.

An accepted idea may be scheduled for later. The roadmap describes priorities, not delivery promises, and may change as the project develops. Issues and discussions should make the current decision clear: more information needed, under consideration, planned, or outside the project’s scope.

Bug reports help improve the existing experience. Reproducible problems affecting privacy, data integrity, or essential workflows receive priority, but an open issue is not a promise of a particular fix or completion date.

Before writing code

Please discuss new features and substantial changes before implementing them. This includes changes to interaction design, architecture, dependencies, and fixes with wider effects. Wait for the maintainer to confirm the scope in the relevant issue or discussion. This helps avoid spending time on work that cannot be included.

Small documentation corrections and straightforward, narrowly scoped bug fixes can be submitted directly. For larger work, look for issues explicitly marked as ready for contributions and leave a comment before starting so efforts do not overlap.

Pull requests

Keep each PR focused on one agreed change. Link the relevant issue, explain the resulting behaviour, and describe how you checked it. Include screenshots or a short recording for visible changes and appropriate tests for changes to behaviour. Avoid unrelated formatting or refactoring. Respect the project’s license and existing third-party notices.

AI-assisted contributions are welcome. The contributor remains responsible for understanding the change, checking its behaviour, and responding to review. Prior agreement establishes a direction; merging still depends on the finished implementation and review.

Working together

Keep discussions respectful and focused on the work. Disagreement is welcome; harassment, spam, and personal attacks are not. Review and support happen as maintainer time allows. When a proposal is deferred or declined, the aim is to explain the reason and keep the decision visible. Contributions are acknowledged in the project’s release notes where appropriate.