There are many ways to contribute to Mattermost beyond a core Mattermost repository:
You can create app integrations for Mattermost to provide additional functionality and host them anywhere.
You can create lightweight external applications that don’t require customizations to the Mattermost user experience by using incoming and outgoing webhooks, or by using the Mattermost API.
You can activate external functionality within Mattermost by creating custom slash commands.
You can extend, modify, and deeply integrate with the Mattermost server, its apps, and its UI/UX by using plugins. However, please note that plugin development comes with the highest level of overhead and must be written in Go and React.
You can use Mattermost from other applications, by embedding and launching Mattermost within other applications and mobile apps.
To get started:
Identify which repository you need to work in (see point below), then review the README located within the root of the repository to learn more about getting started with your contribution and any processes that may be unique to that repository.
These are the Mattermost Core repositories you can contribute to:
Server: Highly-scalable Mattermost server written in Go.
Desktop App: An Electron wrapper around the web app project that runs on Windows, Linux, and macOS.
Core Plugins: A core set of officially-maintained plugins that provide a variety of improvements to Mattermost.
To contribute to documentation, you should be able to edit any page and get to the source file in the documentation repository by selecting the Edit in Github button in the top right of its respective published page. You can read more about this process on the why and how to contribute page. You can contribute to the following Mattermost documentation sites:
Check in regularly with your Pull Request (PR) to review and respond to feedback.
Thoroughly document what you’re doing in your PR. This way, future contributors can pick up on your work (including you!). This is especially helpful if you need to step back from a PR.
Each PR should represent a single project, both in code and in content. Keep unrelated tasks in separate PRs.
Make your PR titles and commit messages descriptive! Briefly describing the project in the PR title and in your commit messages often results in faster responses, less clarifying questions, and better feedback.
Thoroughly test your contributions! We recommend the following testing best practices for your contribution:
Detail exactly what you expect to happen in the product when others test your contributions.
Identify updates to existing product, developer, and/or API documentation based on your contributions, and identify documentation gaps for new features or functionality.