Integrations team processes
- 2.Plugin Release Updates: Was did we ship in the last sprint? What do we want to ship in the next 4 weeks? What are blockers for that?
- 3.Thursday R&D Demo: Decide what to demo.
- 4.Guilds Updates: Short update from every guild meeting. If there isn't anything relevant, skip to the guild.
- 5.Triage Jira Toolkit, Jira Integrations, and GitHub.
- 6.Go through queued meeting items.
- 8.Remove all
Doneitems 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.
- 1.Dylan will @-mention reviewers and request peer testing posting a link to the process.
- 2.Using session-based testing example format provided developers will perform functional testing on the PR and take lightweight session notes. See example attached here: https://mattermost.atlassian.net/wiki/download/attachments/619937892/SampleSessionNotes.txt.
- 3.Once testing is done, developers will at mention Dylan in a comment and attach their session notes.
- 4.Dylan will review session notes.
- 5.As appropriate, Dylan will make updates to release testing based on functional changes or previously untested cases.
- 6.Dylan will approve the PR for merge.
- 7.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.
<!-- Your understanding of what functional impact the PR will have on the product -->
- Display username that created zoom meeting #62.
- Test that username of meeting creator is always shown.
<!-- Testing you've done that you feel validate the change and cover any needed regression -->
- User name is displayed in with Zoom meeting post as expected.
- Tested switching mapped users to ensure display remains accurate.
- Tested updating username to ensure display.
- Trigger 30 second meeting collision post to ensure the functionality is also affected by the enhancement.
Seeing an intermittent connection issue with Zoom on http://dkh-local.ngrok.io. Seems to occur on desktop.
- 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/Xlabel to make clear what type the ticket is.
- You may add a
Difficulty/Xlabel to set a mana estimate.
Easymeans 2 mana
Mediummeans 4 mana
Hardmeans 8 mana
- Staff members add the issues there are working on for the current sprint to https://github.com/orgs/mattermost/projects/1.
- Putting an issue is always preferred over putting a PR on the board.
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:
- docs.mattermost.com: Outline of how integrations work with Mattermost and a list of integrations available.
- 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.
The Apps Framework and Marketplace documentation lives here. When submitting documentation updates and new documentation for apps, there are two options available:
- 1.Submit the content with your PR in the plugin-apps repo. Add the
Docs/Neededlabel to the PR and ping @justinegeffen. The content will then be added to the docs, and the
Docs/Donelabel added to your PR.
- 2.Alternatively, you're welcome (and encouraged) to submit the docs PR yourself, here, then add a
Docs/Neededlabel and tag @justinegeffen.
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.