snapshot of https://github.com/mattermost/mattermost.git (master, 2026-09-16; blobs > 131072B omitted)

docs/develop/contribute/more-info/getting-started/branching.md

@@ -0,0 +1,64 @@
+---
+title: "Mattermost cherry-pick process"
+sidebar_position: 20
+---
+
+The self-managed releases are cut based off of the Mattermost Cloud release tags (e.g Mattermost Server v6.3 release was based off of ``cloud-2021-12-08-1`` Cloud release tag) in the server, webapp, enterprise, and api-reference repos. See [the Handbook release process](https://handbook.mattermost.com/operations/research-and-development/product/release-process/release-overview#cloud-release-branch-processes) for more details.
+
+The Mobile and Desktop app release branches are based off of ``master`` branch.
+
+## Developer process
+
+When your PR is required on a release branch (e.g. for a dot release or to fix a regression for an upcoming release), you will follow the cherry-picking process.
+
+1. Make a PR to 'master' like normal.
+2. Add the appropriate milestone and the `CherryPick/Approved` label.
+3. When your PR is approved, it will be assigned back to you to perform the merge and any cherry picking if necessary.
+4. Merge the PR.
+5. An automated cherry-pick process will try to cherry-pick the PR. If the automatic process succeeds, a new PR pointing to the correct release branch will open with all the appropriate labels. If there are no additional changes from the original PR for the cherry-pick, it can be merged without further review.
+6. If the automated cherry-pick fails, the developer will need to cherry-pick the PR manually. Cherry-pick the master commit back to the appropriate releases. If the release branches have not been cut yet, leave the labels as-is and cherry-pick once the branch has been cut. The release manager will remind you to finish your cherry-pick.
+7. Set the `CherryPick/Done` label when completed.
+
+   * If the cherry-pick fails, the developer needs to apply the cherry-pick manually.
+   * Cherry-pick the commit from `master` to the affected releases. See the steps below:
+8. Run the checks for lint and tests.
+9. Push your changes directly to the remote branch if the check style and tests passed.
+10. No new pull request is required unless there are substantial merge conflicts.
+11. Remove the `CherryPick/Approved` label and apply the `CherryPick/Done` label.
+
+
+<Note title="Note">
+If the PR needs to go to other release branches, you can run the command `/cherry-pick release-x.yz` in the PR comments and it will try to cherry-pick it to the branch you specified.
+</Note>
+
+
+### Manual cherry-pick
+
+If conflicts appear between your pull request (PR) and the cherry-pick target branch, the automated cherry-pick process will fail and will let you know that you need to do a manual cherry-pick. Here are the steps to do so:
+
+1. Fetch the latest updates from origin:
+```sh
+git fetch origin
+```
+2. Create a new branch starting at the release branch on origin.
+```sh
+git checkout -b manual-cherry-pick-pr-[PR_NUMBER] origin/release-[VERSION]
+```
+3. Find the SHA of the pull request merge commit, and cherry-pick this commit in your new branch:
+```sh
+git log origin/master
+git cherry-pick [SHA]
+```
+4. You're likely to face the conflict that prevented the automated cherry-pick now. Fix the conflict, and then run the following:
+```sh
+git add [path/to/conflicted/files]
+git cherry-pick --continue
+```
+5. Finally, push your new branch as usual and create a PR. Make sure you select `release-[VERSION]` as the base branch, and not the default (master).
+```sh
+git push -u origin manual-cherry-pick-pr-[PR_NUMBER]
+```
+
+## Reviewer process
+
+If you are the second reviewer reviewing a PR that needs to be cherry-picked, do not merge the PR. If the submitter is a core team member, you should set the `Reviews Complete` label and assign it to the submitter to cherry-pick. If the submitter is a community member who is not available to cherry-pick their PR or can not do it themselves, you should follow the cherry-pick process above.

docs/develop/contribute/more-info/getting-started/code-review.md

@@ -0,0 +1,140 @@
+---
+title: "Code review"
+sidebar_position: 5
+---
+
+All changes to the product should be reviewed. Every team will have its own workflow, but in general:
+
+* User experience changes should be reviewed by a product manager or designer.
+* Code changes should be reviewed by at least two core committers.
+* Documentation changes should be reviewed by a product manager or technical writer.
+
+Staff should consult the internal [organization chart](https://docs.google.com/spreadsheets/d/1lH8QIjQGEoGospDUdVs_LQ_i2b82I1ce6W7z18vhPTQ/edit#gid=1730823498) as needed when finding the right reviewer.
+
+If you are a community member seeking a review
+----------------------------------------------
+
+1. Submit your pull request.
+    * Follow the [contribution checklist](/developers/contribute/more-info/getting-started/contribution-checklist).
+2. Wait for a reviewer to be assigned.
+    * Product managers are on the lookout for new pull requests and usually handle this for you automatically.
+    * If you have been working alongside a core committer, feel free to message them for help.
+    * When in doubt, ask for help in the [Developers](https://community.mattermost.com/core/channels/developers) channel on our community server.
+    * If you are still stuck, message Jason Blais ([@jasonblais](https://github.com/jasonblais) on GitHub) or Jason Frerich ([@jfrerich](https://github.com/jfrerich) on GitHub).
+3. [Wait for a review](#if-you-are-awaiting-a-review).
+    * Expect some interaction with at least one reviewer within 5 business days. (Business days are typically Monday to Friday, excluding [statutory holidays](https://handbook.mattermost.com/operations/workplace/people/working-at-mattermost/paid-time-off#typical-public-holidays-in-canada-germany-uk-us).)
+    * Keep in mind that core committers are geographically distributed around the world and likely in a different time zone than your own.
+    * If no interaction has occurred after 5 business days, at-mention a reviewer with a comment on your PR.
+4. Make any necessary changes.
+    * If a reviewer requests changes, your pull request will disappear from their queue of reviews.
+    * Once you've addressed the concerns, re-request a review from any reviewer requesting changes.
+    * [Avoid force pushing](https://mattermost.com/blog/submitting-great-prs/#4-avoid-force-pushing).
+5. Wait for your code to be merged.
+    * Larger pull requests may require more time to review.
+    * Once all reviewers have approved your changes, they will handle merging your code.
+
+If you are a core committer seeking a review
+--------------------------------------------
+
+1. Submit your pull request.
+    * Follow the [contribution checklist](/developers/contribute/more-info/getting-started/contribution-checklist).
+2. Immediately add the `1: UX Review`, `2: Dev Review`, and `3: QA Review` labels.
+    * Your pull request should not be merged until these labels are later removed in the review process.
+3. Apply additional labels as necessary:
+    * `CherryPick/Approved`: Apply this if the pull request is meant for a quality or patch release.
+    * `Do Not Merge/Awaiting PR`: Apply this if the pull request depends on another (e.g. server changes)
+    * `Setup Test Server`: Apply this to create a test server with your changes for review.
+    * See [labels](/developers/contribute/more-info/getting-started/labels) for additional documentation.
+4. Assign a milestone as necessary.
+    * Most pull requests do not require a milestone, but will simply ship once merged.
+    * Some reviewers may prioritize reviews for known upcoming milestones.
+    * The milestone is mandatory for bug fixes that must be cherry-picked.
+5. Request a review from a Product Manager and/or a Designer.
+    * The choice of Product Manager or Designer is up to you.
+        - In most cases, choose the individual embedded with your team.
+        - If your change primarily touches another team's codebase, assign the individual from that team.
+        - If in doubt, assign any Product Manager or Designer and comment about the uncertainty. They may reassign as appropriate.
+    * [Wait](#if-you-are-awaiting-a-review) for their review to complete before continuing so as to avoid churn if changes are requested.
+    * Remove the `1: UX Review` label only when these reviews are done and they accept the changes.
+        - Product Managers and Designers ensure the changes meet [user experience guidelines](https://docs.mattermost.com/developer/fx-guidelines.html).
+    * If your changes do not affect the user experience, you may remove `1: UX Review` immediately.
+6. After UX review, request a review from two core committers.
+    * The choice of core committers is up to you.
+        - When picking your first core committer, consider someone with domain expertise relative to your changes. Sometimes GitHub will recommend a recent editor of the code, but often you must rely on your own intuition from past interactions.
+        - When picking your second core committer, consider someone who may have expertise in the language you're using or the problem you're solving, even if they aren't intricately familiar with the codebase. This can provide a fresh set of eyes on the code to reveal blindspots that are not biased by hitting deadlines, and helps expose the team to new parts of the code to help spread out domain knowledge. This may not make sense for every pull request but is a practice to keep in mind. If you don't have someone specific in mind, consider using the [`@core-reviewers`](https://github.com/orgs/mattermost/teams/core-reviewers) group to assign an available reviewer automatically.
+        - Don't be afraid to pick someone who gives "hard" reviews. Code review feedback is never a personal attack: it should "sharpen" the skills of both the author and the reviewers, not to mention improving the quality of the product.
+        - Try to avoid assigning the same person to all of your reviews unless they are related.
+        - When in doubt, ask for recommendations on our community server.
+    * [Wait](#if-you-are-awaiting-a-review) for their review to complete before continuing so as to avoid churn if changes are requested.
+    * Remove the `2: Dev Review` label only when these reviews are done and they accept the changes.
+7. After Dev review, assign a QA tester.
+    * Ensure that your PR includes test steps or expected results for QA reference if the QA Test Steps in the Jira ticket have not already been filled in.
+    * The choice of QA tester is up to you.
+        - In most cases, choose the individual embedded with your team.
+        - If your change primarily touches another team's codebase, assign the individual from that team.
+        - If in doubt, assign any QA tester and comment about the uncertainty. They may reassign as appropriate.
+    * [Wait](#if-you-are-awaiting-a-review) for their review to complete before continuing.
+        - It is the QA tester's responsibility to determine the scope of required testing, if any.
+    * Remove the `3: QA Review` label only when their review is done and they accept the changes.
+    * In the rare event your changes do not require QA review, you may remove `3: QA Review` immediately.
+        - Comment on the pull request clearly explaining the rationale.
+8. Merge the pull request.
+    * Do not merge until the labels `1: UX Review`, `2: Dev Review` and `3: QA Review` labels have been removed.
+    * Add the `4: Reviews Complete` label if the last reviewer did not already add it.
+    * Do not merge if there are outstanding changes requested.
+    * Merge your pull request and delete the branch if not from a fork.
+        - Note that any core committer is free to merge on your behalf.
+        - If your pull request depends on other pull requests, consider assigning the `Do Not Merge/Awaiting PR` label to avoid merging prematurely.
+9. Handle any cherry-picks.
+    * There is an automated cherry-pick process. 
+    * As the author of the pull request, you should make sure the cherry-pick succeeds. 
+    * [Check here](/developers/contribute/more-info/getting-started/branching#cherry-pick-process---developer) for details.
+10. After a pull request is merged (and cherry-picked where needed), update the Jira ticket.
+    * Resolve the ticket for QA from "Ready for QA" button with QA test steps (or "No Testing Required" if no QA testing is needed).
+
+If you are awaiting a review
+----------------------------
+
+1. Wait patiently for reviews to complete.
+    * Expect some interaction with each of your reviewers within 2 business days.
+    * There is no need to explicitly mention them on the pull request or to explicitly reach out on our community server.
+    * Core committers and QA testers are expected to have the GitHub plugin installed to automate notifications and to trigger a daily review of their outstanding requested reviews.
+2. Make any necessary changes.
+    * If a reviewer requests changes, your pull request will disappear from their queue of reviews.
+    * Once you've addressed the concerns, assign them as a reviewer again to put your pull request back in their queue.
+
+If you are a core committer asked to give a review
+--------------------------------------------------
+
+1. Respond promptly to requested reviews.
+    * Assume the requested review is urgent and blocking unless explicitly stated otherwise.
+    * Try to interact with the author within 2 business days.
+    * Configure the GitHub plugin to automate notifications.
+    * Review your outstanding requested reviews daily to avoid blocking authors.
+    * Prioritize earlier milestones when reviewing to help with the release process.
+    * Responding quickly doesn't necessarily mean reviewing quickly! Just don't leave the author hanging.
+2. Feel free to clarify expectations with the author.
+    * If the PR adds a substantial feature, check that a feature flag is included. Please see [criteria here](/developers/contribute/more-info/server/feature-flags#when-to-use).
+    * If the code is experimental, they may need only a cursory glance and thumbs up to proceed with productizing their changes.
+    * If the review is large or complex, additional time may be required to complete your review. Be upfront with the author.
+    * If you are not comfortable reviewing the code, avoid "rubber stamping" the review. Be honest with the author and ask them to consider another core committer.
+3. Never rush a review.
+    * Take the time necessary to review the code thoroughly.
+    * Don't be afraid to ask for changes repeatedly until all concerns are addressed.
+    * Feel free to challenge assumptions and timelines. Rushing a change into a patch release may cause more harm than good.
+4. Avoid leaving a review hanging.
+    * Try to accept or reject the review instead of just leaving comments.
+    * If you are the last developer to approve the changes, consider requesting a review from the appropriate QA tester to speed up the process.
+6. Run the E2E tests against the PR code
+    * After the PR has been reviewed, the reviewer should trigger an E2E test run on it by using [one of the available mechanisms](https://mattermost.atlassian.net/wiki/spaces/CLOUD/pages/2627371043/E2E+Tests). The E2E Test result will be posted back to the PR as a comment.
+    * It's the PR author's responsibility to address the E2E test failures, with the assistance of the reviewers.
+    * Core committers can refer to [this Confluence page](https://mattermost.atlassian.net/wiki/spaces/CLOUD/pages/2627371043/E2E+Tests) for additional informations on E2E testing and related processes.
+7. Merge the pull request.
+    * Do not merge until the labels `1: UX Review`, `2: Dev Review` and `3: QA Review` labels have been removed.
+    * Add the `4: Reviews Complete` label if the last reviewer did not already add it.
+    * Do not merge if there are outstanding changes requested.
+    * Do not merge if there are any `Do Not Merge` labels applied.
+        - When in doubt, leave the merging of the pull request to the author.
+    * Merge the pull request, and delete the branch if not from a fork.
+8. Handle any cherry-picks.
+    * There is an automated cherry-pick process and the author of the pull request should make sure the cherry-pick succeeds. Assume this is the case unless you are explicitly asked to help cherry-pick.

docs/develop/contribute/more-info/getting-started/contribution-checklist.md

@@ -0,0 +1,35 @@
+---
+title: "Contribution checklist"
+sidebar_position: 2
+---
+
+Thanks for your interest in contributing to Mattermost! Come join our [Contributors community channel](https://community.mattermost.com/core/channels/tickets) on the community server, where you can discuss questions with community members and the Mattermost core team.
+
+To help with translations, [see the localization process](https://docs.mattermost.com/developer/localization.html).
+
+Follow this checklist for submitting a pull request (PR):
+
+1. You've signed the [Contributor License Agreement](https://mattermost.com/mattermost-contributor-agreement/), so you can be added to the Mattermost [Approved Contributor List](https://docs.google.com/spreadsheets/d/1NTCeG-iL_VS9bFqtmHSfwETo5f-8MQ7oMDE5IUYJi_Y/pubhtml?gid=0&single=true).
+    - If you've included your mailing address in the signed [Contributor License Agreement](https://mattermost.com/mattermost-contributor-agreement/), you may receive a [Limited Edition Mattermost Mug](https://forum.mattermost.com/t/limited-edition-mattermost-mugs/143) as a thank you gift after your first pull request is merged.
+2. You have claimed the ticket that you wish to work on by asking for an assignment from the Mattermost team.
+   - Tickets are assigned on a first-come-first-serve basis.
+3. Your ticket is a Help Wanted GitHub issue for the Mattermost project you're contributing to.
+    - If not, follow the process [here](/developers/contribute/more-info/getting-started/contributions-without-ticket).
+4. Your code is thoroughly tested, including appropriate [unit, end-to-end, and integration tests for webapp](/developers/contribute/more-info/getting-started/test-guideline).
+5. If applicable, user interface strings are included in localization files:
+    - [mattermost/server/en.json](https://github.com/mattermost/mattermost/blob/master/server/i18n/en.json)
+    - [mattermost/webapp/channels/src/i18n/en.json](https://github.com/mattermost/mattermost/blob/master/webapp/channels/src/i18n/en.json)
+    - [mattermost-mobile/assets/base/i18n/en.json](https://github.com/mattermost/mattermost-mobile/blob/master/assets/base/i18n/en.json)
+
+    5.1. In the webapp/channels repository run `npm run i18n-extract` to generate the new/updated strings.
+6. The PR is submitted against the Mattermost `master` branch from your fork.
+7. The PR title begins with the Jira or GitHub ticket ID (e.g. `[MM-394]` or `[GH-394]`) and summary template is filled out.
+8. If your PR adds or changes a RESTful API endpoint, please update the [API documentation](https://github.com/mattermost/mattermost/tree/master/api).
+9. If your PR adds a new plugin API method or hook, please add an example to the [Plugin Starter Template](https://github.com/mattermost/mattermost-plugin-starter-template).
+10. If QA review is applicable, your PR includes test steps or expected results.
+11. If the PR adds a substantial feature, a feature flag is included. Please see [criteria here](/developers/contribute/more-info/server/feature-flags#when-to-use).
+12. Your PR includes basic documentation about the change/addition you're submitting. View our [guidelines](https://handbook.mattermost.com/operations/research-and-development/product/technical-writing-team-handbook#submit-documentation-with-your-pr-community) for more information about submitting documentation and the review process.
+
+Once submitted, the automated build process must pass in order for the PR to be accepted. Any errors or failures need to be addressed in order for the PR to be accepted. Next, the PR goes through [code review](/developers/contribute/more-info/getting-started/code-review). To learn about the review process for each project, read the `CONTRIBUTING.md` file of that GitHub repository. 
+
+That's all! If you have any feedback about this checklist, let us know in the [Contributors channel](https://community.mattermost.com/core/channels/tickets).

docs/develop/contribute/more-info/getting-started/contributions-without-ticket.md

@@ -0,0 +1,29 @@
+---
+title: "Contributions without ticket"
+sidebar_position: 1
+---
+
+Contributions for minor corrections and improvements without a corresponding `Help Wanted` ticket are welcome. For example, a pull request for a bug or incremental improvement, with less than 20 lines of code change, is usually accepted if the change to existing behaviour is minor.
+
+All pull requests submitted without a corresponding ticket will first be reviewed by a core team product manager. Some examples of minor corrections and improvements include:
+
+- [Fix a formatting error in help text](https://github.com/mattermost/mattermost/pull/5640)
+- [Fix success typo in Makefile](https://github.com/mattermost/mattermost/pull/5809)
+- [Fix broken Cancel button in Edit Webhooks screen](https://github.com/mattermost/mattermost/pull/5612)
+- [Fix Android app crashing when saving user notification settings](https://github.com/mattermost/mattermost-mobile/pull/364)
+- [Fix recent mentions search not working](https://github.com/mattermost/mattermost/pull/5878)
+
+
+<Note title="Note">
+For pull requests greater than 20 lines of code, a `Help Wanted` ticket should be opened by the core team. This helps ensure that everything going into the project aligns with a unified vision. Core committers who review the PR are entitled to reject it if there isn't a `Help Wanted` ticket and feel it significantly changes behavior or user expectations.
+</Note>
+
+
+
+<Note title="Note">
+Please use [our translation server](https://translate.mattermost.com) to correct errors in translation.
+</Note>
+
+
+
+The best way to discuss opening a `Help Wanted` ticket with the core team is by [starting a conversation in the feature idea forum](https://mattermost.uservoice.com/forums/306457-general) or [opening an issue in the GitHub repository](https://github.com/mattermost/mattermost/issues/new). Alternatively, don't hesitate to come chat about it in the [Contributors](https://community.mattermost.com/core/channels/tickets) or [Developers](https://community.mattermost.com/core/channels/developers) channels.

docs/develop/contribute/more-info/getting-started/core-committers.md

@@ -0,0 +1,6 @@
+---
+title: "Core committers"
+sidebar_position: 4
+---
+
+A core committer is a maintainer on the Mattermost project that has merge access to Mattermost repositories. They are responsible for reviewing pull requests, cultivating the Mattermost developer community, and guiding the technical vision of Mattermost. 

docs/develop/contribute/more-info/getting-started/guilds.md

@@ -0,0 +1,41 @@
+---
+title: "Engineering guilds"
+sidebar_position: 50
+---
+
+Our Engineering Guilds are a forum for sharing knowledge, discussing and agreeing on plans, and disseminating information related to a particular subject or technical topic. Many (although not all) Engineering Guilds are affiliated to a particular "platform" that forms a part of Mattermost, and are therefore associated with a particular Platform Team. However, the participants in each Guild span many engineering teams at Mattermost in order to get people together to share knowledge and disseminate decisions across the Engineering organization.
+
+The main activity of Guilds is a regular meeting. These meetings are public, and anyone within Mattermost and the wider community is welcome to attend. Details are provided below on each of the Guilds, including how to participate.
+
+## Web platform guild
+
+The Web Platform Guild covers all areas related to front-end web development and Electron desktop app development at Mattermost.
+
+- **Guild Lead:** Harrison Healey
+- **Guild channel:** [~Developers: WebApp](https://community.mattermost.com/core/channels/webapp)
+- **Guild meeting time:** *(see header of Guild channel for meeting invite)*
+
+## Mobile guild
+
+The Mobile Guild covers all areas related to mobile application development and React Native.
+
+- **Guild Lead:** Elias Nahum
+- **Guild channel:** [~Developers: Mobile](https://community.mattermost.com/core/channels/native-mobile-apps)
+- **Guild meeting time:** *(see header of Guild channel for meeting invite)*
+
+## Server guild
+
+The Server Guild covers all areas related to our server codebase and general Go development at Mattermost.
+
+- **Guild Lead:** Agniva De Sarker
+- **Guild channel:** [~Developers: Server](https://community.mattermost.com/core/channels/developers-server)
+- **Guild meeting time:** *(see header of Guild channel for meeting invite)*
+
+## QA guild
+
+The QA Guild covers all areas related to Quality Assurance and automated testing infrastructure at Mattermost.
+
+- **Guild Lead:** Saturnino Abril
+- **Guild channel:** [~QA: Weekly Meetings](https://community.mattermost.com/core/channels/qa-weekly-meetings)
+- **Guild meeting time:** *(see header of Guild channel for meeting invite)*
+

docs/develop/contribute/more-info/getting-started/inactive-contributions.md

@@ -0,0 +1,26 @@
+---
+title: "Inactive contributions"
+sidebar_position: 3
+---
+
+This process describes how inactive contributions are managed at Mattermost, inspired by the [Kubernetes project](https://github.com/kubernetes/kubernetes):
+
+1. After 10 days of inactivity, a contribution becomes stale and a bot will add the `lifecycle/1:stale` label to the contribution.
+    - If action is required from submitter, Community Coordinator asks if the team can help clarify previous feedback or provide guidance on next steps.
+    - If action is required from reviewers, Community Coordinator asks reviewers to share feedback or help answer questions. The Coordinator will follow up with reviewers until a response is received.
+
+2. After 20 days of inactivity, a contribution becomes inactive.
+    - Community Coordinator asks the submitter if the team can help with questions. They acknowledge that after another 30 days of inactivity the contribution will be closed. They also add a `lifecycle/2:inactive` label to the contribution.
+  
+<Note title="Note">
+Contributions should never become orphaned because of reviewers. The Coordinator will be responsible for receiving a response from the reviewers during the stale period, which may be that the maintainers aren't able to accept the contribution in its current form.
+</Note>
+
+3. After 30 days of inactivity, a contribution becomes orphaned.
+    - Community Coordinator notes that the contribution has been inactive for 60 days, thanks for the contribution and closes the contribution. They also add an `lifecycle/3:orphaned` label to the contribution, and adds an `Up For Grabs` label to the associated help wanted ticket, if appropriate.
+
+Exceptions:
+
+1. If the contribution is inactive but shouldn't be closed, the Coordinator adds a `lifecycle/frozen` label to the contribution. An example of this is when a design decision is being discussed but no decision has been arrived at yet.
+2. Once the contribution reaches the `lifecycle/2:inactive` state, it is eligible to be assumed by another community member interested in working on the ticket.
+3. Invalid PRs may be closed immediately without advancing through this lifecycle, especially if the contributor is unresponsive.

docs/develop/contribute/more-info/getting-started/index.md

@@ -0,0 +1,31 @@
+---
+title: "Contribute code"
+sidebar_position: 1
+---
+
+This site is for developers who want to contribute code to the core Mattermost project. If you’re looking for other ways to contribute, [head over to our website](https://mattermost.com/contribute/). Before getting started, it’s a good idea to review our guide on [integrating and extending Mattermost](/developers/integrate/getting-started) because you might be able to build the improvements you want without needing to contribute them upstream.
+
+
+## Technical overview
+
+The Mattermost core repositories include:
+* [Server](/developers/contribute/more-info/server) - Highly-scalable Mattermost installation written in Go
+* [Web App](/developers/contribute/more-info/webapp) - JavaScript client app built on React and Redux
+* [Mobile Apps](/developers/contribute/more-info/mobile) - JavaScript client apps for Android and iOS built on React Native
+* [Desktop App](/developers/contribute/more-info/desktop) - An Electron wrapper around the web app project that runs on Windows, Linux, and macOS
+* [Core Plugins](/developers/contribute/more-info/plugins) - A core set of officially-maintained plugins that provide a variety of improvements to Mattermost.
+* Core Integrations - Major Mattermost features including [Focalboard](/developers/contribute/more-info/focalboard) and [Playbooks](https://github.com/mattermost/mattermost-plugin-playbooks).
+
+Improvements to Mattermost may require you to contribute to multiple projects; if you’re unsure where to start, the server repository is generally the best way to get introduced to the codebase.
+
+
+## How to contribute code
+
+If you’re looking for an existing issue to help with, check out the [help wanted tickets on GitHub](https://mattermost.com/pl/help-wanted). If you see any that you’re interested in working on, comment on it to let everyone know you’re working on it. If there’s no ticket for what you want to contribute, see our guide on [contributing without a ticket.](/contributions-without-ticket)
+
+Once you’ve created some code that you want to contribute, follow our [pull request checklist](/contribution-checklist) to submit your contribution for [review](/code-review), and one of our [core committers](/developers/contribute/more-info/getting-started/core-committers) will reach out with any feedback, questions, or requests they have.
+
+
+## How to get help with your contribution
+
+Our contributor community is segmented into [guilds](/developers/contribute/more-info/getting-started/guilds) that focus on specific components within the Mattermost ecosystem. Each guild has a leader and a channel on our [community chat server](https://docs.mattermost.com/guides/community-chat.html) where you can ask questions about your contribution.

docs/develop/contribute/more-info/getting-started/labels.md

@@ -0,0 +1,61 @@
+---
+title: "Labels"
+sidebar_position: 7
+---
+
+We leverage [GitHub labels](https://help.github.com/en/articles/about-labels) to track the details and lifecycle of issues and pull requests.
+
+# Issue labels
+
+* `Area/<name>`: Involves changes to the named area (APIv4, E2E Tests, Localization, Plugins, etc.)
+* `Bug Report/Open`: Bug report unresolved, awaiting for more information or in development backlog.
+* `Bug Report/Scheduled for Release`: Bug report resolved and scheduled for an upcoming release. Milestone indicates scheduled release version.
+* `Difficulty/1:easy`: Easy ticket.
+* `Difficulty/2:medium`: Medium ticket.
+* `Difficulty/3:hard`: Hard ticket.
+* `Good First Issue`: Suitable for first-time contributors.
+* `Help Wanted`: Community help wanted.
+* `Move to Feature Ideas forum`: Marked for relocation to the feature ideas forum.
+* `Move to Troubleshooting`: Marked for relocation to the troubleshooting section of the documentation.
+* `PR Submitted`: A pull request has been opened for this issue.
+* `Tech/<name>`: Requires using the named technology (Go, JavaScript, ReactJS, Redux, etc.)
+* `Up for Grabs`: Ready for help from the community. Removed when someone volunteers.
+
+# Pull request labels
+
+* `1: PM Review`: Requires review by a [product manager](https://handbook.mattermost.com/contributors/contributors/core-committers#product-managers).
+* `1: UX Review`: Requires review by a UX designer.
+* `1: SME Review`: Requires review by a subject matter expert (used in the Handbook).
+* `2: Dev Review`: Requires review by a [core committer](https://handbook.mattermost.com/contributors/contributors/core-committers#core-committers).
+* `2: Editor Review`: Requires review by a [technical writer](https://handbook.mattermost.com/contributors/contributors/core-committers#technical-writers).
+* `3: QA Review`: Requires review by a [QA tester](https://handbook.mattermost.com/contributors/contributors/core-committers#qa-testers). May occur at the same time as Dev Review.
+* `4: Reviews Complete`: All reviewers have approved the pull request.
+* `Awaiting Submitter Action`: Blocked on the author.
+* `AutoMerge`: If all checks and approvals pass and the user adds this label, it will be in the queue to get merge automatically without a human intervention.
+* `Changelog/Done`: Required changelog entry has been written.
+* `Changelog/Not Needed`: Does not require a changelog entry.
+* `CherryPick/Approved`: Meant for the quality or patch release tracked in the milestone.
+* `CherryPick/Candidate`: A candidate for a quality or patch release, but not yet approved.
+* `CherryPick/Done`: Successfully cherry-picked to the quality or patch release tracked in the milestone.
+* `Demo Plugin Changes/Needed`: Requires changes to the demo plugin.
+* `Demo Plugin Changes/Done`: Required changes to the demo plugin have been submitted.
+* `Do Not Merge/Awaiting Loadtest`: Must be loadtested before it can be merged.
+* `Do Not Merge/Awaiting Next Release`: To be merged with the next release (e.g. API documentation updates).
+* `Do Not Merge/Awaiting PR`: Awaiting another pull request before merging (e.g. server changes).
+* `Do Not Merge`: Should not be merged until this label is removed.
+* `Docs/Done`: Required documentation has been written.
+* `Docs/Needed`: Requires documentation.
+* `Docs/Not Needed`: Does not require documentation.
+* `Hackfest`: Related to a Mattermost hackathon.
+* `Hacktoberfest`: Related to [Hacktoberfest](https://hacktoberfest.digitalocean.com/).
+* `Lifecycle/<state>`: An [inactive contribution](/developers/contribute/more-info/getting-started/inactive-contributions).
+* `Loadtest`: Triggers an automatic load test.
+* `Major Change`: The pull request is a major feature or affects large areas of the code base (e.g. [moving channel store and actions to Redux](https://github.com/mattermost/platform/pull/6235)).
+* `QA Deferred`: Testing of this PR is expected to be completed after merge, likely when it is available on Community. Apply this in lieu of asking for `3: QA Review`.
+* `Setup Cloud Test Server`: Triggers the creation of a Enterprise Edition test server.
+* `Setup HA Cloud Test Server`: Triggers the creation of a test server that has high availability.
+* `Setup Cloud + CWS Test Server`: Triggers the creation of a test server that connects to our test Customer Web Server.
+* `Setup Upgrade Test Server`: Triggers the creation a test server and performs an upgrade.
+* `Tests/Done`: Required tests have been written.
+* `Tests/Not Needed`: Does not require tests.
+* `Work in Progress`: Not yet ready for review.

docs/develop/contribute/more-info/getting-started/slash-commands.md

@@ -0,0 +1,13 @@
+---
+title: "Slash commands"
+sidebar_position: 30
+---
+
+There are a couple of slash-commands available on GitHub which are implemented via [Mattermod](https://github.com/mattermost/mattermost-mattermod). They only work on PRs.
+
+The commands are:
+
+- `/cherry-pick $BRANCH_NAME`, e.g. `/cherry-pick release-5.10`: Opens a PR to cherry-pick a change into the branch `$BRANCH_NAME`. This command only works for the submitter of the PR and members of the Mattermost organization.
+- `/check-cla`: Checks if the PR contributor has signed the CLA.
+- `/autoassign`: Automatically assigns reviewers to a PR.
+- `/update-branch`: Updates the pull request branch with the latest upstream changes by merging HEAD from the base branch into the pull request branch. This command only works for members of the Mattermost organization.

docs/develop/contribute/more-info/getting-started/test-guideline.md

@@ -0,0 +1,72 @@
+---
+title: "Test guidelines"
+sidebar_position: 6
+---
+
+At Mattermost, we write tests because we want to be confident that our product works as expected for our users. As developers, we write tests as a gift to our future selves or to be confident that changes won't cause regressions or unintended behaviors. We value contributors who write tests as much as any others, and we want the process to be integrated in our core development workflow rather than being an afterthought or follow-up action.
+
+This page stresses the importance of tests, including for every pull request being submitted. It is the foundation of our test guidelines, and serves as a reference on why we do not merge code without tests. This is not to meet higher code coverage but rather to write effective and well-planned use cases depending on the changes being made. But of course, there's always an exception. If, for some reason, it isn't possible to write a test, let the reviewers know by writing a description to start a discussion and to fully understand the situation you are facing.
+
+Test categories
+---------------
+Not all test types are required in a single pull request. Only write whichever test types are most effective and appropriate.
+1. __Unit tests__ - Unit tests verify that individual, isolated parts work as expected.
+2. __Integration tests__ - Integration tests verify that several units work together in harmony.
+3. __End-to-End (E2E) tests__ - End-to-End tests exercise most of the parts of a large application.
+
+
+<Note title="Note">
+Wisdom and definitions mostly taken from [Martin Fowler's Software Testing Guide](https://martinfowler.com/testing/) and [Kent C. Dodds's personal site](https://kentcdodds.com/).
+</Note>
+
+
+In general, when are tests necessary?
+-------------------------------------
+- For all files written in the main language(s) of the repository; this could be JavaScript/Typescript and JSX/TSX files, Go files, or both which are exported such as functions, modules, or components used in various places. 
+- Un-exported functions or methods, which have low or no test coverage from the parent exported function/method, that affect critical functionality or behavior of the application.
+- New features and bug fixes, especially those originating from customer and community bugs.
+
+When is it fine not to have tests?
+--------------------------------------------
+- For implementation details of standard libraries or external packages that are implicitly covered by the standard library or external package itself.
+- Where the situation may require external services running to effectively test the functionality, such as dependencies on feature flags via [Split](https://split.io), OAuth with third-party providers such as Google, etc.
+- Tests should be made at the most effective and lowest possible level, but if it requires too much effort or complicated setup to accomplish at a unit test level, it would be best to skip and assess feasibility on the next level such as integration or end-to-end testing.
+- Mocks and test helpers.
+- Types only.
+- Interfaces only or interfaces to other repositories, such as with private Enterprise via “interfaces”.
+- End-to-end tests codebase.
+- Automatically generated code for database migrations, store layers, etc.
+- External dependencies, modules, imports, or vendors.
+
+How to run and write tests
+------------------
+### Server
+For writing and running **unit tests** in general, see the [Server workflow](/developers/contribute/more-info/server/developer-workflow) page. If you have written a new endpoint or changed an endpoint for the Mattermost REST API, check out the [REST API](/developers/contribute/more-info/server/rest-api) page.
+
+### Web App
+For writing and running **unit tests** in general, see the [Unit tests](/developers/contribute/more-info/webapp/unit-testing) page. For writing and running **E2E tests** in general, see the [End-to-End testing](/developers/contribute/more-info/webapp/e2e-testing) section, and the [End-to-End cheatsheets](/developers/contribute/more-info/webapp/e2e-cheatsheets) section. 
+
+For writing and running **E2E (and unit) tests for Redux** components, see the [Redux Unit and E2E Testing](/developers/contribute/more-info/webapp/redux/testing) page.
+
+### Mobile Apps
+For writing and running **E2E tests** for both Android and iOS systems, take a look at the [Mobile End-to-End (E2E) Tests](/developers/contribute/more-info/mobile/e2e) page.
+
+### Desktop App
+For writing and running **unit and E2E tests** for the desktop app, check out the [Unit and End-to-End (E2E) Tests in the desktop app](/developers/contribute/more-info/desktop/testing) page.
+    
+# How to Contribute E2E Tests
+If you're looking to improve your development skills or improve your familiarity with the Mattermost code base, issues for E2E tests that are marked Help Wanted are a great place to start.
+    
+* Look for [issues in the mattermost](https://github.com/mattermost/mattermost/issues?q=is%3Aissue+is%3Aopen+e2e) repository that have the `Help Wanted` label and either the `Area/E2E Tests` label or something related to E2E in the issue title.
+  * Once you find an issue you would like to work on, comment on the issue to claim it.
+* Each issue is filled with specific test steps and verifications that need to be accomplished as a minimum requirement.  Additional steps and assertions for robust test implementation are very welcome. The contents of an E2E issue follow this general format:
+  * **Steps**: What the code in the test should do and/or emulate.
+  * **Expected**: What the results of the test should be.
+  * **Test Folder**: Where the file that holds the test code should be located.
+  * **Test code arrangement**: Starter code for the test.
+  * **Notes**: Comments on what to add and not to add to the test file, plus resources for contributions, asking questions, etc.
+    
+If you'd like to see an example of an ideal E2E test contribution, please view these issues and their associated PRs:
+* [Write Webapp E2E with Cypress: "MM-T642 Attachment does not collapse"](https://github.com/mattermost/mattermost/issues/18184)
+* [Cypress test: "CTRL/CMD+K - Open private channel using arrow keys and Enter"](https://github.com/mattermost/mattermost/issues/14078)
+

docs/develop/contribute/more-info/getting-started/test-servers.md

@@ -0,0 +1,31 @@
+---
+title: "Test servers"
+sidebar_position: 8
+---
+
+As part of the pull request review process, reviewers may need to test and verify proposed changes. Leveraging our Cloud infrastructure, we can spin up full environments on demand to test code submitted in PRs.
+
+Core committers and staff can trigger test server creation on a PR by adding one of the following labels to the PR:
+
+* `Setup Cloud Test Server`: Triggers the creation of a standard test server using the latest commit on the PR and a PostgreSQL database.
+* `Setup HA Cloud Test Server`: Triggers the creation of a test server that has high availability.
+* `Setup Cloud + CWS Test Server`: Triggers the creation of a test server that connects to our test Customer Web Server.
+
+After adding these labels, a bot will comment on the PR notifying you that a test server is being created. It should take approximately 3-5 minutes for the server to create it. Once it's ready, the bot will comment on the PR again with a link and credentials to the test server for both an admin and a regular user.
+
+If the bot comments that an error has occurred, try removing the label and then re-adding it again. If that still fails, please ask for help in [~Developers: Cloud](https://community.mattermost.com/core/channels/cloud). If you need urgent help, please mention `@sresupport` in your message.
+
+Once testing is complete, remove the label and the test server will be destroyed.
+
+Test servers are available on any repositories that have the labels.
+
+# Tips and tricks
+
+* Avoid adding and removing the labels quickly in succession - this can confuse the bot and result in issues. Please be patient. :)
+* Pushing new commits to PRs will trigger the bot to automatically update the test server.
+* When submitting a new PR or pushing an update to a PR, the docker build/push CI step must complete before a test server can be created/updated.
+* Please make sure to remove labels when testing is complete since there is a limited capacity for test servers.
+* If you want a test server to have the changes from two different PRs across the webapp and server repositories, ensure:
+  * Both server and webapp branches are named the same and are on the main repos and not from forks.
+  * The server build completes before the webapp build runs (you can re-trigger the webapp build if it didn't).
+  * The test server was created after the webapp build is complete (that included the server build) and present on the PR for the web app.

docs/develop/contribute/more-info/getting-started/using-gitpod.md

@@ -0,0 +1,112 @@
+---
+title: "Using Gitpod"
+sidebar_position: 6
+---
+
+### What is Gitpod?
+[Gitpod](https://www.gitpod.io/) is a cloud development environment. The following instructions have been adapted from comments on this issue: [Document general usage of Gitpod #18 ](https://github.com/mattermost/mattermost-gitpod-config/issues/18). You can also check out these videos to learn how to work with Gitpod (and write an E2E test): [How to set up a developer environment for Mattermost with Gitpod](https://www.youtube.com/watch?v=LgQ2Z_GelYQ) and [Writing your first E2E test for Mattermost](https://www.youtube.com/watch?v=mLbzKSGZv4A).
+
+#### :cyclone: Spinning up an environment
+
+1. Create a new workspace for a ticket/issue that you've claimed by going to the [mattermost-gitpod-config](https://github.com/mattermost/mattermost-gitpod-config/tree/master) repository and clicking the "Open in Gitpod" badge.
+
+    * You can also use the [Gitpod browser extension](https://www.gitpod.io/docs/configure/user-settings/browser-extension) to open up a repository in Gitpod, or manually prefix GitHub repository URLs with `gitpod.io/#`. What the extension does is add a green Gitpod button to repository pages on GitHub, and clicking it spins up a new environment for the repository on Gitpod.
+    ![mattermost-gitpod-config-repo](https://user-images.githubusercontent.com/43153413/194467192-675a6b15-bb3b-4a4d-be05-f1df0fbdd524.jpeg)
+
+2. You may need to sign in (through GitHub) to access the workspace on Gitpod. Once Gitpod has done loading, the user interface presented is that of VSCode.
+![mattermost-gitpod-intro](https://user-images.githubusercontent.com/43153413/194467255-98b5a9be-85a5-4da8-b519-279011882384.jpeg)
+ 
+#### :pencil2: Working on an issue/ticket
+ 
+3. Make changes to one of the projects. For example, you could be working on writing an End-to-End (E2E) test, like this issue [Write Webapp E2E with Cypress: "MM-T642 Attachment does not collapse" #18184](https://github.com/mattermost/mattermost/issues/18184). The development process is very similar to how you would work locally.
+
+#### :herb: Making branches and forks
+
+4. You most likely won't have direct write access to the repository you are working on. Thus, you will need to bring the changes you've made over from the `master` or `main` branch to a new branch on your own fork of the repository.
+ 
+5. Click the "Source Control" icon on the left sidebar. On the panel next to the side bar, you will see a list of the repositories in the workspace, and under each repository a list of the files that have changed (if any). Next to the label for `mattermost-webapp`, click the button with the branch name and the source control icon.
+
+6. A dropdown will appear via the command palette. Click the option that says: "+ Create new branch..."
+![mattermost-gitpod-new-branch](https://user-images.githubusercontent.com/43153413/194467696-498917fe-14a3-4cbc-ac35-1b201ce3c730.jpeg)
+
+7. In the box that appears, name your new branch. A good name idea is to name it after the code that refers to your issue - in this case, this is the "Test Key", so a suitable name for the branch is `MM-T642`. Then, hit `Enter` on your keyboard.
+![mattermost-gitpod-branch-name](https://user-images.githubusercontent.com/43153413/194467742-e7312d5d-dbb3-4bcc-a5af-b67941bbf4f2.jpeg)
+
+8. Now that the branch has changed, you can commit your changes to it. Back in the source control panel, you can make a commit message in the text box above the "commit button" in the section for the `mattermost-webapp` repository. Then, press the "commit button". A modal may appear asking you to first stage your changes.
+![mattermost-gitpod-commit-message](https://user-images.githubusercontent.com/43153413/194467789-0f588a7c-ff8b-4bc9-adaf-5d224726b2a5.jpeg)
+ 
+9. You can now publish your branch to the remote. However, as you will not have access to the main repository itself, you will be prompted to first create a fork. Click on the "publish branch button" on the source control panel. A popup will appear, asking if you would like to make a fork and push to that instead. On the popup, select the "create fork" button.
+![mattermost-gitpod-make-fork](https://user-images.githubusercontent.com/43153413/194468420-14564230-fb63-442c-b0e6-815aeb799da5.jpeg)
+ 
+10. During the process of fork creation, you may be prompted to grant GitHub access to Gitpod's GitHub extension (you should allow this).
+![mattermost-gitpod-sign-into-GitHub](https://user-images.githubusercontent.com/43153413/194468466-79cf2804-5393-4a1c-994f-9c087ff42b1d.jpeg)
+ 
+11. You may also be asked to update the permissions you give Gitpod to access GitHub through a popup. If this happens, you will have to restart the fork creation process (publish branch -> say yes to creating a fork). Click the "open access control" button on the popup.
+![mattermost-gitpod-need-perms](https://user-images.githubusercontent.com/43153413/194468523-f7c7ce87-3586-48bf-b779-38253de0059e.jpeg)
+ 
+12. You will get taken to the Integration section of Gitpod's settings. In the list of Git Providers on the page, find GitHub, click the three dots next to the listing, and select "Edit Permissions" from the dropdown menu.
+![mattermost-gitpod-open-perms](https://user-images.githubusercontent.com/43153413/194468548-7b31a634-dd4a-49bb-a697-a8b3e5aa39db.jpeg)
+ 
+13. A popup will appear with a list of permission checkboxes. It's a good idea to check all of them off so you don't need to go through this process again. When you're done checking off the permissions, click the "Update Permissions" button.
+![mattermost-gitpod-select-perms](https://user-images.githubusercontent.com/43153413/194468567-fba1fc58-f4db-4787-8dcd-d594472d7692.jpeg)
+ 
+14. Another tab might also appear where on GitHub's end you accept the additional permissions Gitpod is requesting. Click on the "authorize gitpod-io" button.
+![mattermost-gitpod-confirm-perms](https://user-images.githubusercontent.com/43153413/194468598-1866b681-ae3b-42a0-b94c-c02735776e02.jpeg)
+ 
+15. Once the forking process is done, there will be a couple of popups that appear on Gitpod: one asking if you'd like to periodically run `git fetch` (which will periodically download content from the remote), another one asking if you'd like to create a pull request for the branch you're on right inside Gitpod/the VSCode editor, and finally one informing that the fork was successfully created. On the successful fork creation popup, click the `open on GitHub` option.
+![mattermost-gitpod-open-fork-on-GitHub](https://user-images.githubusercontent.com/43153413/194468614-a89701c4-8b09-4b80-b84e-a0beaca8431c.jpeg)
+ 
+#### :mag: Creating a Pull Request (PR)
+ 
+16. You'll get taken to GitHub, to the fork of the repository you've worked on in your account instead of the main one in the Mattermost organization. Navigate to the branch you've made on your fork if you're not there already.
+ 
+    * Near the top of the page will be a bar mentioning how many commits ahead/behind your branch is from the `master`/`main` branch of the main repository. There will also be two buttons: "contribute" and "sync fork". Click on the "contribute" button, and in the dropdown that appears, click the "open pull request" button.
+![mattermost-gitpod-create-PR-on-GitHub](https://user-images.githubusercontent.com/43153413/194468644-8c625663-17d4-4187-92be-171b683d298f.jpeg)
+ 
+17. You'll be taken to another page on GitHub called "Open a pull request".
+![mattermost-gitpod-PR-creation-page](https://user-images.githubusercontent.com/43153413/194468667-aace5ac5-4bbe-4e93-9902-e210964e00c8.jpeg)
+
+```text
+* The first section of the page compares whether the branches (your branch on your fork - the "head repository" vs. the master/main branch on the main repository - the "base repository") can be merged automatically.
+* The second section of the page will show other PRs that are based on your same branch, if any.
+* The third section is where you create a write-up for your pull request - giving it a title, and filling out the template. At the bottom of this section is a "Create pull request" button. This button will be faded out until you make a title for the PR.
+    * If you haven't already, give Mattermost's [Contribution Checklist](https://developers.mattermost.com/contribute/more-info/getting-started/contribution-checklist/) a read. An important takeaway is that you will need to sign the [Contributor License Agreement](https://mattermost.com/mattermost-contributor-agreement/) - this will be another check on the pull request and if you haven't signed it, this will also block merging.
+    * Also check out this blog post about [Submitting Great PRs](https://developers.mattermost.com/blog/2019-01-24-submitting-great-prs), and other repository specific information [here](https://developers.mattermost.com/contribute).
+    * **Parts of a PR body**:
+        * _Title_: a good title will refer back to the issue; and it should begin with the related Jira or GitHub ticket ID (e.g. [MM-394] or [GH-394]). In the context of the E2E issue example: `MM-T642: Attachment does not collapse - Cypress Webapp E2E Test`.
+        * _Summary_: description of what the PR does, as well as QA test steps (if applicable and if not already added to the Jira ticket). For example: `Verifies that attachments on posts do not collapse after entering the slash command collapse`.
+        * _Ticket Link_: Either link the relevant Jira ticket or if you picked up an issue/ticket with a `Helped Wanted` label, link to the GitHub issue. For example: [Write Webapp E2E with Cypress: "MM-T642 Attachment does not collapse" #18184](https://github.com/mattermost/mattermost/issues/18184).
+        * _Related Pull Requests_: Link other PRs here if they are related to this PR.
+        * _Screenshots_: Illustrate what your changes have done.
+        * _Release Note_: There are certain conditions that require release notes:
+            * Config changes (additions, deletions, updates).
+            * API additions—new endpoints, new response fields, or newly accepted request parameters.
+            * Database changes (any).
+            * Schema migration changes. Use the [Schema Migration Template](https://docs.google.com/document/d/18lD7N32oyMtYjFrJKwsNv8yn6Fe5QtF-eMm8nn0O8tk/edit?usp=sharing) as a starting point to capture these details as release notes.
+            * Websocket additions or changes.
+            * Anything noteworthy to a Mattermost instance administrator (err on the side of over-communicating).
+            * New features and improvements, including behavioral changes, UI changes, and CLI changes.
+            * Bug fixes and fixes of previous known issues.
+            * Deprecation warnings, breaking changes, or compatibility notes.
+            <br/><br/>
+            If no release notes are required, write NONE. Use past-tense. For E2E tests, having `NONE` as a release note suffices. If you do not end up writing a release note at all, you'll get a warning on your PR like this: `Adding the "do-not-merge/release-note-label-needed" label [to the PR] because no release-note block was detected, please follow our release note process to remove it.` If this happens, you can just edit the body of the PR, and add it back in.
+ 
+* The last section details the code changes on your branch, including information on the commits on the branch, the files changed, and the contributors.
+```
+ 
+18. Once you've created your pull request, you'll get taken to its page, like this one: [MM-T642: Attachment does not collapse - Cypress Webapp E2E Test #11231](https://github.com/mattermost/mattermost/pull/11231). Below your initial body text of the PR will be a list of commits and other comments. At the end of this list is a checklist which notes the status of reviews required for the pull request, and the checks that the pull request must pass, plus a place to write your own additional comments.
+![mattermost-gitpod-real-PR-1](https://user-images.githubusercontent.com/43153413/194468726-afddf66f-eaf1-4dab-a6bf-7ddf39db78bf.jpeg)
+ 
+19. if you need to make any changes to your PR, you can return to Gitpod and stage and commit your changes from there onto your branch; and this will be reflected in GitHub.
+ 
+### :white_check_mark: Code Review
+ 
+Information from this section comes from: [Code review at Mattermost](https://developers.mattermost.com/contribute/more-info/getting-started/code-review/). 
+ 
+20. Wait for a reviewer to be assigned - normally this is handled automatically, but if you need help feel free to ask for help in the [Developers channel](https://community.mattermost.com/core/channels/developers) of the Mattermost community server.
+ 
+21. Wait for a review - if a reviewer requests changes, your PR will disappear from their queue of reviews. Once you've addressed the concerns, re-request a review from any person requesting changes. Avoid force pushing, which is the act of overwriting the commit history on the remote with what you have on local.
+ 
+22. Once all reviewers approve your pull request, they will handle the merging of your code.
+
+