Integrations team processes
1% DRAFT
Last updated
Was this helpful?
1% DRAFT
Last updated
Was this helpful?
Schedule meeting items by running /agenda queue Tuesday [item] in .
Metrics updates: 2 min presentation on interesting metrics on .
: Was did we ship in the last sprint? What do we want to ship in the next 4 weeks? What are blockers for that?
Thursday R&D Demo: Decide what to demo.
Guilds Updates: Short update from every guild meeting. If there isn't anything relevant, skip to the guild.
Triage Jira Toolkit, Jira Integrations, and GitHub.
Go through queued meeting items.
(Optional) Quick stand up using and Jira.
Remove all Done items from both GitHub boards.
QA testing is require for all changes for not Beta plugin in the Marketplace.
QA testing may be shipped for Beta plugins.
QA testing is not required to changes that don't touch the production code of a plugin e.g. tooling changes.
Dylan will @-mention reviewers and request peer testing posting a link to the process.
Once testing is done, developers will at mention Dylan in a comment and attach their session notes.
Dylan will review session notes.
As appropriate, Dylan will make updates to release testing based on functional changes or previously untested cases.
Dylan will approve the PR for merge.
Any functional changes will be included in the next end to end test on the version bump PR as usual.
For visual changes, ensure that themes are properly applied.
When front end changes are made you should often test in desktop as well as browser as the JS is different.
Icons generated with system font can be different on from Mac to Windows.
Jira tickets must be filed for:
Planned changes in the core product (Server, Webapp, Mobile, Redux).
Bugs in the core product (Server, Webapp, Mobile, Redux).
Jira ticket may be filled for larger multi-plugin projects.
For all confirmed bugs a GitHub issue on the corresponding repository must be filed.
For all enhancements a GitHub issue on the corresponding repository should be filed.
Add a Type/X label to make clear what type the ticket is.
You may add a Difficulty/X label to set a mana estimate.
Easy means 2 mana
Medium means 4 mana
Hard means 8 mana
Putting an issue is always preferred over putting a PR on the board.
1% draft
This guide outlines the processes and workflows for requesting, updating, managing, and maintaining documentation for Mattermost-managed and community-managed apps, plugins, and integrations. This includes the branching strategy for the Gitbook repos, how to set up a new Gitbook, and the process for aligning documentation with releases.
Mattermost integrations documentation currently spans:
Gitbook: Configuration and User documentation for plugins, as well as developer content.
developers.mattermost.com: Apps documentation, plugin documentation, introduction to the contribution process, contribution workflow, testing, and validation information.
Mattermost-managed integrations are maintained by Mattermost staff and the documentation is written and maintained by the Integrations team. Community-managed integrations are maintained by their creator, which includes documentation maintenance.
For both options, please ensure that doc updates are either provided by you or requested ahead of merge so there's time to review the content. At least four days' notice is ideal. The goal is to ensure that docs and releases are always in sync.
The plugin documentation will soon be moved to developers.mattermost.com and will follow the same process as above. Until then, if you have a documentation update for your plugin, please work with @justinegeffen to ensure changes made in time and aligned with release.
This is the same process used for the webapp and server repos in terms of documentation work.
If a plugin has documentation for multiple versions the master branch is the source of truth of the docs for the current release version of a plugin. Previous releases are archived as a (version)-docs branch when docs need to change.
Every time we release a new minor or major version plugin we cut a new branch with docs and keep the branch forever so customers can still refer back to it.
Plugins that don't have documentation for multiple versions can have their content updated in master and don't follow this process.
We use Gitbook to render our documentation. A migration process from Gitbook to the Developers website is scheduled to start soon, at which point all plugin documentation will live in that repo.
Details of the PR process for updating docs once this migration is complete will follow.
TODO
Using session-based testing example format provided developers will perform functional testing on the PR and take lightweight session notes. See example attached here: .
Staff members add the issues there are working on for the current sprint to .
: Outline of how integrations work with Mattermost and a list of integrations available.
The Apps Framework and Marketplace documentation lives . When submitting documentation updates and new documentation for apps, there are two options available:
Submit the content with your PR in the repo. Add the Docs/Needed label to the PR and ping @justinegeffen. The content will then be added to the docs, and the Docs/Done label added to your PR.
Alternatively, you're welcome (and encouraged) to submit the docs PR yourself, , then add a Docs/Needed label and tag @justinegeffen.