If you're seeing this document, you are an early contributor to the development and success of XMTP. We welcome your questions, feedback, suggestions, and code contributions.
Have a question? We welcome you to ask it in Q&A discussions.
Bugs should be reported as GitHub Issues. Please confirm there isn't already an open issue and include detailed steps to reproduce.
These should also be submitted as GitHub Issues. Again, please confirm there isn't already an open issue. Let us know what use cases this feature would unlock so that we can investigate and prioritize.
PRs are encouraged, but we suggest starting with a Feature Request to temperature-check first. If the PR would involve a major change to the protocol, it should be fleshed out as an XMTP Improvement Proposal before work begins.
We do not accept pull requests that are generated entirely or primarily by AI/LLM tools (e.g., GitHub Copilot, ChatGPT, Claude). This includes:
- Automated typo fixes or formatting changes
- Generic code improvements without context
- Mass automated updates or refactoring
Pull requests that appear to be AI-generated without meaningful human oversight will be closed without review. We value human-driven, thoughtful contributions that demonstrate an understanding of the codebase and project goals.
Caution
To protect project quality and maintain contributor trust, we will restrict access for users who continue to submit AI-generated pull requests.
If you use AI tools to assist your development process, please:
- Thoroughly review and understand all generated code
- Provide detailed PR descriptions explaining your changes and reasoning
- Be prepared to discuss your implementation decisions and how they align with the project goals
Please make sure you have a compatible version as specified in package.json. We recommend using a Node version manager such as nvm or nodenv.
This repository uses the Yarn package manager. To use it, enable Corepack, if it isn't already, by running corepack enable.
A new version of this package will be automatically published whenever there is a merge to the main branch. Specifically, new GitHub releases and tags will be created, and a new NPM package version will be published. The release version increment type is derived from the format of the commit messages that were bundled in the merge to main, using semantic-release commit message conventions.
The table below shows example commits and the resulting release type for a pencil project:
| Commit message | Release type |
|---|---|
docs: describe scribble feature |
No Release |
test: fix failing unit test |
No Release |
fix: stop graphite breaking when too much pressure applied |
|
feat: add 'graphiteWidth' option |
|
perf: remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons. |
(Note that the BREAKING CHANGE: token must be in the footer of the commit) |
This is currently configured to use the Angular Commit Message Conventions. e.g. feat: add message signing would cause a minor release.
If there are multiple commits within a single pull request, each commit will be listed as a separate bullet point in the release notes and bundled together in a release of the highest increment type specified.
If your commit messages are not to your liking, it is permitted to rewrite the history on your branch and force-push it before merging it. Make sure you are never force-pushing on main, and that the following is in your ~/.gitconfig file.
[push]
default = simple
A beta release of this package will be automatically published whenever there is a merge to the beta branch. For more information on the beta branch pre-release workflow, see semantic-release pre-release workflow.
We should only target the beta branch when new functionality would benefit from early testing by downstream clients. Otherwise, features and fixes that are easily testable without input from downstream clients should be targeted against the main branch as usual.