diff options
Diffstat (limited to 'doc/process')
| -rw-r--r-- | doc/process/accepting-pull-request.md | 28 | ||||
| -rw-r--r-- | doc/process/documentation-guidelines.md | 209 | ||||
| -rw-r--r-- | doc/process/overview.md | 143 | ||||
| -rw-r--r-- | doc/process/release-process.md | 156 |
4 files changed, 0 insertions, 536 deletions
diff --git a/doc/process/accepting-pull-request.md b/doc/process/accepting-pull-request.md deleted file mode 100644 index f2bbb3f05..000000000 --- a/doc/process/accepting-pull-request.md +++ /dev/null @@ -1,28 +0,0 @@ -# Accepting Pull Requests (APRs) - -Per the [Contributor Guide](https://github.com/mattermost/platform/blob/master/CONTRIBUTING.md), only PRs that reference Jira tickets with the "accepting pull requests" label should be submitted to this repo. This system ensures: - -1. Proposed changes have been thoughtfully reviewed -2. Proposed changes can be tested, documented, and supported by volunteers -3. The change meets the [fast, obvious, forgiving](http://www.mattermost.org/design-principles/) design principle for the project. -4. The change [aligns to the stated purpose of the project](http://www.mattermost.org/vision/#mattermost-teams-v1) - -Key contributors and core team members are responsible opening Jira tickets that meet the above requirements, which are then reviewed in triage meetings. - -When opening Jira tickets for accepting-pull-requests, please: - -1. Use titles that clearly describe the needed change and its value -2. Include (Proposed APR) in title, so triage team knows to add the APR tag if appropriate -3. Provide unambiguous description so that feature can be tested by any volunteer -4. Link back to community discussions related to this change -5. Apply "accepting-pull-requests", and optionally as "good-first-contribution". -6. Post link back to community channels - -Example of post back to the community: - -``` -Thanks @[USERNAME], - -I created a ticket [for accepting pull requests on this issue](http://link). It will be reviewed in the triage meeting for addition to [the Accepting Pull Requests issues list](https://mattermost.atlassian.net/browse/PLT-797?filter=10101). [Code Contribution Guidelines](https://github.com/mattermost/platform/blob/master/CONTRIBUTING.md) are available for anyone interested in contributing to this project. -``` - diff --git a/doc/process/documentation-guidelines.md b/doc/process/documentation-guidelines.md deleted file mode 100644 index cbfeec850..000000000 --- a/doc/process/documentation-guidelines.md +++ /dev/null @@ -1,209 +0,0 @@ -# Documentation Conventions - -The most important thing about documentation is getting it done and out to the community. - -After that, we can work on upgrading the quality of documentation. The below chart summarizes the different levels of documentation and how the quality gates are applied. - -_Note: Documentation Guidelines are new, and iterating. Documentation has started to balloon and this is our attempt at reducing ambiguity and increasing consistency, but the conventions here are very open to discussion._ - -| Stars | Benchmark | Timeline | -|:-------------|:--------------------------------|:--------------------------------| -| 1 | Documentation is correct. | First draft checked in by developer. Okay to ship in first release of new feature. | -| 2 | Documentation a) follows all objective formatting criteria, b) is tested by someone other than the author, c) satisfies above. | First edit under objective rules. Required before second release cycle with this feature included. | -| 3 | Documentation a) follows all subjective style criteria, b) is reviewed and edited by someone who has previously authored 3-star documentation, and c) satisfies above. | Second edit under subjective rules. Required before third release cycle with this feature included | -| 4 | Documentation a) has received at least 1 edit due to user feedback, b) has received at least one unprompted compliment from user community on quality, c) satisfies above. | Additional edits to refine documentation based on user feedback | - -## 1-Star Requirements: Correctness - -### List precise dependencies - -1. Be explicit about what specific dependencies have been tested as part of an installation procedure. -2. Be explicit about assumptions of compatibility on systems that have not been tested. -3. Do not claim the system works on later versions of a platform if backwards compatibility is not a priority for the dependency (It's okay to say Chrome version 43 and higher, but not Python 2.6 and higher, because Python 3.0 is explicitly incompatible with previous versions). - -#### Correct - ----- -This procedure works on an Ubuntu 14.04 server with Python 2.6 installed and should work on compatible Linux-based operating systems and compatible versions of Python. - ----- -#### Incorrect - ----- -This procedure works on Linux servers running Python. - -also: - -This procedure works on Linux servers running Python 2.6 and higher. - ----- -## 2-Star Requirements: Objective Formatting Checklist - -### Use headings - -Headings in markdown provide anchors that can be used to easily reference sub-sections of long pieces of documentation. This is preferable to just numbering sections without headings. - -##### Correct: - ----- -##### Step 1: Add a heading -This makes things easier to reference via hyperlinks -##### Step 2: Link to headings -So things are easier to find - ----- -##### Incorrect: - ----- -**Step 1: Add a heading** -This makes things easier to reference via hyperlinks -**Step 2: Link to headings** -So things are easier to find ----- - -### Use appropriate heading case - -Cases in headings may vary depending on usage. - -#### When to use Title Case - -H1, H2, H3 headings should be "Title Case" and less than four words, except if a colon is used, then four words per segment separated by the colon. - -These large headings are typically shorter and help with navigating large documents - -#### When to use sentence case - -H3, H4, H5 headings should be "Sentence case" and can be any length. - -These headers are smaller and used to summarize sections. H3 can be considered either a large or small heading. - -These conventions are new, so there's flexibility around them, when you're not sure, consider the convention here as default. - -### Sub-section headings should end with a colon - -For readability and clear layout, end a sub-section heading with a colon - -##### Correct: - ----- - -Service Based: - -- [AWS Elastic Beanstalk Setup](https://github.com/mattermost/platform/blob/master/doc/install/Amazon-Elastic-Beanstalk.md) - ----- -##### Incorrect: - ----- - -Service Based - -- [AWS Elastic Beanstalk Setup](https://github.com/mattermost/platform/blob/master/doc/install/Amazon-Elastic-Beanstalk.md) - - ----- - -### One instruction per line - -It's easy to miss instructions when they're compounded. Have only one instruction per line, so documentation looks more like a checklist. - -A support person should be able to say "Did you complete step 7?" instead of "Did you complete the second part of step 7 after doing XXX?" - -##### Correct: - ----- - -6. For **Predefined configuration** look under **Generic** and select **Docker**. - 7. For **Environment type** select **Single instance** - ----- - -##### Incorrect: - ----- - -6. For **Predefined configuration** look under **Generic** and select **Docker**. For **Environment type** select **Single instance** - ----- - -### End Lists Consistently - -Full sentences in lists should end with proper punctuation. If one point in a bulleted list or numbered list ends with a period, end all points in the list with a period. If all points in the list are fragments, use no end punctuation. - -##### Correct - ----- -- This is an example of a bullet point that ends with a period. - ----- -##### Incorrect - ----- -- Example of an incorrect period at the end of a bullet point. - ----- -### Avoid Passive Phrases - -Examples of passive phrases include "have", "had", "was", "can be", "has been" and documentation is shorter and clearer without them. - -##### Correct - ----- -This software **runs** on any server that supports Python. - ----- -##### Incorrect - ----- -This software **can be run** on any server that supports Python. - ----- -## 3-Star Requirements: Subjective Style Guidelines - -### Be Concise - -Try to use fewer words when possible. - -##### Correct: - ----- -This integration posts [issue](http://doc.gitlab.com/ee/web_hooks/web_hooks.html#issues-events), [comment](http://doc.gitlab.com/ee/web_hooks/web_hooks.html#comment-events) and [merge request](http://doc.gitlab.com/ee/web_hooks/web_hooks.html#merge-request-events) events from a GitLab repository into specific Mattermost channels by formatting output from [GitLab's outgoing webhooks](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md) to [Mattermost's incoming webhooks](https://github.com/mattermost/platform/blob/master/doc/integrations/webhooks/Incoming-Webhooks.md). - ----- -##### Incorrect: - ----- -This integration makes use of GitLab's outgoing webhooks and Mattermost's incoming webhooks to post GitLab events into Mattermost. You can find GitLab's outgoing webhooks described [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md) and Mattermost's incoming webhooks described [here](https://github.com/mattermost/platform/blob/master/doc/integrations/webhooks/Incoming-Webhooks.md). - ----- - -### Use appropriate emphasis - -Mention Clickable Controls in **Bold**, Sections and Setting Names in *Italics*, and Key Strokes in `pre-formatted text`. - -To make it clear and consistent across documentation on how we describe controls that a user is asked to manipulate, we have a number of guidelines: - -**Bold** -- Please **bold** the names of controls you're asking users to click. The text that is bolded should match the label of the control in the user interface. Do not format these references with _italics_, ALL-CAPS or `pre-formatted text`. -- Use `>` to express a series of clicks, for example clicking on **Button One** > **Button Two** > **Button Three**. -- If a button might be difficult to find, give a hint about its location _before_ mentioning the name of the control (this helps people find the hint before they start searching, if the see the name of the button first, they might not continue reading to find the hint before starting to look). - -***Italics*** -- Please *italicize* setting names or section headings that identify that the user is looking in the correct area. The text that is italicized should match the name of the setting or section in the user interface. -- It is helpful to use italics to guide the user to the correct area before mentioning a clickable action in bold. - -**`pre-formatted text`** -- Please use `pre-formatted text` to identify when a user must enter key strokes or paste text into an input box. - -#### Correct - ----- -Type `mattermost-integration-giphy` in the *repo-name* field, then click **Search** and then the **Connect** button once Heroku finds your repository - ----- -#### Incorrect - ----- -Type "mattermost-integration-giphy" in the **repo-name** field, then click Search and then the *Connect* button once Heroku finds your repository - ----- diff --git a/doc/process/overview.md b/doc/process/overview.md deleted file mode 100644 index 8a4c0459d..000000000 --- a/doc/process/overview.md +++ /dev/null @@ -1,143 +0,0 @@ -# Development Process Overview - -This document describes the process through which feedback and design discussions flow into community systems, then into tickets, then into pull requests, then into monthly releases based on the purpose of the product. - -## Purpose - -The core offer for users of Mattermost is: - -- **All your team communication in one place, searchable and accessible anywhere.** - -The design is successful if 100% of team members use Mattermost for internal communications, and are largely off of email and propreitary SaaS products that lock-in user data as part of their business model. - -See [Mattermost scope statement](http://www.mattermost.org/vision/#mattermost-teams-v1) for more details. - -## Community Systems - -The process for managing bugs, feature ideas, troubleshooting, and general discussions are different, so different systems are used to best support each process. Each system ties into Mattermost through notifications to internal channels, so the core team and key contributors can keep up-to-date with community feedback across all systems throughout the day. - -Systems include: - -### Feature Idea Forum - -A forum for filing, upvoting and discussing feature ideas. Reviewed monthly by the core team as part of the planning process for new releases. - -See [Contributing Feature Ideas](http://www.mattermost.org/feature-requests/) for more details on how to use this system. - -_Note: If you want to promote an idea filed in the feature idea forum, or if you are out of votes and want to find like-minded colleagues to vote for you, consider posting to the [Feature Idea Discussion ](https://forum.mattermost.org/t/how-to-use-feature-idea-discussion/63/1) category in the General Forum._ - - -### Troubleshooting Forum - -A system for peer-to-peer support of installation and configuration questions. - -See [Troubleshooting Forum](https://forum.mattermost.org/t/about-the-trouble-shooting-category/150/1). - - -### GitHub Issues - -A system primarily used by Mattermost for reporting bugs with clear statements on repro steps and expected behavior. While it's okay to add feature requests and questions here to start conversations, moderators may ask a submitter's help to move discussions to one of the other channels. - -See [Filing Issues](http://www.mattermost.org/filing-issues/) for details on how to file issues for Mattermost in GitHub. - -Please consider using more mainstream processes for [filing feature ideas to be upvoted](https://github.com/mattermost/platform/blob/master/doc/process/overview.md#feature-idea-forum), to ask [troubleshooting questions](https://github.com/mattermost/platform/blob/master/doc/process/overview.md#troubleshooting-forum), or [general questions](https://github.com/mattermost/platform/blob/master/doc/process/overview.md#general-forum). - -### GitHub Pull Requests - -A system for submitting pull requests for changes to Mattermost. See [Pull Requests](https://github.com/mattermost/platform/blob/master/doc/process/overview.md#merge-requests) section below. - -### General Forum - -A general, peer-to-peer discussion forum with topics organized by category for general questions, trouble shooting, design feedback requests, and FAQs. Monitored and moderated by core team, which is also active on the forum. - -Read more about the [General Forum](https://forum.mattermost.org/t/welcome-to-mattermost-community-discussion/8). - -### Primary Research - -Core team members and key contributors may discuss Mattermost directly with users in a range of systems outside those listed here--in-person meetings, video-conference, usability testing, Twitter, email, etc. Those notes are shared in various Mattermost channels to inform designs. - -## Tickets - -Mattermost priorities are managed in Jira tickets, which are created by the core team via feedback from community systems as well as through the planning processes. - -### Triage - -On non-holiday weekdays new tickets are reviewed in a process called "triage", and assigned a Fix Version of "backlog", indicating the ticket has enough specificity that it can be assigned to a developer to be completed. - -By default, all tickets are created as public unless they contain sensitive information. The triage process reviews them for sufficient specifity. If the ticket is unclear, triage may reassign the ticket back to the original reporter to add more details. - -View [current issues scheduled for the next triage meeting](https://mattermost.atlassian.net/browse/PLT-1203?filter=10105). - -#### Re-triage - -If someone feels an existing ticket should be reexamined, they can add "triage" to the Fix Version and it will be routed to the triage team for review at the next meeting. - -### Release Planning - -Release planning sets the "Fix Version" of tickets to one of the upcoming monthly releases. The Fix Version is an estimate of when a feature might ship, which may change as the planning process continues, until the ticket is scheduled for a Sprint. - -### Sprint Planning - -Tickets to be completed in the upcoming two weeks are organized on Tuesdays, with input from developers, and finalized on Fridays. - -## Pull Requests - -### Core Team Weekly Rhythm - -Core team work on tickets in the active sprint on a weekly basis, which flow into GitHub Pull Requests. - -Each Pull Request needs a minimum of two reviews by other core team developers before it is merged, with possible feedback shared as reviews happen. - -Key contributors might also pick up tickets, or through conversations with the core team contribute pull requests as needed. - -### Community Contributions - -Community members following the [Contribution Guidelines](https://github.com/mattermost/platform/blob/master/CONTRIBUTING.md) might also submit pull requests. Pull requests should not disable existing functionality without a Jira ticket, which are opened [via the feature ideas process](http://www.mattermost.org/feature-requests/). - -#### Bug Fixes - -If you see an obvious bug and want to submit a fix, pull requests following the [contribution guidelines](https://github.com/mattermost/platform/blob/master/CONTRIBUTING.md) are gladly accepted. - -Examples: -- [Fix: Unable to change password #1390](https://github.com/mattermost/platform/pull/1390) -- [Fix isBrowserEdge typo #1260](https://github.com/mattermost/platform/pull/1260) - -#### Tickets Accepting Pull Requests - -If you'd like to improve the product beyond bug fixes, you can select from a list of tickets accepting pull requests prepared by the core team. - -Tickets labelled "accepting pull requests" are intended to be unambiguous projects that could be reasonably completed by contributors outside the core team and are welcome contributions. - -Tickets may have a "mana" value assigned, which is an estimate of the relative complexity of each ticket (2 is "small", "4" is medium, "8" is large). - -Even if the ticket is assigned to someone else, so long as the ticket has Status set to Open and the ticket is not in the [Active Sprint](https://mattermost.atlassian.net/browse/PLT-839?jql=status%20%3D%20Open%20AND%20sprint%20in%20openSprints%20()) contributors following the contribution guidelines are welcome to submit pull requests. - -For a list of tickets that meet this criteria, please the list of [Tickets Accepting Pull Requests](https://mattermost.atlassian.net/browse/PLT-1263?filter=10101). - -#### Documentation Improvements - -Improvements to documentation on master is highly welcome. - -Please see [documentation contribution guidelines](https://forum.mattermost.org/t/help-improve-mattermost-documentation/194) for more details. - -Examples: -- [Production installation instructions for Debian Jessie with Systemd #1134](https://github.com/mattermost/platform/pull/1134) -- [Fix deadlink to AWS file in doc #622]( https://github.com/mattermost/platform/pull/622) - -#### Minor Improvements - -Minor improvements without an Accepting Pull Request ticket may be accepted if: - -1. The contribution aligns with product scope -2. The change is high quality, and does not impose a significant burden for others to test, document and maintain your change. -3. The change aligns with the [fast, obvious, forgiving](http://www.mattermost.org/design-principles/) design principle. - -Examples: -- [Do not clear LastActivityAt for GetProfiles #1396](https://github.com/mattermost/platform/pull/1396/files) -- [Update to proxy_pass #1331](https://github.com/mattermost/platform/pull/1331) - -## Release - -Mattermost ships stable releases on the 16th of the month. Releases begin with a planning process reviewing internal designs and community feedback in the context of the product purpose. Feature development is done in weekly sprints, and releases end with feature complete, stablization, code complete and release candidate milestones prior to final release. - -See [release process documentation](https://github.com/mattermost/platform/blob/master/doc/process/release-process.md) for more details. diff --git a/doc/process/release-process.md b/doc/process/release-process.md deleted file mode 100644 index 6e1cf6a77..000000000 --- a/doc/process/release-process.md +++ /dev/null @@ -1,156 +0,0 @@ -# Mattermost Release Process - -Mattermost core team works on a monthly release process, with a new version shipping on the 16th of each month. - -This document outlines the development process for the Mattermost core team, which draws from what we find works best for us from Agile, Scrum and Software Development Lifecycle approaches. - -Notes: -- All cut-off dates are based on 10am PST (UTC-07/08) on the day stated. -- T-minus counts are measured in "working days" (weekdays other than major holidays concurrent in US and Canada) prior to release day. - -### (Code complete date of previous release) Beginning of release - -Pre-work for the current release begins at the code complete date of the previous release. See "Code Complete" section below for details. - -### (T-minus 10 working days) Cut-off for major features - -No pull requests for major features should be submitted to the current release after this date (except if release manager decides to add "release-exception" label to Jira ticket). - -1. Logistics: - 1. Post this checklist in Release channel -2. PM: - 1. Write compatibility updates for config.json and database changes [See example](https://github.com/mattermost/platform/blob/master/CHANGELOG.md#compatibility) - - Confirm changes to config.json in compatibility section of Changelog are written back to [settings documentation](https://github.com/mattermost/platform/blob/master/doc/install/Configuration-Settings.md) - - Update [Upgrade Guide](https://github.com/mattermost/platform/blob/master/doc/install/Upgrade-Guide.md) for any steps needed to upgrade to new version - - Prepare tickets for [cutting RC builds](https://mattermost.atlassian.net/browse/PLT-985), [creating the final release candidate](https://mattermost.atlassian.net/browse/PLT-986), [creating AMIs](https://mattermost.atlassian.net/browse/PLT-1213), and [testing GitLab RC with Mattermost](https://mattermost.atlassian.net/browse/PLT-1013) -3. Dev: - 1. Prioritize reviewing, updating, and merging of pull requests for current release until there are no more tickets in the [pull request queue](https://github.com/mattermost/platform/pulls) marked for the current release -4. Leads: Meet to prioritize the final tickets of the release
- 1. Backlog is reviewed and major features that won’t make it are moved to next release - - Triage tickets - - Finalize roadmap for next release - - Draft roadmap for release after next (used to prioritize design tasks) -5. Marketing: - 1. Drafts marketing bullet points for next release based off of roadmap - - Submits pull request for "Highlights" section of the Changelog - - Notes date of announcements in release channel -6. Team: - 1. In Stand-up, each team member discusses worst bug (10-15s) - -### (T-minus 8 working days) Feature Complete and Stabilization - -**Stablization** period begins when all features for release have been committed. During this period, only **bugs** can be committed to master. Non-bug pull requests are tagged for next version, and are not committed to master until after a release candidate is cut. - -Exceptions can be made by the release manager setting priority to "Highest" and adding a "release-exception" label to the Jira ticket. This will add the ticket to the [hotfix list for release candidate](https://mattermost.atlassian.net/issues/?filter=10204). - -1. Logistics: - 1. Post this checklist in Release channel - - Update the channel header to reflect date - - Mail out mugs to any new contributors -- Dev: - 1. Prioritize reviewing, updating, and merging of pull requests for current release until there are no more tickets in the [pull request queue](https://github.com/mattermost/platform/pulls) marked for the current release -- PM: - 1. Review all [Severity 1 bugs (data loss or security)](https://mattermost.atlassian.net/secure/IssueNavigator.jspa?mode=hide&requestId=10600) to consider for adding to Hotfix list - - Update documentation: - 1. Make Changelog PR with updates for latest feature additions, known issues, and contributors - - Make NOTICE.txt PR for any new libraries added from dev, if not added already - - Prioritize any developer documentation tickets - - Draft [GitLab ticket](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/942) to take next Mattermost version in the Omnibus, but do not post until RC1 is cut - - Coordinate testing: - 1. Work with Ops to check the [Quality Gate](https://github.com/mattermost/process/blob/master/release/quality-gates.md) for feature complete - - Receive testing sign-off from feature area owners (i.e. PM/Dev either signs-off that their area is well tested, or flags potential quality issues that may exist) - - Check that Release Candidate Testing Spreadsheet is up to date -- **(Team) Feature Complete Meeting (10:15am PST)**: - 1. (PM) Leads review of Changelog - - (Team) Each team member discusses worst bug (10-15s) - - (PM) Review feature list for next release - - (Marketing) Share draft of marketing bullet points for next release -- Marketing: - 1. Communicate checklist of items needed by specific dates to write the blog post announce (e.g. screenshots, GIFs, documentation) and begins to write the blog post, tweet, and email for the release announcement - -### (T-minus 5 working days) Code Complete and Release Candidate Cut - -1. Logistics: - 1. Post this checklist in Release channel - - For the next release, create team meetings on Feature Complete and Code Complete dates -- PM: - 1. Remove "Under Development" notice for current release from Changelog on master - - Assign each area of the release testing spreadsheet to a team member -- **(Team) Code Complete Meeting (10:15am PST meeting)** - 1. (Logistics) Walk through each item of this checklist - - (Dev) Last check of tickets that need to be merged before RC1 - - (Team) Each team member discusses worst bug (10-15s) -- **Code Complete** is declared after meeting -- Dev: - 1. Prioritize reviewing, updating, and merging of pull requests for current release until there are no more tickets in the [pull request queue](https://github.com/mattermost/platform/pulls) marked for the current release -- Build: - 1. Master is tagged and branched and “Release Candidate 1″ is cut (e.g. 1.1.0-RC1) according to the [Release Candidate Checklist](https://github.com/mattermost/process/blob/master/release/create-release-candidate.md) -- PM: - 1. Create meta issue for regressions in GitHub (see [example](https://github.com/mattermost/platform/issues/574)) - - Include link to meta-issue in release notes of RC1 - - Submit GitLab ticket to take next Mattermost version in the Omnibus -- Marketing: - 1. Tweet announcement that RC1 is ready (see [example](https://twitter.com/mattermosthq/status/664172166368264192)) - -### (T-minus 4 working days) Release Candidate Testing - -1. Logistics: - 1. Post this checklist in Release channel - - Queue an agenda item for next team meeting for Release Process Kaizen/Q&A -- Build: - 1. Test upgrade from previous version to current version, following the [Upgrade Guide](https://github.com/mattermost/platform/blob/master/doc/install/Upgrade-Guide.md) - - Database upgrade should be tested on both MySQL and Postgres -- Team: - 1. Test assigned areas of the Release Candidate Testing Spreadsheet and file any bugs found in Jira - - Post a link to any "Blocking" issue that may need a hotfix to the RC in the Release room, with the **#p1** tag. If the issue is security related or contains confidential information, post the link in the Confidential Bugs private group. Blocking issues are considered to be security issues, data loss issues, issues that break core functionality, or significantly impact aesthetics. - - Triage hotfix candidates and decide on whether and when to cut next RC or final - - If no blocking issues are found, PM, Dev and Ops signs off on the release -- PM: - 1. Post links to all issues found in RC as comments on the meta issue - - Update the meta issue description to include approved fixes - - Post screenshot and link to final tickets for next RC to the Release room - - Update Changelog “Known Issues” section with any significant issues that were found and not fixed for the final release -- Dev: - 1. PRs for hotfixes made to release branch, and changes from release branch are merged into master -- Logistics: - 1. For potentially destabilizing changes, test approved fixes on a spinmint private build -- Build: - 1. Push next RC to acceptance after testing is complete and approved fixes merged, announces in Town Square on pre-release.mattermost.com/core -- PM: - 1. Closes the meta issue after the next RC is cut, and opens another ticket for new RC -- Ops: - 1. Verifies each of the issues in meta ticket is fixed - -### (T-minus 2 working days) Release Build Cut - -The final release is cut. If an urgent and important issue needs to be addressed between major releases, a bug fix release (e.g. 1.1.1) may be created - -1. Logistics: - 1. Post this checklist in Release channel -- Build: - 1. Tags a new release (e.g. 1.1.0) and runs an official build which should be essentially identical to the last RC - - Delete RCs after final version is shipped -- PM: - 1. Copy and paste the Release Notes from the Changelog to the Release Description - - Update the mattermost.org/download page - - Update the AMI links on mattermost.org/download and mattermost.org/installation - - Close final GitHub RC meta ticket -- Marketing: - 1. Finalize mailchimp email blast - - Finalize blog post and put on timer for release - - Finalize tweet announcement - - Finalize announcement on general mailing list - - Finalize announcement for gitlab.mattermost.com - -### (T-minus 0 working days) Release Day - -1. Logistics: - 1. Post this checklist in Release channel - - Post key dates for the next release in the header of the Release channel -- PM: - 1. Close the release in Jira - - Set header of next release as UNDER DEVELOPMENT in CHANGELOG on master -- Dev: - 1. Check if any libraries need to be updated for the next release, and if so bring up in weekly team meeting -- Marketing: - 1. Confirm marketing has been posted (animated GIFs, screenshots, mail announcement, tweets, blog posts) |