# About Mattermost (90%) Mattermost, Inc. is a company based on the Mattermost open source project. Mattermost software is used by thousands of organizations around the world in 16 languages. ## Mission Our mission is to make the world more safe and productive by developing and delivering secure, open source collaboration software that is trusted, flexible and offers fast time-to-value. ## Leadership Principles Leadership principles are deliberate choices defining our behavior. When facing complexity, uncertainty, or ambiguity (CUA) we determine our point of view and our actions through the lens of our values: * **Customer Obsession:** We exist to make customers successful. In everything we do, start with customer perspective and work backwards. Earn and keep their trust. * **Ownership:** Own the outcomes of your activity. Don’t drop the ball. When we see a vacuum on something important, we jump in – we never say “it’s not my job.” * **High Impact:** Align work to our shared vision and focus on those priorities. When deciding to work on low impact or high impact projects, choose high impact. * **Self-Awareness:** We understand and seek to understand our strengths and growth opportunities, as individuals and organizations. We are open to critique and share critique constructively and respectfully. * **Earn Trust:** Make decisions based on maximizing the trust of others in your judgement. Be open, self-critical, and factual. Earn and keep people’s trust. ## Products and Business Model Mattermost, Inc is a commercial open source company with a subscription-based, buyer-based open core licensing model. ### Mattermost Team Edition Audience: * Development team that wants to self-host workplace messaging in private network. Our core product is Mattermost Team Edition offered under an open source MIT license. It’s built for a team of 10 to 50 developers and IT professionals who need to self-host a workplace messaging platform. Developer-focused features including web, desktop, and mobile apps as well as core integrations with DevOps platforms, archiving, search, and extensibility framework are offered in the open soure core at no cost. Mattermost Team Edition is packaged as a single Linux binary that’s straightforward to install and maintain, with automated deployment from public cloud marketplaces including AWS, Azure, VMWare, and GCP. ### Mattermost Enterprise Edition Audience: * IT organization needing to self-host workplace messaging in private network for multiple development teams, or other end users in high trust environments. Mattermost Enterprise Edition is an extended version of Mattermost Team Edition offered under a proprietary license priced with a user-based annual subscription. It offers features designed for IT organizations to manage multiple teams of developers and other end users in high trust environments with Single Sign-on, Active Directory/LDAP integration, eDiscovery support, and High Availability deployment configurations. Different packages of commercial features are offered based on buyer needs. For more information, see our [Product Overview](https://docs.mattermost.com/overview/product.html) and open source repository at . ## Company Mattermost is an open source, remote-first, communities-centered company based in Palo Alto, California and headquartered on the internet. **Open source** means that by default we make our technology, business process and source code available to the public. We develop a small portion as proprietary technology, built upon our open source work, to license for subscription fees that enable more high quality open source work to be produced. Since the start of the Mattermost open source project in 2015, we have used this model to develop effective open source solutions for the world to use. This model is sometimes called [Thin Open Core](https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c). **Remote-first** means that the majority of our staff works from home, cottages, coffee shops, and other personal areas rather than at a shared corporate office location. Mattermost was born in an extraordinary age where remote-first organizations can attract, hire and enable remote teams to produce better technology, business process and business results in less time than office-based teams, while maintaining security and compliance standards. Remote-first culture flourishes when we share one simple principle: **Courtesy**. Courtesy means Mattermosters are thoughtful about keeping our communities appropriately informed, following etiquette for discussions, calls and video meetings, and giving and receiving feedback on how to work better together. Courtesy also means we gladly accommodate those who prefer to work out of a dedicated office. We are remote-first, not remote-only. **Communities-centered** means we define our success in the context of the success of our [communities](https://docs.mattermost.com/process/community-overview.html): users, customers, implementers, resellers, technology partners, contributors, and colleagues. The success of each community is owned by a member of the Mattermost leadership team. The plural definition of “communities” is intended to avoid unconsciously marginalizing downstream stakeholders. **Based in Palo Alto, California and headquartered on the internet** means the mailing address for Mattermost, Inc. is in Palo Alto, California, and our headquarters is on the internet, specifically the production-quality Mattermost instance at [https://community.mattermost.com](https://community.mattermost.com/). Our online headquarters is where Mattermost staff work with our communities of colleagues, users, partners, customers, candidates, contributors, and other [community members](https://docs.mattermost.com/process/community-overview.html) to envision, develop, and refine new open source technologies to make the world safer and more productive. ## Mindsets NOTE: This section is currently being imported from: Mindsets are “tool sets for the mind” that help us find blindspots and increase performance in specific situations. They’re a reflection of our shared learnings and culture in the Mattermost community and at Mattermost Inc. To make the most out of mindsets, remember: * **Mindsets are tools:** Use common sense to find the right mindset for your situation. Avoid using ones that don’t fit. * **Mindsets are temporary:** Try on a mindset the way you’d try a tool. You can always put it down if it doesn’t work. * **Mindsets are not laws:** Mindsets are situation-specific, not universal. Don’t use them to debate. When you read about great leaders, they share mindsets relevant to success in their specific situations, which differ from their peers. Remember that “advice is personal experience generalized” so be mindful about what you apply. In this context, here are mindsets for Mattermost: ### Learn, Master, Teach **Learn** a new topic quickly, develop **mastery** (be the smartest person at the team/company/community on the topic), then **teach** it to someone who will start the cycle over. If you’re a strong teacher, their mastery should surpass yours. This mindset helps us constantly grow and rotate into new roles, while preventing “single-points of failure” where only one person is qualified for a certain task. ### Slow is smooth, smooth is fast When you rush to get something done quickly, it can actually increase the time and cost for the project. Rushing means a higher chance of missing things that need to be done, and the cost of doing them later is significantly higher because you have to re-create your original setup to add on the work. ### Emotion, Assumption, and Priority Consider when two rational people disagree, the cause often comes from one of three areas: 1. **Emotion:** There could be an **emotion** biasing the discussion. Just asking if this might be the case can clear the issue. It’s okay to have emotions. We are humans, not robots. 2. **Assumption:** People may have different underlying **assumptions** (including definitions). Try to understand each other’s assumptions and get to agreement or facts when you can. 3. **Priorities:** Finally, people can have different **priorities**. When everyone’s priorities are shared and understood it’s easier to find solutions that satisfy everyone’s criteria. While the emotions, assumptions, priority mindset won’t work for everyone in every case, it’s helped resolve complex decisions in our company’s history. ### Likes and Wishes An easy way to check in with team members about how things are going. * What do you *like* about how things are going? * What do you *wish* we might change? Use these one-on-one or in a group as a way to open conversations about what to keep and what to change in how we do things. ### Drafts at 1%, 50%, 99% Being clear on expectations when asking for someone’s review can help speed and smooth the process. In this mindset, there are three types of review: * 1% Draft - Completely open to ideas and changes in direction. Rework is inexpensive. * 50% Draft - Half complete work. There is structure, but also a lot of room for change. Some rework is inexpensive, some is expensive. * 99% Draft - Nearly completed work. Rework at this point is very expensive. ### Shoulder Check When a new owner takes over a process or a project from a previous owner, there are a finite number of “blindspots” of which the original owner is aware and the new owner will need to understand. Using the analogy of changing lanes while driving a vehicle and learning to do a “shoulder check” for information that is not visible from standard controls, we have a process for the new owner and previous owner to jointly review processes until the transfer is complete. This process is similar to [Mini-boss, End-boss](https://docs.mattermost.com/process/training.html#mini-boss-end-boss), except that the mini-boss is also the new owner of a process, and not only a reviewer. Shoulder checks should be requested by new owners to avoid “crashing”: > * Making changes to systems that break existing processes and may lose data and hurt the productivity of others downstream without notice and without a replacement system in place (behavior known as [“Dead Tarzan”](https://docs.mattermost.com/process/training.html#dead-tarzan)). > * Repeatedly investing in mis-prioritized projects due to a misunderstanding of requirements from project stakeholders and insufficient confirmation of intended outcomes. Even when not crashing, as part of our [Self Awareness value](https://docs.mattermost.com/process/handbook.html#values), top team members will constantly be seeking feedback and review from people around the company. ### Brown M\&Ms A “brown M\&M” is a mistake that could either signal dangerous oversights in the execution of a project, or be a completely innocuous and unimportant error. When a brown M\&M is found, aim to rule out a dangerous error as quickly as possible. Do fast drilldowns and systematic checks to see if more brown M\&Ms are found, and if so, an entire project may need to be reviewed. Examples of brown M\&Ms may include: 1. Significant mistakes in process, consistency, or documentation suggesting lack of review or lack of understanding of the pre-existing system. 2. Ambiguous definitions that would make completion of a procedure difficult or unpredictable. The name brown M\&M comes from a safety technique used by the American music band Van Halen, who had to set up large, complex concert stages in third tier cities, where few local workers had experience with the safety standards vital to construction. In the [contract rider](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders) with each venue, Van Halen required a bowl of M\&M candies with all brown M\&Ms removed. Failure to provide the bowl was grounds for Van Halen’s stage crew to inspect all of the local vendor’s work for safety issues, because it meant the vendor had not paid attention to detail, and safety could be at risk. ### Correct Minimums: Medic, Field Surgeon, Plastic Surgeon When making project investment decisions, we optimize for high impact in the context of customer obsession, empowered by ownership, while being constrained by “be proud of what you build”. The failure case is over-investing in processes and infrastructure, stealing mana from higher priority work, reducing speed and agility for the company and unnecessarily increasing cost and bureacracy. The objective of optimization is to invest at minimal levels for efficiency and safety while maximizing impact. In making these trade-offs, consider the following mindsets: * **Correct Minimum 1: Medic** > Safely fix something that is important, broken and dangerous as fast as possible. Speed is critical - do not worry about “leaving a scar” in our architecture or business process, just own it and get it done. Solve the problem, **do not overbuild**. > > *Example:* Something incorrect on our public website with more than 100 page views a month should be fixed immediately and not delayed to be done with a longer term project, such as a website re-design. If the staging server cannot be pushed, this means manually fixing production and duplicating that change on staging, rather than trying to fix staging. * **Correct Minimum 2: Field Surgeon** > Triage tasks that are important and broken but not dangerous, and fix the most important things with a minimum time and cost. Scarring should be a low-priority consideration–it is fine to leave scars and it is fine to spend a little energy to avoid big ones. Solve the problem for the next stage of growth, but don’t solve it in two to three stages ahead. > > *Example:* In Mattermost, spend 2 mana to enable automated messages over 4000 characters to be broken into multiple posts instead of being rejected, which is a problem every developer hits when they attempt to output log information via curl commands. * **Correct Minimum 3: Plastic Surgeon** > Fix and optimize critical, high volume flows in our customer experience and product with heavy investment if needed to make high impact changes. Scars can be avoided and removed to produce a high impact result. > > *Example:* Click-tracking traffic on about.mattermost.com and optimizing flows to direct visitors to learn about the product and downloading it is a flow that should be continually optimized. ### Mini-boss, End-boss After completing the initial draft of a project, there may often be more than one reviewer to approve changes. This may be for different disciplines to review the work (for example, both development and design teams reviewing code changes to the user experience) and it may also be for reviewers with different levels of experience to share feedback. When reviewing significant user interface changes, code changes, responses to community or customers, or changes to systems or marketing material changes, it is ideal to have at least two reviewers: * **Mini-boss:** Reviewer less experienced in domain or Mattermost standards for the first review. * **End-boss:** Reviewer more experienced in domain or Mattermost standards for the final review for the discipline (e.g. development, design, documentation, etc.). This system has several benefits: 1. The Mini-boss provides feedback on the most obvious issues, allowing the End-boss to focus on nuanced issues the Mini-boss didn’t find. 2. The Mini-boss learns from the End-boss feedback, understanding what was missed, and becoming a better reviewer. 3. Eventually the Mini-boss will be as skilled at reviewing as the End-boss, who will have nothing futher to add after the Mini-boss review. At this point, the Mini-boss becomes an End-boss, ready to train a new Mini-boss. The naming of this term comes from video games, where a person submitting material for review must pass a “mini-boss” challenge before a “end-boss” challenge for different disciplines. # How to VPMOM (90%) VPMOM is an exercise in awareness. When correctly implemented it results in total alignment across organizations while executing at high speed. VPMOM (pronounced “Vee Pea Mom”) is an acronym for vision, priorities, methods, obstacles, and measures and is expressed as a one-page document communicating these five areas of a strategy. VPMOMs are the API resourcing and ROI measures at our company. #### Structure Writing good VPMOMs is a critical skill for leadership in thinking through what they are asking of their organizations and concisely laying out how the organization should operate, make choices and measure progress. When you write a VPMOM, imagine that you’re posting it to both your organization and the company as a whole, and can have no further communication for the quarter. Your organization and its service providers within the company and outside the company, need to use your VPMOM to plan, prioritize, execute and make trade-offs during the quarter, and present to you at the end of the quarter what they have achieved based on what you have asked. Assume your team is high performance and will aspire to 150% of what’s been required, but due to circumstances beyond their control they have achieved only 70% of what their own aspirations. Your VPMOM should ensure the right priorities were delivered, which feed into the VPMOMs across the company that depend on your success. **Vision** * One sentence definition of what we want to do This is a summary sentence to concisely communicate priorities. **Priorities** * List of the most important parts of the vision in priority order When an organization needs to make trade-offs, the VPMOM tells it to cut the lower priorities in order to achieve the higher priorities. **Methods** * List of what’s needed from everyone to get the job done **Obstacles** * List of key challenges to be overcome to achieve our vision **Measures** * List of desired results, often numerical #### VPMOM Example Vision * Operate efficiently with Standard Operating Procedures (SOPs) that are aligned, documented, easy-to-use and deliver value quickly Priorities * Alignment - SOPs should clearly align to vetted VPMOMs * Documentation - All SOPs found online through web search * Ease-of-use - Experience of using SOPs is fast, obvious and forgiving * Agreement - RAPID feedback and agreement achieved * Fast time-to-value - We move faster with SOPs, not slower Methods * Education on how to draft, RAPID review and publish SOPs * Table of Contents - Public list and link all SOPs at Operations section of handbook.mattermost.com * RAPID review - Update SOPs with RAPID stakeholder review * Onboard and train - Include onboarding, training for new and updated SOPs * SOP iteration - Measure, monitor and manage SOPs Obstacles * Too many procedures stored in email, channels and tribal knowledge * Too many undocumented, unclear procedures * Duplicate, conflicted procedure documented * People not knowing about and/or following SOPs Measures * All SOPs are clearly tied to a VPMOM * 90% of non-confidential SOPs can be found via a web search * <5% error rate by SOP * 80% of SOPs document RAPID sign-off within last 12 months * NPS of 20+ on SOPs from users due to ease-of-use and speed **Commentary** In this VPMOM “Alignment” is the top priority. We note in the obstacles that the organization suffers from duplicate and conflicting SOPs today. If there was only one thing achieved in this VPMOM during the quarter it would be aligning SOPs with VPMOMs. This is measured by “All SOPs are clearly tied to a VPMOM” The next priority is “Documentation” with a measure of “90% of non-confidential SOPs can be found via a web search” to surface SOPs to further ensure alignment and removing conflict. We note here that Documentation and Alignment are interlinked, and that there are multiple ways we could have priorized the two. For example, if we have gaps in VPMOMs then Alignment this period might not be feasible and we could prioritize Documentation, and we may end up documenting duplicate and conflicting SOPs, but in doing so resolve them. When you write a VPMOM you need to decide how to prioritize the elements of your vision so that our organizations know how to make decisions. It’s okay to get things wrong once in a while so long as we are right most of the time, and we can course correct when we make a mistake. #### VPMOM Template The following template is used to lock annual VPMOMs in one page. Anything that doesn’t fit on one page should be added to the “Commentary” section at the end of the one page VPMOM. ``` # [TITLE] VPMOM Plan ([INITIALS OF DRI]) Vision - [Define what you want to do in one sentence] Priorities - [What are the relative priorities of the elements of your vision?] Methods - [What are the steps and actions everyone needs to take?] - [Include hiring and on-boarding if you plan to increase headcount] Obstacles - [What are the key challenges to be overcome to meet vision? (typically outside your control)] Measures - [What are the actual results we want to deliver? (typically numbers)] [Commentary on anything RAPID should know that doesn't fit within the one-page V2MOM structure.] ``` #### History VPMOMs are a fork of [V2MOMs created in 1999 by Marc Benioff](https://www.salesforce.com/blog/2013/04/how-to-create-alignment-within-your-company.html) to align the efforts at Salesforce.com. One key difference is we use the term “Priorities” to describe the stack ranked priorities of the “Vision”, instead of the word “Values” which gets too often confused with a company’s “Core Values”. Also, people would get confused thinking a specific method or measure was the priority for the vision, and it became necessary to be explicit on the priority for the vision. For example, a VPMOM for R\&D may have the bulk of methods and measures on product delivery, and the Vision statement may have many elements, but when “High Quality” is clearly listed as the top priority it is unambiguous what our focus needs to be. Also, VPMOMs are defined by Mattermost and therefore can be optimized for our business and cadence. Whereas, VP2MOMs have been used for over 20 years at different organizations, in different ways, in different eras, in different departments and when we tried using V2MOMs in the past they created too much inconsistency and confusion, despite good intentions. # Company Operations (10%) How Mattermost, Inc. operates as a company ## Company #### Company Key Info * [About Mattermost](/0.2.0): Mission, vision, company overview, history * [How to VPMOM](/0.2.0/how-to-vpmom): How we use VPMOMs to create organizational alignment at high speed * [MLT Cadence](/0.2.0/operations/operations-30/mlt-cadence-80): Cadence of Mattermost Leadership Team to develop company strategy, plan, review and adapt. #### FY20 MLT VPMOM The following section lists out the public portions of VPMOMs for Fiscal Year 2020 (“FY20”), which ends January 31, 2020: Vision * Be #1 high trust open core DevOps-first collaboration platform Priorities * Best people for function and culture - High performance, remote first * Openly document DevOps, product, and workplace * Time to value - Deliver value to customers and colleagues quickly * User experience - Easy-to-use, easy-to-work with * High output process - Scalable, reliable, vacation-ready processes that are efficient Methods * Hire & onboard open source, remote-first, communities-centered team * Deliver high quality, DevOp-first collaboration and app platform * Design and scale effective customer onboarding * Deliver pipe by scaling online discovery, education, and trial experience * Build the machine to scale open core sales, direct and indirect * Operate efficiently \~\~and fund growth\~\~ Obstacles * Under-resourced on support, on-boarding and best practices * Lack of infrastructure * Missing tools, automated metrics and reporting * Lack of recommended solutions for core DevOps integrations * Lack of core DevOps thought leadership across the company * Lack of clearly and publicly defined metrics * Lack of unified theory of the business Measures * Top Tier sales ARR growth, net expansion and retention metrics * Choice destination for open source, remote-first, communities-centered candidates * Co-marketing with 2+ leading DevOps platforms, 2+ customer references each * Consistently achieve product NPS target * Growth in free downloads and reported trial activations * Growth in contributor community ### ### ### ### ### ### # MLT Cadence (80%) Mattermost Leadership Team (MLT) consists of Mattermost department heads plus the CEO This section outlines: * The VPMOM for MLT cadence summarizing purpose and measures * The operations of administrative, tactical and strategic meetings * Process for alignment and cascading communications * Process for quarterly business reviews, planning and board meetings ## MLT Daily Admin The purpose of MLT Daily Admin is to clear day-to-day administrative items from our other MLT meetings and from disruptive interruptions during the day. MLT Daily Admin consists of: 1. **Standup Post:** A concise summary of Asks, Heads-ups, and FYIs for MLT peers from your department posted on working days 2. **MLT Sync:** A Zoom meeting for entire MLT up to 10 minutes starting at *8:31am Palo Alto time on working days.* 3. **MLT After Sync:** Spontaneous cross-departmental follow-ups not relevant to entire MLT after *end of MLT Sync until 8:55am Palo Alto time* via Zoom or phone among MLT leaders ### Topics for MLT Daily Admin | Topic | Definition and Examples | Where to share in MLT Daily Admin | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------- | | Asks |

|

| | Heads-up |

|

| | FYI |

| | | Sensitive issues | | | ### **Stand-Up Post** **Any time up to 12 hours before 8:31am Palo Alto time on weekdays** Before meeting use `/standup` command to post updates to peers in the channel of what’s important: ``` /standup - Met with Alice Evans from Gartner - [Notes posted](XXX) - Carter Lee starts today as Director of BizOps ``` If you post incorrectly, use the “Edit” option to update. Most updates will look something like this: ``` ##### Status Update for Tuesday 16 April 2019 - Met with Alice Evans from Gartner - [Notes posted](XXX) - Carter Lee starts today as Director of BizOps #standup-20190416 #standup ``` If there’s a lot to talk about, use this format: ``` ##### Status Update for Tuesday 16 April 2019 Heads-up - CTO of ABC Co escalating ask for custom SAML provider, blocking purchase. Need R&D's help FYI - Met with Alice Evans from Gartner - [Notes posted](XXX) - Carter Lee starts today as Director of BizOps Asks - @john.smith can you share where things are with the Twitter issue brought up yesterday? #standup-20190416 #standup ``` ### **MLT Sync** **8:31am to 8:41am Palo Alto time** * Meeting starts promptly at 8:31am SF time * Each MLT member has \~60s for updates * Meeting ends at 8:41am SF time ### **MLT After Sync** **8:42am SF time to 8:55am Palo Alto time** * 8:42am to 8:55am offers 14 minutes to talk through cross-team communication and administrative items outside of meeting * Use Zoom in DM channel or phone ## MLT Weekly Tactical **Tuesdays 10:00am to 11:30am Palo Alto time with MLT**\ The purpose of MLT Weekly Tactical is to keep MLT team on track to quarterly and annual targets. Discussions held in [MLT Weekly Tactical Channel](https://community.mattermost.com/private-core/channels/ijt-weekly-tactical). #### Process * **(0:00) MLT Sync** - Complete MLT Sync and queue any last items for Weekly Tactical * **(0:11) Scoreboard Review -** Review Thematic Goal * Discuss red/yellows on Defining Objectives and Standard Operating Objectives * Check that all objectives have measures and due dates * (0:45) **Tactical Agenda -** Discuss queued items, 5m max per topic. Choose: * Discuss now * Discuss later (another Monthly Strategic or at another Weekly Tactical) * Discuss 1-1/outside of MLT * (1:10) **Decisions/Actions** - Summarize decisions/actions in writing * (1:20) **Cascading Communications** - Decide what to communicate broadly * This includes Customer Obsession Meeting announcements * If meeting ends without agreement, Vice-Chair notes this in [MLT Weekly Tactical channel](https://community.mattermost.com/private-core/channels/ijt-weekly-tactical) with an `@all` mention ## MLT Monthly Strategic The purpose of MLT monthly strategic meeting is to achieve clarity and closure on strategic issues through review, discussion and decision on queued topics. * Meeting is monthly for 2-4 hours with Mattermost Leadership Team. * Ad hoc meetings may also be called for strategic discussions using same format. **Pre-work** * (Vice-Chair) Agenda drafted based on queued topics in [MLT Monthly Strategic channel](https://community.mattermost.com/private-core/channels/monthly-strategic-mtg) * (Vice-Chair) Agenda posted in MLT Monthly Strategic [Scratch document](https://docs.google.com/document/d/1O6ok1Uvb8uuCCFaxYjkkPZCPfDFK8nlb7OGrmyfwtCc/edit) * (MLT) People who queue topics post relevant materials in Agenda 24 hours before meeting **Meeting Cadence** * MLT reviews, discusses, adjusts as needed, and agrees on Agenda for time allotted * MLT discusses each topic and reaches decisions for clarity and closure * (20m before end of meeting) Decisions/Actions are summarized * (10m before end of meeting) Cascading Communications are agreed ## MLT Planning The purpose of target setting is to confirm targets, plan and budget for MLT departments for the period. The MLT plan consists of: 1. Company and department fiscal year 1-page VPMOMs 2. Quarterly plan, in the context of fiscal year VPMOM 3. Financial plan, including revenue 4. Headcount plan We’re currently focused on quarterly plans and will move to halves #### Plan Expectations * Quarterly plans are locked for the quarter–Changeable only in MLT team meeting * Progress on quarter plans reviewed at the start of next quarter * Okay to reduce targets prior to 20 days before quarter end (except revenue & pipeline) * Quarterly plans are in context of annual VPMOM #### Plan Process **Drafting MLT Plan** **T-Minus 4 Weeks to announcement.** The following should happen within a 2 week period, with 1-2 iterations in each step: 1. CEO discusses company and department VPMOMs 1-1 with department heads to ensure alignment * If applicable during the period, sales, CEO and finance set or adjust the revenue targets 2. People meets with department heads to discuss current and future org structure * Include discussion on performance, potential and any FYIs 3. Finance works with department heads to discuss headcount and program spend budget * Include budget variance 4. Department heads social plans with their teams **Review WIP Plan** **T-Minus 2 Weeks to announcement.** * At Monthly Strategic Meeting: * WIP VPMOMs, quarterly plan and proposed orgs reviewed by MLT * MLT shares feedback on each VPMOM and quarterly plan * Cross-department dependencies documented * Draft agenda * Review of MLT Plan Process * Company VPMOM & Q2 plan * Sales VPMOM, Q2 plan and proposed org * R\&D VPMOM, Q2 plan and proposed org * Marketing VPMOM, Q2 plan and proposed org * Customer Success VPMOM, Q2 plan and proposed org * Finance VPMOM, Q2 plan and proposed org * People VPMOM, Q2 plan and proposed org * MLT socializes updates to high-level plan with their departments **Finalize Plan** **T-Minus 1 Week to announcement** * Company and VPMOMs updated given feedback * Financial plan adjusted * Headcount approvals published **Plan Shared** **Week of announcement** * Company VPMOM shared at all-hands * Department VPMOMs are posted * MLT presents company plan to their departments ## Quarterly Leadership Review (QLR) Each quarter we review process towards our VPMOMs and discuss achievements and opportunities. #### QLR VPMOM TBD #### Quarterly Leadership Checkin QLR is an exercise to increase output through concise, efficient review of quarterly goals for company and department in the context of VPMOMs. **Time and People** * Scheduled monthly for 3.5 hours with Mattermost Leadership Team. **Prior to Meeting** * Materials for QLR agenda are shared by Friday prior to the QLR meeting. **Agenda** * (CEO) Reviews [MLT Cadence VPMOM](http://handbook.mattermost.com/leadership/leadership-meetings.html#MLT-Cadence-VPMOM) (10 minutes) * (Each department head) Reviews quarterly goals in the context of VPMOMs, including the following (15 minutes per person): * Goals for previous quarter * Previous quarter achievements and opportunities * Goals for current quarter * Cross-department dependencies * Hiring plan and org chart * (MLT) Break (10 minutes) * (MLT) Deep dive into GTM (90 minutes) * (CEO) Wrap-up, including follow-ups (10 minutes) #### Quarterly GTM Review QGR is a quarterly drilldown on sales, marketing and customer success in the context of VPMOMs. Agenda to be determined. #### Quarterly Product Review QRR is a review of product vision, near term roadmap and long term roadmap in the context of VPMOMs. Agenda to be determined. #### Quarterly Operations Review Review of non-GTM, non-R\&D departments in context of VPMOMs. Agenda to be determined. #### QBR follow-ups As reviews happen, follow-up items are noted in RAPID format and meetings scheduled based on RAPID assignments. ## Board Meetings * Between 21st and end of the month * Scheduled 18 months in advance * Board deck is sent to Board 3 calendar days before Board meeting #### Meeting Structure 1. General session: Includes leads from Mattermost team, usually sales, occasionally CS, product 2. Closed session: VP Finance and CEO update Board 3. CEO and Board: Board gives feedback to CEO 4. Board without CEO: Board discusses feedback among themselves, then one board member delivers feedback to CEO #### Debrief Calls 1. 25 minute debrief scheduled with each board member same day or the day after board meeting via their admins. 2. 1 hour debrief with MLT scheduled same day after board meeting. ## Fiscal Year Planning (1%) Preparation for the annual plan and budget for the next fiscal year begins in the second half of the current fiscal year. #### Q3 Planning for next fiscal year In Q3 we have three goals: 1. 50% VPMOM for company and departments based on our latest thinking 2. Prioritized issues to solve before we lock 99% plan at end of Q4–largely coming from Obstacles in 50% VPMOM 3. After aligning with MLT, begin to discuss 50% VPMOMs with departments to develop into 99% in Q4 Typically there is not pressure for budget or headcount discussions in Q3, focus is strategy. **Q3 Punchlist for Next Fiscal Year Planning** 1. The company 3-year aspirations are reviewed 2. A 1% MLT VPMOM for next fiscal year is drafted by CEO and reviewed with MLT department heads 3. Department heads draft 1% Department VPMOMs for next fiscal year and review with peer stakeholders and CEO 4. At Q3 Planning Offsite, MLT reviews 50% MLT VPMOM for next fiscal year developed from 1% draft 5. At Q3 Planning Offsite, department heads present 50% Department VPMOMs, reviewed by peer stakeholders and CEO 6. Action items are documented and developed around Obstacles to success of next fiscal year 7. 50% MLT and Department VPMOMs, plus Obstacles, are presented to department leaders #### Q4 Planning for next fiscal year The focus of Q4 is arriving at a 99% draft of the plan for next fiscal with alignment across MLT and departments, with key Obstacles mitigated, and headcount and budgets reviewed. 1. MLT and middle managers work through key Obstacles for next fiscal year 2. Finance works with MLT to draft financials plan for next fiscal year 3. CEO works with MLT to develop MLT VPMOM from 50% to 99% 4. Department heads work with their teams, peer stakeholders and CEO to develop Department VPMOM from 50% to 99% 5. 99% MLT VPMOM is reviewed by MLT and agreed 6. 99% Department VPMOMs are reviewed by MLT peers and CEO and agreed 7. Plan for next fiscal year is locked based on VPMOMs
#### MLT VPMOM Review Process VPMOMs, quarterly plans and proposed orgs are reviewed by MLT. Use the following order to review VPMOMs: * Measures * Priorities * Vision * Obstacles * Methods MLT shares feedback on each VPMOM and quarterly plan. Cross-department dependencies documented. # MLT Cadence VPMOM (1%) One-page summary on how MLT works together as a first team to meet and exceed company objectives Vision * MLT delivers outstanding results with first-team mindset and cadence driving alignment, effectiveness and predictability Values * MLT is our first team - Prioritize company over departments. No one fails alone * Alignment - MLT in sync on plan, priorities, process and progress * Effectiveness - We run the company well * Predictability - We make progress on plan with few preventable surprises Methods * Strategic, tactical and administrative MLT cadence - Stay in sync, solve problems as a team * Quarterly planning process (moving to halves) - Develop, adapt and finalize plans for next quarter * Quarterly business review - As a first team, review previous quarter and align plans for current quarter * Annual planning offsite - Discuss and finalize plans for the year * Board and adviser reviews - Check-in with board and advisers to align on annual plans * Team leadership workshops - Increase organizational health by investing in team cohension * Opportunity for leadership coaching / advisers (no obligation) - Invest in our leaders Obstacles * Need to realign natural tendency to prioritize department over company * Need to make time for MLT cadence Measures * MLT meets and exceeds objectives * Company is excited about direction and understands their contribution * Measures, budget and program spend agreed and stable for the period # MLT Metrics (10%) This section outlines metric definitions maintained by finance for reporting to investors. 1. These are metrics for MLT discussions 1. Any metrics shared by a department with the MLT will be asked to work with business operations to define the metric to be listed on this page under standardized naming and MLT definition checklist 2. Definitions center around ARR, GMA Magic Number and NPS MLT definitions checklist 1. Qualifiers precede metrics names 1. i.e. use ""Gross Margin Adjusted Magic Number" instead of "Magic Number, Gross Margin Adjusted" to avoid ambiguity when label names are truncated 2. Metric names should only have one possible interpretation 3. All MLT Metrics should have a unique acronym shorter than 8 characters 1. Metrics will inevitably be shortened, pre-emptive definition avoids collision ## ARR ### **Revenue Metrics** * **IARR: Incremental Annual Recurring Revenue (50%)**: (New logo ARR + Expansion ARR) - (Contraction ARR + Churn ARR) * **New Logo ARR** (1%): ARR from new logos signed, with start dates in the respective period. * **Expansion ARR** (1%): ARR from existing customers with a cross-sell/upsell deal, with start dates in the respective period (e.g. increased licensed seat count, upgrading from E10 to E20). * **Contraction ARR** (1%): Reduction in ARR from existing customers whose ARR does not become zero. * **Churn ARR** (1%): Reduction in ARR from an existing customer whose ARR becomes zero. * **Net New ARR** (1%): (New logo ARR + Expansion ARR) - (Contraction ARR + Churn ARR) * **Count of New Logos** (1%): Count of new logos signed, with start dates in the respective period. * **Count of Churned Logos** (1%): Count of logos lost where an existing customer is no longer paying Mattermost. #### Active Users * **Total Active Users**: The total number of user accounts created on a single Mattermost server. Excludes deactivated accounts, deleted accounts and bot accounts. This is also the “Total Active Users” measure shown in **System Console > Site Statistics**. * **Registered Authorized Users**: Same as **Total Active Users**. * **Total Registered Users**: The total number of user accounts created on a single Mattermost server, including deactivated and deleted accounts. * **Daily Active Users (DAU)**: The total number of users who viewed the Mattermost site in the last 24 hours. Excludes bot accounts. This is also the “Daily Active Users” measure shown in **System Console > Site Statistics**. * **Monthly Active Users (MAU)**: The total number of users who viewed the Mattermost site in the last 30 days. Excludes bot accounts. This is also the “Monthly Active Users” measure shown in **System Console > Site Statistics**. * **Active User Count**: A measure of the number of active users last 24 hours. **Legacy measure, do not use this for analysis or decision-making.** ## GMA Magic Number * **GMA Magic Number:** *Gross Margin Adjusted Magic Number* (1%): Net New ARR in a period multiplied by Gross Margin in the period, divided by total Sales & Marketing expense in prior period. * **NGMA Magic Number:** *Non-Gross Margin Adjusted Magic Number* (1%) * **Gross Margin**: Net sales revenue minus cost of goods sold * Cost of Goods Sold: ## NPS * **Product NPS**: The product net promoter score (Product NPS) measures user satisfaction of the product, calculated based on single question “How likely are you to recommend Mattermost?”. The score is based on a -100 to 100 scale, with the [calculation detailed here](https://en.wikipedia.org/wiki/Net_Promoter#How_it_works). * **End User Product NPS**: The Product NPS calculated among end users only (ie. not among Team or System Admins). * **System Admin Product NPS**: The Product NPS calculated among System Admins only. #### Support * **Support Metrics (E10 and E20)**: Metrics calculated based on Zendesk tickets opened by E10 and E20 customers. Tickets opened by non-subscribed organizations are not counted towards these metrics. * **Tickets Created**: Number of net new Zendesk tickets created. * **First Response Time \[Median, hours]**: The median number of hours from when a ticket was opened in Zendesk to when the first response was sent to the customer. * **% First Response >8 Business Hours**: % of newly opened Zendesk tickets whose first response time is greater than 8 business hours as defined in . * **Resolution Time \[Median, hours]**: The median number of hours from when a ticket was opened in Zendesk to when the ticket is resolved. * **% Resolution Time >7 days**: % of newly opened Zendesk tickets whose first resolution time is greater than 7 days. * **% Resolution Time >14 days**: % of newly opened Zendesk tickets whose first response time is greater than 14 days. * **Number of CSAT Responses**: # of new CSAT (Customer Satisfaction) survey responses from customers whose Zendesk ticket was resolved. * **Customer Satisfaction Score**: % of newly submitted CSAT survey responses who responded “Yes” to the question . For technical analytics definitions not covered here, see the [Analytics Playbook](https://docs.google.com/document/d/1__65LymlUfXLzOiSKD-G56j16Jlx1fRaIu714s3yxDU/edit#heading=h.sowg5wp7n9lk). ### Best Practices To be added. # Contributors (0%) ## Contributors ### Contributors Key Info * [Taxonomy of Mattermost Contributors](https://docs.mattermost.com/process/community-overview.html) ### FY20 Contributors VPMOM (TBA) New VPMOM to be added. ### Staff ### **Staff Key Info** * HR Admin: [Onboarding Playbook](https://docs.google.com/document/d/1VajR9okB231ZACNCG5oyiIAUZBb9Hjn3qkSnJfwraEI/edit#bookmark=id.jqu3ximag4ya), [Offboarding Playbook](https://docs.google.com/document/d/1CuIne4XAxt8sWiH1wvpICjxDmmZLu57x1_ZxnytYhx4/edit#heading=h.nrzjl1py8ndw), [Human Resources Privacy Policy](https://docs.google.com/document/d/1Z7kcPAGBt9WARpxsvklrdHcX4W9qc1Qvucwx0YhUIV4/edit), [Listings](https://docs.google.com/document/d/1epozNqWcKf4dRd-nJuP5RrDiNpLaYB73Q4rFwO_6hng/edit) * Development: [Manager Expectations](http://handbook.mattermost.com/people/manager-expectations.html), [Performance Review Process](http://handbook.mattermost.com/people/performance-reviews.html), [Annual Performance Review Template](https://docs.google.com/document/d/1C1BY8h6dZVQIuQd_vxRy1S-3f1lhAdtM5frIATmUG5A/edit?ts=5bf46661#heading=h.hu5vu6dn98iw) * Hiring: [Auditions](http://handbook.mattermost.com/people/audition.html), U.S. Employees (TBD), Canadian Employees (TBD), Non-U.S./Canadian Fulltime Staff (TBD) **FY20 Staff VPMOM (TBA)** New VPMOM to be added. VPMOM in need of update: [Scaling Team Mattermost](https://docs.google.com/document/d/1Y4pRZEjEop2D42P-Q899R8f4Pg0TJwUBltUFhq7TX_g/edit?ts=5bf740a1#heading=h.pwfphms1e2gi) #### Open Source Contributors **Open Source Contributors Key Info** * [(Needs updating) Contributors VPMOM](https://docs.google.com/document/d/1Y4pRZEjEop2D42P-Q899R8f4Pg0TJwUBltUFhq7TX_g/edit?ts=5bf740a1#heading=h.gpdj7j670rwj): Massive Community Momentum **FY20 Open Source Contributors VPMOM (TBA)** #### Partners **Partners Key Info** **FY20 Partners VPMOM (TBA)** ### # Research & Development (10%) R\&D includes engineering, QA, product management, and design (UX, UI) #### R\&D Key Info * [Development & Release Process](https://docs.mattermost.com/guides/core.html#development-process): How open source software is developed * [Platform Contribution Process](https://docs.mattermost.com/guides/core.html#community-process): How contributors can get involved * [Analytics](https://community.mattermost.com/private-core/channels/analytics-2): Analytics playbook and data wallows * [WIP: Feature Idea Flow Chart](https://docs.google.com/drawings/d/1D6KiN31mhNr1A0DGGHOuu6hvS0gpDTFuftnh2yyniNQ/edit): Work-in-progress **Product Strategy** * [Analyst Research](https://community.mattermost.com/private-core/channels/analyst-research): Analyst meeting tracker, briefing procedures, research. We are currently Gartner clients. * [Compete](https://community.mattermost.com/private-core/channels/compete): Key articles on competitors. Also see [automated feeds from competitor marketing](https://community.mattermost.com/private-core/channels/compete-feeds). #### FY20 R\&D VPMOM (TBA) New VPMOM to be added. VPMOM in need of update: [Irresistable Solution and Platform for High Trust Teams](https://docs.google.com/document/d/1Y4pRZEjEop2D42P-Q899R8f4Pg0TJwUBltUFhq7TX_g/edit?ts=5bf740a1#heading=h.2lyyszkcm50h): # Customer Success (0%) ### Customer Success #### Customer Success Key Info * [Customer Feedback](https://community.mattermost.com/private-core/channels/customer-feedback): Customer feedback archive and Feature Idea Flowchart * [Customer Support](https://community.mattermost.com/private-core/channels/community): Discussion, wscalation Process, feedback form, office hour notes * [Community Guidelines](https://sites.google.com/a/mattermost.com/core-team/community-forum-guidelines?pli=1): How to handle support forums. [sample community responses](https://docs.google.com/document/d/1WcVXpWA5QX1ukBC5vYYTqT5hErGb5bm8F1vHP9oZ21Q/edit) #### FY20 Customer Success (TBA) New VPMOM to be added. VPMOM in need of update: [Fanatical, Lifetime Customers Who Promote Us](https://docs.google.com/document/d/1Y4pRZEjEop2D42P-Q899R8f4Pg0TJwUBltUFhq7TX_g/edit?ts=5bf740a1#heading=h.ltri8ltmnam9) ### # Finance (10%) Finance Key Info * Professional Services Procurement: [How to procure at Mattermost](http://handbook.mattermost.com/people/procurement.html) * E-sign Procedure (Internal, TBA) * Accounting: [Invoicing and Collections Playbook](https://docs.google.com/document/d/1fh2NQsOJUALVyC7SEFHc_oK3Xpc74T2_RLFABiFD6Oo/edit#) * Legal and Compliance: [Archives](http://handbook.mattermost.com/bizops/archives.html) * Reporting: [Operating Metrics](http://handbook.mattermost.com/bizops/operating-metrics.html) * Planning, Budgeting, Forecasting: [VPMOM Process](http://handbook.mattermost.com/leadership/VPMOM.html) #### FY20 Finance VPMOM (TBA) New VPMOM to be added. VPMOM in need of update: [High Output Operations](https://docs.google.com/document/d/1Y4pRZEjEop2D42P-Q899R8f4Pg0TJwUBltUFhq7TX_g/edit?ts=5bf740a1#heading=h.ds55krfrlcsc) # Business Operations (10%) ## FY20 Business Operations VPMOM (TBA) Vision\ Priorities \ \- \ Methods\ \- Automated deals under $5K \ Obstacles\ Measures \ \- NPS for all purchase experiences, including renewals Vision * Fulfill operational needs for the core business functions efficiently Priorities 1\. Customer Obsession - Know our customers and align our GTM to their journeys through data, automation and process \ 2\. Aligned Communities - One version of data across company and community \ 3\. Conscious Competence - Understand what's working and not working\ 4\. Earn Trust and Iterate - Systems work and continually improve \ 5\. High Impact then Efficient - Priorities addressed and efficiency gains follow Methods (just starting) 1. GTM operations and reporting aligned to customer journey - Online & Enterprise | Community vs Commercial 2. Instrumented Journey - Web, products, GTM processes consistently defined & measured 3. Decision Support Platform - Reporting, analytics, data warehousing, automated ETL established 4\. Something about data wallows/drill downs 5\. Subscription Management - Purchase, renewal expansion with taxes, rev share back ends work 6\. Diligence Ready - Ready for diligence on custom agreements, taxes, export regs, etc. 7\. Mattermost as data platform - We are our best demo 8. Process and Documentation
## **FY20 Standard Operating Procedures (TBA)** Vision * Operate efficiently with Standard Operating Procedures (SOPs) that are aligned, documented, easy-to-use and deliver value quickly Priorities * Alignment - SOPs should clearly align to vetted VPMOMs * Documented - All SOPs found online through web search * Easy-to-use - Experience of using SOPs is fast, obvious and forgiving * Agreed - RAPID feedback and agreement achieved * Delivery Value Quickly - We move faster with SOPs, not slower Methods * Table of Contents - Public list and link all SOPs at [Operations section of handbook.mattermost.com](http://handbook.mattermost.com/sop/operations.html) * RAPID review - Update SOPs with RAPID stakeholder review * Onboard and train - Include on-boarding, training for new and updated SOPs * SOP iteration - Measure, monitor and manage SOPs Obstacles * Too many procedures stored in email, channels and tribal knowledge * Too many undocumented, unclear procedures * Duplicate, conflicted procedure documented * People not knowing about and/or following SOPs Measures * Number of unlisted procedures (no TOC listing) * Number of undocumented procedures * Error rate by SOP # Messaging and Math (0%) Messaging and Math (“M\&M”) are the components of marketing where we focus. * Messaging includes company, audience and product messaging and positioning as well as content and brand. * Math includes revenue marketing, demand generation and campaigns, marketing operations, website, events and developer outreach. We use the “Messaging and Math” framing to focus investments on the messaging and quantitative outcomes vital to the growth of our business. #### M\&M Key Info * [Customer References](https://community.mattermost.com/private-core/channels/customer-references): Tracking sheet, discussion, ask templates * [Editorial Guide](< https://docs.google.com/document/d/1XWjtWdF77qKdxDso_-aC_S1c3E0ohOoxCRL_PIf3pco/edit#heading=h.mowcb1f5jyj7>): Guidelines for copy and content #### FY20 M\&M VPMOM (TBA) New VPMOM to be added. VPMOM in need of update: [Monster Pipeline](https://docs.google.com/document/d/1Y4pRZEjEop2D42P-Q899R8f4Pg0TJwUBltUFhq7TX_g/edit?ts=5bf740a1#heading=h.h0etjzlw92y3) # Sales (50%) #### Sales Key Info * [Operating Metrics Definitions](https://docs.google.com/document/d/1aKJrJ7VBf6lGzYNe2xpsTaAfUjw_3Pv1TBRw5XhRCs0/edit?usp=sharing) * [Salesforce.com Field Definitions](https://docs.google.com/document/d/1FIoKrd1yEqmS_opi1jxXOEbhxx88N0WVZBsjWO_abow/edit?usp=sharing) #### FY20 Sales VPMOM Vision * Build the machine to scale open core sales, direct and indirect Values * Work within the structure and process - Use Salesforce, follow guides, be consistent * Understand the customer and address their needs - Ask, listen, add value * Be super responsive - Quick on leads, inquiries, asks–time kills all deals Methods * (Sales Ops) Upgrade sales ops infrastructure and automate low dollar customers * (SA) Deliver core demos as foundation of GTM * (SA) Support GTM with webinars, events, blogs and technical content * (Field) Repeatedly grow G2000 accounts in key regions and prepare to hire reps * (Sales Ops) Uniformly structure partner agreements on fulfillment and lead gen * (SA) De-risk onboarding with pre-sales deployment checklists in Salesforce * (CS) 100% renewals, uncover expansion, and close co-marketing * (Inside) Repeatedly grow midmarket new logo count Obstacles * Creating awareness in the G2000 to engage * Prospects won’t talk to AEs for lack of compelling content * Need actionable info from telemetry on open source users * Onboarding (process, best practices, docs and training) * Keeping the product competitive and differentiated * Need top 5 most important integrations from Mattermost (e.g. WebEx) * Meet product the demands of new G2000 customers * Need to optimize pricing and packaging (repackage E10) * Need for greater bottoms-up interest in EE within the product Measures * See [confidential version](https://github.com/mattermost/mattermost-mlt/wiki/FY20-Sales-VPMOM) # Join Us (30%) ## Join Us Thank you for your interest in joining the Mattermost community. Note: This section is being migrated from: ### Ways to Join There’s many ways to join the [Mattermost community](https://docs.mattermost.com/process/community-overview.html) through our open source programs, our company and our partner ecosystem: * Open source contributor community for the Mattermost projects (from authorized contributor to core committer) * Employee and staff contributor community for for Mattermost, Inc. (employee or staff contributor) * Commercial partner community with Mattermost Enterprise Edition (reseller, systems integrator or technical alliance partner). #### Open source contributors Join our community of open source contributors: * Contribute to Mattermost-related open source projects: [See Contribution Opportunities](https://mattermost.com/contribute/) * Let us know about a Mattermost integration you’ve created: [Submit your integration to the Mattermost Integration Directory](https://spinpunch.wufoo.com/forms/mattermost-integrations-and-installers/) * See examples of open source integrations: [View Mattermost Integrations Directory](https://integrations.mattermost.com/) #### Staff contributors Become a paid member of the staff at Mattermost, Inc. as an employee or staff contributor: * See open staff positions: [See Careers at Mattermost.com](https://mattermost.com/careers/) * Read about what it’s like to work here: [Previous Join Us content (to be migrated here)](https://docs.mattermost.com/guides/core.html#joining-the-team) #### Enterprise Edition Partners Help deliver professional services and commercial software for large, enterprise-scale Mattermost deployments by joining a partner program for Mattermost Enterprise Edition: * Sell Mattermost Enterprise Edition to your customers: [Become a Mattermost Authorized Partner](https://docs.mattermost.com/process/partner-programs.html#mattermost-authorized-partner-program) or a [Mattermost Value-Added Reseller](https://docs.mattermost.com/process/partner-programs.html#mattermost-value-added-reseller-program) * Certify your inclusion of Mattermost software in your open source or commercial offering to be listed in our partner directory: [Mattermost Deployment Solutions Partner Program](https://docs.mattermost.com/process/partner-programs.html#mattermost-deployment-solutions-partner-program) * Learn more about becoming a Mattermost partner: [Mattermost Partner Programs](https://docs.mattermost.com/process/partner-programs.html) ### Learning about Mattermost Note: This section is work-in-progress, being migrated from: #### Exploring Mattermost as a workplace At Mattermost, most of the company works from home. Our headquarters is on the internet–Specifically, we work on an open test server called [https://pre-release.mattermost.com](https://pre-release.mattermost.com/) which runs a pre-released version of Mattermost software with all the newest features and improvements (which is occassionally unstable). The server is integrated with Zoom and employees and staff members can launch voice, video and screensharing meetings with a button click. **Joining the test server** If you’re thinking of joining Mattermost as an open source contributor, as an employee or staff contributor, or as an ecosystem partner, we welcome you to start an account on our server and see what it’s like to work here–and even try installing the mobile apps if you would like. When you join, please use the username `firstname.lastname` so it’s easier to get to know you. You can create a new account from here: (select Email and Password). A bot will suggest different channels for you to view, and you’re welcome to join any channel on the server. All the information you’ll have access to is public (employees and staff have confidential channels and workspaces on the server). **Say “Hello”** If you’re in contact with someone with an @mattermost.com email address, such as a recruiter or hiring manager, you can message them or your hiring manager on the server by contacting them at `firstname.lastname` to let them know if you have joined. **Try some formatting** To practice sending messages in Mattermost, particularly around formatting, you can send messages to yourself to test out how messages will look before sending to another person. ### FAQ #### Do you offer internships? We don’t currently offer internships. If you’re interested in expanding your experiences and resume, please consider joining our open source community: #### I’m interested in a staff position, how do I get noticed? If you haven’t yet experienced the product, you should do that as a first step. Join our testing server at When you apply there’s a question about your experience with Mattermost and at a minimum you should have spent some time using the product and have some opinions on what we might improve. We hire about 70% of our R\&D staff from our open source community. If you want to increase your odds further, please consider trying a beginner or intermediate open source contribution via #### I’m an agency or contingent recruiter and I have a candidate for you Thank you for thinking of us. In general, we don’t work with agency or contingent recruiters unless they are referred from people we know who can vouch for success in working with you. Unless you fit this criteria, we would ask you remove us from your mailing list. # Onboarding (1%) Onboarding information and checklists for general staff and departments # Staff On-boarding (10%) ## Contents * [WIP: Staff Onboarding Guide](http://handbook.mattermost.com/people/general-onboarding.html#wip-staff-onboarding-guide) * [Welcome to Mattermost](http://handbook.mattermost.com/people/general-onboarding.html#welcome-to-mattermost) * [How to use our Handbook](http://handbook.mattermost.com/people/general-onboarding.html#how-to-use-our-handbook) * [Our Mission](http://handbook.mattermost.com/people/general-onboarding.html#our-mission) * [Leadership Principles](http://handbook.mattermost.com/people/general-onboarding.html#leadership-principles) * [Products](http://handbook.mattermost.com/people/general-onboarding.html#products) * [Company](http://handbook.mattermost.com/people/general-onboarding.html#company) * [General Onboarding Checklist](http://handbook.mattermost.com/people/general-onboarding.html#general-onboarding-checklist) * [Departmental Onboarding Checklists](http://handbook.mattermost.com/people/general-onboarding.html#departmental-onboarding-checklists) ### [Welcome to Mattermost](http://handbook.mattermost.com/people/general-onboarding.html#contents) We’re on a mission to make the world safer and more productive through open source. To make that happen we first have to create a great place to work–an inclusive, courteous online community where incredibly talented individuals are empowered to do their best work for our customers, with very little in their way. This guide is a summary of our guiding principles. As Mattermost grows, we hope these principles serve each new staff person that joins us. If you are new to Mattermost, welcome! While the goals here are important, it’s your ideas, talent, and energy that will keep Mattermost shining in the years ahead. Thanks for being here. Let’s change the world. ### [How to use our Handbook](http://handbook.mattermost.com/people/general-onboarding.html#contents) Our handbook defines what it’s like to work at Mattermost, from the high level to specific operating procedures. If you’re new, you’ll start with our onboarding guides. ### [Our Mission](http://handbook.mattermost.com/people/general-onboarding.html#contents) Our mission is to make the world safer and more productive by developing and delivering secure, open source collaboration software that is trusted, flexible and offers fast time-to-value. ### [Leadership Principles](http://handbook.mattermost.com/people/general-onboarding.html#contents) Leadership principles are deliberate choices defining our behavior. When facing complexity, uncertainty, or ambiguity (CUA) we determine our point of view and our actions through the lens of our values: * **Customer Obsession** - Mattermost exists to make customers successful. Every project starts with the customer perspective. * **Ownership** — Own the outcome of your actions. Act on behalf of the company, not just the team. Never say “that’s not my job.” * **High-Impact** — Choose high-impact projects over low-impact projects. Figure out what matters most and focus on those priorities. * **Insist on High Standards** — Have relentless high standards. Continually raise the bar for high-quality products and processes. * **Self-Awareness** — Seek to understand strengths and growth opportunities while being open to criticism. Share critiques constructively and respectfully. * **Earn Trust** — Make decisions based on maximizing the trust of others in your judgment. Be open, self-critical and factual. To view video of these Leadership Principles, please click [here](https://drive.google.com/open?id=1cuxqePfpj2zy4DYLQ__DPtq2uJdGfwaL). ### [Products](http://handbook.mattermost.com/people/general-onboarding.html#contents) Mattermost Team Edition under MIT license and the Mattermost open source projects under various licenses are maintained by core committers, including both staff from Mattermost, Inc. and volunteer contributors from the Mattermost user and customer communities. Mattermost Enterprise Editions, which are commercial extensions built on top of the Mattermost open source projects, are developed, supported and sold by Mattermost, Inc. For more information, see our [Product Overview](https://docs.mattermost.com/overview/product.html). ### [Company](http://handbook.mattermost.com/people/general-onboarding.html#contents) Mattermost is an open source, remote-first, communities-centered company based in Palo Alto, California and headquartered on the internet. **Open source** means that by default we make our technology, business process and source code available to the public. We develop a small portion as proprietary technology, built upon our open source work, to license for subscription fees that enable more high quality open source work to be produced. Since the start of the Mattermost open source project in 2015, we have used this model to develop effective open source solutions for the world to use. This model is sometimes called [Thin Open Core](https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c). **Remote-first** means that by default our staff works anywhere in the world where a) we have support for quality video calling and b) where we can work in a legally appropriate environment. Mattermost was born in an extraordinary age where organizations can attract, hire and enable remote teams–working from homes, coffee shops and co-working spaces across timezones–to produce better technology and business results in less time than purely office-based teams, while maintaining security and compliance standards. Remote-first culture flourishes when we share one simple principle: **Courtesy**. Courtesy means Mattermosters are thoughtful about keeping our communities appropriately informed, following etiquette for discussions, calls and video meetings, and giving and receiving feedback on how to work better together. Courtesy also means we gladly accommodate those who prefer to work out of a dedicated office. We are remote-first, not remote-only. **Communities-centered** means we define our success in the context of the success of our [communities](https://docs.mattermost.com/process/community-overview.html): users, customers, implementers, resellers, technology partners, contributors, and colleagues. The success of each community is owned by a member of the Mattermost leadership team. The plural definition of “communities” is intended to avoid unconsciously marginalizing downstream stakeholders. **Based in Palo Alto, California and headquartered on the internet** means the mailing address for Mattermost, Inc. is in Palo Alto, California, and our headquarters is on the internet, specifically the Mattermost instance at [https://community.mattermost.com](https://community.mattermost.com/). Our online headquarters is where Mattermost staff work with our communities of colleagues, users, partners, customers and contributors, to envision, develop and refine new open source technologies to make the world safer and more productive. ### [General Onboarding Checklist](http://handbook.mattermost.com/people/general-onboarding.html#contents) **People Team Responsibilities** * \[ ] When notified by HR Lead, send an [email](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#bookmark=id.srysr7dn6fzd) to find out new staff’s preference for laptop and equipment, either to be purchased or taken from stock and shipped by People Ops or purchased locally by new staff and expensed. * \[ ] Send new staff the [Mattermost email agreement](https://docs.google.com/document/d/1PhkQkvoaunu8V8qjtmt6GmZoIMZI8sq01C1nG-FoHQo/edit?usp=sharing) via DocuSign before issuing an @mattermost.com email address. New staff should use this email address on community.mattermost.com (replace personal email with company email if already registered there). [FIRST\_NAME.LAST\_NAME@mattermost.com](mailto:FIRST_NAME.LAST_NAME%40mattermost.com) is the standard naming convention. * \[ ] Send new staff an [email](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#bookmark=kix.9dj4d3aa8un9) about payroll and benefits. * \[ ] Send new staff (and manager) a [group message](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#bookmark=id.tufgijkmrb91) requesting new staff’s biography, inviting new staff to the Mattermost [demo](https://mattermost.com/demo/) and sharing more about [working at Mattermost](https://docs.mattermost.com/process/working-at-mattermost.html), including our [leadership principles](https://mattermost.com/about-us/). *First Day* * \[ ] Invite new staff to [tools used across Mattermost](https://airtable.com/tblI4gu3oPUiZazs8/viwlYaOOIveb3dhLV?blocks=hide) and the [Customer Obsession Meeting](https://docs.mattermost.com/process/training.html#customer-obsession-all-hands-meeting). * \[ ] Send new staff a [direct message](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#heading=h.w5heque66i1c) sharing a first day checklist (below) and information about laptop setup, and gives an overview of New Hire’s first week. * \[ ] Meet with new staff to review required documentation (e.g. [I-9 documents](https://www.uscis.gov/i-9)). *First Week Checklist* (Markdown) \#### Instructions: 1. Please copy each item and add an - to the left of the bracket and an x inside of the bracket you complete the item (e.g. - \[x]). 2. **Please reply to this message (hover over any message to reveal the reply button) with the items you’ve completed**. \##### Day 1 \[ ] Share your bio with @managername \` (this will be posted in the \[Welcome channel]\() in the private \`Staff team - @managername \`, please include the hashtag \`#newcolleague). \[ ] Accept the invitation to your OneLogin account and switch your Mattermost account to use OneLogin from Account Settings -> Security -> Sign-in Method -> Switch to SAML. Instructions are found \[here]\(). Note: You’ll find other apps, like LastPass and Zoom, there. \[ ] Download the Mattermost Desktop Client \[here]\() and login to [http://community.mattermost.com](http://community.mattermost.com/). \[ ] Download the \[Mattermost app]\() on your smartphone and login to community.mattermost.com using your OneLogin account. \[ ] Join the channels listed \[here]\() to get a feel for the company and to see how we communicate. \[ ] Explore your Mattermost account settings, making note of your notification settings. Tip: Set your messages to send on CTRL + ENTER, while using ENTER will insert a new line, while you’re learning to use Mattermost. \[ ] Learn how to format your messages using Markdown by reviewing this \[guide]\(). \[ ] Take Mattermost’s end user training \[here]\() and note any feedback. \[ ] Register your laptop and any other Mattermost-issued equipment \[here]\(). \[ ] Set up your email signature. \[Here’s how]\(). \[ ] Activate your Office365 account and download to your computer. Instructions \[here]\(). \##### Days 2-5 \[ ] Share your GitHub username with @camille.harris. You can, and are encouraged, to use your personal GitHub account. You may also create a GitHub account with your @mattermost email instead. \[ ] Connect GitHub and Mattermost via the instructions here: \[\]\(/core/pl/i4k6eke5t38gxxwrjtpeegbhwr). \[ ] Join GitLab with your @mattermost email and contact @hanna.park to be added to the Mattermost group. \[ ] Read about the \[Customer Obsession All Hands Meeting]\() \[here]\(). \[ ] Read about the \[R\&D Meeting]\() and let us know if you’d be OK doing an \[icebreaker]\() in a future meeting. \[ ] Review our data privacy policy \[here]\(). \[ ] Review our \[Code Contribution Guidelines]\() to learn how to contribute to Mattermost to receive a personalized Mattermug. \[ ] Add your mailing address, profile photo, and emergency contact information to Bamboo. You can also view the company \[org chart]\() there. **Note**: If you do not have access to Bamboo, please message @natalie.jew. *Week 2* * \[ ] Ask new staff to review the last three recordings of the [Customer Obsession All Hands Meeting](https://docs.mattermost.com/process/training.html#customer-obsession-all-hands-meeting) and confirm whether they will present their own intro in that week’s meeting, or if they’d like their manager to introduce them. Share decision with [Meeting Chair](https://docs.mattermost.com/process/training.html#customer-obsession-all-hands-meeting). * \[ ] Schedule CEO welcome meeting (Tuesdays at 8:30am or Fridays at 8am Palo Alto time) and invite new staff. Double-check new staff has completed the [end user training module](https://academy.mattermost.com/p/end-user-onboarding). * \[ ] Send new staff (and manager) a [group message](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#bookmark=id.tlsyeisvmbc1) answering frequently asked questions and sharing Mattermost’s [User’s Guide](https://docs.mattermost.com/guides/user.html#getting-started). *Week 3* * \[ ] Send new staff (and manager) a [group message](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#bookmark=kix.toi80hx08jzs) sharing the [org chart](https://mattermost.bamboohr.com/employees/orgchart.php) and [staff email list](https://docs.google.com/spreadsheets/d/1NQE0fkZgavMTrSSB1aPWg5hGRL182S6AGsa4ts4pWZ4/edit#gid=649832066) and describing how to view other staff members’ calendars to book meetings. *Week 4* * \[ ] Send new staff (and manager) an [email](https://docs.google.com/document/d/1TX2pnJebl7Mi2-R5u3R6PsjX8YOMS54xcI0KJhh9_xI/edit#bookmark=id.reex8djwhwfa) inviting new staff to create their [Mattermost avatar](https://docs.mattermost.com/process/training.html#mattermost-avatar). **Manager Responsibilities** *First Day* * \[ ] Post new staff member’s bio to the [Welcome channel](https://community.mattermost.com/private-core/channels/welcome) using the hashtag **#newcolleague**. * \[ ] Add new staff to relevant aliases (e.g. [sales@mattermost.com](mailto:sales%40mattermost.com)). Note: If you do not have manager access to the alias(es), please contact the People team ([people@mattermost.com](mailto:people%40mattermost.com)). ### [Departmental Onboarding Checklists](http://handbook.mattermost.com/people/general-onboarding.html#contents) \[Placeholder for links to Departmental checklists] * Exec onboarding: * R\&D onboarding: > - Product team onboarding: > - QA onboarding: > - Support onboarding: * G\&A onboarding: * Marketing onboarding: * People team onboarding: * Sales onboarding: * Customer success onboarding: # R\&D Onboarding (1%) ### R\&D Channels * See: ### Development Process * See: ### Release Process * See: # "How to" guides for staff (0%) # How to procure (0%) # How to Interview (0%) # How to open a job requisition (0%) # How to update the handbook (0%) # Mattermost Handbook The Mattermost Handbook is a continual work-in-progress for Mattermost staff (people who are paid to work on our open source software), contributor community, and end user community. We use it to document the processes that underpin our company behind our software. Its purpose is to **iteratively increase clarity** for Mattermost staff and community co-building the future of our company and our offerings, and provide a single-source of truth. Early in our history, when we were a much smaller company, our staff handbook was included in our product documentation. Now the Handbook lives in the the dedicated repository at which is edited using GitBook as a frontend. Want to contribute to the Handbook? Start here: [How to update the Handbook](/company/how-to-guides-for-staff/how-to-update-handbook). All documentation is available under the terms of a [Creative Commons License](https://creativecommons.org/licenses/by-nc-sa/3.0/). Some norms you'll see here in the Handbook: ## Growing companies are a work-in-progress It's Day 1 at Mattermost. We're a growing company and growing open source project out to support the massive transformation underway as open source software unlocks the massive potential of people and teams around the world. As an open source company we like to share early. Sharing ideas early gets us feedback sooner, so we can iterate faster, so we can better results. On some pages, you'll see reference to [1% and 50% drafts](/company/about-mattermost/mindsets#drafts-at-1-50-99). This is used to express how complete our thinking is around the published content, and indicate whether fundamental changes may be made. When a section of the handbook is at less than the 50% draft stage you should see it labeled in the page description with the % draft status. When a section doesn't have a % draft status, assume it's over the 50% draft stage. We believe this system has two key benefits: 1. **Be more open to feedback and iteration:** Having something published publicly can make it seem overly "final". By having pages in our handbook at 1% and 50% we make it easier to go through feedback and iteration cycles. 2. **Engage more non-technical people in the discussion:** In the past, we've done reviews largely in GitHub pull requests, which is friendly and familiar for technical team members, but more difficult for others. Sharing 1% and 50% drafts in the public for feedback makes our process more inclusive. There are trade-offs as well: There may be confusion among people who haven't been onboarded into the [1%, 50% draft](/company/about-mattermost/mindsets#drafts-at-1-50-99) concept. People who aren't comfortable with the level of early sharing may feel upset. For these reasons, this page itself is only a 10% draft, so opinions can be expressed and discussed. ## Sharing feedback and updating the handbook Feedback on this handbook is immensely appreciated. There are two ways you can share your feedback: 1. You can create an issue in the [Handbook repository](https://github.com/mattermost/mattermost-handbook/issues). Select **New issue**, and provide as much detail as possible in the issue. Screenshots and links are also welcome. Choose **Submit new issue**. The [Handbook channel](https://community.mattermost.com/private-core/channels/handbook) receives a notification and this begins the cycle of feedback and iteration. While not all feedback will result in an update to the handbook, we definitely want to hear everyone's opinion. 2. You can edit the page directly, and submit your feedback/suggested changes as a Pull Request (PR). PRs go through the same cycle of feedback and iteration. The only difference is that an issue is not an immediate change and may take longer to action. A PR already contains the changes, and has a quicker turnaround time. [Learn how to update this handbook through GitHub](https://handbook.mattermost.com/company/how-to-guides-for-staff/how-to-update-handbook) for detailed steps. ## Key links and materials Below is a work-in-progress list of key documents and channels at Mattermost. The symbol `*` indicates material internal to Mattermost staff. * [Mattermost 9.0 Launch Announcement](https://mattermost.com/blog/mattermost-v9-0-is-now-available/) * [Newsroom](https://mattermost.com/newsroom/) * [Message House](https://docs.google.com/document/d/1XGeyPRwD1vr3WYx3bKUGtE1LuW2HgyaZf6Kpf-HjH68/edit)\* * [Product Onboarding](https://docs.google.com/document/d/1BCFdXHMY5iWc6Ix66yuLtLNbO0sYLMJJDDsSLwqvlTA/edit)\* # About Mattermost Mattermost, Inc. is a company based on the Mattermost open source project, which is a messaging collaboration platform for team communication across mobile, web, and PC with instant search, continuous archiving, and unlimited integrations. Mattermost software is used by thousands of organizations around the world in 16 languages. **What we do:** Mattermost, Inc. helps solve collaboration challenges for developers, operators & security teams so organizations can focus on business-critical tasks. **Who we serve:** Our Ideal Customer Profile (“ICP”) is an enterprise, defense or governmental organization with 2,500+ employees in need of a collaboration platform for mission critical work that meets complex requirements for security, compliance and self-sovereignty. ICP organizations have significant in-house Dev/Sec/Ops talent and the ability to deploy and secure self-managed infrastructure. We believe that mission critical work is hampered by one or more of the following; * *Risk from non-compliance* * *End of Life of existing systems* * *Lack of resilience at scale during infrastructure failure or breach* * *Competitive Risk* * *Need to preserve sovereignty* * *Noise/gaps of MS Teams/general collab tools for tech/operational orgs* * *Risk from gaps in Mattermost Team Edition for large organizations* * *Low efficiency, high delay and error rates due to inflexible platform* * *Need interconnect outside of AD domains and CAC systems* **What we offer:** Mattermost is a secure collaboration platform for accelerating mission critical work in complex environments. We connect teams, tools and processes on a self-sovereign hub with workflow, integrations, real-time messaging, voice, screen share and federation to deliver more focused, adaptable and resilient decision cycles and outcomes. ## Mission Mattermost’s mission is to make the world safer and more productive by developing and delivering secure, open source collaboration software. ## Leadership Principles Leadership principles are deliberate choices defining our behavior. When facing complexity, uncertainty, or ambiguity (CUA) we determine our point of view and our actions through the lens of our values: * **Customer Obsession:** We exist to make customers successful. In everything we do, start with customer perspective and work backwards. Earn and keep their trust. * **Ownership:** Own the outcomes of your activity. Don’t drop the ball. When we see a vacuum on something important, we jump in – we never say “it’s not my job.” * **High Impact:** Align work to our shared vision and focus on those priorities. When deciding to work on low impact or high impact projects, choose high impact. * **Self-Awareness:** We understand and seek to understand our strengths and growth opportunities, as individuals and organizations. We are open to critique and share critique constructively and respectfully. * **Earn Trust:** Make decisions based on maximizing the trust of others in your judgement. Be open, self-critical, and factual. Earn and keep peoples' trust. ## Market We see a $30B+ market opportunity in the secure collaboration space and the growth of “open source collaboration” accelerating vs proprietary solutions. Open source has already commoditized operating systems, databases, tooling, and virtualization infrastructure. We see the entry of open source into the application layer driving fast adoption of a new generation of open source and open core solutions, inherently more flexible, trustworthy, and economical than past models. ### Products and Business Model Mattermost, Inc is a commercial open source company with a subscription-based, [buyer-based open core licensing model](/company/about-mattermost/business-model). | | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Mattermost Professional

Audience: Development team that wants to build and scale sophisticiated work flows for multiple cross-functional teams to be able to deliver mission critical operations.

|

Mattermost Professional is offered under an open source MIT license. It's built for a team of 10 to 50 developers and IT professionals who need to self-host a workplace messaging platform. Developer-focused features including web, desktop, and mobile apps, core integrations with DevOps platforms, archiving, search, and extensibility framework are offered in the open source core at no cost.

Mattermost Professional is packaged as a single Linux binary that's straightforward to install and maintain, with automated deployment from public cloud marketplaces including AWS, Azure, VMWare, and GCP.

| |

Mattermost Enterprise

Audience: Enterprise deployments who need to accelerate mission critical work in complex environments by increasing speed, efficiency and resilience in vital operations while meeting nation-state level security and compliance requirements.

|

Mattermost Enterprise is an enterprise-grade collaboration system that supports and helps you scale your mission-critical enterprise workflows, meet strict enterprise security, compliance, and privacy requirements, as well as provide executive reporting, dashboards, and productivity metrics.

Different packages of commercial features are offered based on buyer needs.

| For more information, see our [Product Overview](https://docs.mattermost.com/overview/product.html) and open source repository at [https://github.com/mattermost/](https://github.com/mattermost). ## Company Mattermost is an open source, remote-first, communities-centered company based in Palo Alto, California and headquartered on the internet. **Open source** means that by default we make our technology, business process and source code available to the public. We develop a small portion as proprietary technology, built upon our open source work, to license for subscription fees that enable more high quality open source work to be produced. Since the start of the Mattermost open source project in 2015, we have used this model to develop effective open source solutions for the world to use. This model is sometimes called [Thin Open Core](https://doubledown.substack.com/p/open-source-software-projects-business). **Remote-first** means that the majority of our staff works from home, cottages, coffee shops and other personal areas, rather than at a shared corporate office location. Mattermost was born in an extraordinary age where remote-first organizations can attract, hire and enable remote teams to produce better technology, business process and business results in less time than office-based teams, while maintaining security and compliance standards. Remote-first culture flourishes when we share one simple principle: **Courtesy**. Courtesy means Mattermosters are thoughtful about keeping our communities appropriately informed, following etiquette for discussions, calls and video meetings, and giving and receiving feedback on how to work better together. Courtesy also means we gladly accommodate those who prefer to work out of a dedicated office. We are remote-first, not remote-only. **Communities-centered** means we define our success in the context of the success of our [communities](https://handbook.mattermost.com/contributors/contributors/community): users, customers, implementers, resellers, technology partners, contributors, and colleagues. The success of each community is owned by a member of the Mattermost leadership team. The plural definition of “communities” is intended to avoid unconsciously marginalizing downstream stakeholders. **Based in Palo Alto, California and headquartered on the internet** means the mailing address for Mattermost, Inc. is in Palo Alto, California, and our headquarters is on the internet, specifically the production-quality Mattermost instance at [https://community.mattermost.com](https://community.mattermost.com/). Our online headquarters is where Mattermost staff work with our communities of colleagues, users, partners, customers, candidates, contributors, and other [community members](https://docs.mattermost.com/process/community-overview.html) to envision, develop, and refine new open source technologies to make the world safer and more productive. ## Logo | | | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | -------------------------------- | | The Mattermost logomark is called "the instrument". It represents four tools organizations need to achieve their highest priorities: A **compass** for direction, a **clock** to set pace, a **meter** to measure output, and a **dial** representing inputs - the contribution of everyone on the team. | | ![](/files/N3EwVMHc469ynQY3pMeB) | See [brand guidelines](https://handbook.mattermost.com/operations/operations/publishing/publishing-guidelines/brand-and-visual-design-guidelines) for usage guidance. # List of terms ## Current Terms The following lists current terms actively used at Mattermost. You can also see [Tombstoned Terms](#tombstoned-terms) for terms that have either been modified or deprecated. We use Tombstoned Terms to preserve links to previous definitions so clarity is maintained. ### 0/5, 1/5, 2/5, 3/5, 4/5, 5/5 We use “x/5” to concisely communicate conviction. 0/5 means you don’t have a strong opinion, you are just sharing an idea or asking a question. 5/5 means you are highly confident and would stake your reputation on the opinion you’re expressing. Example: "0/5, I think before archiving a channel a user should type in the name of the channel to make sure they really want to do it" expresses low conviction and indifference in the suggestion. The decision maker should feel free to ignore the input. As another example: "4/5, I think before archiving a channel a user should type in the name of the channel to make sure they really want to do it" expresses high conviction and the decision maker may want to ask more questions to understand whether [emotion, assumption, or priority](/company/about-mattermost/mindsets#emotion-assumption-and-priority) is behind the feedback. ### Best Practices We try not to use the term "best practice" at Mattermost, as it's counter-cultural to our focus on [iteration](#iteration), [self-awareness](/company/about-mattermost#leadership-principles), and [earn trust](/company/about-mattermost#leadership-principles). Iteration means there is always opportunity to grow and improve and so we never reach our "best". ### AA Refers to both an [As Appropriate interview](/contributors/join-us/recruiting#as-appropriate-interviews-aa-s) as well as the [As Appropriate interviewer](/contributors/join-us/recruiting#as-appropriate-interviews-aa-s). Final interview required before making a decision on a new hire. ### AOR *Area Of Responsibility* defines the area for which a [DRI](#dri) is accountable. The [AOR page](/operations/operations/areas-of-responsibility) provides information on AORs across the company. ### ARR Annual Recurring Revenue (“ARR”) is a measurement for time-limited subscription contracts. ARR normalizes contracted recurring revenue into a one year period to allow for like-kind comparisons between contracts that have differing start/end dates and/or different contract lengths. In a recurring revenue model, ARR represents the anticipated total revenue from all active contracts for the future 12 months from any measurement period. “Active” is defined as starting from customer contract signing date, not subscription start date. ARR does not include revenue from non-recurring items such as one-time setup fees or professional services. For example, total ARR from 3 separate customers would be as follows: Customer A: 6-month contract totaling $60,000. ARR = $120,000 ($60,000/6 \* 12) Customer B: 12-month contract totaling $240,000. ARR = $240,000 Customer C: 15-month contract totaling $45,000. ARR = $36,000 ($45,000/15 \* 12) Total ARR for Company = $396,000 ($120,000 + $240,000 + $36,000) ### Bookings The ARR associated with sales transactions closed during the period. Note that Bookings and Billings are different, particularly for pro-rated contracts and multi-year contracts. Billings corresponds to the amount the customer is invoiced. For example, Customer A signs a 3 year paid upfront transaction for $300,000. For Customer A, the bookings amount would be $100,000 ($300,000/3 years = ARR of $100,000) and the billings amount would be $300,000 (what we actually invoiced the customer at time of order signing). Customer B has a contract for 100 licenses at $50/year/license for 12 months, for total ARR of $5,000. They decide to add 25 more licenses after 4 months. For Customer B, the bookings amount would be $1,250 (25 \* $50/year) and the billings amount would be $833.33 (25 \* $50/year \* 8 remaining months/12 months total contract). ### Bug An obvious error in Mattermost software that is typically a code defect. Changes required to accommodate unsupported third-party software (such as browsers or operating systems) are not considered bugs - they are considered improvements. ### CAO *Contract Accountability Owner* is a [DRI](#dri) for ensuring a contract meets our guidelines and standards ahead of final approval by [a company signatory](/operations/operations/company-processes/company-agreements#who-can-sign-on-behalf-of-the-company). Also see [listing of CAOs](/operations/operations/company-processes/company-agreements#who-are-contract-accountability-owners-caos). ### Churn When an existing customer completely cancels and is no longer a continuing customer. Dollar value of ARR is $0 after the reduction. ### COM COM is short for [Customer Obsession Meeting](https://docs.mattermost.com/process/training.html?#customer-obsession-all-hands-meeting), which is our “All Hands” meeting focused on how we’re aligning the company to serve our customers. ### Contraction When an existing customer decreases the dollar value of their ARR, either by decreasing the number of licenses, decreasing the number of products and/or the discounting being applied is increased. Note that the decrease is classified as “contraction” if there is still some amount of ARR remaining after the reduction. ### Country/Region Because the term "country" may be either controversial or incorrect when describing a geographic area governed by a state-like political entity we use the term "country/region" to avoid any accidental or implied judgement on the independence of a region. If the term "country" appears to be incorrectly used, when "country/region" is more appropriate, please contact . ### Collapsed Reply Threads (CRT) Collapsed Reply Threads (CRT) is a Mattermost Messaging feature available in beta offering an enhanced experience for users communicating in threads and replying to messages. When enabled, Collapsed Reply Threads improve users’ ability to process channel content, find, follow, and resume conversations more easily, and keep threaded conversations focused. See our [Organizing Conversations using Collapsed Reply Threads (Beta)](https://docs.mattermost.com/help/messaging/organizing-conversations.html) product documentation for details. ### Core Committers Core committers are staff or community developers with the responsibility to contribute and review Mattermost source code. ### CSM Customer Success Management function at Mattermost responsible for retaining customer revenue, with quarterly & annual targets, including customer relationship management, executive relationships, and quarterly business reviews. ### Customer The primary external audience we are focused on for an initiative, which could be an end user without budget (if our goal is adoption and engagement) or a buyer (if our objective for the initiative is revenue). A customer does not include internal staff, since staff are not external. ### Dark Actions The act of using non-web-discoverable formats (Mattermost channels requiring login, Google docs that aren't web searchable, Zoom call, email, etc.) to share non-confidential information or processes. Example: Giving someone instructions on how to set up Okta for MFA on the community server in a DM rather than writing it into a handbook entry for all new staff to use and re-use. Dark actions create [false openness](#false-openness). [Open actions](#open-actions) are highly preferred. ### DDIL Denied, Disrupted, Intermittent, and Limited. An acronym used to describe situations where internet or network connectivity is degraded, unreliable, unpredictable or entirely unavailable. ### DE Deployment Engineering function at Mattermost responsible for accelerating seats deployed at $50K+ accounts, focusing on single customer pain points & needs by working directly with customers in partnership with post-sales and revenue retention teams, and providing expertise on how to run and deploy Mattermost and the platform as a whole. ### Dead Tarzan Discarding an imperfect solution without a clearly thought out and working alternative. Based on idea of [Tarzan of the Jungle](https://en.wikipedia.org/wiki/Tarzan) letting go of a vine without having a new vine to swing to. ### Decking A term for shipping something that is far below quality standards. This term is used by mountain climbers to describe falling off the side of a mountain, which often involves a series of failures, not just one. ### Dev Mana A specific type of [mana](#mana) for developers similar to “points” or “jelly beans” in an Agile/Scrum methodology. On average, full time Mattermost developers each complete tickets adding up to approximately 28 mana per week. A “small” item is 2 mana, a “medium” is 4, a “large” is 8, and any project bigger needs to be broken down into smaller tickets. ### DRI *Directly Responsible Individual* means a human individual who is accountable for a given Area Of Responsibility. A DRI is a single person, not a group of people. If there is a shift schedule, define each shift as a separate AOR (e.g. Tier 2 Mobile Support Escalations Weekdays 8am to 5pm Palo Alto time). If you are unsure who is the DRI, make the AOR more specific until the DRI is clear. ### Edge “Edge Release”, a version of Mattermost which indicates the latest unstable release off of the main branch. ### ESR “Extended Support Release”, a version of Mattermost maintained for a longer period of time that will receive security fixes. ### Expansion When an existing customer increases the dollar value of their ARR, either by adding licenses, adding additional products and/or reducing the discount being applied. ### Expert Mode Expert Mode (also known as "Crimson Force Field") is when documentation or on-screen text is written for someone with considerable knowledge or expertise, instead of being designed for a new learner. In general, try to state things simply rather than speaking to just the “experts” reading the text. If something is extremely difficult to understand, and yet still justified in the mind of the writer, we call it “Crimson Force Field”. This term is intended to evoke the emotional response of coming across something that is difficult to understand, so writers of Crimson Force Field material can empathize with the readers. Crimson Force Field is drawn from an esoteric episode of Star Trek and it is unlikely anyone but the originator of the term understands its complete meaning. Crimson Force Field is itself Crimson Force Field. ### False Openness Keeping non-sensitive information that would be helpful for staff and community to know out of public web search through the use of dark actions. Often false openness is unintentional, though after staff members are educated on the topic and empowered to use [open actions](#open-actions), continued use of [dark actions](#dark-actions) would appear to be deliberate. ### FF Fast Futures function at Mattermost responsible for prototyping and validating enterprise customer needs ahead of product engineering investment, which was the approach applied to Calls, MS Teams and OpenOps prior to adding the functionality to the mainstream roadmap. ### GNN A status update format that is split into three categories: Going Well, Not Going Well, Next Actions. Read more about [GNNs here](/operations/operations/company-cadence#gnn-updates). ### Gross Margin (“GM”)-Weighted Magic Number A measurement to determine sales efficiency. The GM-Weighted Magic Number is determined by taking the Net Change in ARR for the Period (or New Logo & Expansion ARR in the period less Churn & Contraction) times the Gross Margin percentage, divided by total Sales & Marketing spend in the prior period. This metric attempts to quantify how much Sales & Marketing spend is required to generate ARR. ### Gross Margin & Gross Margin % Gross Margin is determined by taking Revenue less Cost of Goods Sold (“COGS” or “COS”). COGS or COS are the direct costs associated with delivering the product or service to existing customers (e.g. cost of Success, Support, hosting costs, etc.). Gross Margin % is calculated by taking Gross Margin and dividing by Revenue. ### Gross Revenue Retention A measurement that attempts to quantify how well a company retains its existing customers. Gross Revenue Retention (“GRR”) is calculated by taking Beginning Balance ARR less Churn/Contraction and dividing by Beginning Balance ARR. Because both New Logo ARR and Expansion ARR are excluded from this calculation, this value cannot exceed 100%. ### HW - Help Wanted [Help Wanted tickets](http://docs.mattermost.com/process/help-wanted.html), which are vetted changes to the source code open for community contributions. ### Improvement A beneficial change to code that is not fixing a bug. ### Iteration Iteration means being able to quickly improve on something by shipping a minimally viable change in how we do things. It's the opposite of the "wait, wait, wait, ship" method we call the [Windows Vista Approach](#windows-vista-approach). ### Latest “Latest Release”, a version of Mattermost which indicates the latest stable release. ### LHS The “Left-Hand Sidebar” in the Mattermost team site, used for navigation. ### Majority Regions Countries and regions outside the United States are referred to as "majority regions". We use this term for a few reasons, a) we use the word "majority" to remind everyone that the \~300M United States are only a tiny fraction (<5%) of the world's 7 billion people (many American companies refer to the U.S. as "domestic" and the rest of the world as "international" which is counter to the inclusive culture at Mattermost), b) we use "regions" instead of "countries" because there are political issues with some locations. For example, we should always refer to Taiwan as a "region" and not a "country" due to [geo-political issues](https://en.m.wikipedia.org/wiki/Taiwan#Political_and_legal_status). ### Mana An estimate of total energy, attention and effort required for a task - not a measure of amount of code to be changed or cumulative time needed for a change. A one-line change to code can cost more mana than a 100-line change due to risk and the need for documentation, testing, support, and all the other activities needed. Every code change added has an initial and on-going mana cost in technical debt, test case coverages, and supportability, which is taken into account in feature decisions. ### MBR The “Monthly Business Review”, where senior leadership team and department heads work with functional leaders to clear escalations, make key decisions & have concrete next steps for the next review period. ### MLT The “Mattermost Leadership Team”, senior leadership team and department heads working with the CEO in [MLT meetings and offsites](/operations/operations/mlt-cadence). ### MME A customer that is any Midmarket ("MM") or Enterprise ("E") organization, including public sector, with 2,500 employees or more, buying a Mattermost subscription that's not on a non-profit or educational discount. ### MOR Monthly Operating Review. A monthly review of operations from each department including a GNN and metrics. ### MQL A Marketing Qualified Lead refers to a prospect deemed to have a higher likelihood of becoming a paying customer based on their marketing activities, e.g. certain website activities (content downloads, etc), trial activations, demo or quote requests, and more. ### Net Dollar Retention A measurement that attempts to quantify the ability to both retain and grow our existing customers. Net Dollar Retention (“NDR” or Net Revenue Retention “NRR”) is calculated by taking Beginning Balance ARR + Expansion ARR - Churn/Contraction and dividing by Beginning Balance ARR. Because NDR includes the impact of Expansion ARR, this value can exceed 100%. NDR does not include the impact of New Logo ARR. This measurement is typically favored by investors. Both GRR and NDR are typically presented on an annual basis, using a static Beginning Balance at the beginning of the year. For annual presentation, this number represents total Churn/Contraction for the year divided by the beginning balance of ARR at the start of the year. For mid-year discussion and presentation, this number represents total Churn/Contraction for the period (e.g. first half) divided by the beginning balance of ARR at the start of the year. It is important to note that annual churn will naturally present lower than mid-year churn, using this method, due to the fact that the numerator is changing but the denominator is not. ### Nerfs and Buffs Nerfs and buffs are the framework for setting culture at Mattermost. A "nerf" is a downgraded experience as the result of a behavior. For example, if half of a team is traveling to a conference and holds a team meeting in a hotel room and the other half calls in remotely but they can't see everyone in the room and audio is low quality, then the team is "nerfing" their remote colleagues. The people in the hotel room are downgrading the experience of their remote colleagues. Under this framework, we want to discourage behavior that nerfs remote work, so if your team is holding in-person meeting with remote colleagues, please split up to take the call from separate areas so everyone can be seen and heard. A "buff" is an upgrade experience as the result of a behavior. If a remote team is meeting on a topic with a clear, concise written proposal requesting asynchronous feedback, people who share high-quality feedback asynchronously ahead of the meeting may have an out-sized influence on iterations of the document ahead of the meeting, compared to people who don't provide asynchronous feedback ahead of the meeting. Here we want to buff asynchronous communication by focusing review on asynchronous comments ahead of live comments. Culture is the set of behaviors that are nerfed and buffed. As a remote-first culture, we want to buff behavior that promotes asynchronous communication and remote work. We want to nerf behavior that creates unnecessary synchronous meetings. ### New Logo Sale A standard sale with a customer that has never previously purchased any kind of product or service from Mattermost, either directly or indirectly through a purchase by an affiliate on the customer’s behalf. A sale shall be deemed to be a New Logo Sale even if one of customer's affiliates is already a customer of Mattermost so long as (a) the entity making the purchase has never itself previously made a purchase or has had a purchase made on its behalf, and (b) the new sale is either a purchase of a license key to a new Self-Hosted server independent from other Mattermost installs or a purchase of a subscription to a new Cloud workspace independent from other Mattermost workspaces. ### Open Actions Term for publicly documenting information in a web-discoverable format (GitHub Issue, Staff Handbook entry, forum post, etc.) prior to sharing guidance to staff and community members. We prefer open actions to [dark actions](#dark-actions). ### PE Product Engineering function at Mattermost responsible for the software architecture, design and development of the product focused on delivering high quality, reliably built and maintained features, systems and improvements applicable to the broad range of ideal customers. ### PgM Program Management function at Mattermost responsible for leading and executing key cross-functional programs, working with cross-departmental stakeholders to increase operational efficiency and accelerate alignment towards customer and company objectives. ### PO Product Operations function at Mattermost responsible for infrastructure engineering and customer reliability engineering. ### PTO *Paid Time Off* is time away from work paid for by the company to staff, including holidays, vacations, and approved leaves of absence. See [PTO](/operations/workplace/people/working-at-mattermost/paid-time-off). ### Renewal Success Rate A comparison of the actual dollar value renewed compared to the total dollar value of contracts up for renewal in the period. This measurement attempts to quantify the “success rate” of renewals scheduled in the period, and cannot exceed 100%. Unlike GRR or NDR, this measurement excludes the impact of any multi-year contracts that are not up for renewal in the period. ### RHS The “Right-Hand Sidebar” in the Mattermost team site, used for navigation. ### SAL A Sales Accepted Lead refers to a prospect that a Sales team has spoken to either in-person (e.g. tradeshow, conference, dinner), or remotely (phone call, video call), and validated the prospect has a legitimate potential to convert to a paying customer. ### SBIR A Small Business Innovation Research (or SBIR) program funded by the U.S. government to accelerate technology innovation in partnership with small businesses. Funding takes the form of contracts or grants. The recipient projects must have the potential for commercialization and must meet specific U.S. government R\&D needs. The program includes Phase 1 SBIRs (concepts with no development work), Phase 2 SBIRs (development work to create a prototype with a potential for commercialization), as well as larger contracts via TACFI, STRATFI and more: ### Spinmint Spinmint refers to our first generation of automated infrastructure to spin up test servers to evaluate pull requests. The word "spin" comes from the original name of our company, "Spinpunch, Inc." (before we became ("Mattermost, Inc.") and the word "mint" as a short, unambiguous, easy-to-spell name referring to a [factory method pattern](https://en.wikipedia.org/wiki/Factory_method_pattern). ### SpinWick New test servers that use the cloud infrastructure and can be spun up on pull requests to test changes. The name is reference to first generation infrastructure, [spinmint](#spinmint), combined with an arbitrary reference to a movie that some people saw called “John Wick”. ### SOM Standard Operating Metrics are metrics tracked monthly by each department as indicators for operating health and status. ### TAM Technical Account Management function at Mattermost responsible for retaining & expanding customer revenue, including technical adoption & bottlenecks, technical onboarding, issue coordination and escalation. ### Tombstoned Replacing a webpage with a link to the new page created so that people using the original link can easily find the new page. [An example of tombstoned terms can be found at the bottom of this page](#tombstoned-terms). ### YouTweetInFace A reference to the major social media platforms: YouTube (“You”), Twitter (“Tweet”), LinkedIn (“In”), and Facebook (“Face”). The [YouTweetInFace channel](https://community.mattermost.com/private-core/channels/pre-tweet) is used to discuss social media posts before asking contributors and community to engage with the content. The name is a reminder that our tone and approach to social media needs to be thoughtful, memorable, and ideally bring a smile. ### Windows Vista Approach Instead of working iteratively a "Windows Vista approach" attempts to ship significant changes in a complex one-time effort, which seems like a good idea at the time but ends up causing delays, wasted effort, and numerous avoidable errors. This tempting, high risk approach is named after Microsoft’s “Windows Vista” operating system, one of its most famous examples. ### Mattermost Cloud Describes cloud infrastructure within AWS, where the Cloud Provisioning server, Mattermost Operator, databases, file storage, etc exist. ### Installation An installation is an instance of Mattermost, otherwise known as a Mattermost [Workspace](#Workspace). Internally, the term Installation generally implies it is hosted inside Mattermost Cloud. ### Workspace A workspace is an instance of Mattermost, otherwise known as an [Installation](#Installation). While it can be used interchangeably with "Installation", "Workspace" generally implies it is a self-hosted deployment. ### Cloud Server An ambiguous term that describes an [Installation](#Installation) (ie, Mattermost [Workspace](#Workspace)) which is hosted in Mattermost Cloud. ### Cloud installation An [Installation](#Installation), hosted in Mattermost Cloud, with the necessary configurations to represent a Mattermost Cloud SaaS workspace (ie, configs, license, connections to CWS, configurability restrictions, etc) like one created from ### Self-Hosted Installation An installation, hosted in Mattermost Cloud, with the necessary configurations present to represent a self-hosted workspace (ie, configs, license, configurability, etc). ## Tombstoned Terms The following is a list of terms no longer used with links to their definitions or notes on their deprecation. Tombstoned Terms use H3 headings on this page to distinguish them from active terms, which are H2 in heading formatting. #### Tomb-stoned Previously hyphenated, now not hyphenated, see [Tombstoned](#tombstoned). #### Vacation-ready A team and process that is ready for a key member to go on vacation, or spend time away from work. # Business model ## Vision Our vision is becoming the leading solution for developer collaboration through an integrated suite of open core tools that accelerate developer productivity, increase software service levels, and raise workplace satisfaction among technical teams. As the world moves more digital and remote, technical organizations face mounting challenges: stagnating productivity, increasing exposure to outages and service-level degradations, and declining workplace satisfaction leading to staffing churn and expanding talent gaps. We solve these issues for customers by developing and delivering an open, flexible, developer-focused collaboration suite competing against both point solutions (Slack, Asana/Trello/Notion, WebEx/Zoom/Loom, RunDeck/Transposit/Firehydrant, Confluence/GitHuge Pages) and general-purpose collaboration suites (Microsoft Teams/Office, G Suite). We deliver our solutions through an open core, product-led growth motion with freemium offerings that flow into usage and conversion from free-to-paid supported by Mattermost champions in customer accounts, frictionless self-serve purchase experience on both cloud and self-hosted instances, and both direct fulfillment and channel-based fulfillment depending on customer preferences and our ability to provide regional support. This motion is accelerated through our BDR and field sales motions with warm outbound into our freemium install base, plus cold outbound into named enterprise accounts driving awareness of the ROI of Mattermost solutions from like customers. ## Market Analysts project that in 2022, over $4.5 trillion USD will be spent on IT. What portion of that investment turns into productivity and results depends entirely on how well teams of software builders and operators can effectively collaborate. Mattermost competes in a $15B market for "developer collaboration", a segment of the broader general collaboration market focused on accelerating developer productivity through agile workflows across application development, digital operations and security operations. Our focus is serving a market of 30 million developers with an integrated, open core collaboration suite across workplace messaging, project management, incident management, real time communication, and documentation available both in cloud and as a self-hosted component of an organization's digital infrastructure. Many of these organizations are facing three critical challenges: **Flat or declining developer productivity in post-remote environments.** While many technical organizations accelerated productivity in the initial move to remote work--decreasing commute time, onsite logistics, and interruptions--many post-remote environments now suffer from gaps in clarity and alignment that in-office environments provided in the past. The context created by in-person meetings, hallway conversations, war rooms--and even by physical whiteboards and post-it notes--continues to degrade in many organizations. Digital substitutes across meeting organization, note taking, workplace messaging, incident response, and project management have exploded as point solutions. They served as life rafts during the pandemic, but the misfit of teams, tools and workflows is now becoming an overwhelming tax--copy and pasting, inconsistent formatting, unclear access controls, redundancy of information, and the breakage of flow. **Increasing complexity, vendor lock-in and outage exposure.** In many organizations the acceleration to cloud has dramatically increased vendor-dependency, data lock-in, and exposure to the business disruption. In some cases, there is risk of both a company’s technical infrastructure and online collaboration tools going down at the same time when they are outsourced to the same vendor, or share dependencies--especially cloud dependencies. These risks may be dramatically heightened with remote work if incident response teams don’t have either a secure physical location to work on mitigations, or online collaboration tools independent of the underlying outage. Moreover, as cloud vendors control more and more of their customer’s data and operations, businesses have fewer options to hold vendors accountable. **Gaps in workplace satisfaction for technical talent.** Acceleration in remote hiring coupled with a surge in global demand has made staffing developer organizations an unprecedented challenge. Workplace satisfaction is now more important than ever as a leading indicator of organizational success. Satisfaction includes both conceptual factors, such as opportunities for impact, connection and growth, and concrete factors such as the technologies and tools teams get to operate. Winning on workplace satisfaction in conceptual and concrete factors is a leading indicator of meeting the capacity needs of digital operations organizations, which is a leading factor to market relevance. ## Business model Mattermost uses a buyer-based open core business model to deliver a high trust, self-managed messaging platform for developers and high security end users. We develop a portfolio of offerings at different price points (including free/open source) that align to the needs and budgets of different buyers. ### Mattermost Free / open source The free/open source version of Mattermost is built for **developers** as an innovative, flexible, high trust collaboration platform that accelerates the productivity and agile workflows of a tight-knit team, and includes the following capabilities: #### Channels (Workplace Messaging) - An open source alternative to Slack, with [Slack-compatible keyboard shortcuts](https://docs.mattermost.com/channels/keyboard-shortcuts-for-channels.html) and [Slack-compatible webhooks](https://docs.mattermost.com/developer/webhooks-incoming.html#slack-compatibility), along with a layered extensibility model ranging from [plug-ins to custom applications](https://mattermost.com/integrations-overview/). #### Boards (Work Management) - An open source alternative to Trello, Notion, Asana, Jira and Todoist, deeply integrated with Channels, with the ability to [import from other systems](https://docs.mattermost.com/guides/boards.html), to [use and create custom templates and workflows](https://docs.mattermost.com/boards/templates.html), and to integrate deeply with the rest of the Mattermost collaboration platform. #### Playbooks (Incident Management) - An open source alternative to Rundeck, Firehydrant, Transposit, and other incident management solutions for [standardizing](https://docs.mattermost.com/playbooks/setting-up-playbooks.html) and [running incident management escalations](https://docs.mattermost.com/playbooks/running-playbooks.html), remediations, and [timeline-based retrospectives](https://docs.mattermost.com/playbooks/refining-and-improving.html) deeply integrated with [access controls](https://docs.mattermost.com/playbooks/playbook-permissions.html) and real-time workplace messaging and [notification experiences](https://docs.mattermost.com/playbooks/notifications-and-updates.html) on the Mattermost platform. For our self-hosting community, we have an open source **Mattermost Team Edition** available as a Linux Binary under MIT license that [deploys](https://docs.mattermost.com/guides/deployment.html#upgrade-mattermost) with MySQL or PostgreSQL and optionally a web-proxy such as NGNIX. There's a single-node local machine "Preview" mode you can use to try out the features using Docker, along with a streamlined omnibus version you can use to get a production system up and running quickly on an Ubuntu-compatible Linux distribution. For our cloud community, our "Free" offering is currently a hosted version of the open source Mattermost Team Edition available on demand from Mattermost.com with unlimited users and a flat rate hosting cost of $149/year. While the software is free, we currently do need to pay for hosting costs in this cloud offering, however we also have plans to provide a fully free offering in future subsidized by revenues from paid versions of Mattermost through our open core model. ### Mattermost Professional Our entry-level paid version, Mattermost Professional, is built for **team managers** - commonly managers of managers - who need additional controls and workflows specific to multi-team coordination. This version can be purchased via self-service, through resellers, or - for accounts over a certain size in certain territories - transacted through our sales team. ### Mattermost Enterprise As usage of Mattermost grows, we have a high scale edition, Mattermost Enterprise, providing enterprise compliance features and high scale support, including self-managed, multi-node, high availability configurations. ## Customer journey Our customer journey starts developers and IT admins seeking better collaboration tools for themselves and their teams. They may have used Mattermost personally, or in a previous role, or heard about the product through word of mouth, review sites, or discovered Mattermost through web search. They discover, download, and install Mattermost using a [deployment guide](https://docs.mattermost.com/guides/deployment.html). Over time, as the number of users grows beyond a single team, typically an IT administrator will be interested in the user management and access control features in Mattermost Professional, and be interested in getting a 30-day trial version license key to [upgrade to Mattermost E0 and activate the trial key](https://docs.mattermost.com/install/enterprise-install-upgrade.html?highlight=trial%20key). A subscription license to [Mattermost Professional](https://mattermost.com/pricing/) can be purchased online through our self-serve process, through a channel partner, or by [contacting a member of the Mattermost sales team](https://mattermost.com/contact-sales/) assigned to the territory. As the deployment of Mattermost grows within an organization, typically past 250 or 500 users, the customer's procurement organization may be interested in advanced features and customization available in our [Mattermost Enterprise](https://mattermost.com/pricing/) offering. ## Self-served motions For Mattermost Professional, we have self-serve options to purchasing subscription licenses by credit card. ## Sales-served motions We're focused on a number of sales motions to turn leads and prospects into customers. #### Champion-led inbound direct Prospect comes to us to buy. In this motion, developers or a System Admin deploys the open source or cloud free version of Mattermost, adopts its usage, and realizes value for a small group (\~20 for cloud and 5-25 for self-hosted). When they want to scale usage beyond 25 and need administrative features like user management, SAML SSO, and the champion contacts IT and procurement to purchase. IT or procurement contacts Mattermost and is directed to the sales team to discuss a purchase, ask for volume discounting, answer security, compliance or technical questions, and/or negotiate MSA terms on their way to a purchase. In the meeting, Mattermost AE probes to get a detailed understanding of the customer’s situation and needs using a MEDPPICC framework, and works with the prospect’s IT, procurement, champion, economic buyer and other stakeholders to help the customer envision their success with Mattermost, complete an initial purchase, and set up the account for success in the post-purchase journey. Key Input: This process often begins with a **Marketing Qualified Lead** ("MQL") of a certain type (pricing quotation or "Contact Us" request) indicating a "hand held high" level of interest in a purchase, and a work email which can be used to determine the organization from which the MQL originates and can be used to identify the correct member of the sales team to lead and execute on our process based on territory and industry assignments. This process can also begin with a **Product Qualified Lead** ("PQL") which is a type of MQL (has work email and can be mapped to a sales person) that has an indication of product adoption and ideally trial activation. In-product trial requests are an example of PQLs that can be used as a starting point for sales to accelerate this motion. #### Champion-led inbound channel Similar to Champion-Led Inbound Direct journey except prospect buys through a channel partner rather than working with our sales team directly. In some cases we don’t have MEDPPICC information nor relationships with the key stakeholders at the accounts, and need to build up that context in order to properly connect with the account. Key input: The inputs for this motion are the same as for "Champion-Led Inbound Direct" (above) with the exception that PQLs and MQLs may be shared by our sales team with a channel partner, who may have relationships (e.g. vendor agreement with a prospect) or capabilities (e.g. speaking languages that the Mattermost field doesn't) that we don't have. #### Sales-led warm outbound Identifying organizations where the free version of Mattermost is used, contacting people who didn’t reach out to us, and selling our way to close a new customer. In this journey, the Mattermost sales team, either BDR or AE depending on region and segment, identifies an account where someone seems to be running the open source version of Mattermost (through webchat, contact requests, E0 download data, cloud trials, enterprise trials, noticing “Mattermost” skillsets in LinkedIn profiles, etc.), identifies potential contacts (using ZoomInfo, LeadIQ/LinkedIn Sales Navigator, Demandbase and other resources), and outbounds (via email, LinkedIn, and social media) to different personas in the target organization to eventually connect with Mattermost champions, and for the AE to share the vision, benefits, use cases, ROI, and case studies of our commercial offerings, along with technical pre-sales support, and guide the prospect into becoming a customer. Key input: The minimum input is a Marketing Qualified Lead ("MQL") with a work email (so organization can be identified and the right sales person assigned), indications of early interest in Mattermost (e.g. newsletter sign-up, unactivated trial request, etc.), and product usage in some form (after MQL identifies the organization, sales can review public information like LinkedIn bios, blog posts, social shares from company employees, open source contributions, etc.). In an outbound motion the intent is to reach multiple people in an organization, not just the person taking an MQL-creating action, so that marketing and sales resources can be applied to accelerating early interest into envision and unlocking value into purchase and expansion decisions. #### Sales-led cold outbound Selling into organizations that aren’t known to be using Mattermost but who are similar to existing Mattermost customers and could potentially benefit from our offerings, and potentially showed early interest. This starts with BDRs and AEs focusing on a list of organizations - ”Named accounts” - that aren’t known to use Mattermost, but are similar to existing customers who benefit from Mattermost, finding and contacting the right people at the organization to share about the ROI and benefits of Mattermost solutions, getting meetings, and getting agreement to run a trial to prove that Mattermost would solve the issues the prospect is facing, running the trial with technical pre-sales support, and closing customers who can understand the vision for how Mattermost solves their urgent needs, with a proof of value in the trial to validate the purchase they are making. Key input: Cold outbound can be started with just a list of "Named Accounts" that we believe would have similar needs and buying patterns as existing Mattermost customers. Ideally there are also MQLs similar to "Sales-Led Warm Outbound" though without the requirement of free usage to start this process. #### Channel-led outbound In some countries/regions, channel partners may execute Sales-Led outbound motions in partnership with our sales teams. This motion can be particularly additive in countries/regions and organizations with languages and culture that can’t yet be supported with our internal sales organization, or to reach the existing customer base of a channel partner who are likely to have similar needs to existing Mattermost customers and likely to buy (e.g. Carahsoft/FedResults). Key input: The key input for a channel partner is training, enablement and on-going support on how to idenitify and call on high potential existing customers to consider, evaluate and purchase Mattermost offerings. This motion is not yet broadly used, as the majority of channel activity is currently from "Champion-Led Inbound Channel" (described above). ### Frequently asked questions #### What keeps other companies from using your open source software to create offerings that compete with your paid products? We use the acronym "TACTICAL" to summarize the approach to maintaining differentiation of the paid version of our offerings to offerings a competitor may create from our open source code base: * **Test infrastructure:** We use [SaaS QA](https://www.rainforestqa.com/) which isn't included in the open source version. * **Alignment:** Developer features are free. Paid features are for managers and IT pros, who are less likely to spend time and effort forking and maintaining an open source project vs. deploying budgets to purchase paid features. * **Core committers:** We work with an active community of [core committers](https://handbook.mattermost.com/company/about-mattermost/list-of-terms#core-committers) to keep the project and business in sync. * **Threat intelligence:** Mattermost's [responsible disclosure policy](https://mattermost.com/security-vulnerability-report) means forks will lag in threat intelligence. * **Innovation:** Regular ship cycles and high velocity innovation rapidly lower the value of forks. * **Compatibility:** Only genuine versions upgrade smoothly to new releases and security patches. * **Architecture:** Modular architecture makes the need to fork rare. * **Licensing:** Mattermost's trademark is registered internationally, forking requires renaming. # Mindsets Mindsets are “tool sets for the mind” that help us find blindspots and increase performance in specific situations. They’re a reflection of our shared learnings and culture in the Mattermost community and at Mattermost Inc. To make the most out of mindsets, remember: * **Mindsets are tools:** Use common sense to find the right mindset for your situation. Avoid using ones that don’t fit. * **Mindsets are temporary:** Try on a mindset the way you’d try a tool. You can always put it down if it doesn’t work. * **Mindsets are not laws:** Mindsets are situation-specific, not universal. Don’t use them to debate. When you read about great leaders, they share mindsets relevant to success in their specific situations, which differ from their peers. Remember that “advice is personal experience generalized” so be mindful about what you apply. In this context, here are mindsets for Mattermost: ## Learn, Master, Teach **Learn** a new topic quickly, develop **mastery** (be the smartest person at the team/company/community on the topic), then **teach** it to someone who will start the cycle over. The best teachers can speed colleagues to surpass them. This mindset helps us constantly grow and rotate into new roles, while preventing single-points of failure where only one person is qualified for a certain task. ## Slow is Smooth, Smooth is Fast Rushing to get something done can create confusion, errors, and/or (paradoxically) delays. When you feel rushed, consider slowing down and taking a moment to ask: What would it look like for this project to be running smoothly? If you're running a collaborative project, consider: 1. Are the people I'm working with clear on the intent of this project or workflow? 2. Is everyone clear on who needs to do what? 3. Are we aligned on the measures that signal if our work is a success? Getting to a "Yes" on these three questions can smooth out your process, and move things faster. ## Boring Solutions Use the simplest and most boring solution to solve problems. The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology or methodology just to make your work more fun; using established and proven tech and processes that best match our needs to ensure a more stable and more familiar experience for you and other contributors. When facing a high impact problem without a simple and obvious solution, focus your time on: * Understanding the problem you're solving. * Understanding how others have solved the same problem in an enduring way. * What vital changes, if any, are needed to apply a proven solution that works. **More:** Read GitLab's boring solutions mindset and Dan McKinley's blog post on [choosing boring technology](https://mcfunley.com/choose-boring-technology). ## Emotion, Assumption, and Priority Consider when rational people disagree, the cause often comes from one of three areas: emotion, assumption, and priority. Understanding the underlying difference in thinking can help us get to agreement faster: 1. **Emotion:** Is there a strong emotion biasing the discussion? Talking through that emotion can often solve an issue. It’s okay to have emotions. We're humans, not robots. 2. **Assumption:** People may have different underlying **assumptions** (including definitions). Try to understand each other’s assumptions and get to agreement or facts when you can. 3. **Priorities:** Finally, people can have different **priorities**. When everyone’s priorities are shared and understood it’s easier to find solutions that satisfy everyone’s criteria. While the emotions, assumptions, priority mindset won’t work for everyone in every case, it’s helped resolve complex decisions in our company’s history. ## Likes and Wishes An easy way to check in with team members about how things are going. * What do you *like* about how things are going? * What do you *wish* we might change? Use these one-on-one or in a group as a way to open conversations about what to keep and what to change in how we do things. ## Drafts at 1%, 50%, 99% Being clear on expectations when asking for someone’s review can help speed and smooth the process. In this mindset, there are three types of review: * **1% Draft:** Completely open to ideas and changes in direction. Rework is inexpensive. * **50% Draft:** Half complete work. There is structure, but also a lot of room for change. Some rework is inexpensive, some is expensive. * **99% Draft:** Nearly completed work. Rework at this point is very expensive. ## Shoulder Check When a new owner takes over a process or a project from a previous owner, there are a finite number of “blindspots” of which the original owner is aware and the new owner will need to understand. Using the analogy of changing lanes while driving a vehicle and learning to do a “shoulder check” for information that is not visible from standard controls, we have a process for the new owner and previous owner to jointly review processes until the transfer is complete. This process is similar to [Mini-boss, End-boss](#mini-boss-end-boss), except that the mini-boss is also the new owner of a process, and not only a reviewer. Shoulder checks should be requested by new owners to avoid “crashing”: * Making changes to systems that break existing processes may lose data and hurt the productivity of others downstream without notice and without a replacement system in place (behavior known as [“Dead Tarzan”](#dead-tarzan)). * Repeatedly investing in mis-prioritized projects due to a misunderstanding of requirements from project stakeholders and insufficient confirmation of intended outcomes. Even when not crashing, as part of our [Self Awareness leadership principle](https://handbook.mattermost.com/company/about-mattermost/pages/-LozYevyIGsEFVKeOLPS#leadership-principles.md), top team members will constantly be seeking feedback and review from people around the company. ## Brown M\&Ms A “brown M\&M” is a mistake that could either signal dangerous oversights in the execution of a project, or be a completely innocuous and unimportant error. When a brown M\&M is found, aim to rule out a dangerous error as quickly as possible. Do fast drilldowns and systematic checks to see if more brown M\&Ms are found, and if so, an entire project may need to be reviewed. Examples of brown M\&Ms may include: * Significant mistakes in process, consistency or documentation suggesting lack of review or lack of understanding of the pre-existing system. * Ambiguous definitions that would make completion of a procedure difficult or unpredictable. The name "brown M\&M" comes from a safety technique used by the American music band Van Halen, who had to set up large, complex concert stages in third tier cities, where few local workers had experience with the safety standards vital to construction. In the [contract rider](https://en.wikipedia.org/wiki/Van_Halen#Contract_riders) with each venue, Van Halen required a bowl of M\&M candies with all brown M\&Ms removed. Failure to provide the bowl was grounds for Van Halen’s stage crew to inspect all of the local vendor’s work for safety issues, because it meant the vendor had not paid attention to detail, and safety could be at risk. ## Correct Minimums: Medic, Field Surgeon, Plastic Surgeon When making project investment decisions, we optimize for high impact in the context of customer obsession, empowered by ownership, while being constrained by “be proud of what you build”. The failure case is over-investing in processes and infrastructure, stealing mana from higher priority work, reducing speed and agility for the company and unnecessarily increasing cost and bureaucracy. The objective of optimization is to invest at minimal levels for efficiency and safety while maximizing impact. In making these trade-offs, consider the following mindsets: * **Correct Minimum 1: Medic** > Safely fix something that is important, broken, and dangerous as fast as possible. Speed is critical - don't worry about “leaving a scar” on our architecture or business process, just own it and get it done. Solve the problem, **do not overbuild**. > > *Example:* Something incorrect on our public website with more than 100 page views a month should be fixed immediately and not delayed to be done with a longer-term project, such as a website redesign. If the staging server cannot be pushed, this means manually fixing production and duplicating that change on staging, rather than trying to fix staging. * **Correct Minimum 2: Field Surgeon** > Triage tasks that are important and broken but not dangerous, and fix the most important things with a minimum time and cost. Scarring should be a low-priority consideration – it's fine to leave scars and it's fine to spend a little energy to avoid big ones. Solve the problem for the next stage of growth, but don’t solve it in two to three stages ahead. > > *Example:* In Mattermost, spend 2 mana to enable automated messages over 4000 characters to be broken into multiple posts instead of being rejected, which is a problem every developer hits when they attempt to output log information via `curl` commands. * **Correct Minimum 3: Plastic Surgeon** > Fix and optimize critical, high volume flows in our customer experience and product with heavy investment if needed to make high impact changes. Scars can be avoided and removed to produce a high impact result. > > *Example:* Click-tracking traffic on about.mattermost.com and optimizing flows to direct visitors to learn about the product and downloading it is a flow that should be continually optimized. ## Mini-boss, End-boss After completing the initial draft of a project, there may often be more than one reviewer to approve changes. This may be for different disciplines to review the work (for example, both development and design teams reviewing code changes to the user experience) and it may also be for reviewers with different levels of experience to share feedback. When reviewing significant user interface changes, code changes, responses to community or customers, or changes to systems or marketing material changes, it is ideal to have at least two reviewers: * **Mini-boss:** Reviewer less experienced in domain or Mattermost standards for the first review. * **End-boss:** Reviewer more experienced in domain or Mattermost standards for the final review for the discipline (e.g. development, design, documentation, etc.). This system has several benefits: 1. The Mini-boss provides feedback on the most obvious issues, allowing the End-boss to focus on nuanced issues the Mini-boss didn’t find. 2. The Mini-boss learns from the End-boss feedback, understanding what was missed, and becoming a better reviewer. 3. Eventually the Mini-boss will be as skilled at reviewing as the End-boss, who will have nothing further to add after the Mini-boss review. At this point, the Mini-boss becomes an End-boss, ready to train a new Mini-boss. The naming of this term comes from video games, where a person submitting material for review must pass a “mini-boss” challenge before a “end-boss” challenge for different disciplines. ## Savor Surprises When we make important decisions quickly it's important to run at least a lightweight analysis to identify blindspots that could put success at risk. "Savoring surprises" means discussing unexpected findings from an analysis and understanding root cause in order to de-risk our original plan and/or find new opportunities. Example: In our early days, just months after launching our first commercial product Mattermost had a product roadmap for security and DevOps features that was vetted by customer roadmap reviews. We "savored the surprise" that custom emojis (which we assumed was a vanity feature to be cut) was highly important to support legacy processes that used them to communicate different outcomes of an automated process, like a build break. The surprise made our roadmap more valuable and effective. A good analysis will result in surprises uncovering blindspots. An analysis that has no surprises is a surprise in itself and the blindspot should be determined. Did the analysis use the right data and methodology? Was it free from the unconscious or conscious bias of someone influential? **More:** Watch Scott Cook's talk on [savoring surprises](https://vimeo.com/254376327). ## RAPID for Complex Projects When practical, projects and decision-making should be run at the lowest possible level of the organization, by people who are closest to the facts and data. When a project is complex and involves many stakeholders, a different approach may be needed. We use a RAPID framework for complex, multi-stakeholder projects where clarity in the roles of stakeholders is vital. RAPID is an acronym for the five different roles a stakeholder might be asked to take on in a complex project: Recommend, Agree, Perform, Input, Decide. Each stakeholder can take on one or more roles: | Letter | Role | Responsibility | | ------ | --------- | ---------------------------------------------------------------------------------------------------------- | | R | Recommend | Recommend a decision or action | | A | Agree | Formally agree with decision. Views - especially Obstacles - should be documented in final proposal shared | | P | Perform | Accountable for executing the decision once made | | I | Input | Provide input to a recommendation. Views may or may not be included in final proposal | | D | Decide | Make the decision and commit the organization to action | **More:** RAPID framework from [Bain Consulting](https://www.bain.com/insights/rapid-tool-to-clarify-decision-accountability/). # "How to" guides for staff 1% Complete # How to set up a 1-1 channel ## Getting started 1. **Create a Google Doc** and name the file `[INITIALS_OF_FIRST_PERSON]-[INITIALS_OF_SECOND_PERSON] 1-1`. * For example, if Bob Adrian Jones is meeting with Jen Tai Yin Lee, the title of the file would be `BAJ-JTL 1-1.` * Use three letter initials when possible since there may be people with the same initials. 2. **Share the file** with the other person, using the **Share** option in the Google Doc. 3. Create a Direct Message channel in Mattermost and add the other person. 4. **Add a link to the Google Doc** at the top of the Direct Message channel by editing the header of the channel. Choose **Edit Header** and paste the link. 5. **Use the file for 1-1s** to post material in advance and to write notes of your discussions. # How to update the handbook On this page * [Who can update the Handbook?](#who-can-update-the-handbook) * [How do I know what to update?](#how-do-i-know-what-to-update) * [Hints and tips](#hints-and-tips) * [Your first Mattermost contribution](#your-first-mattermost-contribution) * [Edit an existing page](#edit-an-existing-page) * [Create a new page](#create-a-new-page) * [Create a new section](#create-a-new-section) * [Frequently asked questions](#frequently-asked-questions) * [Training video](#training-video) * [Official Handbook reviewers](#official-handbook-reviewers) ## Who can update the Handbook? Contributions from everyone are welcome, including staff members and community members. You don't have to work at Mattermost to submit an update or fix something that's caught your eye. ## How do I know what to update? "Update the Handbook" is a term we use regularly at Mattermost but it's not always obvious exactly what to update or how. Here are some examples of what a Handbook update could be: * Updating your team page with new team members and AORs. * Adding a new page to describe a new process. * Updating existing content to accommodate a change in process, policy, or requirement. * Archiving old content that should be preserved for reference. Updating the Handbook can be as easy as fixing a typo, or as complex as reorganizing an entire section. The key is to update it regularly, so that updates are less daunting and time-consuming. ## Hints and tips The Handbook is a public-facing body of work and although it's a constantly-evolving work-in-progress, we still need to ensure our content is accurate, easy to read, and clear. * **Be concise:** Say what's essential, not more. * **Get feedback:** Have someone from your target audience read your draft to share feedback so you can [savor surprises](/company/about-mattermost/mindsets#savor-surprises). * **Don't aim for perfection:** Our goal is regular iteration, so your content doesn't have to be perfect before it's published. It will be reviewed by an editor prior to publication so any major errors will be addressed then. ## Your first Mattermost contribution If this is your first time contributing to Mattermost, first read the [Mattermost Contributor Agreement](https://mattermost.com/mattermost-contributor-agreement/) and sign it (at the bottom of the page), 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). Please ensure the **GitHub username** field matches your GitHub username exactly, including capitalization. If you're not already a member of the `mattermost` GitHub organization, you can request access through the [Mattermost IT helpdesk](https://helpdesk.mattermost.com/support/home). This will allow you to edit the files in the Handbook repo without having to create a fork for your changes. Now you're ready to get started. ## Edit an existing page When you edit an existing page, it's usually to add content, remove content, or edit existing content. In general it's easiest if pages are edited directly, although you're also welcome to [edit files directly from the repo](#edit-a-file-in-the-repo) if that's easier for you. All editing is done in GitHub, as that's where the Handbook files are stored. Pages are formatted using Markdown - if you're not familiar with Markdown, you can take a look at [this page](https://docs.mattermost.com/messaging/formatting-text.html) for tips. Don't worry too much about formatting - it can always be adjusted during the review process. Once a page is edited and you're happy with the changes, it's submitted as a pull request which is then reviewed. If there's any feedback or comments have been made, you'll be alerted. If suggestions have been made, you can choose to commit them (add them to your content) or you can ask the reviewer for more information before doing that. When the PR is approved, it'll be merged and published. If you have more changes to make, you can simply repeat the process. ### Edit a page directly This is probably the quickest way to make changes, as it doesn't require you to find the file in the repo first. 1. Login to your Mattermost GitHub account 2. Open the Handbook and navigate to the page you want to edit. 3. Underneath the blue banner, locate three dots next to the page title at the top of the page. Click on the three dots and choose **Edit on GitHub**. This action will open the page in GitHub. 4. In GitHub select the pencil icon in the navigation bar (above the page header) called **Edit this file** to open the editable Markdown-format page. If you see **Edit this file in your fork of this project** the process is the same, it just means you're not part of the Mattermost organization and are working in a forked repo. * To learn more about Markdown formatting, see the [Mattermost guide for formatting text](https://docs.mattermost.com/messaging/formatting-text.html), or [the guide from GitBook](https://docs.gitbook.com/editing-content/markdown). 5. Make your edits. When you're ready to submit your changes, commit your changes to start a pull request. 6. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made. 7. The default setting is **Create a new branch for this commit and start a pull request**. In the field below that, you can customize the branch name - you can also leave it as default. 8. Select **Propose changes**. 9. On the next page, you can scroll down to compare changes with the original document to double-check your changes. 10. If you're happy with them confirm that the title and description are correct, then select **Create pull request**. Once a pull request has been submitted, a core committer with write-access assigns relevant reviewers and labels to kick off the review process. The review process includes aligning the content with the Style Guide, validating the changes, and tagging any other relevant committers. Multiple committers may comment on your pull request and provide edits or suggestions which you can commit directly. You can also add line comments. Take a look at [Commenting on pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request) for more details. Once the review process is complete, the change is merged and pushed live. We recommend that you review your changes at for potential formatting errors. ### Edit a file in the repo This option works best if you know where the file is located in the repo. 1. Open the [Handbook repo](https://github.com/mattermost/mattermost-handbook). 2. Navigate through the directories to the file you want to edit. 3. Once you've found the file, select **Edit this file** in the top corner. If you see **Edit this file in your fork of this project** the process is the same, it just means you're not part of the Mattermost organization and are working in a forked repo. * To learn more about Markdown formatting, see the [Mattermost guide for formatting text](https://docs.mattermost.com/messaging/formatting-text.html), or [the guide from GitBook](https://docs.gitbook.com/editing-content/markdown). 4. Make your edits. When you're ready to submit your changes, commit your changes to start a pull request. 5. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made. 6. The default setting is **Create a new branch for this commit and start a pull request**. In the field below that, you can customize the branch name - you can also leave it as default. 7. Select **Propose changes**. 8. On the next page, you can scroll down to compare changes with the original document to double-check your changes. 9. If you're happy with them confirm that the title and description are correct, then select **Create pull request**. ## Create a new page Creating new content can take the form of a new page, or [an entirely new section](https://github.com/mattermost/mattermost-handbook/tree/0.2.1/company/how-to-guides-for-staff/create-a-new-section/README.md). Some things to keep in mind are naming conventions and that the Table of Contents entry is made manually in the `SUMMARY.md` file. 1. Open the [Handbook repo](https://github.com/mattermost/mattermost-handbook). 2. Navigate through the directories until you reach the section where you'd like to add your new content. 3. Select **Add file > Create new file**. When you create a new page in the Handbook ensure that: * The page name is all lowercase * There are hyphens instead of spaces between the words. * New page names end with `.md`. 4. Write your content as needed. 5. When you're ready to submit your changes, commit your changes to start a pull request. 6. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made. 7. The default setting is **Create a new branch for this commit and start a pull request**. In the field below that, you can customize the branch name - you can also leave it as default. 8. Select **Propose changes**. 9. On the next page, you can scroll down to compare changes with the original document to double-check your changes. 10. If you're happy with them confirm that the title and description are correct, then select **Create pull request**. 11. Add your new page to the [Handbook table of contents](https://github.com/mattermost/mattermost-handbook/blob/0.2.1/SUMMARY.md). If you plan to reorder the table of contents as part of your change, please tag @jason.blais or @carrie.warner in Mattermost (@jasonblais or @cwarnermm in GitHub) as a redirect may need to be set up to accommodate the change. [Watch a two-minute training video on how to create a new page in GitHub](https://drive.google.com/file/d/12JUpEdP3uU_bPxDVWdlEZv65v1tttlQn/view?usp=sharing). ## Create a new section If you want to create nested content, you can create folders. You cannot create an empty folder and then add files to that folder, but rather creation of a folder must happen together with adding of at least a single file. On GitHub you can do it this way: 1. Navigate to the folder within which you're creating your new folder. 2. Select **Add file > Create new file**. 3. Enter the new folder's name in the text field and add `/` at the end. 4. In the next text box, enter the name of the new page, ending with `.md`. 5. When you're ready to submit your changes, commit your changes to start a pull request. 6. Add a descriptive title if the default title isn't sufficient. Add an extended description to summarize the changes you've made. 7. The default setting is **Create a new branch for this commit and start a pull request**. In the field below that, you can customize the branch name - you can also leave it as default. 8. Select **Propose changes**. 9. On the next page, you can scroll down to compare changes with the original document to double-check your changes. 10. If you're happy with them confirm that the title and description are correct, then select **Create pull request**. 11. Add your new section to the [Handbook table of contents](https://github.com/mattermost/mattermost-handbook/blob/0.2.1/SUMMARY.md). If you plan to reorder the table of contents as part of your change, please tag @jason.blais or @carrie.warner in Mattermost (@jasonblais or @cwarnermm in GitHub) as a redirect may need to be set up to accommodate the change. ## Frequently asked questions ### How do I format a page? All Handbook pages are written in Markdown, which is also the language used to post messages in Mattermost. To learn more about Markdown formatting, see the [Mattermost guide for formatting text](https://docs.mattermost.com/messaging/formatting-text.html), or [the guide from GitBook](https://docs.gitbook.com/editing-content/markdown). ### How do I update the left-hand navigation? You can update the left-hand navigation in the [SUMMARY.md](https://github.com/mattermost/mattermost-handbook/blob/0.2.1/SUMMARY.md) file. **Important note:** GitBook dynamically changes the URL based on the location in the table of contents. This means that when a page changes its location, the previous link results in a 'page not found' error. There is a redirect file that we use to prevent this in the `gitbook.yaml` file. Please mention @jason.blais or @carrie.warner in Mattermost (@jasonblais or @cwarnermm in GitHub) for assistance if needed. ### How do I add an image to the documentation? Follow these two steps: * Go to the [/assets](https://github.com/mattermost/mattermost-handbook/tree/0.2.1/.gitbook/assets/README.md) folder, select **Upload files**, then upload the image files you want to add to your documentation. Make sure to have a clear name for each file you upload. * Next, go to the section you want to add an image to and include the following Markdown formatting: ``` ![](../../../.gitbook/assets/release-timeline-jan2020.png) ``` ### Can I convert a Google Doc to Markdown? Yes! Sometimes it's easier to draft content for the Handbook in a Google Doc. An open-source Google Drive add-on called [Docs to Markdown](https://workspace.google.com/marketplace/app/docs_to_markdown/700168918607) can convert the content to Markdown. See the add-on [documentation](https://github.com/evbacher/gd2md-html/wiki) for details on installing and using this tool. Once the add-on is installed, there are a number of conversion settings you can configure. Selecting all but the **Use HTML headings/IDs** option is recommended. * To see the embedded errors and warnings, disable the **Use reckless mode** option. * To see all conversion details, disable the **Suppress info comment** option. The resulting Markdown code isn't perfect, but it's an excellent initial step towards preparing a PR for the Mattermost Handbook. Review the following areas of converted code: * Embedded images must be saved out as files, added to appropriate image folders, and links need to be added to point to correct locations. * If the doc contains screenshots or other image assets, right-click on the embedded image in the Google Doc, then select **Save to Keep**. * In the right pane, right-click on the image in the **Keep list**, then select **Save Image As**. Rename the image file as needed to match the Markdown code. * Images need to live in the `.gitbook/assets` folder and must use a relative link in the source file. * Numbered lists and nested lists likely need corrections. * Many lines end in a `/` which need to be removed. * ALT tags are added as `alt_text` for all images. Update the ALT tag to be more descriptive, or remove it altogether. ## Training video [Watch a training video on how to update the handbook in GitHub](https://drive.google.com/file/d/1AOI8H-oe2u1JW6oOA4nPPTSbGnK3Xuq1/view?usp=sharing). ## Official Handbook reviewers Below is a list of approved reviewers. 1. @cwarnermm: Reviews major changes to handbook.mattermost.com, such as updates to the Table of Contents (SUMMARY.md). 2. @cwarnermm: Editor reviews of all submitted PRs for correct grammar and consistent style. 3. @kevinfayle: Signs off on changes to [marketing ops and analytics](https://handbook.mattermost.com/operations/messaging-and-math/demand-generation-reporting). 4. @aedott: Signs off on changes to [messaging and math](https://handbook.mattermost.com/operations/messaging-and-math). 5. @it33: Signs off on changes to [finance](https://handbook.mattermost.com/operations/finance). 6. @natalie-hub: Signs off on changes to [workplace](https://handbook.mattermost.com/operations/workplace). 7. @it33: Signs off on changes to signing authority ([example](https://github.com/mattermost/mattermost-handbook/pull/60)). 8. @dschalla: Signs off on changes to [Security](https://handbook.mattermost.com/operations/security). Each PR should be reviewed by at least one approved reviewer. A build check requiring at least one approved review prior to a merge is planned, similar to other Mattermost repositories. Below is a list of permissions handbook contributors have access to: 1. @jasonblais, @amyblais, @cwarnermm: Write permissions to the repository. 2. Staff contributors: Submit changes to `handbook.mattermost.com` using PRs. May have access to request reviews, add labels, submit PR reviews, and be requested as reviewers. 3. Non-staff contributors: Submit changes to `handbook.mattermost.com` using PRs. Do not have access to request reviews, add labels. Can submit PR reviews. # How to manage Handbook notifications # How to change mobile device At Mattermost, we are using our mobile devices daily at work. This how-to document provides guidance on what steps you need to take when planning to migrate to a new phone. **Note:** If you’ve lost your mobile phone, please refer to the [How To Handle a Lost Mobile Device](https://handbook.mattermost.com/company/how-to-guides-for-staff/how-to-change-mobile-device/how-to-handle-a-lost-mobile-device) guide. ## **GSuite two-factor authentication** For GSuite two-factor authentication, please follow these steps: 1. Open [https://myaccount.google.com/security](https://myaccount.google.com/u/1/security). 2. Select **2-Step Verification**. 3. You'll be prompted to log in again to prove your identity. 4. Select **Change Phone** and follow the provided steps. 5. (Optional) If you’ve changed your phone number, update the phone number in the **Google Security Center** as well. ## **Okta two-factor authentication** For Okta two-factor authentication, please follow these steps: 1. Open . 2. Log in with your Okta credentials and authentication code from your old mobile device. If you can't sign in, please reach out to the IT team. 3. Select your name in the top right and select **Settings**. 4. If the **Edit Profile** button appears, enter your password if prompted. 5. In the **Security Methods** section, depending on the two-factor method you're using, it will show you **Remove** or **Set up another**. 6. Please choose **Remove** to remove your old device and **Set up another** to add your new device and follow the instructions on the screen. For detailed steps-by-step instruction, please go to the links below: * **Andriod user** : * **iOS user** : # How to handle a lost mobile device In the event of a lost mobile device, please report it immediately to the company security team via , or via the [Security Team channel](https://community.mattermost.com/private-core/channels/security-team). Make sure to include the mention "@securityteam" in your message to notify the security team. The security team will assist you in removing access from your lost mobile device to your Mattermost resources, and walk you through the set up of a new mobile device. # How to do a mini-retrospective After hitting an unanticipated issue or approval escalation, we should complete a mini-retrospective to help us improve our processes and avoid making the same mistake twice. In the spirit of iteration and continuous improvement, after hitting a significant or repeated issue, we should write a mini-retrospective and share it with the team. This should take 5-10 minutes to prepare. Following the resolution, the person with the most knowledge of the issue should send an email to the group with the following summary: 1. What was the issue? 2. What might be done to improve our outcomes in the future? 3. What are we changing in our process and/or documentation (if anything) to improve future outcomes? By taking a moment to reflect, we have the opportunity to uplevel, and create lasting change and improvement. # How to autolink keywords in Mattermost On the [Mattermost Community Server](https://community.mattermost.com), specific keywords in messages, such as MLT, display and behave as links that take you to a documented definition of the word MLT. These keyword links are particularly helpful for new Mattermost staff members ramping up on Mattermost-specific terms and processes. We often refer to these hyperlinked keywords as *autolinks* because they're created using a Mattermost plugin called [Autolink](https://github.com/mattermost/mattermost-plugin-autolink). To add a new autolink on the Mattermost Community Server: 1. Define the word and URL to autolink on. For example, the term ISP is linked to the [issue/solution process](https://handbook.mattermost.com/operations/operations/company-processes/issue-solution) documentation in the [Mattermost Handbook](https://handbook.mattermost.com). 2. On the Mattermost Community Server in the [Community Configuration channel](https://community.mattermost.com/core/channels/community-configuration), ask to help add the new autolink to the Mattermost server. This ensures that everyone on the Mattermost Community Server benefits from having a quick definition at their fingertips when the term is used in messages and threads. For an example request, see: . # Company operations How Mattermost, Inc. operates as a company, and how we communicate externally and internally. Some of this information may be company confidential and may not be viewable. ## Company Key Info * [About Mattermost](/company/about-mattermost#mission) - Mission, vision, company overview, history * [R\&D Operations](https://handbook.mattermost.com/operations/research-and-development) - How we build software * [Deployment Engineering Operations](https://handbook.mattermost.com/operations/deployment-engineering) - How we support customer deployments * [Finance Operations](https://handbook.mattermost.com/operations/finance) - Procurement, spend, fiscal year infor, etc. * [Legal Operations](https://handbook.mattermost.com/operations/legal) - Approvals, processes and specialist legal support * [Security Operations](https://handbook.mattermost.com/operations/security) - Our security, privacy and policies around security research * [Workplace](https://handbook.mattermost.com/operations/workplace) - How we work at Mattermost day-to-day ## How Mattermost uses Mattermost ### Channels Think of Channels like rooms in a building. Public channels are open rooms that people can enter and leave freely. Private channels are like private rooms that are invitation-only. Direct Messages are like popping your head into someone's private office to have a conversation. Group Direct Messages are like popping your head in to a shared office to have a discussion. All channels can be used to communicated, some are better at specific use cases than others: #### Public channels Find public channels from **+ > Browse Channels** and join and leave based on your topics of interest. Use public channels for "open door" discussions of information relevant to everyone in the channel, for example **News and Buzz** is a channel to share updates on Mattermost being mentioned on social media and in press. #### Private channels Use private channels to collaborate on work that would benefit from privacy, and not appropriate for an "open door" discussion. For example, planning manager training, organizing our next MatterCon conference, procurement processes where financial data could be shared, launch planning activities (which can be fast changing and confusing if shared ahead of launch). #### Direct messages Use direct messages (or "DMs") to send quick notes to someone to get their attention, like "Running late" or "Can you comment on this ticket? \[Link]". Avoid using DMs for collaborative work, as it's difficult to share context from a DM discussion with others--use Boards or group channels instead. #### Group direct messages Use group direct messages (or "GDMs") very sparingly, and ideally to send only ephemeral notes to a group like "Running late" or "Please get your forecasts in by end-of-day. \[Link]". Once a GDM is sent, it can be difficult for some users to find the channel again, so it's best if it's not a store of data. ### Boards Think of Boards like a project board on a giant wall, with "Tickets" that can contain all sorts of rich information. You can use Boards to managing any project--goals, tasks, interview candidates, SWAG projects--and organize things based on custom properties, like categories, status, dates, numbers and people. Here's some examples: * **FY23 Goals** - For MLT and MLX, we use Boards to run our [FY23 Goals process in Boards](https://community.mattermost.com/boards/workspace/8qt6sh1dzbybb8365caots67iy/b7qzfu3p11f8u9q6mkkfjer4pjr/ve8dq37s8t7baxbgn8t47mtpixe) to align the company and operations around our vision for the year. ### Playbooks Think of "Playbooks" as a set of binder on a shelf with plans and procedures for different incidents and processes. Based on the type of incident or process, the context (e.g. time of day) Playbooks will include steps to follow, people to notify and automation to kick-off to rapidly flow through, resolve, and learn from different "Runs" of a Playbook. Examples include: * **Incident Response** - The [Incident Response Playbook](https://community.mattermost.com/playbooks/playbooks/ao69o4kkn3yy8mbzgmnn5ichqo/outline) is based on our [Incident Response Process (Internal only)](https://mattermost.sharepoint.com/:w:/r/sites/org-pde/_layouts/15/Doc.aspx?sourcedoc=%7B41AB5A40-CF3D-4874-AEB8-B5D396A5FD55%7D\&file=On-Call%20Process%20%26%20Incident%20Response.docx\&action=default\&mobileredirect=true\&DefaultItemOpen=1). ### Email Think of email like a physical piece of mail you'd want to send to individuals and groups, who might forward the message to others, or reply to the original group. Examples include: * **Cascading Content** - If you're making an announcement across management layers and you want to give each layer and opportunity to add context to the message or choose the people to whom it's forwarded and decide on timing, then email is the best choice. For example, if you're announcing a "company day off" you want to give different managers an opportunity to customize the message as it flows through to their teams, some managers who have on-call staff might have to make accomodations (on-call people need to work, but they can choose a different day off) while another manager who's team has been working on a massive project might want to give an extra day off for their teams, etc. * **Approvals** - Written approvals that need to be circulated and archived are an excellent fit for email. Offer letter approvals are a good example, which need to flow through different HR and manager approval chains and ultimately archived in our HR systems. * **One new topic** - If you have a new topic to discuss in a small group and there's not a good public or private channel, email is an ideal way to start. Choose email over DMs and GDMs if it's an on-going conversation - but choose DMs and GDMs for urgent and ephemeral topics, e.g., "Can you approve this thing?" / "The meeting invite link is broken!", etc. ### Documentation Documentation is like the policy manual for a company. As much as possible, document things publicly. * **Product Documentation** - docs.mattermost.com - Make product documentation as public as possible. * **Operating Documentation** - handbook.mattermost.com - Document our internal processes and operations. * **Mattermost.com** - mattermost.com - Document our customer-facing information. # Areas of Responsibility [Areas of Responsibility](/company/about-mattermost/list-of-terms#aor) (or "AORs") map areas of ownership to [Directly Responsible Individuals](/company/about-mattermost/list-of-terms#dri) ("DRIs"), Backups (people to contact when the DRI is on vacation or unavailable) with a link to a publicly shared Process Write-Up in the Mattermost Handbook, which includes questions and answers to what's been previously asked. For security reasons, visibility of the AORs is limited to authenticated Mattermost Staff and available in our [AOR directory](https://docs.google.com/spreadsheets/d/1qraUnYC-4W1W7nouaWzmLKl5zVzKYKqXwkMdBX2t97M/edit#gid=684908004) # Mattermost Leadership Team (MLT) Mattermost Leadership Team (MLT) consists of Mattermost department heads plus the CEO ## Mattermost Leadership Team (MLT) This section outlines: * Introduction to MLT * The operations of administrative, tactical, and strategic meetings * Process for alignment and cascading communications * Process for quarterly business reviews, planning, and board meetings ### Introduction to MLT * Ian Tien: Co-Founder and CEO * Corey Hulen: Co-Founder and CTO * Kendra Niedziejko: CFO * David Reardon: Chief Revenue Officer * Nirosha Ruwan: VP, Legal * Chen-i Lim: VP, Product * Natalie Jew: VP Human Resources ### Fiscal Year Planning (1%) Preparation for the annual plan and budget for the next fiscal year begins in the second half of the current fiscal year. #### Q3 Planning for Next Fiscal Year In Q3 we have three goals: 1. Fiscal year defining objectives for company and departments based on our latest thinking. 2. Product Strategy and direction for next fiscal year. 3. D0 & D1 Goals by MLT and MLX Directly Responsible Individual Typically there is not pressure for budget or headcount discussions in Q3, focus is strategy. **Q3 Punchlist for Next Fiscal Year Planning** 1. The company 3-year aspirations are reviewed 2. 1% Next Fiscal Year Strategy and Plan are drafted 3. At Q3 Planning Offsite, MLT reviews Strategy and Plan for next fiscal year developed from 1% draft 4. Action items are documented and developed around obstacles to success of next fiscal year 5. Draft budget based on Strategy and Plan and financial investments required to bring plan to life #### Q4 Planning for Next Fiscal Year The focus of Q4 is arriving at a 99% draft of the plan for next fiscal with alignment across MLT and departments, with obstacles mitigated, and headcount and budgets reviewed. 1. MLT and middle managers work through key defining objectives and map out D0 and D1 goals for next fiscal year 2. Finance works with MLT to draft financials plan for next fiscal year 3. Department heads work with their teams, peer stakeholders, and CEO to develop department D2 and D3 goals. 4. 99% department D2 & D3 goals are reviewed by MLT peers and CEO and agreed 5. Plan for next fiscal year # MLT cadence The following cadence is used to product our Monthly Business Review deck. ## Week 1 - Monthly Strategic Review ### Intent: * Begin the month deciding on strategic ISPs, and ISPs from last month’s MBR ### Tuesday Meeting - 60m "MLT Monthly Strategic Review" * Strategic issues as ISPs discussed and decided * MLT invites MLX as appropriate * Time permitting, ISPs from prior MBR discussed and decided * MLT invites MLX as appropriate * Time permitting, have MLT feedback for 10 minutes at the end of this meeting ## Week 2 - Monthly Forecast Update ### Intent: * MLT leaders prepare for MBR by reviewing results with their directs and appropriate MLX teams (e.g. MLX Growth). Forecasts for FY23 Goals are shared, with context. ### Tuesday Meeting - 60m hold for "HOLD: MLT MBR Prep" * Slot for ad hoc ISPs--Tell CEO in Monday 1-1 if meeting is MLT meeting is needed * Otherwise, this is prep time for MLT and their directs/MLX ### Due Date: Forecasts Updated for FY23 Goals by Thursday EOD * In first two months of the quarter forecast to end of quarter * In the third month of quarter forecast to end of next quarter * All monthly forecasts should have a comment with at least the following: ``` # [DATE] ## Going well - Include thank yous ## Not going well - Include next actions, DRI and follow-up date ``` ## Week 3 - Department/Function Leaders Review ### Intent: * Complete MBR deck to share context, next actions, and escalate any ISPs ### Monday Meeting - MLT 1-1 w/ CEO, review draft content for MBR ### Tuesday Meeting - 60m hold for "MLT MBR Prep" (replaces 90m MLT Weekly) * Slot for ad hoc ISPs--Tell CEO in Monday 1-1 if meeting is MLT meeting is needed * Otherwise, this is prep time for MLT and their directs/MLX ### Due Date: Draft deck for Monthly Business Review complete by Tuesday EOD * MLT leaders, directs & MLX (cross-department stakeholders) to complete their slides * MLT works with functional leaders (e.g. CSM, Growth, Support, etc.) help dial in data and commentary. Issues requiring escalation should have an ISP prepared. * Optional: MLT can prepare recordings linked to the deck * Deck made “Comment Only”. Opened to MLT comments ahead of MBR meeting * NOTE: Confidential issues (e.g. PIPs, HR, etc.) will be omitted ## Week 4 - Monthly Business Review ### Intent: * Complete MBR discussion, get MLT to full context on the business. Escalate & clear ISPs ### Tuesday Meeting - 2.5 hour "MLT Monthly Business Review" Meeting * MLT arrives having read the deck and made comments async (unless comments are sensitive, e.g. HR-related) * Maximum 20 minutes discussion per department * Time permitting, MLT can review ISPs queued # Company measures You can't impact what you don't measure. So at Mattermost we have defined standard operating metrics that we monitor to run our business. This section is dedicated to this effort. * Our main company measures are defined and tracked by way of our Standard Operating Metrics (SOM) * SOM: Metrics we believe give the best overall understanding of how the company is performing across departments. * Metrics LifeCycle * Choose them * Define them * Document them * Automate where possible * Reports and Dashboards * Monthly Going Well, Not Going Well & Next Actions (GNN) Review by MLT and MLX. # Metrics definitions ## Contact us requests #### All contact us * Number of contact us requests via . #### Enterprise contact usrequests * Number of contact us requests via from Named Accounts or Enterprises with 5,000+ employees, in America, EMEA, Australia, or Japan. ## Contributors ### GitHub contributors * Members of the open source community with contributions to Mattermost GitHub repositories. * This does not include internal Mattermost staff * Definitions: * First Time Contributors: The first month someone contributes, they are considered a First Time Contributor that whole month. * Old Contributors: Anyone that is not a First Time Contributor. * First Contribution: The first contribution ever made by someone. Any following contributions will not be considered a First Contribution. * Examples: * Person A * 2019-01-02 Contribution 1 * 2019-01-04 Contribution 2 * 2019-01-05 Contribution 3 * Would count as * 1 First Time Contributor + 1 First Time contribution + 2 Non First Contributions. ## CS Account Health Score Customer Success Account Health Score represents the overall health of a Mattermost SFDC Account. * **Account Has Open Opportunity w/ Renewal Risk Status = 'At Risk'** * Account Health Score = 20% * **Account Has Open Opportunity w/ Renewal Risk Status = 'Early Warning'** * Account Health Score = 50% * \*\**Note: If account has open opportunity w/renewal risk status of At Risk or Early Warning, it will override all other Healthscore metrics.* * **Account has a completed Customer Reference** * Customer Reference Score = 10 additional bonus points * **Account Has No Open Opportunity w/ Renewal Risk Status = 'At Risk or 'Early Warning'** * ***Account Health Score = Tenure Score + License End Score + Ticket Score + Task Score*** * **Tenure Score = 25 \* Tenure Health %** * Tenure Health %: * Tenure <= 0.5 Years: **10%** * Tenure Between 0.5-1 Years: **50%** * Tenure Between 1-2 Years: **75%** * Tenure > 2 Years: **100%** * **License End Score = 25 \* License End Health %** * License End Health %: * License End <= 15 Days From Now: **10%** * License End Between 16-30 Days From Now: **25%** * License End Between 31-60 Days From Now: **75%** * License End Between 61-90 Days From Now: **90%** * License End > 90 Days From Now: **100%** * **Ticket Score = 25 \* Ticket Health %** * Ticket Health %: * Count of Tickets Past 90 Days >= 5: **25%** * Count of Tickets Past 90 Days = 0: **50%** * Count of Tickets Past 90 Days Between 3-4: **75%** * Count of Tickets Past 90 Days Between 1-2: **100%** * **Task Score = 25 \* Task Health %** * Task Health %: * Days Since Most Recent Task >= 90: **25%** * Days Since Most Recent Task Between 60-90: **50%** * Days Since Most Recent Task Between 30-60: **75%** * Days Since Most Recent Task <= 30: **100%** ## Downloads ### Monthly Server Downloads #### All Server Downloads * Number of successfully completed unique TE (Team Edition) + EE (Enterprise Edition) downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget/curl downloads. ***Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.*** **Monthly Enterprise Account Server Downloads** * Number of Monthly Server Downloads among companies and organizations with over 5,000 employees. **New Monthly Server Downloads from Named Enterprise Accounts** * The first contact or lead from a Named Enterprise Account who is attached to an Account either manually by an AE or by Marketo, and who provides a business email on mattermost.com/download after downloading the Mattermost server binary. * Excludes Salesforce account types equal to Customer or Partner. ### Monthly App Downloads #### All Desktop App Downloads * Number of successfully completed desktop application downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget / curl downloads. ***Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads.*** ## Finance Financial numbers cater to a wide range of teams. Below you will find information on ACV, TCV, and ARR. **ACV, TCV, Bookings are relevant to Sales/CS and ARR relevant to Finance/CS.** ### TCV (Total Contract Value) ***What the customer bought*** * TCV measures revenue from across the entire contract a customer signs. * Recognized **only** in the Closed Won Month. * `TCV = Total Contract Value` ### ACV (Annual Contract Value) ***What the customer bought annualized for the first year of their contract*** * Recognized **only** in the Closed Won Month. * `ACV = (Total Contract Value / (End Date - Start Date)) * 365` ### Bookings ***Standard financial term used to define how much sales credit is recognized for a deal. This is also the basis for all commission plans starting in FY21.*** * **If term length >= 1 year, Bookings = ACV** * **If term length < 1 year, Bookings = TCV** * **Net New and Expansion only** * Why would we have deals < 1 year? * True-ups * Customer owes MM 30K for Q1FY21 * Booking would be 30K on the first day of Q2 (May 1) * Co-Term Renewals * Ramped Deals * Customer signs a 3 year deal on Feb 28, 2020. Year 1 = 50K, Year 2 = 100K, Year 3 = 150K * Bookings * 2/28/20: 50K * 2/28/21: 100K - 50K = 50K * 2/28/22: 150K - 100K = 50K ### ARR (Annual Recurring Revenue) ***What the customer bought normalized for one year length and reoccurs for length of contract***. * ARR is the value of the contracted recurring revenue of your term subscriptions normalized to a one-year period. * Recognized from **start to end** of contract. * `ARR = (Total Contract Value / (End Date - Start Date)) * 365` * ARR increases and decreases based on the following categories of change: * New: Increase in ARR from $0 to > $0 & New Logo never seen before * Caused by a brand new and never before seen Account signing a contract * Expansion: Increase in ARR by an Account * Caused by seat increase, price increase, or product upgrade * Resurrection: Increase in ARR from $0 to > $0 & by a known Account * Caused by an Account churning and returning to Mattermost * Contraction: Decrease in ARR by an Account * Caused by seat decrease, price decrease, or product downgrade * Churn: Decrease in ARR from > $0 to $0 by an Account * Caused by an Account moving completely off of Mattermost ### TCV vs. ACV vs. ARR Example: * Opportunity: [Example Opportunity](https://mattermost.lightning.force.com/lightning/r/Opportunity/0063600000eRMmcAAG/view) * Close Date: 2019-05-07 * Amount = $250 * Start Date: 2019-06-15 * End Date: 2022-06-14 * Metrics Breakdown (see graph below): * ACV one-time $83 in May 2019 * TCV one-time $250 in May 2019 * ARR $83 from June 2019 until June 2022 ## Google Analytics All Google Analytics data in Snowflake is at a **daily** level. See [limitations](https://handbook.mattermost.com/operations/research-and-development/product/analytics/metrics-definitions#google-analytics-limitations). ### Organic Traffic * Organic Web Traffic is the **daily** unique visitors to \*.mattermost.org, \*.mattermost.com who originate from non-paid sources. * Organic Search Traffic is the **daily** unique visitors to \*.mattermost.org, \*.mattermost.com who originate from an organic Google search. ### Unique Pageview (UPV) A **Unique Pageview (UPV)** aggregates pageviews that are generated by the same user during the same [session](https://handbook.mattermost.com/operations/research-and-development/product/analytics/metrics-definitions#session). The metric combines the pageviews that are from the same person (a user in Google Analytics), on the same page, in the same [session](https://handbook.mattermost.com/operations/research-and-development/product/analytics/metrics-definitions#session), and counts them as one. * Unique Page Views (UPV) are calculated as the **daily** count of distinct pageviews per user per session to view a Mattermost web property webpage ([list of web properties defined in Google Analytics Accounts](https://handbook.mattermost.com/operations/research-and-development/product/analytics/metrics-definitions#google-analytics-accounts)). ### Session A **session** is a group of user interactions within a website that take place within a given time frame. A single session can contain multiple page views, events, social interactions, and ecommerce transactions. A single user can open multiple sessions. Those sessions can occur on the same day, or over several days, weeks, or months. #### Session Expiration As soon as one session ends, there is then an opportunity to start a new session. There are two methods by which a session ends: * Time-based expiration: * After 30 minutes of inactivity. * At midnight. * Campaign change: * If a user arrives via one campaign, leaves, and then comes back via a different campaign. ### Google Analytics Accounts 1. mattermost.com 2. (old mattermost.com) 3. mattermost.org 4. developers.mattermost.com 5. integrations.mattermost.com 6. docs.mattermost.com 7. handbook.mattermost.com 8. licensing.mattermost.com 9. mattermost.gitbook.io/jira-plugin 10. pre-release.mattermost.com (which is old community.mattermost.com) 11. mattermost.zendesk.com ### Google Analytics Limitations * [Stitch](https://handbook.mattermost.com/operations/business-operations/data-engineering#stitch-data) is used to pull Google Analytics data into Snowflake. * Stitch is only able to pull data at a daily level. * Aggregating up daily level to a monthly level causes double counting of users that may have visited the site more than one time in a given month. ## Hiring * WIP ## Net Promoter Score (NPS) ### NPS Survey Mattermost NPS data is collected using an in-product survey on servers where the [User Satisfaction Survey plugin](https://docs.mattermost.com/manage/user-satisfaction-surveys.html) is enabled. Users answer the question "How likely are you to recommend Mattermost?" by selecting a 0-10 score and can provide additional written feedback about their experience. Selecting a score and providing feedback are optional. Net Promoter Score is computed as **(% Promoters - % Detractors)** and ranges from -100 (every user is a Detractor) to +100 (every user is a Promoter). * Promoters (score 9-10): Loyal enthusiasts who will keep buying and refer others. * Passives (score 7-8): Satisfied but unenthusiastic users who are vulnerable. * Detractors (score 0-6): Unhappy users who can damage your brand. If users edit their response to the survey on any particular server version, only the latest rating on each server version is used for computing NPS. Test server data is also removed via the excludable servers list and by trimming any responses submitted on a server version that has not been publically available for 21 days (time delay before an NPS survey is triggered after a server upgrade). Based on the above calculation method, we can apply a time window (Quarterly Trailing NPS) and a version filter (NPS by Server Version) to represent and track the state of Mattermost NPS. ### Quarterly Trailing NPS [Quarterly Trailing NPS](https://mattermost.looker.com/dashboards/147) represents the NPS score computed based on survey submissions received in the last 90 days. We target a 90 day window of NPS responses because it: 1. Encompasses responses across all server versions that are currently in use by customers (with surveys enabled), meaning it is representative of the state of user experience that customers are facing today. 2. Ensures we have a [statistically significant sample size](https://www.checkmarket.com/sample-size-calculator/) representing the [server versions currently in use](https://mattermost.looker.com/looks/203?toggle=dat,det,pik). 3. Helps us capture week-to-week variations in NPS while being less volatile than NPS by server version given the larger sample size. ### NPS by Server Version [NPS by Server Version](https://mattermost.looker.com/dashboards/147) represents the NPS score computed based on survey submissions on a specific server version. While Quarterly Trailing NPS provides a representation of the state of user experience that our customers are facing, NPS by Server Version provides a representation of the user experience offered by the product in particular releases. As such, it's used heavily by the PM team to track the success of particular product team initiatives as they ship. NPS by Server Version is a lagging metric since we need to collect a statistically significant sample size before reporting NPS for a server version. Based on historical data, \~2000 unique user responses (\~1.5-2 months post-ship) are required for the NPS of a particular server version to stabilize. NPS by Server Version can be volatile since it can be affected by the upgrade cadence of heavy usage servers. We typically see a surge in responses when surveys are triggered (21 days after server upgrade) for servers with large DAU, which can impact the NPS trend for that server version. Quarterly trailing NPS is not as affected by this since the sample size is larger and responses are submitted on various server versions. ### Written Response Feedback Users can optionally submit written responses to the NPS survey. These responses are reviewed and categorized by the PM team to allow us to stack rank certain initiatives for roadmap planning based on their impact to NPS, reach and effort to design, implement and test. To determine impact to NPS, we can: 1. Segment the reponses based on written feedback from users who are detractors or passives (See the NPS Feedback section of the [NPS dashboard](https://mattermost.looker.com/dashboards/147)). 2. Segment the responses based on the feedback category to analyze what requested product enhancements equate to the lowest NPS scores from users. 3. View overall number of responses by feedback category. ### Renewal Metrics Reporting ![](https://github.com/mattermost/mattermost-handbook/tree/47c855f4b78d8732ae328c3ec5a2a17453061d11/operations/.gitbook/assets/renewal_metrics_handbook.png) Renewal Metrics in simple terms: * Available Renewals (**X**): Total dollar amount of licenses ending is in the Renewal Qtr * Renewal Rate (**Y%**): Total Won Amount ÷ Available Renewals where: * Won Opportunity License start date falls in the Renewal Qtr * Won Opportunity Product Line Type = 'Ren' * Won Amount <= Available Renewal Amount * Forecasted Renewal Rate (**Z%**): Won Amount + (Total Open Amount \* Probability) ÷ Available Renewals where: * Won & Open Opportunity License Start Date falls in the Renewal Qtr * Won & Open Opportunity Product Line Type = 'Ren' * Won & Open Amount <= Available Renewal Amount * Target (**A**): Target Total Bookings set for the Renewal Qtr by Finance * Actual (**B**): Total Bookings **Won** in the Renewal Qtr where Product Line Type = 'Ren' * Target vs Actual aka TvA (**C%**): Actual ÷ Target ### Renewal Target vs Actual (TvA) * Calculation: **Renewal Actual ÷ Renewal Target** * Renewal Target * Target set in a given period (Mo, Qtr, FY) by Finance * Renewal Actual * Total Bookings **Won** in a given period (Mo, Qtr, FY) where Product Line Type = 'Ren' ### Renewal Rate (Bookings) * Calculation: **∑ Gross Renewals ÷ ∑ Available Renewals** * Available Renewals * Amount up for renewal at Account level by Qtr * Gross Renewals * Renewal amount booked (up to Available Renewal Amount) where **License Start** is in a given Qtr * Calculation: MIN(Available Renewals,Renewal Bookings) * Example 1: * Account: Account 1 * Available Renewals Q4: $100k * Renewal Bookings Q4: $130k * Gross Renewals Q4: $100k * Example 2: * Account: Account 2 * Available Renewals Q4: $100k * Renewal Bookings Q4: $70k * Gross Renewals Q4: $70k ### Forecasted Renewal Rate (Bookings) * Calculation: **(∑ Gross Renewals + ∑ Forecasted Renewals) ÷ ∑ Available Renewals** * Available Renewals (See Above) * Gross Renewals (See Above) * Open Renewal Amount * Renewal amount for open Opportunities where **License Start** is in a given Qtr * Forecasted Renewals * Open Renewal Amount \* Probability + Gross Renewal Amount (up to Available Renewal Amount) * Calculation: MIN(Available Renewals,(Open Renewal Amount \* Probability + Renewal Bookings) ## Support Tickets ### Definitions #### Ticket Status * **New**: Ticket created that has not been assigned a support agent. * **Waiting on customer**: The support agent asks the customer a question and is waiting for their response. * **Waiting on customer - Do not Close**: Checkbox on the ticket. This is used for tickets that are expected to be open for a long period of time. This stops the clock. * Examples include: The customer requests that the ticket remain open after a solution is provided, the customer is on vacation, or the customer is out ill. * **On Hold**: The support agent reaches out to an internal team and is waiting to hear back. Internal teams include Product, Development, or Customer Success. Any ticket that is tied to a Jira ticket is placed **On Hold**. * **Solved**: Support agent provides a solution to the customer. A ticket remains in a **Solved** status for 48 hours before it is set to **Closed**. While the ticket is in a **Solved** status any response from the customer will reopen the ticket. * **Closed**: If no response is recorded after 48 hours, a ticket in a **Solved** status will automatically be set to **Closed**. Any response to the ticket after that period of time will open a new ticket. #### Ticket Level * **Level 1: Urgent Business Impact**: Urgent issue on production system preventing business operations. A large number of users are prevented from working, and no procedural workaround is available. * **Level 2: High Business Impact**: Major issue on the production system severely impacting business operations. * **Level 3: Normal Business Impact**: Moderate issue causing a partial or non-critical loss of functionality on the production system. A small number of users are affected. * **Level 4: Low Business Impact**: Minor issue on non-production system or question, comment, feature request, documentation issue or other non-impacting issues. #### Ticket Measures * **First reply time**: The duration between ticket creation and the first public agent reply on the ticket. * **Next reply time**: The duration between ticket's first reply time and next reply time, unless otherwise communicated. **SLAs** **First Reply Time - Premium and E20 only** **Premium** * L1 (Urgent) - 1 hour * L2 (High) - 2 hours * L3 (Normal) - 8 hours * L4 (Low) - 24 hours **E20** * L1 (Urgent) - 4 hours * L2 (High) - 8 hours * L3 (Normal) - 24 hours * L4 (Low) - next business day **Next Reply Time - Premium and E20 only** **Premium** * L1 (Urgent) - 2 hours * L2 (High) - 4 hours * L3 (Normal) - 24 hours * L4 (Low) - 24 hours **E20** * L1 (Normal) - 4 hours * L2 (High) - 8 hours * L3 (Normal) - 24 hours * L4 (Low) - 24 hours **CSAT** CSAT stands for *Customer Satisfaction Rating*. 24 hours after the ticket is set to closed, the end-user receives an email asking them to rate their experience. In the email the end-user is presented with the question "How would you rate the support you received?". Below the question is the option to select "Good, I'm satisfied" or "Bad, I'm unsatisfied" with the option to leave a comment about their experience. **CSAT Formula** Good, I'm Satisfied / Good I'm Satisfied + Bad I'm Unsatisfied ## Active Servers (TES, TEDAS, and TEDAU) ### TES TES stands for *Telemetry-Enabled Servers*. It is the count of unique, [production servers](#server-considerations) sending telemetry (“activity") data to Mattermost on a given date. Each component of TES can be described as follows: * Telemetry Enabled: * Servers have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console. * Response to Mattermost's call to collect telemetry data recorded on a given date. * For a server to respond, it must be online and telemetry enabled. * Servers: * Servers host Mattermost instances for teams and organizations. * Each team/organization can have one-to-many servers installed to host their instance. * Small/Medium teams typically leverage a single server. * Large teams can leverage Enterprise Edition features to create server clusters that allow them to scale their instance. #### TEDAS TEDAS stands for *Telemetry-Enabled Daily Active Servers*. It is the count of unique [production servers](#server-considerations) sending telemetry (“activity") data to Mattermost on a given date **with at least one daily active user**. A server is considered to have a daily active user, if at least one user recorded activity on the Mattermost server, such as viewed a channel or posted a message, in the last 24 hours. #### TEMAS TEMAS stands for *Telemetry-Enabled Monthly Active Servers*. It is the count of unique [production servers](#server-considerations) sending telemetry (“activity") data to Mattermost on a given date **with at least one monthly active user**. A server has a monthly active user, if at least one user recorded activity on the Mattermost server in the last 30 days, such as viewed a channel or posted a message. Note that an update to the metric is considered to only consider activity in the last 28 days to remove weekday variation. However, this change would require in-product changes and thus has not yet been prioritized. #### TES: Additional Metric Considerations There are several ways to view the TEDAS metric, and there are several more ways to create metrics that are derivatives of TEDAS. Below are some of the ways to view, pivot, and/or filter the TEDAS metric to gather additional insights regarding the overall health of the business: * [TEDAS by First Telemetry-Enabled Date](https://mattermost.looker.com/looks/140): * Provides the count of Telemetry-Enabled Servers trended by their first telemetry active date. * Is an indicator of how many New, Telemetry-Enabled Production Servers are being stood up on any given date, week, month, year, etc. throughout the history of Mattermost. * [TEDAS >= 7 Days Old w/ Active Users](https://mattermost.looker.com/looks/141): * The count of Telemetry-Enabled Servers that are >= 7 days old since their first telemetry active date w/ >= 1 active user logged on the server. * [TEDAS Churn Rate](https://mattermost.looker.com/looks/142): * The rate (percentage) at which Telemetry-Enabled Servers leave the platform (churn) or disable telemetry within a given number of days since the server's first telemetry active date. * Typically (as of 4/15/20), 75-80% of new, Telemetry-Enabled Servers churn within the first 7 days of their first telemetry active date. #### Server Considerations TES only measures the count of active production servers. The Mattermost.server\_daily\_details table is used to calculate TES and only contains production servers. Mattermost.server\_daily\_details is derived from the `Events.security` table. The `Events.security` table logs all server responses to Mattermost's call to collect telemetry data. The Server type responses include test, development, and production servers. Conditional logic is used to filter out non-production servers from the `Events.security` table and insert them into the Mattermost.server\_daily\_details table. * Logic to identify production servers within the `Events.security` table is as follows: * Mattermost Version matching recognized format * `version LIKE '_.%._._.%._'` * Other version formats are not valid because they indicate a test, development, or custom built instance. * No "Dev Builds" and "Ran Tests" recorded * `dev_build = 0` * `ran_tests = 0` * Registered Users >= Active Users * `user_count >= active_user_count` * Data anomalies occur causing servers to show active users > provisioned users - these servers must be excluded. **Non-production servers** Non-production servers are not included in TES calculations. Test and development servers are non-production servers that can be spun up for testing and various other use cases. **Server Age** The age of a server is determined by the server's first active date. This is the minimum date a response to Mattermost's call to collect telemetry data is recorded. It can be thought of as the server's first recorded telemetry-enabled date -i.e. first active date. The age of the server is calculated as a function of this date. It is the days between the server's first active date, discussed above, and the current date (or other relative date being used as a comparison to calculate server age at any point throughout its lifetime). * Server Age = Current Date - Server First Active Date #### TES, TEDAS and TEMAS Caveats There are additional data quality issues within the `Events.security` table that need to be addressed before inserting the verified production servers and calculating TES, TEDAS or TEMAS. The `Events.security` table is supposed to contain 1 record per server per day. This is not always the case: \~2% of server IDs have multiple rows per day. To select a single record per production server we must: * Identify the row per production server containing the maximum number of active users on the given date. * If the maximum number of active users = 0 then we select the most recently logged row based on the "hour" field value. ### TEDAU TEDAU stands for *Telemetry-Enabled Daily Active Users*. It is a metric that takes the rolling 7-day average of the sum of all "Active Users" logged by [telemetry-enabled production servers](#tedas) on a given date. The TEDAU calculation sums the active\_user\_count column in the Mattermost.server\_daily\_details table, and then averages that value over the last 7 days. #### TEDAU Events Currently only a subset of possible events, dubbed "whitelist" events, count towards TEDAU. The reason only a subset of events are captured is a result of exceeding Segment's (third-party event logging service) row limit. In the future, event logging will transition to Rudder (another third-party event logging service), and the list of events that count towards TEDAU will become more expansive. Deactivating a user in Mattermost will result in TEDAU decreasing, as deactivated users are filtered out of the statistic's query. However, reactivating a user in Mattermost will increase the TEDAU statistic. #### TEDAU Caveats TEDAU is the rolling 7-day average sum of active users for only verified production servers that are telemetry-enabled (described in [this TEDAS section](#server-considerations)). All other servers, and their active user counts, are ignored as they represent testing, dev, and one-off user case environments that skew the results. **Telemetry-Enabled Active Users vs. TEDAU Metric** The distinction between an individual server's Telemetry-Enabled Active Users and the TEDAU metric is important to note. Telemetry-Enabled Active Users are the collection of users hosted by a telemetry-enabled production server, that have visited the Mattermost site in the last 24 hours. The TEDAU metric is the rolling 7-day average sum of these users across all servers. ### Server Activations A **Server Activation** is defined as the first date a production server sends telemetry data to Mattermost. In order to send telemetry data to Mattermost, a production server must be set up and activated by the end user. When a production server is first activated its telemetry feature is automatically enabled, which sends security diagnostics information to Mattermost via Segment (soon transitioning to Rudder). The server will continue to send this information on a daily basis until this telemetry feature is disabled by a Mattermost System Admin. A server activation is only captured and counted on the first telemetry-enabled date associated with a specific server. ### Monthly Active Users **Monthly Active Users (MAU)** are users that have performed an event on or within 30 days of a given date. User events are triggered when a user interacts with the Mattermost platform from their desktop or mobile device. After a user performs an event, that user will remain in MAU for 30 days. After that time the user will fall out of MAU and be classified as "Disengaged". #### MAU Engagement Lifecycle Segments Monthly active users are categorized into **Engagement Lifecycle Segments**. There are five engagement lifecycle segments: "Persisted", "First-Time Active", "Reengaged", "Newly Disengaged", and "Disengaged". Each segment is derived from the timeline from when a user performs an event. Each Engagement Lifecycle Segment is defined as follows: * **First-Time Active**: The first time a user performs an event on the Mattermost platform and is classified as a MAU. * **Reengaged**: A user performs an event for the first time after >= 31 days of inactivity on the Mattermost platform. * **Persisted**: A user that performed an event in the last 30 days that does not fall into "First-Time Active" or "Reengaged" MAU Engagement Lifecyle Segments. * **Newly Disgengaged**: A user, that was previously in MAU, that has not performed an event within 30 days of their last event. A user is only "Newly Disengaged" on the 31st day of inactivity. * **Disengaged**: A user, that was previously in MAU, that has not performed an event > 31 days of their last event. A "Newly Disengaged" user becomes "Disengaged" on their 32nd+ day of inactivity. #### MAU Considerations ### Server Retention Server retention is calculated as Day N retention, which shows the percent of users who return to the app on a specified day after their first launch. We do not use rolling retention, which shows the percentage of users who return to the app on a specified day or any day after that. The reason is that rolling retention continues to increase as days go by (someone who comes back to the app on day 31 will count towards day 1, day 2, up to day 31 retention). For concrete examples, a server is included in: * day 1 retention, if there is activity 24-48 hours after server creation * day 7 retention, if there is activity 168-192 hours after server creation * day 14 retention, if there is activity 336-360 hours after server creation * day 28 retention, if there is activity 672-696 hours after server creation ## Trials ### Trial Requests **All Trial Requests** * Number of trial license requests via . **Enterprise Trial Requests** * Number of trial license requests via from Named Accounts or Enterprises with 5,000+ employees, in America, EMEA, Australia, or Japan. # FY23 goals board We use Focalboard to track our [company-wide goals](https://community.mattermost.com/boards/workspace/8qt6sh1dzbybb8365caots67iy/b7qzfu3p11f8u9q6mkkfjer4pjr/vmhddhuuz6tbw3bnbou9gkeq8gw). This page summarizes our processes and instructions. ## Instructions for Monthly DRI updates 1. **Go to Goal** - By the 2nd Tuesday of the month, in the left tab, click on [**Goals by DRI**](https://community.mattermost.com/boards/workspace/8qt6sh1dzbybb8365caots67iy/b7qzfu3p11f8u9q6mkkfjer4pjr/vbpoc5xwtm3ddfrz8kz11m38s7o). In the board, scroll to the goals under your initials. 2. **Share Forecast** - Open each goal and update the "forecast" field with your forecast for the end of the period. E.g. For "Q1 Forecast", put in your forecast for Q1 ending number. 3. **Set "Status** - Status is a summary of how you feel progress is going.\` * `GREEN` - If you believe you'll hit your target by the end of the period, set status to `Green`. * `YELLOW/RED` If you feel your target is off-track, but there's still a chance to hit your target, set status to `Yellow`, and if it's way off use `Red`. * `UNREACHABLE` If you feel it's impossible to reach your goal, set your status to `UNREACHABLE`. Your MLT member will work with you to bring this to the monthly review meeting to discuss how we can adapt as a company. * `DATA NEEDED` If you don't feel you're able to provide a forecast, or are unsure about anything in the process, set status to `DATA NEEDED`. 4. **Share "Going well" and "Not going well"** - Add a comment to share more context about your goal. Include at least the following: * `Going Well:` Share wins, successes, and good news in general. Share "Thank yous" to people who have helped, and @mention them if you feel appropriate. * `Not going well:` Share the key issues you're facing. If the status for the goal is not `Green`, share the key reasons why in this section. * `Next actions:` Share key actions to be taken in the following month, with owners and checkins. Be specific. 5. **Update the "Last Forecasted"** - Update the field "Last Forecasted" with the date of your forecast so MLX knows it's been completed. # MLT metrics ## Self-Serve Analytics Metric Definitions The document linked below has been created in hopes of creating a *more* self-serve Analytics infrastructure for product, product managers, and other employees to perform their own analysis. It provides up-to-date metric definitions, as well as Looker links to pre-filtered jumping off points for modeling the data. This documentation was presented in series of Self-Serve Analytics workshops that were hosted in early June FY22. A recording from the workshop has also been provided below for additional context. 1. [Self-Serve Analytics: Mattermost Metric Definitions](https://docs.google.com/document/d/10mChNYHOPutoTDA7Gm-XqRQYKtipt6RKaAmQofLYy58/edit?usp=sharing) 2. [FY22 Self-Serve Analytics Training Session Recording](https://drive.google.com/file/d/1uSVkXJcU7YUlCGw6Cl9k-PzchbEVMj7_/view?usp=sharing) ## MLT Metrics This section outlines metric definitions maintained by finance for reporting to investors. 1. These are metrics for MLT discussions 1. Any metrics shared by a department with the MLT will be asked to work with business operations to define the metric to be listed on this page under standardized naming and MLT definition checklist 2. Definitions center around ARR, GMA Magic Number and NPS MLT definitions checklist 1. Qualifiers precede metrics names 1. i.e. use ""Gross Margin Adjusted Magic Number" instead of "Magic Number, Gross Margin Adjusted" to avoid ambiguity when label names are truncated 2. Metric names should only have one possible interpretation 3. All MLT Metrics should have a unique acronym shorter than 8 characters 1. Metrics will inevitably be shortened, pre-emptive definition avoids collision ### ARR #### Revenue Metrics *50% complete* * **New ARR**: ARR from new logos signed, with license start dates in the respective period. * **Expansion ARR**: ARR from existing customers with a cross-sell/upsell deal, with license start dates in the respective period (e.g. increased licensed seat count, upgrading from E10 to E20). * **Contraction ARR:** Reduction in ARR from existing customers, but where they are still paying Mattermost based on date of license change. * **Churn ARR**: Reduction in ARR from an existing customer where they are no longer paying Mattermost based on the license end date. * **Total ARR:** Total ARR ending in a specific period. * **IARR: Incremental Annual Recurring Revenue**: (New ARR + Expansion ARR) - (Contraction ARR + Churn ARR) * **Count of New Logos** (1%): Count of new logos signed, with start dates in the respective period. * **Count of Churned Logos** (1%): Count of logos lost where an existing customer is no longer paying Mattermost. #### Active Servers *50% complete* * **Monthly Server Downloads**: Number of successfully completed unique TE + EE downloads by unique client IP address per month, from mattermost.com. Includes web browser and wget / curl downloads. * Note: Excludes GitLab Omnibus downloads, Docker (Dockerhub) downloads, and Bitnami or other cloud image downloads, as we don’t currently have a good way of measuring these downloads. * **Monthly Enterprise Account Server Downloads:** Number of Monthly Server Downloads among companies and organizations with over 5,000 employees. * **New Monthly Server Downloads from Named Enterprise Accounts** (1%)**:** The first contact or lead from a Named Enterprise Account who were attached to an opportunity either manually by an AE or by Marketo, and who provides a business email on mattermost.com/download after downloading the Mattermost server binary. Excludes Salesforce account types equal to Customer or Partner. * **TEDAS:** *Telemetry Enabled Daily Active Servers:* \_\*\*\_Number of unique servers that have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console, and send telemetry “activity data” (such as number of users). #### Active Users *10% complete* * **Total Active Users**: The total number of user accounts created on a single Mattermost server. Excludes deactivated accounts, deleted accounts and bot accounts. This is also the “Total Active Users” measure shown in **System Console > Site Statistics**. * **Registered Authorized Users**: Same as **Total Active Users**. * **Total Registered Users**: The total number of user accounts created on a single Mattermost server, including deactivated and deleted accounts. * **DAU**: *Daily Active Users:* The total number of users who viewed the Mattermost site in the last 24 hours. Excludes bot accounts. This is also the “Daily Active Users” measure shown in **System Console > Site Statistics**. * **TEDAU:** *Telemetry Enabled Daily Active Users:* The total number of users averaged over the last 7 days, who viewed the Mattermost site in the last 24 hours from servers that have “Error Reporting and Diagnostics” or “Security Alert” enabled in System Console, and send telemetry “activity data” (such as number of users). Excludes bot accounts. * **MAU**: *Monthly Active Users:* The total number of users who viewed the Mattermost site in the last 30 days. Excludes bot accounts. This is also the “Monthly Active Users” measure shown in **System Console > Site Statistics**. * **Active User Count**: A measure of the number of active users last 24 hours. **Legacy measure, do not use this for analysis or decision-making.** ### GMA Magic Number #### Gross Margin Metrics *1% complete* * **GMA Magic Number:** *Gross Margin Adjusted Magic Number* (1%): Net New ARR in a period multiplied by Gross Margin in the period, divided by total Sales & Marketing expense in prior period. * **NGMA Magic Number:** *Non-Gross Margin Adjusted Magic Number* (1%) * **Gross Margin**: Net sales revenue minus cost of goods sold * **Net Sales Revenue:** * **Cost of Goods Sold:** #### **Website Traffic** *50% complete* * **Organic Traffic:** * **Organic Web Traffic:** Monthly unique visitors to \*.mattermost.org, \*.mattermost.com who originate from non-paid sources. * **Organic Search Traffic:** Monthly unique visitors to \*.mattermost.org, \*.mattermost.com who originate from an organic Google search. #### Qualified Leads *1% complete* * **Enterprise Trial Requests:** Number of trial license requests via from Named Accounts or Enterprises with 5,000+ employees, in America, EMEA, Australia or Japan. * **Enterprise Contact Us Requests:** Number of contact us requests via from Named Accounts or Enterprises with 5,000+ employees, in America, EMEA, Australia or Japan. * **MQL:** *Marketing Qualified Lead:* * **PQL:** *Product Qualified Lead:* Installed free TE/E0 version from a Target Account interested in EE features. ### NPS #### Contributors *10% complete* * **90s Hiring vs Goal (P0, P1, P2)**: Difference between hiring plan and hires broken out by priority level (P0, P1, P2), function and time. * P0 - Roles which hiring managers have flagged as high need. * P1 (1%) - Roles which hiring managers have flagged as medium need. * P2 (1%) - Roles which hiring managers have flagged as nice-to-have. * **Monthly Active Contributors:** Number of unique contributors in a given month who have posted at least one message on the Mattermost forums OR have committed at least one line of code to any of the publicly available Mattermost repositories on GitHub, including Mattermost Staff and those participating in a [paid R\&D candidate audition project](https://docs.mattermost.com/process/developer.html#audition). * Note: Excludes translators, integration/solution creators and QA/UX contributors, as we don’t currently have a good way of measuring these contributors. * **Monthly Code Contributors**: \_\*\*\_Number of unique contributors in a given month who have committed at least one line of code to any of the publicly available Mattermost repositories on GitHub, excluding members in the Mattermost GitHub organization. #### Product *50% complete* * **Product NPS**: The product net promoter score (Product NPS) measures user satisfaction of the product, calculated based on single question “How likely are you to recommend Mattermost?”. The score is based on a -100 to 100 scale, with the [calculation detailed here](https://en.wikipedia.org/wiki/Net_Promoter#How_it_works) \_\*\*\_gathered through in-product survey. * **End User Product NPS**: The Product NPS calculated among end users only (ie. not among Team or System Admins). * **System Admin Product NPS**: The Product NPS calculated among System Admins only. * **EE Product NPS:** The Product NPS calculated among all users in licensed E10 or E20 servers only. #### Customer Success *1% complete* * **Customer NPS**: Customer satisfaction of the product, calculated based on single question “How likely are you to recommend Mattermost to a friend or colleague?", sent two days after booking or renewal is closed. The score is based on a -100 to 100 scale. * **Support Metrics (E10 and E20)**: Metrics calculated based on Zendesk tickets opened by E10 and E20 customers. Tickets opened by non-subscribed organizations are not counted towards these metrics. * **Tickets Created**: Number of net new Zendesk tickets created. * **First Response Time \[Median, hours]**: The median number of hours from when a ticket was opened in Zendesk to when the first response was sent to the customer. * **% First Response >8 Business Hours**: % of newly opened Zendesk tickets whose first response time is greater than 8 business hours as defined in . * **Resolution Time \[Median, hours]**: The median number of hours from when a ticket was opened in Zendesk to when the ticket is resolved. * **% Resolution Time >7 days**: % of newly opened Zendesk tickets whose first resolution time is greater than 7 days. * **% Resolution Time >14 days**: % of newly opened Zendesk tickets whose first response time is greater than 14 days. * **Number of CSAT Responses**: # of new CSAT (Customer Satisfaction) survey responses from customers whose Zendesk ticket was resolved. * **Customer Satisfaction Score**: % of newly submitted CSAT survey responses who responded “Yes” to the question . For technical analytics definitions not covered here, see the [Analytics Playbook](https://docs.google.com/document/d/1__65LymlUfXLzOiSKD-G56j16Jlx1fRaIu714s3yxDU/edit#heading=h.sowg5wp7n9lk). #### Best Practices To be added. DRI for this page is Jason Blais # Company cadence This section details all of the different ways the company communicates and at what cadence We have a number of different ways we communicate. Use the right side bar to jump to a specific area: * Customer Obsession Meetings (COM) * Surveys * CEO Listening Tours ## Customer Obsession Meeting (aka "COM") This is a bi-weekly all-staff meeting focused on increasing alignment and awareness of how the company, departments, teams and individuals serve our customers. [Customer Obsession](/company/about-mattermost#leadership-principles) is a key leadership principle and we emphasize its priority when we bring the company together. Colleagues who come from companies that aren't obsessed with customers have suggested we refer to this meeting as "All Hands" and not expect everything we announce - from [spending company money](/operations/finance/staff-member-expenses/how-to-spend-company-money) to [recruiting new talent](/contributors/join-us/staff-recruiting) - to be framed in the context of serving customers. Such expectations are typical and common, and therefore we don't have "All Hands" meetings and instead have "Customer Obsession Meetings" to continually remind us that our focus on customers is atypical and uncommon. | Attendees: |
  • All Mattermost Staff
  • Chair: Amy Nicol
  • Co-Chairs: Co-founders
| | ---------- | ---------------------------------------------------------------------------------------------- | | Objectives: |
  • Reach alignment on near and long term goals
  • Reinforce our obsession with making customers safer and more productive
  • Bring awareness through key company updates and news
  • Celebrate team achievements and patterns of success
| | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Time: |
  • Bi-weekly meeting on Wednesdays from 8:00am to 8:25am Palo Alto time and once per quarter at 6:00pm Palo Alto time to allow APAC team members to participate.
| | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 1. Chair works 1-1 with presenters to prepare for them. 2. Team members can share meeting agenda topics with Chair via direct message. Must be shared at least 24 hours prior to meeting start and be aligned with the meeting objectives above. **2 - T-8:** Chair and Vice Chair meet to review agenda. Vice Chair works with approriate presenters of agenda topics to develope slides for presentation **3 - T-1:** COM prep meeting held with Chair, Co-Chairs, and Vice Chair and review the following items: 1. Meeting starts with thematic goal, including the theme statement, defining objectives, and actions the company is taking towards the goal. 2. Introductions for each Week 2 Welcome are confirmed by PeopleOps. 1. If new hire or manager is away, introduction is postponed to the following meeting. 2. New team members are introduced on their second week by their manager, including name, role, what they're working on, timezone, additional info as appropriate (max 2 minutes). 3. New hire can opt-in to introduce themselves if they choose (default is not to require public speaking). 3. Material for each agenda item is reviewed, and contains a link for more information such as a post to a channel, documentation or a blog post. 1. Each link shared in meeting notes should be publicly accessible to everyone in Mattermost. 4. If computer sound is shared during the call, test it prior to the meeting and install libraries or tools as required. ### During meeting 1. (Vice Chair) At 7:58am Palo Alto time on the day meeting is held, post a reminder in Customer Obsession Meeting channel. [See here for an example](https://community-release.mattermost.com/private-core/pl/et6haawrufdo9ysmgd7r56p7xe). 2. (Chair & Vice Chair) Sign into their Zoom account to access recording and screenshare during the meeting. 3. (Team) Join the **Zoom** link in the header of the [Customer Obsession Meeting channel](https://community.mattermost.com/private-core/channels/cust-obs-meeting), and open the **Meeting Notes** link in the header to see the agenda. 4. (Vice Chair) Start Zoom recording at 8:00am Palo Alto time. 5. (Chair and Co-Chairs) Run through the agenda, which comprises one or more of the following items: * **Introduction:** One of the founders does an introduction to the meeting. Usually to align company on short and long term objectives, to reiterate larger vision for the company, or to emphasize leadership principles. * **Good News:** News or updates shared by team members. * **Week 2 Welcomes:** New team members introduced on their second week by their manager, or optionally by the new team member themselves. * **Main Topics:** Align and educate team around challenges faced by Enterprise customers and around department near-term goals. Examples include: FOSDEM event highlights and learnings; Enterprise customer's path from pilot to production; key updates, use cases or stories from customers. * Links to publicly shared documents or slides may be included in meeting notes. * **Feedback:** At end of meeting, conclude meeting with a reminder to share feedback via survey. ### After meeting 1. (Chair) Share meeting recording (viewable only by signed-in users and non-downloadable) and link to feedback survey. [See an example here](https://community.mattermost.com/private-core/pl/nai7nsr61jnbzd67kg37853ybc). **Note:** Include the hashtag `#com-recording` somewhere in the post. 2. (Chair) Post a link to the meeting recording in the header of the [Customer Obsession Meeting channel](https://community.mattermost.com/private-core/channels/cust-obs-meeting) and in the meeting notes. 3. (Chair) Collect feedback from survey and add to next meeting's draft agenda for Chair and Co-Chairs to review. 4. (Presenter) Any presenter that introduces a new acronym needs to include this in the [Mattermost Acronyms Focalboard](https://community.mattermost.com/boards/workspace/orw8z8yajpd9fgxtuijq31eqkh/bemqt6wf847fsdjoeobkor8ucye/vu8rm3mniwp8jbmtr6xkxpwor8r). ## Staff enablement survey Every 6 months we'll be asking staff to spend around 3 minutes completing a [staff enablement survey of 12 engagement questions](https://handbook.mattermost.com/operations/workplace/people/hr-cadences#staff-enablement-survey), plus identifying their organizational leader. * The enablement survey will be announced in COM one week before the survey goes live. * The survey link will be shared at the beginning of COM. * The link will be posted in the COM channel with "Thumbs Up" emoji reaction. * All staff are asked to complete the survey and signal completion by clicking on "Thumbs Up". * Ideally, the meeting will conclude after "Thumbs Up" count reaches attendee count but this is not a requirement. * An analysis of the results should be prepared and presented within the next 2 - 4 weeks in COM. Links to previous staff enablement surveys: * [March 2019 staff enablement survey](https://docs.google.com/presentation/d/1bkUQOCvJyYX-695gpZI7SJal14AWefFx5fJQxTOJKlI/edit#slide=id.g730cbfe72a_0_393) * [September 2019 staff enablement survey](https://docs.google.com/presentation/d/1qArPEreSsI3cuSoW0GWdr02L_nIe_-OyCR0_sI2-0Qc/edit#slide=id.p) * [March 2020 staff enablement survey](https://docs.google.com/presentation/d/1bkUQOCvJyYX-695gpZI7SJal14AWefFx5fJQxTOJKlI/edit#slide=id.g730cbfe72a_0_9) * [April 2021 staff enablement survey](https://docs.google.com/presentation/d/16rKYpHDUQ8aghsmwEJwhXMMSZWldm1t7Y4nPhv5uj-4/edit) ## CEO Listening Tours Listening to feedback is vital to iteration and to continually improve everything we do. Feedback and listening is at the core of our self-awareness leadership principle. We have 1-1s with managers, regular pulse and engagement surveys, People team outreach and conversations, and annonymous feedback available in every weekly Customer Obsession/All-Hands Meeting. CEO Listening Tours are another way we listen. CEO Listening Tours happen over Zoom in meetings around 25-30 minutes with different groups of 5-8 staff, typically within the same department or in a related function. Managers of the team members in the group are typically not included in the meeting. Some notes about Listening Tours: * It's an opportunity to hear from staff about their likes and wishes, which could be about their team, their department, the company in general, or on any topic. These could be likes and wishes off the top of your head, or maybe something you've been thinking about for a while. This simulates an open feedback session at MatterCon where we would ask people to share their thoughts and feelings. * The priority of the meeting is listening. During these sessions the CEO takes notes and refrains from commentary, though may ask follow-up questions. Notes are "default open" to be shared with managers, executives, and anyone in the company. * At the end of the session the CEO reads back what they heard. The notes are shared with the management team/s of the group. * It's then up to managers to decide how to process and address the feedback at the team level. The CEO can also incorporate the information at the company level. * In the past, participants and managers of listening tours have found the meetings productive for uncovering blindspots at the company and within departments. If you're not able to make a particular listening meeting, please ping @amy.nicol to add you to a different slot. How to participate in Listening Tours: 1. **Join us:** Attend the scheduled meeting, or if it's not convenient, ping @amy.nicol to join a different meeting slot. 2. **Share about yourself:** Please introduce yourself with the group (even if we all know each other), with your name, your role, the city and country you're in, and what time it is there. 3. **Share a like and a wish:** If you'd like to share feedback, in the form of a like and a wish, please share it when you feel appropriate. Your feedback can be about anything, something recent ("Wish Zoom was more stable") or something you've been thinking about or talking about for a while ("Really like the Social Coffee channel and meeting people across the company"). 4. **Confirm you've been heard:** As feedback is read back, share if what you had to say has been accurately captured to be shared with our leadership team, execs, and managers. Listening tours are just another way we gather feedback so we can iterate and improve everything we do. Thank you for helping speed us on our journey of continual improvement. ## GNN Updates A GNN Update is a concise way to share out what's "Going Well", "Not Going Well", and "Next Actions" on a specific initiative or goal. * **Going Well**: What's going well, and what would we want to amplify or repeat? * **Not Going Well**: What's moving slower than expected? What's in our way? * **Next Actions**: Based on what's going well (things we want to amplify or repeat) and Not Going Well (problems we need to solve), what are the next actions we want to take in the next 1-2 weeks? Next actions should include who is responsible for them, a due date and what the expected outcomes and imapct of the next actions. If a GNN has been shared previously, the Business owner should share the following in their next update: * **Outcomes of previous Next Actions**: Share what happened after the last set of Next Actions were shared out, good and bad. If the Next Action wasn't completed, explain why, and then what we'll do next time to complete the action. * **Link to previous GNN Update**: Add a link back to the previous GNN update as a reference. ## Monthly Business Review ("MBR") * Each month we review our progress against our company-level standard operating metrics. * The GNN Updates are prepared by business owners with input from the data owners. * In the MBR we align on the most important opportunities to accelerate the company, and supporting the DRI with Next Actions across the company to bring a goal back to success. # Company policies This section provides information about company-wide policies. # Community response policy This page outlines the process for escalating sensitive topics within Mattermost. ## Why do we need a policy? There are several sensitive topics raised by the community that we want to address appropriately and consistently at all times. However, currently the struggles we have as a team is the unclarity on where Mattermost stands on each of the sensitive topics listed below. This unclarity often results in inconsistent responses that lead to confusion for our users, or ingenuine responses that breaks the trust from our community. We want to stop both of these from happening. This policy is put in place to compel us as a team to have a clear official point of view for each of the listed topics below, with standard responses that can be used by a broader team. Until a clear point of view is reached, a person or a group of people are assigned as the approved responders to avoid unnecessary confusion and broken trust with our users and our community. Therefore, if you see a question on a sensitive topic, the ask is to follow the escalation process below, and escalate sensitive topics to the approved responders until an official point of view is clearly documented. Once documented, this process will be revisited. This policy is intended to be an iterative process, and feedback is encouraged and welcome. If there are any questions about this policy, please reach out in the [Community Escalations channel](https://community.mattermost.com/private-core/channels/community-escalations) in Mattermost, or message @jason.blais directly. ## Escalation process Sensitive topics listed below are escalated to a [Community Escalations channel](https://community.mattermost.com/private-core/channels/community-escalations) in the Private Staff team, which includes all members of the Mattermost Leadership Team (MLT) plus any approved responders. This channel is public, so anyone in the company can escalate an issue. When an issue relating to a sensitive topic is raised (for example, on GitHub issues, Twitter, or elsewhere), it should be posted in the Community Escalations channel with an @-mention to the list of approved responders related to that particular issue. Raising an issue is the responsibility of whoever is managing community responses in a given forum. However, it is also open for anyone at the company to escalate an issue that they see. It is then the responsibility of the approved responders to review the issue and choose an owner for responding (if a response is appropriate). By default, ownership is delegated to the first person on the list of approved responders. ## Sensitive topics While anyone can escalate a sensitive topic, only approved responders listed below can engage. If you’d like to be an approved responder for one or more of the topics, we welcome the help! Reach out to @jason.blais on community.mattermost.com, and you will be added to the next training session. 1. Non-regulatory **Privacy/Telemetry** where opinions are at play more than legal or regulatory issues: * Approved Responders: Dr. Program Management, Lead PM, CTO, CEO * Loop in: CEO, CRO * Template Response: To be added 2. Product-related **Regulations/GDPR**, and other legal issues: * Approved Responders: Head of Security, VP Legal, VP Product, CRO, CEO * Loop in: VP Legal, Lead PM, CFO * Template Response: To be added 3. **Licensing**, including open source and commercial license inquiries: * Approved Responders: Dr. Program Management, CRO, CEO * Template Response: To be added 4. **Packaging**, including requests for making an Enterprise feature free: * Approved Responders: Lead PM, VP Product, CTO * Loop in: CEO, CRO * Template Response: To be added 5. **Workplace policies**, including hiring locations: * Approved Responders: VP HR, VP Legal * Template Response: To be added 6. **Security vulnerabilities** * Approved Responders: Head of Security, Security PM, CTO * Loop in: CEO, VP Product, CFO * Template Response: To be added 7. **Illicit use** * Approved Responders: VP Legal, CFO * Loop in: VP Legal, CEO * Template Response: To be added 8. Marketing-related **Regulations/GDPR**, and other legal issues: * Approved Responders: VP Legal, CFO, CEO * Loop in: VP Legal, CEO * Template Response: To be added 9. **Governmental data request**, e.g. US government requesting user/customer data under US jurisdiction: * Approved Responders: VP Legal, CEO * Loop in: VP Legal * Template Response: To be added ### Non-sensitive topics Non-sensitive topics include feature requests, troubleshooting questions, bug reports, and other user feedback. Anyone in the company is welcome and encouraged to respond, regardless of the medium. If it is your first time responding to the community, please read [principles, tips, and sample responses](https://docs.mattermost.com/process/community-guidelines.html#mattermost-community-forums) for help on various inquiries. ### Response writing tips * **Don't make false promises or assumptions** * If you are unsure of the answer, ask someone for help. Do not reply with an assumption or incomplete understanding. * Don’t say "we’ll work on feature X" that sets expectations we cannot meet (e.g. after presenting to core team it turns out you can’t implement the feature). * **Choose positivity over negativity** * Avoid excuses like “we’re busy”, or “our team is small” and turn a missing feature into an invitation to share a feature idea to be upvoted. * **Do your best to link documentation as answers** * Allow answers to be easily updated dynamically, as documentation is updated. * Turn questions that are not answered in docs, but should be, into tickets to create that documentation (and include ticket link in your response). * **Keep community end user information secure** * If you come across a post that includes the person's IP address, domain name, or other information you think should not be disclosed publicly, edit the post to remove this information. Then click the **hide revision** button so that your edits won't be visible to others on the forum. * **Be thankful** * Communities really respond well to being praised and thanked for their work. * **Do not focus on opinions** * Try to understand each person's [emotions, assumptions and priorities](https://handbook.mattermost.com/company/about-mattermost/mindsets#emotion-assumption-and-priority) and shift the conversation away from opinions. * Turn product discussions into conversations of specific audiences and use cases that each product edition serves. For more guidelines on Mattermost forums and the public GitHub repositories, see the [Mattermost Community Playbook](https://handbook.mattermost.com/contributors/contributors/community-playbook#mattermost-community-forums). ### Roles Below is the list of members mapped to each role mentioned as an approved responder: * CEO: Ian Tien * CTO: Corey Hulen * CFO: Kendra Neidziejko * VP Product: Chen-i Lim * VP HR: Natalie Jew * VP Legal: Nirosha Ruwan * Lead PM: Katie Wiersgalla * Head of Security: Daniel Schalla * Dr. Program Management: Jason Blais * Security PM: Katie Wiersgalla # Security policy This document summarizes the internal security policies at Mattermost, Inc. ## Security benefits of an open source platform The open source Mattermost Team Edition is used by thousands of teams around the world. Development is aided by hundreds of open source contributors, with full access to the product source code, who have a vested interest in keeping the software secure and vetted. As new threats emerge, a [responsible disclosure policy](https://mattermost.com/security-vulnerability-report/) is in place for the community to confidentially report security issues so they can be addressed by Mattermost, Inc. prior to documenting [security updates](https://mattermost.com/security-updates/) publicly. The commercial Mattermost Enterprise Edition extends the security and productivity benefits of the open source solution with support for advanced security, management, scale, and policy compliance features for complex organizations. ## Mattermost development guidelines ### Tracking * Prior to implementation, potential code changes are discussed and documented in [Mattermost's issue tracking system](https://mattermost.atlassian.net). * Security tickets are confidential to Mattermost, Inc. staff, who are under NDA, and specially tagged to avoid disclosure. * All potential code changes are mapped to tickets prior to acceptance, with the exception of trivial changes and bug fixes. ### Review * To uphold security, quality and reliability standards, all potential changes submitted by open source contributors must pass an [accepting pull requests](https://handbook.mattermost.com/contributors/contributors/ways-to-contribute/help-wanted) vetting process prior to submission. * Clarity and readability of code is enforced through the [Mattermost contribution checklist](https://developers.mattermost.com/contribute/getting-started/contribution-checklist/). * After submission, all proposed changes require at least two code reviews for reliability, quality, and system security. * All open source contributions are available for public inspection and commentary before and after acceptance. ### Reporting * Mattermost uses a [responsible disclosure policy](https://mattermost.com/security-vulnerability-report/) to accept confidential reports of new threats, so they can be addressed either immediately through a dot release, or by the next monthly release depending on potential impact. * When Mattermost software undergoes security and penetration testing at customer sites security updates are added to the core software and [publicly documented by release](https://mattermost.com/security-updates/). ### Patch management * Critical updates are released for urgent, high priority security issues or critical losses of functionality that should not wait for the next monthly release. * Mattermost software has a mandatory upgrade policy and customers and users need to be on the latest release to receive critical updates. * Critical updates are delivered as dot releases, for example a critical update to release `3.1.0` would be named `3.1.1`. * Customers and subscribers to the Security Bulletin [mailing list](https://mattermost.com/blog/category/security-updates) receive notifications about all critical updates. ### Security review checklist In addition to checklists for quality and reliability, code changes receive multiple reviews for the following system security design principles: * Reducing information disclosure * Reducing attack surface * Protecting against denial of service vulnerabilities * Preventing message spoofing * Preventing cross-site scripting * Preventing cross-site forgery * Preventing remote code execution ## Security update monitoring The following resources are monitored for information about new security threats and attack vectors. * * * * * * * * All dependencies are updated on a regular basis to ensure Mattermost uses the latest security updates. ## Common security-related questions for Enterprises ### Governance 1. Do you maintain a quality management system (QMS) approved by management? Does your quality management system (QMS) include coverage for software application security principles? * Yes. 2. Is quality management system (QMS) content published and communicated to all relevant employees? * Yes. 3. Is quality management system (QMS) content reviewed and updated (if appropriate) at least once per year? * Yes. 4. Is there defined management oversight who is responsible for application quality and security reporting and signoff? * Yes. 5. For all IT systems including but not limited to servers, routers, switches, firewalls, databases, and external social spaces, is management approval required prior to creating all user and privileged accounts (e.g., system or security administrator)? * Yes. 6. For all IT systems including but not limited to servers, routers, switches, firewalls, and databases, are privileged accounts (e.g., system or security administrator) logged at all times and reviewed on at least a quarterly basis? * Yes. 7. Are all system, application and device password files encrypted using an industry standard encryption algorithm where technically feasible? * Yes 8. For all IT systems including but not limited to servers, routers, switches, firewalls, and databases, do privileged accounts (e.g., system or security administrator) that communicate directly with the internet, contain any personally identifiable information (PII) such as: social security numbers, credit card numbers, patient health record information, or other confidential records? * Yes 9. Is all sensitive, protected health information (PHI) and personally identifiable information (PII) protected using an industry standard encryption algorithm where technically feasible? * Yes 10. Are information assets classified? * Yes. 11. Are security roles and responsibilities of personnel defined and documented in accordance with the organization’s information security policy? * Yes. 12. Is a background screening performed prior to allowing personnel access to Scoped Systems and Data? * Yes. 13. Are new hires required to sign any agreements upon hire? * Yes. 14. Is there a disciplinary process for non-compliance with information security policies? * Yes, disclosure of confidential information or egregious disregard for documented security policies is grounds for termination. 15. Is there a personnel termination or change of status process? * Yes. ### Access control 1. Is access to and maintenance of applications, systems, network components (including routers, databases, firewalls, voice communications servers, voice recording servers, voice response units (VRU) etc), operating systems, virtualization components, hypervisors, or other information objects restricted to authorized personnel only? * Yes. 2. Is access to and maintenance of applications, systems, network components (including routers, databases, firewalls, voice communications servers, voice recording servers, voice response units (VRU) etc), operating systems, virtualization components, hypervisors, or other information objects granted based upon need-to-know job function? * Yes. 3. Are unique user IDs required for all user and privileged accounts (e.g., system or security administrator) to access all IT systems including but not limited to servers, routers, switches, firewalls, and databases? * Yes. 4. Are passwords required for all user and privileged accounts (e.g., system or security administrator) to access all IT systems including but not limited to servers, routers, switches, firewalls, and databases? * Yes. 5. Are there written network password policies and/or procedures? * Yes. 6. Is password administration employed for critical systems? * Yes. 7. Are passwords prevented from being displayed in clear text during user authentication or in electronic/printed reports? * Yes. 8. If user accounts are assigned to non-permanent personnel (e.g., contractors, consultants) for troubleshooting purposes, are the accounts disabled or removed after each use? * Yes. ### Operational security 1. Is there a risk assessment program that has been approved by management, communicated to appropriate personnel, and has an owner to maintain and review the program? * Yes. 2. Is there an information security policy that has been approved by management, communicated to appropriate personnel, and has an owner to maintain and review the policy? * Yes. 3. Is there a vendor management program? * Yes. 4. Is there a respondent information security function responsible for security initiatives? * Yes. 5. Is there an asset management policy or program that has been approved by management, communicated to appropriate personnel, and has an owner to maintain and review the policy? * Yes. 6. Are management approved operating procedures utilized? * Yes. 7. Is there an operational change management/change control policy or program that has been approved by management, communicated to appropriate personnel, and has an owner to maintain and review the policy? * Yes. 8. Are system backups performed? * Yes. 9. Are firewalls in use for both internal and external connections? * Yes. 10. Are firewalls or IPS(s) secured against unauthorized access from the internet, Extranet, and Intranet users? * Yes. 11. Are vulnerability assessments, scans, or penetration tests performed on internal or external networks? * Yes. 12. Are incoming emails scanned for questionable file attachments? * Yes. 13. Does the company use spam filtering software to reduce the number of unsolicited emails? * Yes. 14. Are email attachments scanned by anti-virus software? * Yes. ### Business resiliency For more information on Business Resiliency, see the Business Continuity Plan. 1. Is there an established Business Resiliency program that has been approved by management and communicated to appropriate personnel? * Yes. 2. Has a Business Impact Analysis been conducted? * Yes. 3. Is there a formal process focused on identifying and addressing risks of disruptive incidents to the organization? * Yes. 4. Is there an established Business Resiliency program that has been approved by management and communicated to appropriate personnel? * Yes. 5. Are specific response and recovery strategies defined for addressing risks of disruptive incidents to the organization? * Yes. 6. Are formal business continuity procedures developed and documented? * Yes. 7. Has senior management assigned the responsibility for the overall management of the response and recovery efforts? * Yes. 8. Is there a periodic review of your Business Resiliency Program? * Yes, annually. 9. Is there an Influenza Pandemic/Infectious Disease Outbreak Plan? * Yes. 10. Is there insurance coverage for business interruptions or general services interruption? * Yes. ### Compliance 1. Is there an internal audit, risk management, or compliance department with responsibility for identifying and tracking resolution of outstanding regulatory issues? * Yes. 2. Are there policies and procedures to ensure compliance with applicable legislative, regulatory, and contractual requirements to address intellectual property rights on business processes or information technology software products? * Yes. 3. Is there a records retention policy covering paper and electronic records, including email in support of applicable regulations, standards, and contractual requirements? * Yes. For example, records of customers with NDAs are retained in the event an NDA is terminated and requires destruction of records. 4. Is licensing maintained in all jurisdictions where the business operates or where licensing is required? * Yes. 5. Is there an internal compliance and ethics program to ensure professional ethics and business practices are implemented? * Yes. 6. Are policies and procedures maintained for enabling compliance with applicable legal, regulatory, statutory, or contractual obligations related to any information security requirements? * Yes. 7. Is there a formalized governance process to identify and assess changes that could significantly affect the system of internal controls for security, confidentiality, and availability? * Yes. ### Software Development Life Cycle (SDLC) 1. Are there documented processes, procedures, standards and templates used in your SDLC process? * Yes. 2. Do the materials above include references to application security best practices and principles being followed? * Yes. 3. Are design and code reviews performed as part of your SDLC processes? * Yes. 4. Are security considerations (checklists, standards, and policies) referenced in the design and code review? * Yes. 5. Is application code managed in a secure configuration management system with access controls? * Yes. 6. Is there a configuration management plan and are release artifacts maintained in a configuration management system? * Yes. 7. Are test plans and records kept that reflects the tests performed and results observed for each release? * Yes. 8. Is a release criteria defined, measured and reported on to confirm targeted release quality is achieved? * Yes. 9. Do you work with third parties that may have access to your IP and sensitive data? * Yes, we may employ vendors and consultants, including third-party security analysts. 10. If so, is access to data controlled by terms of Non-Disclosure Agreements? * Yes. ### Training 1. Is internal company training available and performed commensurate with personnel roles and responsibilities? * Yes. 2. Does training include security awareness? * Yes. 3. Does training include education on policies, standards, procedures, and updates when needed? * Yes. 4. Are personnel training plans and records kept for internal company compliance purposes? * Yes. ### Validation 1. Are results from the execution of test plans reported and used to track and justify release readiness? * Yes. 2. Does the quality assurance organization have authority to delay shipment of releases due to non-conformance reasons? * Yes. 3. Is some form of static code scanning performed as part of the release acceptance? What tools are used? * Yes, static analysis tools include ESLint and gofmt. 4. Is some form of dynamic code scanning performed as part of the release acceptance? What tools are used? * Yes, Jenkins is used for dynamic code scanning as part of the release process. ### Security response 1. Do you have a documented company security incident response process? * Yes. 2. Do your maintenance releases include fixes for both quality and security related issues? * Yes. 3. Do you provide dedicated security patches for software versions that are released and supported in the field? How? * Yes. Security patches may be provided on the latest release when applicable. 4. Is there proactive notification provided to customers and software partners (PTC)? How? * Yes. Security updates are announced via email to customers as well as mailing list subscribers. 5. Is there a specified response policy that includes the timeframe issues are to be addressed? * Yes, please see: [https://about.mattermost.com/support/](https://mattermost.com/support/). ## Infrastructure security policies 1. Technical infrastructure, including network security, servers and access control protocols are regularly reviewed for potential threats and vulnerabilities. 2. Business process, HR process and policies are regularly reviewed for potential threats and vulnerabilities. 3. A penetration test on the software is performed regularly. A copy of penetration results may be requested by customers upon five (5) day written notice at any time, but no more than once per twelve (12) month period. ## Business continuity plan This document outlines Mattermost, Inc.'s **Disaster Recovery and Business Continuity Plan (DRBCP)** informed by the Federal Financial Institutions Examination Council guidelines on Business Continuity Planning in the context of Mattermost, Inc. being a vendor providing self-hosted software and consulting services to financial institutions. Because Mattermost software runs within a customer's data center, behind a customer's firewall and existing layers of security, without dependency to services hosted by Mattermost, the disruption of the business continuity of Mattermost, Inc. does not immediately impact the operating continuity of its customers. It does affect Mattermost's ability to answer support requests, provide consulting services, and provide new improvements or patches to Mattermost software. At a high level, precautions include: * DRBCP is tested, evaluated and refined annually to ensure our processes are working and up-to-date. * As support is the most critical service offered, multiple channels for support engagement are available and monitored, including email, a Mattermost community server available on web, desktop and mobile, online forums, online forms, social media channels (Twitter and Facebook), and for Premier Support customers, we offer a telephone-based call center. * Subject Matter Experts for escalations are available in at least three centers in different timezones to provide redundant coverage should communication with one or multiple centers be disrupted. Mattermost staff use a diverse set of operating systems, including Mac, Windows, and different distributions of Linux, and a diverse set of global internet service providers, to reduce the potential damage of a single strain of malware, single desktop computing exploit, or single telecommunications outage. * As further redundancy, we have a network of [partners](https://mattermost.com/partners/) around the world skilled in Mattermost technologies to be contacted for assistance for critical customer issues. * As further redundancy, we have a community of several hundred engineers around the world and over a thousand contributors to our online forums, who have sufficient access and expertise in Mattermost's open source technologies that could be contact in the highly unlikely event both Mattermost, Inc. and our partner networks are unable to service our customers. * As further redundancy, Mattermost provides open source code for its core server technology, mobile applications, desktop applications, and a wide array of extensions which allows customers to have transparency into the functionality of the software and solve the issue with their internal technical teams should a massive worldwide failure of Mattermost, Inc., its partners and its community arise. Mattermost, Inc. is headquartered in Palo Alto, California with a distributed organization across three timezones, and is therefore not easily affected by typical causes of business disruption, such as local failures of equipment, power, telecommunications, social unrest, fire, or natural disasters. Even so, threats considered in the context of business continuity are categorized by impact of the disruption. ### Priority 1: Outages that would have immediate impact on a Mattermost customer #### Key support staff unavailable in case of customer emergency. **Effect: Emergency response times exceed expectations.** **Solution(s)** Level 1 (Critical Business Impact) and Level 2 (Major Business Impact) support requests are received by on-call support staff, as well as three supervisory staff who can monitor and escalate issues should the assigned staff member appear to be unavailable or unable to respond to the request within the SLA time allotted. As an additional safeguard, when an L1 or L2 escalation is reported, a notification is sent via the company's internal Mattermost instance to all qualified support staff to be aware of the issue, and any member can step in if it seems follow up may not be achieved within SLA expectations. **Mitigation(s)** * Mattermost, Inc. employs support staff and engineers in multiple timezones to increase availability, reduce response times and to reduce the risk that key support staff would be unavailable to service emergency requests. #### Downtime for Mattermost Hosted Push Notification Service (HPNS) **Effect: End users at customer sites deploying on HPNS do not receive mobile push notifications.** **Solution(s)** Mattermost, Inc. can re-deploy the service from backup to new infrastructure, should its existing infrastructure suffer an outage. **Mitigation(s)** HPNS is available [as open source software hosted on GitHub.com](https://github.com/mattermost/push-proxy), allowing enterprises an option to compile and self-host the service, should they choose not to use HPNS hosted by Mattermost, Inc. #### Disruption of infrastructure providing support over email, online tickets or Mattermost messaging during customer emergency **Effect: Unable to communicate with Mattermost, Inc. support team during emergency** **Solution(s)** Should a support channel be out-of-service, Mattermost, Inc. provides redundant support options through email, online ticketing, and (for customers who have purchased core access Premier support) online message via Mattermost. ### Priority 2: Outages having immediate impact on business continuity #### Outage due to malicious software (viruses, works, trojans, and similar) **Effect: Reduced capacity to continue business operations, depending on attack.** **Solution(s)** Mattermost, Inc. staff uses multiple anti-virus solutions for detecting and removing malicious software and regularly backs up key systems to delete infected systems and re-deploy its infrastructure. Moreover, the company uses a range of Windows, Mac, and Linux-based workstations, reducing the probability of a company wide disruption from a single strain of malicious software. #### Outage due to online attacks **Effect: Reduced capacity to continue business operations, depending on attack.** **Solution(s)** Mattermost, Inc. runs multiple monitoring and alerting services to detect and isolate suspicious traffic and requests in order to minimize downtime from potential online threats. Should our self-hosted Mattermost instance be disrupted we can, if needed, quickly re-deploy the solution within our VPN. #### Disruption due to influenza pandemic or infectious disease outbreak **Effect: Reduced capacity to continue business operations.** **Solution(s)** Mattermost, Inc. employs staff and engineers in multiple timezones and geographic areas, reducing the risk of significant disruption that an influenza pandemic or infectious disease outbreak would cause to business operations. ### Priority 3: Outages greater than 72 hours impacting business continuity #### Outage of online CRM system **Effect: Reduced ability to continue sales operations.** **Solution(s)** While there is no current failover plan should our online CRM system become disrupted, we have SLAs with our CRM vendor - which is used by thousands of other organizations - and believe the probability of sustained outage is low. ### Priority 4: Outages greater than 10 days impacting business continuity #### Outage of online HR and intranet systems **Effect: Reduced ability to continue HR and internal operations.** **Solution(s)** While there is no current failover plan should our online HR or intranet system become disrupted, we have SLAs with our vendors - which is used by thousands of other organizations - and believe the probability of sustained outage is low. # Company processes This section provides information about company-wide processes, including * Issue/Solution process * Company agreements * Publishing process and guidelines # Issue/solution process ## Issue/Solution Proposal Process Issue/Solution Proposal (ISP) is a tool for increasing clarity, speed, and output in teams. Note: Special thanks to [Matt Mochary](https://www.linkedin.com/in/matt-mochary-34bb4/) for the framework on which this system is based. ## Decision-making ### Getting buy-in One of the core challenges in leadership is getting teams to buy into a decision intellectually and emotionally. You create buy-in when you make people feel they're part of the decision, and that their input contributes to the final outcome. The more influence they feel they have on the outcome, the more they’ll be invested in the final result. Broadly, there are three ways to make a decision. Each has a different time requirement, and creates a different level of buy-in. The methods that create the most buy-in also take the most amount of time. #### Method A: Unilateral decision For a decision where there's a clear decision maker based on Areas of Responsibility (see Type 1 vs Type 2 below), the decision maker announces a decision to the team, and answers questions. This is typical when a decision is within someone’s Area of Responsibility. Example: A digital marketer who's responsible for managing the executing of advertising campaigns using different vendors would make a Method A decision on which vendors to choose, and let others know. Pros: * Takes very little time. Con: * Creates very little buy-in and gets no benefit from the team’s knowledge and experience. #### Method B: Issue and solution proposed A decision maker creates (or assigns someone to create) a written straw man (a hypothetical answer designed to inspire discussion), shares it with the team, invites team to give feedback (written and verbal), facilitates group discussion, makes everyone feel heard by repeating back their comments, and then makes a final decision. Pros: * Creates more buy-in. Gets some minimal benefit from the collective wisdom of the team. Con: * Takes more time. #### Method C: Wallow on strategic issue A decision maker invites a team to a meeting where a dilemma is discussed from scratch with no straw man. The team shares ideas. The decision maker repeats back everyone’s ideas until they feel heard. The decision maker shares their own idea last (because theirs is the loudest voice in the room). Lastly, decision maker makes the decision. Note that this is not a consensus decision. Buy-in is created by the decision maker confirming that they heard all ideas, not by accommodating all ideas. Pros: * Creates the most buy-in. Gets a lot of benefit from the collective wisdom of the team. Con: * Takes the most time. Not surprisingly, the greatest benefits require the most work. If you want more buy-in and a better decision, you need to take more time in making the decision. So, which method should you use? It depends on how significant the decision is, and how important buy-in is. For everyday, low-impact issues (for example, entering a new reseller relationship), Method A is sufficient. For major, core issues (for example, Company 10-Year Vision), Method C is necessary. For everything in between (the vast majority of important decisions), Method B is optimal. For Method B, we use the Issue/Proposed Solution method. ## Issues/Solution Proposed (ISP) Team members will often want to bring up an issue and discuss it verbally. This is both inefficient (listening takes longer than reading) and ineffective (in verbal discussions the most vocal people often have the most influence). Instead, we require that anyone who presents an issue at a team meeting do so in writing. The write-up should include both a detailed description of the Issue as well as their Proposed Solution. A team member asked to do a write-up might say “I don’t know the answer.” It doesn’t matter. They should take a guess and create a strawman. Even if they only have 10% confidence that their answer is the right one. And they should phrase the Proposed Solution in very bold, directive terms (“Do this ….”). This may seem aggressive, but it plants a flag in the sand which generates a much more productive discussion and a quicker decision-time, which is more important than appearing to be humble. All Issues and Proposed Solutions are presented at the weekly Team Meeting, including a pre-recording that can be replayed asynchronously at high speed to save time. Allow up to 5 minutes of discussion for each tactical (short-term) Proposed Solution and up to 20 minutes for each strategic (long-term) Proposed Solution. If in that time, the decision maker feels that they have enough context to make a decision, they announce and write the decision. The Solution is turned into one or more Next Actions with a DRI (Directly Responsible Individual) and Due Date for each. We use an Issue/Solution Proposed (ISP) template to structure these issues, and typically include a recording of the issue so it can be explained quickly and concisely. If the decision maker feels they don’t have enough context to make a decision, DO NOT spend more time talking about the Issue. Instead turn to the RAPID decision-making framework described below. ## Type 1 vs Type 2 decisions A Type 1 decision is a “one-way door”. Once it’s made, it’s very difficult to reverse. Acquiring a company, or discontinuing a product line are examples of Type 1 decisions. As organizations get larger, there’s a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We need to fight that tendency. Each time there is a decision to be made, rate it as Type 1 or Type 2. * Type 1 decisions should be made by the CEO. * Type 2 decisions should be made by someone who is not CEO, unless it impacts CEO-specific AORs. Most decisions are Type 2. ## RAPID decision-making When a decision is complex and can’t be reached efficiently even after a well-prepared ISP, we should use a RAPID framework. This is in specific cases when: * A team has become too large to easily get all of the needed voices in one room. * Consensus cannot be reached within 5-20 minutes of discussion. Here is an Example of a RAPID. In an Issue/Proposed Solution using RAPID: 1. Someone identifies an issue or decision that needs to be made. They write up: 2. The Issue 3. The Proposed Solution 4. The list of people needed to make and implement the decision: * R (Recommend) = the one who first proposed the Issue and Solution. * A (Agree) = those people whose input must be incorporated in the decision. This is typically blank, unless is is the legal team to ensure no one is breaking the law. It should be very rare that anyone else's agreement is required for a decision. * P (Perform) = those people who will have to enact any decision and therefore should be heard. * I (Input) = those people whose input is worth considering. * D (Decide) = the one who will make the decision. * If Type 1, this should be the CEO. * If Type 2, this should be someone other than the CEO. 5. A section on the document for each person above to write their comments. 6. The R then reaches out to all the As, Ps, and Is to solicit their input. Once this input is received, the document is ready to be reviewed by the D. If the ISP involves an off-cycle budget change over $100K, R should work with finance team for their estimate of impact to financial plan. 7. The R schedules a Decision Meeting and invites the D, As, Is, and Ps. * If the issue is urgent, the R schedules this Decision Meeting as soon as it needs to be. * If the issue is non-urgent, the R can use the next Team Meeting as the Decision Meeting. This is much more efficient, and should be done whenever the issue is non-urgent. 8. At the Decision Meeting, the D reads through the document. If they have any questions, they asks them. If the questions can be fully answered in 5 minutes, they decide. If the questions can't be answered in 5 minutes, the D asks for another round of written responses on the document to answer the questions. At the next Team Meeting, the D reviews these responses, and decides. 9. Once the D decides, they write up the Decision (or asks the R to do so) along with all the Next Actions (each with a DRI and Due Date). The D then publishes this decision to the company via the appropriate ticketing system and/or other channels. # Company agreements **Note: Pull Requests for updates to this page need to be signed off by both CFO and CEO in the PR process.** ## Who can sign on behalf of the company? Company agreements should only be signed by CEO, Ian Tien, or CFO, Kendra Niedziejko, with the following exceptions: * If you are on-site and need to sign an NDA to enter a facility you may sign such an agreement. * The following agreements may also be signed by the VP Legal, Nirosha Ruwan: * Non-Disclosure Agreements. * Data Privacy Agreements * The following agreements may also be signed by the CFO, Kendra Niedziejko. * Unmodified Order Forms where the Customer is requesting a Mattermost signature. * Vendor contracts. * Any contracts with terms that could have material impacts on financing or M\&A transactions may only be signed by the CEO (e.g. non-standard liability, indemnification or inability to assign the agreement). Use the [Authorization Matrix](https://docs.google.com/spreadsheets/d/1fDIMiO0uydB_1zCUxZ4sGfSnBJ0P_49zbeQGgTqbYPI/edit?usp=sharing) for a full list of document types and threshold levels. ## Who can send contracts for signature? The following staff are approved to send contracts to be e-signed: ## Approved Mattermost staff * Lynn Conway - Primary for staff agreements * Amy Nicol - Primary for vendor contracts, consulting agreements, and corporate agreements * Nikki Johnson - Primary for sales agreements and customer supplier forms * Jeff Dynda - Approved vendor contracts from legal and customer supplier forms * Natalie Jew ## What are e-sign completion expectations? * E-sign request sent on weekdays before 4pm Palo Alto time should be signed by 9pm Palo Alto on the same day and if sent on a weekend signed by 9pm Palo Alto time on the following Monday provided one of the following is true: * **For e-sign from Mattermost staff member:** The e-sign is sent by a Mattermost staff member and must have Legal approval. E-signs sent from approved Mattermost staff are preferred since they are archived automatically in our e-sign system. * **For e-sign from outside the company:** The e-sign is prepared by a non-Mattermost staff member (potentially a vendor, partner or customer) and Legal approval is provided via email to Ian Tien and Amy Nicol ideally ahead of receiving the e-sign request. * Within 5 business days of the e-sign completion the contract owner or Mattermost staff submitting for signature should send Amy Nicol a link to the Box.com URL containing the fully executed signature to confirm the archiving of the contract is complete, since archiving is not automatic. * **Note:** E-sign requests from non-Mattermost staff are automatically filtered to a spam folder and the spam filter needs to be searched to find the request. * If the timeline is urgent, or if the e-sign isn't completed by the expected timeline please send Ian Tien and Amy Nicol a Group Direct Message on the Mattermost server to expedite. ### How to wet sign an agreement * A "wet sign" agreement requires printing and physically signing paperwork with a pen, which is required by some regulatory bodies. * Culturally, it is important we have a smooth, clear process that makes physically signing paperwork in a remote company almost as easy and error free as signing in a physical office. * **Wet sign process** * The wet sign process should follow the same workflow process as an e-sign process in terms of oversight and approvals, but instead of running the final e-sign a physical signing packet should be created with: * Two copies of printed paperwork to be signed. * Each should have sticker labels indicating what is needed to sign, so nothing is missed. * A pen. * Appropriate envelopes and/or UPS mailing labels to send the signed package on after it is received. # Publishing This page provides processes and guidelines for publishing in our public web properties. The goal is to have clear public web properties where it is easy to find solutions to problems or questions you have for each of our audiences: * **Staff** to do their work effectively. * **Users** (including developers, administrators and end users) and **Buyers** to easily adopt and purchase Mattermost. * **Contributors** to easily contribute to Mattermost. ## Principles **Trust** * Consistent experience across public sites, including brand and voice. * No inaccurate information. * No "dead ends" where the user does not have a pathway to continue. * No confidential information. **Growth** * Effective self-service where anyone can find solutions to problems or questions starting from a Google search. * Scalable processes and guidelines that empower everyone to contribute. **Iteration** * Iteration over completeness, with constant openness to feedback. ## Directly Responsible Individuals Below are the tentative directly responsible individuals (DRIs) and success measures for each of our audiences: | Audience | Owner | Success Measures | | --------------- | ------------------------------------------------- | ------------------------------------------------------------ | | **User** | [Justine Geffen](http://github.com/justinegeffen) | % visitors adopted Mattermost; content NPS | | **Buyer** | TBD | % visitors purchased or renewed Mattermost; content NPS | | **Contributor** | [Joram Wilander](http://github.com/jwilander) | % visitors contributed to Mattermost; content NPS | | **Staff** | [Jason Blais](http://github.com/jasonblais) | % visitors successfully onboarded at Mattermost; content NPS | Please read the following articles to learn more: * [Public web properties](https://handbook.mattermost.com/operations/operations/publishing/web-properties) * [Publishing guidelines](https://handbook.mattermost.com/operations/operations/publishing/publishing-guidelines) * [Post-publication quality control process](https://handbook.mattermost.com/operations/operations/publishing/quality-control-process) # Public web properties This page is a work in progress. ## Areas of ownership Below is a summary of our public web properties, including their target content, publishing system and areas of ownership: | Domain | Content | Publishing System | Content Owner | Quality Control Owner | | ----------------------- | ------------------------------------------------------------------------------------ | -------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------- | | docs.mattermost.com | Technical product documentation for end users, administrators, and developers | Exploring Hugo with Markdown\*\* | [Justine Geffen](http://github.com/justinegeffen) | [Justine Geffen](http://github.com/justinegeffen) and [Amy Blais](http://github.com/amyblais) | | TBD | Technical articles, guides, videos, and courses | Exploring Hugo with Markdown\*\* | [Jason Blais](http://github.com/jasonblais) | TBD | | TBD | Contributor documentation and relevant community communications | Exploring Hugo with Markdown\*\* | [Joram Wilander](http://github.com/jwilander) | [Joram Wilander](http://github.com/jwilander) | | TBD | Self-service support content, including knowledge-based FAQs | TBD | TBD | TBD | | handbook.mattermost.com | Internal processes for company operations and recruiting | GitBook with Markdown | [Jason Blais](http://github.com/jasonblais) | [Justine Geffen](http://github.com/justinegeffen) and [Amy Blais](http://github.com/amyblais) | | mattermost.com | Commercial site, including blogs, product offerings, customer case studies, and more | Wordpress | [Hanna Park](https://github.com/hannaparks) | [Asaad Mahmood](https://github.com/asaadmahmood) | \*\* We are exploring Hugo as the system of choice for documentation sites, given it supports advanced search, Markdown language, and a GitHub review process to ensure consistent quality across the site . ## Information architecture Below is the tentative top-level information architecture for each of the above domains, work in progress. See a [more detailed analysis on information architecture recommendations](https://docs.google.com/document/d/1CaRpCo0Aic-bDIKGtIA5mbtaH7JarCH-3v7rP-SBFHk/edit#) for Docs, Education, Community, and Support. ### handbook.mattermost.com The handbook is developed with the following structure: * About Mattermost, including mission, vision, leadership principles, company, and history * Culture, including our remote-first culture, standards, and MatterCon * Join Us, including why to work at Mattermost and open positions * Onboarding, including guides for new staff and managers * Operations, including mindsets, cadences, metrics, and definitions ### .../docs Since much software follows recognizable patterns these days, product documentation is shaped into familiar schemas. This often takes the form of product areas/topics, or common use cases. Thus, information architecture is organized by topic or use case, such as below (exact architecture yet to be determined): * Install and Configuration * Deployment * User Management * System Administration * Account Settings and Notifications * Integrations and Plugins * RESTful API * Customization Good examples of this approach include: [Stripe](https://stripe.com/docs) | [Docker](https://docs.docker.com/) | [Twilio](https://www.twilio.com/docs) ### .../education Here, the focus is on providing learners access to content by their learning style and provides a mechanism with a currently limited scale of content. It is divided into three categories: * Guides * Videos * Courses From here, further organization based on themes (informed by persona use cases), as content is made available. Later, as content evolves, content may be based on particular personas and their learning paths. ### .../community Here, the information architecture is organized by [types of community members](https://docs.mattermost.com/process/community-overview.html), including users and contributors. A sample architecture for contributors may look like: * Contributor Process * Platform and Solution Development, including content in * Translations * Documentation * etc. ### .../support No information architecture is yet defined, but in general it will consist of: * Support Resources (including peer-to-peer forums) * Knowledge Base FAQs ### mattermost.com The Mattermost website is developed with the following architecture: * Product, including features and integrations * Pricing * Solutions, including use cases * Case Studies * Resources, including training and blog * Docs, including installation and configuration # Publishing guidelines This page provides publishing guidelines, including * [Brand and Visual Design Guidelines](https://handbook.mattermost.com/operations/operations/publishing/publishing-guidelines/brand-and-visual-design-guidelines) * [Voice, Tone and Writing Style Guidelines](https://handbook.mattermost.com/operations/operations/publishing/publishing-guidelines/voice-tone-and-writing-style-guidelines) * [Confidentiality Guidelines](https://handbook.mattermost.com/operations/operations/publishing/publishing-guidelines/confidentiality-guidelines) # Brand and visual design guidelines ## The Mattermost logo The logos below are available for use in your integrations and applications that connect to Mattermost. Use of the logo is permitted as long as it’s used in a non-commercial way and does not imply endorsement by Mattermost, Inc. ![](/files/-MUpBGij1H3q3Va1ppIT) The Mattermost logomark is called **"the instrument"**. It represents four tools that organizations need to achieve their highest priorities: * A compass for direction * A clock to set pace * A meter to measure output * A dial representing inputs — the contribution of everyone on the team ### Logo variations The Mattermost logo is available in vertical, horizontal, and logomark-only versions. The logo can be represented in black or white as displayed below. **Horizontal Logo:** Min size 100x16px \| ![Mattermost Horizontal Logo Black](/files/ExDjByztZy3OWRv7nQYz) | | ![Mattermost Horizontal Logo White](/files/7Wgdvpw0a5fxDoZzXWDQ) **Vertical Logo:** Min size 70x39px \| ![Mattermost Vertical Logo Black](/files/uofnVPAEMNIpFf0S8OVy) | | ![Mattermost Vertical Logo White](/files/qSofoopVpzakncLWxV7O) | **Logomark:** Min size 16x16px ![Mattermost logomark](/files/-MUpBGiqTkxI6ZQGHubn) ### Usage guidelines #### Clear space To ensure an uncluttered presentation, always maintain a full "X" space around the logo. The "X" height is always the height of the lowercase letter "m" in "Mattermost". Use the safety area as an invisible border. ![](/files/29lLq6x96GLbMEAULJ7k) #### Misuse Please use the Mattermost logo with care. Don’t alter the Mattermost logo in any way: * Don’t redraw the logo. * Don’t warp the shape. * Don’t recolor the logo. * Don’t apply effects. * Don’t crop the logo. Make sure you’re using the correct version: some old and distorted versions from the past exist and should be replaced. ![](/files/TOFNljqlbczRyABp81Ob) ### Logo downloads [You can download all Mattermost logo files here](https://mattermost.com/brand-guidelines/). ## Brand guidelines You can view the [Mattermost Brand Guidelines here](https://mattermost.com/brand-guidelines/). ## Name usage guidelines Using the Mattermost name is generally permitted as long as it’s used in a non-commercial way and does not imply endorsement by Mattermost, Inc. * Please do not name your integrations or apps starting with, or only using, the name "Mattermost", as this may confuse end-users as to where to find support. Community projects might be named using "for Mattermost", examples: * [GitLab Integration Service for Mattermost](https://github.com/mattermost/mattermost-integration-gitlab) * [Giphy Integration Service for Mattermost](https://github.com/mattermost/mattermost-integration-giphy) Alternatively, community projects may concatenate names containing Mattermost, for example: * [Matterbridge](https://github.com/42wim/matterbridge) – is a Mattermost bridge connecting with IRC * [Mattersend](https://github.com/mtorromeo/mattersend) – is a Mattermost integration for sending webhook events **Exception:** Please don’t use the name “matterbot”, as that is an internal service under development. ## Company short description Mattermost is an open source platform for secure collaboration across the entire software development lifecycle. Hundreds of thousands of developers around the globe trust Mattermost to increase their productivity by bringing together team communication, task and project management, and workflow orchestration into a unified platform for agile software development. Founded in 2016, Mattermost’s open source platform powers over 800,000 workspaces worldwide with the support of over 4,000 contributors from across the developer community. The company serves over 800 customers, including Samsung, Nasdaq, SAP, European Parliament, and the United States Air Force, and is backed by world-class investors including Redpoint, YC Continuity, Battery Ventures, and S28 Capital. To learn more, visit [www.mattermost.com](http://www.mattermost.com). # Voice, tone, and writing style guidelines ## Voice and tone Our voice is informed by our foundation as a messaging platform for Enterprise Developers and DevOps, but respects that our client base spans many types of organizations. Writing is one way we can bring Mattermost’s values to life. And above all, our voice demonstrates our deep respect for our clients and users. Ultimately, Mattermost exists because of them, so it’s important we keep their needs at the forefront of our writing style. Mattermost's voice is: * Clear * Concise * Consistent * Customer-centric * Professional To achieve this, we keep the following principles in mind when writing content: * Write clearly and concisely - get to the point quickly without losing valuable information * Use simple, plain language that is easy to understand and family-friendly * Avoid jargon and overly technical terminology * Use direct, casual tone instead of an informal tone * Use the active voice * Write short, active sentences and maintain a visual separation between page elements * Focus on what the target audience wants to accomplish by being practical/outcome-focused * Write for an international audience without idioms or expressions that people outside of your country/region are unlikely to understand We generally avoid the following statements and phrases as they're overused and vague: * "Work better" * "Do better work, faster" * "Get more done in less time" * "Chat" (as a stand-alone feature reference. However it is ok to use chat when describing a benefit "Create a Jira ticket without leaving your chat window." ) * "DevOps teams" * "Utilize" (instead, use “use”) * "High performance teams" * Phrases that directly praise ourselves: “We’ve built an intuitive workplace messaging solution.”, “It’s a joy to use.” The appropriate tone differs across different mediums. We don’t write technical and help documentation with the same tone as website copy or educational content. You can vary your tone to fit the situation, just as you’d talk to an angry person with a different tone than with an excited child. Voice is to tone as climate is to weather. The Mattermost voice remains the same, even when the tone varies. Visit our [Documentation Style Guide](https://handbook.mattermost.com/operations/research-and-development/product/technical-writing-team-handbook/documentation-style-guide) for additional information and examples. ## More information These guidelines were inspired by [Stripe's knowledge base content](https://document360.io/blog/tear-down-of-stripe-knowledge-base/) and [by other sites shared in this Document360 article](https://document360.io/blog/10-knowledge-base-software-best-practice-examples/). [Learn more about recommendations, analysis and next steps](https://docs.google.com/document/d/1LNAgmKKtmRN1T7UCvOgcUbGiFfk8UXqcmCgF80-sVyQ). # Contribute to documentation # Confidentiality guidelines By default, Mattermost defaults to [open actions](/company/about-mattermost/list-of-terms#open-actions) for publicly documenting information in a web-discoverable format. Below is a set of guidelines on what information is considered confidential and should not be published publicly: * Financial information related to Mattermost, such as revenue and cash, as this may impact potential future funding and IPO. * Usage metrics and analysis related to Mattermost deployments (such as telemetry, trial conversions, DAU) as this may impact potential future funding and IPO. * Personal information related to staff, customers or community, including residence and full name unless otherwise publicly disclosed. * Customer information received during support or sales discussions, including customer name unless usage of Mattermost is otherwise publicly disclosed. * Open discussions about security vulnerabilities, as this may put our users at risk of security attacks. # Post-publication quality control process Quality control process is a work-in-progress, but is based on the principles of iteration and empowering everyone to write an MVP. ## Empowerment Everyone in our community, including users, contributors and staff, should feel empowered to contribute minimal documentation that adds to or improves existing content. Typical barriers to contributing includes: * Uncertainty of where to add content * Uncertainty of how to structure the content (paragraphs etc) * Too many rules and guidelines * English not first language * Intimidating comments or feedback * Limited or no experience in writing documentation Our quality control process should ensure we reduce or in some cases remove these barriers to empower everyone to contribute to our public web properties. ## Iteration In addition to empowerement, a second key principle is iteration. When we iterate, we do the smallest thing possible that adds value, and get it out as quickly as possible. By iterating in partnership with stakeholders, we're quickly listening, understanding, learning, and shipping. Thus, the quality control process will be focused on post-publication, where updates can be made after the initial version of content has been published. # Handbook processes and policies Welcome to the Mattermost Handbook process, policy, and onboarding section. As a remote-first company, we rely heavily on shared knowledge. Often, that knowledge is stored in peoples' heads, on a notepad somewhere, or in a Google Doc. The purpose of the Handbook is to capture everyone's knowledge of how Mattermost works so that we can all have access to it. This means that there's no ambiguity or confusion. It also means that when new staff members join us, it's easier for them to ramp up. So, let's get started! ## Handbook-first As we mature, a Handbook-first policy is critical. But what does this mean? Handbook-first means that when you have a new idea, a new process, an update to a process, a change in your team, etc you document it in the Handbook first. For example, when a new staff member joins us, they should be added to your team's page before their first day. Another example is if you've created a new Jira process - first document it in the Handbook and then announce it to your team/the company. This allows you to find blindspots and also means that people can go to the relevant page immediately after the announcement to read more. ### How do we drive Handbook-first? Great question. It's a team effort across the whole company, but we plan to have a secret weapon in the form of Handbook Champions. ## Handbook Champions A Handbook Champion is a volunteer from a specific team/operational area who drives Handbook-first adoption and acts as a go-to in the team for Handbook questions. They also enjoy saying "oh you can find that in the Handbook!" and "You should put the in the Handbook!". They're motivated by the understanding that a single source of truth is empowering and decreases wasted time. Lastly, Handbook Champions enjoy working with their team to ensure processes, ideas, plans, and everything in between are documented in the Handbook. The long-term goal is that Handbook Champions will have a huge impact on Mattermost by supporting constant iteration, decreasing the barrier to information, and breaking down knowledge silos. ### What's expected of Handbook Champions? The only requirements are that you're excited about the Handbook and knowledge sharing, and love knowing that you're building something indispensable. There's no set time or output expectation - and it's completely voluntary. The idea is not to have you write or update everything yourself, but to corral your team/operational area and get them into the habit of documenting everything in the Handbook. Another aspect is sharing outstanding Help Wanted issues with your team to see where any gaps can be filled. However, if the Handbook is something you're passionate about: * You can take as much initiative as you want. * You can suggest and own new content. * You can help drive change and alignment if that’s what you’re interested in. ### What do I need to do? To put it simply, anytime someone in your team/operational area mentions a process in a meeting or asks about one, remind them that they should either document it or can find it in the Handbook. You may also be asked to review PRs before they're merged. In time, you'll find that you're reminding less, and being asked to review more... until Handbook-first becomes a company habit. Of course, if you have ideas for content that's needed or content that should be updated and you're happy to tackle some of it that's fantastic. Likewise if you have suggestions, ideas, complaints, or issues - feel free to raise them. ### How do I get involved? You can join the [Handbook Champions channel](https://community.mattermost.com/private-core/channels/handbook-champions), and then also update [this list](https://docs.google.com/spreadsheets/d/1emT9vTA-D61uESeQdLuFZY-dY6MNBDpyaH7z_pw6hYI/edit?usp=sharing) with your name and team/organizational area. There can be multiple champions per team. ### Will there be meetings? Yes. We'll sync up once every two weeks initially, for 25 minutes. This will allow us to catch up, sync up, and keep up. ### Do I get a cool badge? Yes! You get a Handbook Champion badge, and may also be eligible for a Contribution Champion badge, depending a number of factors. There's also swag on offer (of course!) # Handbook onboarding The Mattermost Handbook is a work-in-progress in that information is constantly being updated, added, revised, and edited. ## Editing the Handbook The Handbook is open to the public and edits can be submitted by anyone. ## Adding content You don't need to ask permission to add content to the Handbook. Follow the steps in [How to update the Handbook](https://handbook.mattermost.com/company/how-to-guides-for-staff/how-to-update-handbook) to get started. ## Questions, suggestions, bugs If you have an idea for content, you can submit an issue detailing your idea. The more information you provide the better. That said, if you have content ideas why not add it to the Handbook, open a PR, and see where that goes. # Fiscal year planning Mattermost fiscal year ends on January 31. As part of the yearly planning, we use various documents as references. Below is a list of references used for FY24 Strategy & Plan (link to be added). * [Nov 2022 COM Presentation of Thematic Goal & Defining Objectives](https://docs.google.com/presentation/d/19shfHNoUMs4Z-lS_eh7Qh65jE54ZYQbQQHFhqRvQpFo/edit#slide=id.g19c6ca47425_0_992) * [FY24 Message House](https://docs.google.com/document/u/1/d/1IZUL74p6qAQJvduOrElzJbZtLbyAIkRJQdQ8v1iObvU/edit) * [FY24 Pricing & Packaging Principles](https://docs.google.com/document/d/1pKxiEevyM_dVb2MKoa-m50ZC_t6zCZ4vntGBbfazG1s/edit) * [FY24 Product Editions & Plans](https://docs.google.com/document/d/1bAsnfCRsp23d30FEMLluf0zcpvsizTAme_acZ4PdSOc/edit#) * [FY24 Company-Level Goal Tracker](https://docs.google.com/spreadsheets/d/1n_BShB_rrn3kNx0vCgQ-hnf4ZaRsnjz8ZT7UCEFTZ_4/edit#gid=311756856) * [FY24 Prioritization Worksheet](https://docs.google.com/spreadsheets/d/1epHwKC6QgcruA1aajbRX-Z8oA81KNDiQTECrOX9uJ1g/edit#gid=1080622947) * [FY23 Strategy and Plan](https://docs.google.com/document/d/1Rq3hPLXLrmA5wTAacDkDjySZrpdYpf2zX-3lm3ymxV4/edit#heading=h.az0lixiueeoa) * [Simon & Kutcher Final Packaging Readout](https://drive.google.com/file/d/1xtTbp6n6SdyToEs35gefBMSWFOwRHWng/view) * [Simon & Kutcher Full Packaging Deck](https://docs.google.com/presentation/d/1yhzgrF07dof04HWKDeftnEHZgwK--asl-mhJpaj31JA/edit#slide=id.p) * [Redpoint metrics template](https://docs.google.com/spreadsheets/d/1cdtqPcEcpP9lxqrOINH_FsxF8HBzaE6oKtAU9kPr6-k/edit#gid=0) * [MLX Areas of Responsibility](https://community.mattermost.com/boards/team/qghzt68dq7bopgqamcnziq69ao/bxekuo4ea9tn5b8jpj3zzogtfuh/vqdsdwgjnm7bsbd7cbukwknut9a) * [Acronyms](https://handbook.mattermost.com/company/about-mattermost/list-of-terms) # Product, Design, and Engineering (PDE) Product, Design, and Engineering (PDE) includes engineering, QA, product management, documentation, analytics, community, and design (UX, UI). PDE was formerly known as *Research and Development*, the name was changed to highlight Mattermost's commitment to Design and focus on Product. ### PDE Key Info * [Analyst Research](https://community.mattermost.com/private-core/channels/analyst-research): Analyst meeting tracker, briefing procedures, research. We are currently Gartner clients. * [Compete](https://community.mattermost.com/private-core/channels/compete): Key articles on competitors. Also see [automated feeds from competitor marketing](https://community.mattermost.com/private-core/channels/compete-feeds). ### What tools we use We use a variety of tools at Mattermost. Not every team uses the same tools, and it can get overwhelming to try remember who uses what and where it is. During onboarding you'll be provided with a list of tools to set up. You can also visit the [Helpdesk](https://helpdesk.mattermost.com/support/catalog/items) to find the tool and request access. ### Where to find information We use a range of web properties and tools to document and share plans, specs, roadmaps, and release schedules. * Product roadmaps, feature releases, planned features: [Features by release productboard](https://mattermost.productboard.com/roadmap/2855466-features-by-release), [Release roadmap by vertical](https://mattermost.productboard.com/roadmap/2941622-release-roadmap-by-product-vertical). * Product specs: [Teams](https://mattermost.atlassian.net/wiki/spaces?label=teams), [Software project](https://mattermost.atlassian.net/wiki/spaces?label=software-project) * Apps, integrations, plugins: [Integrate](https://developers.mattermost.com/integrate/getting-started/) * How to get started with contributing and developer set up: [Getting started](https://developers.mattermost.com/contribute/getting-started/) * Designs and mockups: [Figma](https://www.figma.com/files/802235376456811310/recent?fuid=788840938074139976) * How open source software is developed: [Development & Release Process](https://handbook.mattermost.com/operations/research-and-development/product/release-process/release-overview) * How contributors can get involved: [Platform Contribution Process](https://handbook.mattermost.com/contributors/contributors/community-playbook) * Analytics playbook and data wallows: [Analytics](https://community.mattermost.com/private-core/channels/analytics-2) ### Where to find us * Technical writers: [DWG: Documentation Working Group](https://community.mattermost.com/private-core/channels/dwg-documentation-working-group) * Product Managers: [Product Management](https://community.mattermost.com/private-core/channels/product-management) * UX team: [UX Design](https://community.mattermost.com/core/channels/ux-design) * Analysts: [Analytics](https://community.mattermost.com/private-core/channels/analytics-2) * Community: [Community Team](https://community.mattermost.com/private-core/channels/community-team) **Tip:** We generally use channel naming conventions to make it easier to find channels. Team channels are prefixed with "team", feature channels prefixed with "feature" and so on. For example, if you're looking for a team channel, open the channel browser and search for "team". ## Who we are PDE is led by: * Joram Wilander - Director, Engineering * Jason Blais - VP, Product and Program Management We use [this spreadsheet to track the organization structure](https://mattermost.sharepoint.com/:x:/s/org-pde/Ea5II-MK6xRHruGtj7CUbl4BKxZOaxx0BnfS8cW8RWQi2A?e=KMsR59). # Organization The source of truth for the R\&D org structure and team membership is [this spreadsheet](https://docs.google.com/spreadsheets/d/1lH8QIjQGEoGospDUdVs_LQ_i2b82I1ce6W7z18vhPTQ/edit#gid=1820415931). ## Divisions R\&D is split into multiple divisions, detailed below. Areas of responsibility (AORs) for each team are linked. ### Product The Product division develops and ships the majority of anything product related. It consists of full stack teams made of developers, UX designers, QA analysts, technical writers and product managers. These teams work together on the core product features, frameworks, platform and performance. See [the spreadsheet](https://docs.google.com/spreadsheets/d/1lH8QIjQGEoGospDUdVs_LQ_i2b82I1ce6W7z18vhPTQ/edit#gid=1820415931) for team members and AORs. **Please use the following community channels to discuss particular product topics:** * [Channels](https://community.mattermost.com/core/channels/messaging) * [Playbooks](https://community.mattermost.com/core/channels/developers-playbooks) * [Calls](https://community.mattermost.com/core/channels/developers-channel-call) * [Integrations & Apps](https://community.mattermost.com/core/channels/integrations) * [AI](https://community.mattermost.com/core/channels/ai-exchange) * [Server](https://community.mattermost.com/core/channels/developers-server) * [Mobile](https://community.mattermost.com/core/channels/native-mobile-apps) * [Desktop App](https://community.mattermost.com/core/channels/desktop-app) * [Web App](https://community.mattermost.com/core/channels/webapp) * [Feature Proposals](https://mattermost.com/suggestions/) ### Data Engineering The Data Engineering division builds and supports the data infrastructure and analysis tools. * [**Data Engineering**](/operations/research-and-development/organization/data_engineering) ### Infrastructure The [Infrastructure](/operations/research-and-development/engineering/infrastructure-engineering) group empowers Mattermost to provide a SaaS Platform as Product which serves internal and external users by guaranteeing that we operate an enterprise-grade SaaS platform with self-serve powers. * [**Delivery**](/operations/research-and-development/organization/delivery) * [**Cloud Platform**](/operations/research-and-development/organization/cloud_platform) * [**Site Reliabilty Engineering**](/operations/research-and-development/organization/sre) ### Security The Security division is responsible for the implementation and monitoring of the company's security program. * [**Governance, Risk, and Compliance (GRC)**](/operations/research-and-development/organization/grc) * [**Product Security**](/operations/research-and-development/organization/product_security) * [**Security Operations**](/operations/research-and-development/organization/security_operations) ## Calendar The [R\&D Calendar](https://calendar.google.com/calendar/u/0?cid=bWF0dGVybW9zdC5jb21fdTc3cWxscjB2NDVhM3ZzczdycWN1dHQ3ZDRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) highlights recurring events such team planning meetings, guild meetings, hangouts, and office hours. Adding these events to a shared calendar accomplishes several purposes: * It improves the onboarding experience by allowing new staff members to self-discover meetings of interest. * It reinforces our culture of being "default open", even if most of the time only those explicitly invited show up. * It allows for occasional guest participation without having to juggle a permanent invite. ### Guest Participation All staff are encouraged to occasionally join another team's planning meeting. In addition to learning more about the product and areas of ownership, this can be a chance to see how that team works together and incorporate the best parts on your own team. It's not necessary to ask permisison to join a meeting on the R\&D Calendar, but focus on being a listener instead of a contributor to avoid distracting the team. ### Adding events to the R\&D Calendar All staff in R\&D have permisison to invite the R\&D Calendar to recurring meetings. When adding a guest, search for `R&D` and be careful not to invite `rnd@mattermost.com` which would invite everyone in R\&D. Instead, simply invite the calendar itself: ![Invite the R\&D Calendar](/files/JEqx9m11eTFGD7xogrgv) The calendar will not "accept" the invite by default, with the invitation showing up as pending. With the calendar visible, select the event and accept the invite so the calendar appears uniform: **Before Accepting** ![Not yet accepted](/files/7AuR53Whx0v3xvrEKDoJ) **After Accepting** ![Accepted](/files/JPPkTYLr8CAhmynoMpLx) # Tech Writing The Tech Writing team is responsible for maintaining the Mattermost Documentation site and stewarding the quality of other Mattermost knowledge and language repositories used within Mattermost products. ## Areas of Ownership * docs.mattermost.com * Information architecture and quality of developers.mattermost.com * In-product UI text * Mattermost Product Translations * Information architecture and quality of handbook.mattermost.com # Data engineering The Data Engineering team is responsible for data warehouse and management. ## Areas of Ownership * Data warehouse & management * Data Pipelines * ETL scripts and data transformations * Data connections to Looker, dbt * Rudderstack, Snowflake, Airflow, Stitch # Delivery ## Mission The Delivery team enables Mattermost Engineering to deliver products of **high quality**, **secure**, **scalable**, and **efficient** fashion to Mattermost customers. The team ensures that Mattermost scheduled, security, and patch releases are publicly released in a timely fashion. ## Vision By its own nature, the Delivery team is a backstage, non-user feature facing team whose product and output has a high impact on day to day development operations, quality and releases. The team creates the workflows, frameworks, tools, architecture, and automation for Engineering teams to see their work reach production effectively and efficiently. ## Actions * CI/CD blueprints, tooling & infrastructure for dev & testing workflows * Automation test framework * Automate release generation and reduce Release Manager toil work * Improve security principles in Mattermost software supply chain * Extend release environments to improve testing for Mattermost releases ## Principles * Guard and raise end-product quality standards * Treat our work like a product * Promote self-serve * Aim to make our work easy to use * Influence best practices ## How we work ### Reaching our Team Every week we have a support rota who is responsible for troubleshooting any S1/P1 related issues. | Reason | Contact (order priority) | Via | | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | | S1/P1 Deployment/Release related issues |
  • @release-manager group mention
  • @delivery-rota group mention
| Mattermost | | Quality related issues / verification |
  • @qa-guild group mention
| Mattermost | | CI/CD Blueprints & Automated testing issues for day to day | | Mattermost | | Influence and help with best practices | | Mattermost | ## Areas of Ownership The team regularly works on the following tasks, in the order of priority: * Ensuring continuous delivery of Mattermost products to SaaS and self-managed * Participating in incident resolution and acting on corrective actions for SaaS and self-managed software delivery * Minimizing the use of custom tooling by building or enhancing features within Mattermost * Improving the robustness of SaaS software delivery by creating and improving tooling (release & testing) * Coordination, education, and preparation of Mattermost releases for SaaS and self-managed users for the scheduled minor, patch, and security releases * Review release metrics ## Meetings | Topics | Meeting | Participants | Cadence | | ----------------------- | -------------------- | --------------------------------------------- | -------- | | Triage & Planning | Delivery Planning | Delivery | Tuesday | | Cross-org collaboration | Infrastructure Guild | Leadership, Infrastructure, Product, Security | Thursday | # Cloud Platform The Cloud Platform team is responsible for our Mattermost Cloud SaaS technology. ### Vision Enable everyone to build and deploy with high velocity in a self-served manner. ### Actions * Increase developer productivity * Influence Cloud readiness * Input driven decision making * Encourage best practices and keep quality standards high * Keep experimenting * Keep documentation fresh ### Principles * Balance stability and experimentation * Embrace teamwork * Leave the room better than it was * Data/Feedback driven to find the best solution * Distributed systems, distributed team * Be curious and keep learning * Share knowledge and seek feedback ### Ask for Help If you need our assistance please use the following follow the [General Workflow](#general-workflow) We can also be reached out: 1. For support questions related to production you can reach us in `~cloud-support` channel. 2. For all the other questions you can reach us in [\~infrastructure-platform-team](https://community.mattermost.com/private-core/channels/infrastructure-platform-team) channel ### How we work #### General Workflow 1. Mattermost members open new issues in [Platform Board](https://mattermost.atlassian.net/jira/software/c/projects/CLD/boards/129) 2. Every new issues goes through an Issue Triage weekly ### Areas of Ownership The team regularly works on the following tasks, in the order of priority: * Ensuring provisioning, rolling out and controlling the workspaces fleet with an automated manner (eg. provisioner, k8s operator) * Improving developer productivity with providing self-served capabilities for testing envs in cloud developer platform (eg. [spinwick](https://handbook.mattermost.com/company/about-mattermost/list-of-terms#spinwick), cloud plugin) * Ensuring and supporting other teams for cloud readiness (eg. Mattermost migrations, database connection pooling) ### Meetings | Topics | Meeting | Participants | Cadence | | ----------------------- | -------------------- | --------------------------------------------- | -------- | | Triage & Planning | Platform Planning | SRE, Platform | Tuesday | | Cross-org collaboration | Infrastructure Guild | Leadership, Infrastructure, Product, Security | Thursday | # Site Reliability Engineering ### Who We Are Site Reliability Engineering (SRE) team ensures the availability of Mattermost Cloud user-facing services, building the tools and automation to monitor and enable this availability. These user-facing services include multiple environments including testing, development and production, among others. ### Vision Enable developers to build reliable, scalable, cost efficient services that keep the Mattermost Cloud customer's reliability targets (SLA, SLO) and SRE principles (observability, SLOs etc.) in mind. ### Actions * On-call, Incident Management and Incident Review * Change management * Influence and encourage best practices * Maintain and update documentation, training, and Runbooks * Empower developers with self-serve tools * Meet & review reliability, quality, and cost KPIs regularly ### Principles * Be proactive instead of reactive * Be open and data driven * Embrace risk and chaos * Promote and embrace communication * Evangelise cost effectiveness * Evangelise and adopt SRE & DevOps practices ### Ask for Help If you need our assistance please follow the [General Workflow](#general-workflow) You can also reach us on the Mattermost Community Server as follows: 1. For support questions related to production you can reach us in `~cloud-support` channel. 2. For all the other questions you can reach us in `~cloud-sre-team` channel ### How we work Each quarter, we maintain our OKRs as epics in this [board](https://mattermost.atlassian.net/jira/software/c/projects/CLD/boards/109/roadmap?statuses=2%2C4) which is divided into the following areas: * Reliability & Resiliency * Availability & Cost Optimisation * Automation * Security * Documentation * Keep the lights on #### General Workflow 1. Mattermost members open new issues in the [SRE Board](https://mattermost.atlassian.net/jira/software/c/projects/CLD/boards/109) 2. New issues are reviewed weekly via Issue Triage. ### Areas of Ownership The team regularly works on the following tasks, listed below in priority order: * Ensuring availability of Mattermost Cloud user-facing services * Ensuring availability of community.mattermost.com (e.g. daily releases, calls) * Ensuring the availability of the internal Cloud Platform (e.g. self-serve testing environments, Observability Platform, GitOps Platform, IaC platform ) ### Meetings | Topics | Meeting | Participants | Cadence | | --------------------------------- | ----------------------- | --------------------------------------------- | -------- | | Incident Review & Knowledge share | Reliability Engineering | Cloud leadership, SRE, Release | Monday | | Triage & Planning | SRE Planning | SRE, Platform | Tuesday | | Cross-org collaboration | Infrastructure Guild | Leadership, Infrastructure, Product, Security | Thursday | | Bring chaos to our systems | Chaos Gameday | SRE | Monthly | # GRC The team is responsible for the implementation and monitoring of the companies governance, risk, and compliance program within the company. ## Areas of Ownership * Third-Party Risk Management * Security Policies * Security Risk Register * Customer Security Questionnaires / RFPs * Security Compliance * SOC 2 # Product Security The Product Security team is responsible for identifying and managing solutions to protect Mattermost product security. ## Areas of Ownership * Responsible Disclosure Program * Security Reviews * Plugins * Features * Architecture * Release Pipelines * Bug Bounty Program * Threat Modeling * Security Automation * SAST * SCA * SBOM * Penetration Testing (Product) * Security Release Notes # Security Operations The Security Operations team is responsible for the security monitoring and operational security policies of the Mattemost organization. ## Areas of Ownership * Security Incident Response Program * Active monitoring and analysis of security events taking place across company, product, and service, platforms * Implementation, upkeep, and growth of security monitoring and analysis platforms * Availability of log ingestion and processing infrastructure * Create, review, and enforce operational security policies, procedures, along with controls related to existing and future-planned compliance frameworks * Infrastructure Vulnerability Management Program * Maintain visibility of industry trends, emerging security issues, 0day/vulnerabilities * Contribute to customer security questionnaires on operational security and compliance topics * Act on results of Red Team / Penetration Testing against Mattermost (the company) and product/service infrastructure * Monitoring and upkeep of Endpoint Detection & Response (EDR) * Access control for Engineering tools and services, and integration with Okta * Engage in verification and impact of product vulnerabilities as it relates to Community and Cloud-hosted instances * Analysis, verification, and reaction to phishing and other malicious email * Management and upkeep of Vault infrastructure and policies * Management and upkeep of Teleport (cloud/company) platform * Management and upkeep of Pritunl VPN platform # Processes This section outlines key processes shared between Product, Engineering, Quality Assurance, Security, and Product Operations. * [Feature Labels](/operations/research-and-development/processes/feature-labels): Learn what each feature status label means # Feature Labels Mattermost’s feature labels serve as indicators of the status, maturity, and support level of each feature, helping users and administrators navigate product feature adoption with clarity and confidence. They communicate the stage of development, level of readiness, and potential risks associated with a feature for customers seeking to adopt new value. ## Experimental Solution is an early Proof of Concept (POC) with an unstable codebase, minimal QA, and potential UI issues. Security reviews are incomplete, making it unsuitable for production. Distribution of the solution is limited, and our Cloud environments are typically not eligible to use experimental features. Caution is advised as the solution may be discarded if its value is not proven. ## Alpha Solution is in early development towards General Availability, with an unstable codebase, minimal QA, and potential UI issues. Security reviews are incomplete, making it unsuitable for production. Distribution of the solution is limited, and our Cloud environments are typically not eligible to use alpha features. ## Beta Solution is in active development towards General Availability. Not fully complete, but reviewed by our security team, adoption is suitable for a small set of customers behind a feature flag. Identified bugs are fixed on a best effort basis, and no major breaking changes are anticipated. Beta is a transitional stage, meaning the solution is maturing but requires careful consideration in a full production deployment as scale and client availability may vary. ## General Availablity Solution has undergone thorough validation and testing. It is feature-complete, meets quality standards, and has successfully passed security reviews. General Availability features are suitable for widespread production deployment and adoption, as they offer stability and reliability, with no expected changes that could disrupt functionality or scalability. ## Deprecated Solution is officially marked for removal from the product. It is no longer supported or actively maintained by the development team. If the feature is still in use in your deployed version, we recommend users discontinue its use and migrate to alternative functionalities. # Product This section contains: * [Product Planning Process](/operations/research-and-development/product/product-planning) * [Development Process](/operations/research-and-development/product/development-process) * [Release Process](/operations/research-and-development/product/release-process) * [How to Guides for Product](/operations/research-and-development/product/how-to-guides-for-product) * [Product Management Team Handbook](/operations/research-and-development/product/product-management-team-handbook) * [Product Design Team Handbook](/operations/research-and-development/product/product-design-team-handbook) * [Product Management Areas of Ownership](https://github.com/mattermost/mattermost-handbook/tree/0.2.1/operations/research-and-development/product/product-management-team-handbook/product-ownership-areas/README.md) * [Technical Writing Team Handbook](/operations/research-and-development/product/technical-writing-team-handbook) * [Growth](/operations/research-and-development/product/growth) * [Analytics](/operations/research-and-development/product/analytics) * [Developer Relations](/operations/research-and-development/product/developer-relations) * [Product Team Hangouts](/operations/research-and-development/product/product-team-hangouts) # Product planning Learn more about our product planning strategy and processes. # Product philosophy and principles While we use vision and strategy to guide what we work on, there are some common principles, which are built from our [leadership principles](https://handbook.mattermost.com/company/about-mattermost#leadership-principles), that define our behavior in building our product. These principles align the R\&D team on the approach to product development and provide insight to our customers why we act the way we do. ## Product Direction not Roadmap We are **Customer Obsessed**. Working in an agile development process, we think of roadmapping and product development as living; subject to changes as our communities and customer needs change. The further out we commit, the harder it is for us to adapt to our customers’ needs. We use customer feedback to guide our product direction. ## Collaborative Product Design We **Earn Trust**. We welcome input from all members of the core staff and community. We appreciate input on the technical solution, user interface design, overall user experience and functional behavior of the product. This helps us uncover blind spots and promotes input and perspective of our customers. ## MVP and Iteration We are **Self-Aware** and work on **High Impact** changes. We use data in our decision-making processes. By developing an MVP (minimum viable product) of a solution, we can gather more data to inform our future work; thereby allowing us to create solutions for real pains. A MVP may include providing a prototype or a partial solution so we can collect feedback in the most realistic scenarios. We try to ship the smallest thing as quickly as possible and learn from it, so we make sure what we are building is going to create the value expected by our customers. ## Quality is a first class citizen We **Insist on High Standards** and have **Ownership** of the work we do.. This means we keep a high quality bar for our product. Each release we follow a thorough testing process that ensures each feature meets our [design principles](https://docs.mattermost.com/developer/fx-guidelines.html), is tested for happy path and edge cases and meets security best practices. If a new feature does not meet our quality bar, we will push it into a later release instead of risking creating issues and frustration for our customers. If we find out that there is an issue in a version of released software, we prioritize fixing it. We don’t shy away from [dot releases](https://docs.mattermost.com/process/dot-release.html), when a fix is critical to the usability of our product. # Prioritization process There are so many things we want to accomplish. How do we prioritize these properly? In any teams’ backlog you will see stories, epics, customer bugs, and tasks. The type of work that we prioritize includes security fixes, bugs, features, UX improvements and technical debt. Work is prioritized based on its ability to keep the product functioning at a high-quality production level, to help us fulfill our strategies and by demand from our communities and market. New features are prioritized based on how they help support company strategies and product goals. A high level principle that drives priortization is the value of the feature over the cost to develop the feature. One way that we try to measure this is through the [RICE model](https://www.productplan.com/glossary/rice-scoring-model/). RICE stands for Reach, Impact, Confidence and Effort. A feature that would improve the product for a large volume of our end-users, would make a difference everyday to how they work and is fairly low risk and effort to add is likely prioritized over one that was very risky and did not make a difference to a large volume of users. When something is not on the roadmap and is important to our community, we rely on feedback to know if we should reconsider prioritizing it. We value community input on our open source offering equally to feedback from our largest paying enterprise customers. Since our roadmapping process is agile, we often reconsider features based on new information for future releases. Typically, we lock in on prioritization for a quarter’s worth of time. This allows our teams to focus on work for that quarter without major changes which are disruptive to the development flow. The next quarter’s work is usually queued, however there is some flexibility to changes prior to beginning development. Work planned for more than two quarters in the future is subject to changes and reprioritization. # Release planning process There are three distinctive characteristics that influence our release planning process: 1. Agile development cycle 2. Time-based releases 3. Release planning cadence ## Agile development cycle The waterfall model follows a linear approach to software development where each phase in the process only begins after the previous phase is complete. The intent of this approach is to deliver a feature to customers once all the agreed upon requirements are completed. An agile methodology is a more iterative approach. Components of the work is shared with customers as they are completed for feedback and validation - this may include Beta releases, prototypes or even wireframes during the design stage. The intent is that customers have more opportunities to influence decisions and enables development teams to change direction faster if needed. Mattermost uses the agile methodology for development because it supports iteration and allows the product team to get closer to our customers and users. This is also the model that development teams have been adopting in recent years. This means our release planning process is also agile. We continuously iterate our priorities based on new feedback and painpoints we receive, and treat our release plan as a continuously evolving, living document. Therefore, typically we lock the release plan for a quarter. The next quarter’s work is usually queued, but there is some flexibility to changes prior to beginning development. Work planned for more than two quarters in the future is very flexible to changes and reprioritization. ## Time-based releases In a feature-based release cycle, you release when a given set of features is implemented. Thus, there is no release date set until the work is complete. In a time-based release cycle, you release at a predetermined date with whatever features are ready at the time. As a result, some features may be pushed to a following release, but the release date itself does not change. Mattermost uses time-based releases for the following reasons: * **Trust:** Having a predetermined release date increases predictability as it enables organizations to plan their own upgrade cycle. * **Iteration:** Having a set release cadence enables us to release new features and bug fixes early and often; in a feature-based release cycle, a release may get delayed by days or even weeks if surprises arise during the release cycle. * **Community:** A time-based release cycle is preferred among developer communities, especially in open source. Contributors are aware of the release schedule and often aim to complete development by a specified date so that the feature makes it into a release. However, if those dates are missed, we can simply deliver the community-built feature on the next release. Doing feature-based releases with the community is risky, since there is generally less influence on when exactly the work is completed. You can find step-by-step details of the release planning process and timelines at . ## Release planning cadence At Mattermost, our planning cadence consists of: * **Yearly:** Company fiscal year and long term product strategy planning * **Quarterly:** Release Plan and Quarterly OKR planning * **Monthly:** Check in on OKR status Since we follow an agile development style, our release plan is also agile. We plan releases quarterly, following the process outlined below. Before each quarter begins, we lock on plans for: * **What's Launching:** Key initiatives we plan to work with Marketing on launching this quarter. * **What's In Progress:** Key initiatives we will start working on this quarter, but may not ship until a future quarter. We also update the backlog to show which items we are considering for 6 to 12 months out, but this list is flexible and gets updated each quarter based on any changes to company strategy, product goals, community needs, and market conditions. # Roadmap views Mattermost has three different roadmap views: Public Product Direction, Internal Roadmap, and a Release Plan. Each has a specific target audience and framed in different ways: ## Public Product Direction This view is external-facing, shared publicly with our users, community and customers. This is currently available on our website (). The primary intent is to share the vision and direction of the product with no committed dates. We use it to highlight the benefits of what we’re building, so it’s easy for people to picture how what we’re building is going to make their Mattermost experience the best it can be. For an example of similar public product direction sites, see . In addition to communicating the direction, we also include features framed in terms of estimated timelines on our [productboard portal](https://portal.productboard.com/mattermost/19-combined-highlighted-features) * **3+ Months:** This tab includes projects that are in progress now. We’re happy to get on calls to share updates and gather feedback on specs, designs, and prototypes. * **6+ Months:** This stage covers projects coming up soon, after some of the “Now” work is completed. If an item is in this category, we’re happy to have conversations validating requirements and use cases. * **Future Consideration:** This stage includes features we’re considering for later. We’re happy to have conceptual conversations on these items, to see which problems resonate the most. We add and remove things from this category as we learn from those conversations. ## Internal Roadmap This view is internal facing, shared cross-functionally across Mattermost staff, to let people see how our product efforts tie back to the higher level company goals and strategy. Items on the roadmap are related back to objectives, and the objectives tie back to our [Company Fiscal Year plan](https://handbook.mattermost.com/operations/operations/mlt-cadence#fiscal-year-planning), so it’s easy to see how everything fits together. Key distinction from the Public Product Direction is that this view is framed in terms of business goals (such as increasing NPS, ARR, retention) rather than benefits. Moreover, this view may include business initiatives such as the customer portal, technical, or telemetry efforts that are not outwardly beneficial to our customers. ## Release Plan We also create a release plan based on the internal roadmap. The purpose of the release plan is to enable project management for development teams. All dates in our release plan are target dates not commitments, and items are often moved, added, and removed from the list. This view is internal facing, month-by-month release plan of new features. Currently, the Release Plan can be found in [productboard](https://mattermost.productboard.com/roadmap/2855466-features-by-release), and is updated weekly by the Product Management team. [Learn more about release plans](https://github.com/mattermost/mattermost-handbook/tree/c36385e5895aa33eed32d17b0c64a2de922aef1a/operations/research-and-development/product/product-planning/operations/research-and-development/product/product-planning/release-plan/README.md). # Release plan A release plan outlines the features and work that we plan on putting into the release version of the product. A release plan allows us to understand our resources available to accomplish the design, development, and quality assurance work required for a successful product release. ## Release Plan vs. Roadmap A release plan is different from a roadmap, in that a roadmap typically lays out the direction and prioritization the product is headed and includes larger objectives and larger features. The release plan may include major bugs, smaller features and even tasks required to complete a feature set. The release plan document typically includes all the R\&D teams’ proposed work so that we can get a holistic view of what features, bugs or improvements are targeted for the release. Each team may also have their own version of a release plan that they use for tracking features and resource planning. You can find our [release plan here](https://mattermost.productboard.com/feature-board/1097526-release-tracking-internal). When we add items to a release, we are targeting their completion by that release, however, things such as underestimation of work required or quality issues found during testing may prevent it from actually being released. * If a feature is at risk being cut from a release after it was targeted, we do our best to communicate to all those interested as soon as possible. Typically, the PM team reviews and updates the release plan weekly. * If a feature is cut from a release, it is not necessarily put into the next release. There may be unforeseen complications that need to be solved that may take multiple release cycles to address. In some cases, other work may be deemed higher priority and the feature will be deprioritized and considered at a later stage. PMs will do their best to communicate next steps for features that are cut. ## Release Philosophy We follow a time-based release philosophy. This means we release a new version of our Mattermost product every month on the 16th. ### Extended Support Releases Our releases for January and July are offered as an [Extended Support Releases (ESR)](https://docs.mattermost.com/administration/extended-support-release.html). This type of release allows customers to receive backports for security fixes and bug fixes without having to upgrade to a version with new functionality that would require significant testing and certification before rolling to large volume of users. We also do dot releases for major bugs and security fixes and backport these to the previous three monthly releases. For more information on our release types and processes please see this [documentation](https://handbook.mattermost.com/operations/research-and-development/product/release-process/release-overview). ## Major Versions At times, we may do a major release version of our software. A major version provides us the opportunity to make breaking changes that allow us to re-define how product functions and to support future features, deprecate some foundational features that have been replaced, as well as package new major functionality as part of the binary. Major versions are scheduled well in advance and notices about major changes are communicated early so that customers can prepare for changes. # Launch plan We plan periodic launches to drive awareness in the market so that our target audiences who aren't already Mattermost customers can get exposure to our product and our offerings. Launches are also a way for the company to put stories into the market to communicate Mattermost’s position and strategic direction. Launches are different than releases or a roadmap in that a launch highlights the most exciting changes to our product. A launch plan is owned by the Marketing team whereas the release plan is owned by the Release team (R\&D). We may plan a launch with the release of a new product offering, at the release of a highly demanded feature, or to announce a set of features that are thematically connected. The timing of a launch may be different than a release depending on other communications and events of the organization. # Feature requests How feature requests are tracked, prioritized, and escalated. ## Where are feature requests tracked? At Mattermost, we track paid customer feature requests in [Productboard](https://portal.productboard.com/mattermost/33-what-matters-to-you). Productboard is an internal tool used for tracking and organizing customer intelligence, feedback, and requests. Customer-facing teams can add notes to Productboard based on [this process](https://handbook.mattermost.com/operations/research-and-development/product/how-to-guides-for-product/how-to-use-productboard#productboard-insights-also-called-notes). [Uservoice](https://mattermost.uservoice.com/forums/306457-general) is used for our community to submit a request or upvote existing requests. The Product Management team uses the information from both our customers and community to help prioritize features for the roadmap. ## Where to share feedback? The Mattermost Product team uses information from our customers and the open-source community to guide feature roadmap. We use two forums to connect with the user community - [Customer ProductBoard](https://portal.productboard.com/mattermost/33-what-matters-to-you/) and [Community Feature Proposal Forum](https://mattermost.uservoice.com/forums/306457-general). ### Customer ProductBoard Customer ProductBoard is a place for paying customers to connect directly with the product team on improvements most important to our ideal customer profile (ICP): In this portal, customers can share how important an improvement is, share their use cases relevant to those improvements, and submit new ideas directly to the product team. Product Managers review the feedback weekly to guide product direction and feature roadmap development. ### Community Feature Proposal Forum Community Feature Proposal Forum is a place for users in our free deployments to propose new feature ideas: In this forum, community members can propose new features, share ideas for new improvements, and connect with other members in refining their proposed features. Community Manager reviews the feedback weekly to hear what matters to the most engaged users in free deployments. Key trends are also shared with the Product team. ## Filing great feature requests When filing a feature request, the most important thing to do is capture the "why" behind it. A great way to do this is by writing requests in the form of an "Experience Report". As described in the [golang wiki](https://github.com/golang/go/wiki/ExperienceReports): **"The best experience reports tell: (1) what you wanted to do, (2) what you actually did, and (3) why that wasn’t great, illustrating those by real concrete examples."** Writing in this format ensures the focus is on pain points, rather than solutions. This allows us to better define the root of the problem, which in turn makes it easier to come up with creative solutions to fix it. If you're filing a feature request on behalf of a customer, make sure to also include: * Who requested the feature. * How important it is to them (ideally, based on stack rank against their other requests). * Links to any relevant conversations, Zendesk tickets, etc. ## Escalating a feature request Generally speaking, feature requests are prioritized through our normal roadmap process. The roadmap provides an idea of where the feature falls on our prioritization list, but is not a committed release date. If a deal is dependent on committing to a concrete timeline for a feature, the Sales team can escalate the request by sharing: * What is the request? * What is the timeline ask from the customer? * Are there other “must have” features blocking the deal? If so, please provide a full list. * If we build this feature, is the customer committed to closing the deal? If so, how big is the deal? * Did the customer offer NRE dollars to accelerate the feature? The Product Management team will then evaluate the ask, and determine if we can commit to a timeline or if the feature does not fit on our roadmap. Please be aware that committing to a concrete timeline for a deal is the exception not the norm, as it can have a negative impact on delivering other features that the rest of our user base is expecting. # Development process Learn more about our development planning and processes. # Mobile feature guidelines New product features should consider the mobile client at the same level of importance as the web app client. For new features implemented on the server or web app, please consider the mobile client through these lenses: ## Are mobile app code changes needed? A good rule of thumb is that if there are web app repo code changes (outside of the System Console UI), mobile code changes are needed to support the feature. While not every web app feature needs parity with mobile, this is a discussion to have with the Product Managers and UX team, and a decision to be made in the requirements gathering phase of feature design. * If a feature requires mobile code changes, the Mobile team PM (Eric Sethna) should be made aware of the feature before it’s committed to the feature team's quarterly roadmap. Please involve the Mobile team PM in roadmap planning and quarterly OKR planning discussions. The same applies even if the feature team will be doing the mobile implementation themselves, given that the Mobile team will be involved in code reviews, testing, and should provide guidance on the feature implementation. * During design and spec development of any feature that will involve mobile code changes, please involve the Mobile PM (Eric Sethna) and Mobile dev lead (Elias Nahum) at all stakeholder checkpoints including requirements gathering, design option exploration, and final design review. * Set deliverables taking into account the limitation that a team may not have enough skills to develop features for mobile. Consider the impact if the feature is left out from mobile, document the reasons, and set goals to cover the mobile space. The feature should be [released as beta or experimental](https://handbook.mattermost.com/operations/research-and-development/product/product-management-team-handbook#can-we-take-this-feature-out-of-beta) and any documentation should clearly communicate the impact of not having mobile support as well as when mobile support is expected. * If a feature is related to authentication, such as Single Sign-On (SSO), plan to release the feature on Mobile Apps prior to Cloud to avoid users from being blocked from using the Mobile Apps. ## Backward compatibility * Mobile releases must be backward compatible with at least all server versions back to the [oldest supported ESR](https://docs.mattermost.com/upgrade/extended-support-release.html). An important question to ask during design is: *What is the expected behavior on a new server with an old app, or a new app with an old server?* Here's an example: * **New mobile app with an old server:** If the server is running older code and does not support the new feature, we can’t allow users to access the feature from a new mobile app. * Example: Hide the “Mark as Unread” option if the server is older than v5.18. * [Use the isMinimumServerVersion helper function](https://github.com/mattermost/mattermost-mobile/blob/master/app/screens/post_options/index.js#L49) * **New server with an old mobile app:** Users will not be able access the new features from their mobile device since it’s running older code, but the new server code should not cause regressions to a user's experience on an older mobile app. * Example: Users cannot see the “Mark as Unread” option in an older mobile app that does not contain that code, but marking a channel unread on a webapp running v5.20 or later should still mark the channel as unread on mobile, and not cause any mobile app regressions for a user running an old app. Ideally any new features should be tested on all server versions back to the [oldest supported ESR](https://docs.mattermost.com/administration/extended-support-release.html?highlight=esr). However, since testing mana is limited, feel free to work with your QA representative to determine the most effective testing approach based on the risks of your feature. At a minimum, new mobile app features should be tested on all supported server ESRs and the latest three server versions. For new features, consider a `minserverversion` check that only executes the code if the server connected to the app is newer than xyz. [See example to disable or not the position field when editing the profile](https://github.com/mattermost/mattermost-mobile/blob/ee4b85edcfee8316db08c31ec5b2a26afb343bd3/app/screens/edit_profile/index.js#L29). Bonus: Legacy servers (i.e. < v5.0) don't have post metadata, don't rely on it. ## Variable network conditions * API requests will fail on mobile because network conditions are much more variable than on desktop. As such defaults need to be carefully chosen to avoid failing requests breaking or blocking core user functionality. As an example, if the default for a channel is set to be read-only until a permission API request grants the user permissions, this is likely to result in a poor user experience in bad networks. When in doubt, [the default if an API request fails should not change existing behavior, or a failed API request should either do nothing or notify the user somehow](https://github.com/mattermost/mattermost-mobile/blob/master/app/mm-redux/actions/preferences.ts#L18). * [Retries should be added to important API requests](https://github.com/mattermost/mattermost-mobile/blob/master/app/actions/views/channel.js#L607). ## Client performance impact * Mobile devices vary significantly in their computing capabilities, as such performance should be top of mind when developing mobile features. * Minimize requests where possible, make requests in parallel if possible, batch dispatches wherever possible. * Do NOT track requests. Examples: * Here we are fetching the needed data in sequence but holding dispatching any action, and then once we have all the required data we dispatch an action batch. With this we ensure that the redux store is being updated only once and that every `mapStateToProps` of mounted connected components runs once instead of multiple times, this will then reduce computation time: . * Here we are fetching data from the server in sequential order and then in parallel, as we need data from one request and then all others are not dependent on each other. The use of `Promise.all` will help wait on all responses but take into consideration if one of them fails, everything will fail (do add retries if needed). In the end we batch the actions as we do in the example above: . * Don’t do this: Here we are using a bind function or an action created that is dispatching at least two actions in total, one for tracking the start of the request and then if the requests succeeded or failed. That means that calling that function will update the store twice instead of once: * * # Deprecation policy ## Deprecation Policy This document outlines the process for announcing deprecated features to the community. The guiding principle is [no surprises](https://docs.mattermost.com/developer/manifesto.html#no-surprises) with guaranteed long-term stability, where admins or users should never run into anything unexpected while using Mattermost. ### Definition of a deprecated feature A deprecated feature is considered to be one that breaks backwards compatibility with previous versions. Examples include: 1\) Removing an API endpoint, or one of its parameters. * APIv3 endpoints on January 16, 2018. * “permanent” parameter of the DELETE /teams/{team\_id} APIv4 endpoint in Mattermost v5.0.0. 2\) Removing a config.json setting * System Console settings in **Files > Images** in Mattermost v4.0.0. 3\) Removing an end user setting or functionality. * Font setting in **Account Settings > Display** in Mattermost v4.0.0. ### Notice When the decision to deprecate a feature or function is made, the product manager responsible for the feature carries out the following actions: 1. Adds the scheduled deprecation to the [deprecated features page](https://docs.mattermost.com/deploy/deprecated-features.html) with a note of what it's been replaced with. 2. Prepares a forum post describing the reasons for deprecating the feature, providing an opportunity for the community to share feedback. See a [sample forum post](https://forum.mattermost.com/t/switching-teammate-name-display-to-a-system-console-setting/3366). 3. Creates a JIRA ticket for removing the feature, including a prefix “Deprecation:” and a fix version matching the removal target date. Moreover, the acting release manager takes the following actions: 1. [20 working days before each release](https://handbook.mattermost.com/operations/research-and-development/product/release-process/feature-release#c-t-minus-20-working-days-feature-complete), adds a list of deprecated features to the compatibility section of the [changelog](https://docs.mattermost.com/administration/changelog.html) and [important upgrade notes](https://docs.mattermost.com/upgrade/important-upgrade-notes.html). The changelog should include deprecations scheduled for upcoming releases. 2. [20 working days before each release](https://handbook.mattermost.com/operations/research-and-development/product/release-process/feature-release#c-t-minus-20-working-days-feature-complete), sends the list of deprecated features to the marketing manager, who includes this information in the release announcement. 3. [2 working days before each release](https://handbook.mattermost.com/operations/research-and-development/product/release-process/feature-release#k-t-minus-2-working-days-release-build-cut), ensures the [deprecated features page](https://docs.mattermost.com/install/deprecated-features/) is up to date. ## Removal target date The removal target date should always be the date of the next major release, such as v4.0.0. If the date is not known, you can reference the next major version rather than the actual release date. However, there should always be at least two months from the time the deprecation is announced to its removal. This number is chosen to match our security backport release policy. See the table below for examples: | Deprecation Announced | Final Minor Release | Removal Target Date | | --------------------- | ------------------- | ------------------- | | 3.9.0 | 3.10.0 | 4.0.0 | | 3.10.0 | 3.10.0 | 5.0.0 | Exceptions for the removal target date may be made if it impacts security or the performance of Mattermost. In such cases, the target date for removing the feature may be made sooner. On the other hand, if removing a feature is deemed significant, such as the removal of APIv3 endpoints, the target date for removing the feature may be extended to a later release. # Mattermost software requirements process ## Mattermost Software Requirements This document provides guidelines for determining which software versions Mattermost requires. For past discussion on why these guidelines were chosen, see [this conversation](https://community.mattermost.com/core/pl/sb4fq6qhyfbb5xjdp7x3ud146e). Current software requirements are [documented here](https://docs.mattermost.com/install/software-hardware-requirements.html). Before submitting software requirement updates to the documentation, the following steps have to be taken into consideration: 1. Check with Chen in [the Analytics channel](https://community.mattermost.com/private-core/pl/qy675c87zbfn7dmzkh919ppmor) to see what % of users and what % of posts are made by the versions we’re considering to drop support for, to review potential impact to users. 2. For versions we are considering dropping support for, ask the customer support team what the impact is for customers (e.g. if there are known customers on those versions and if we get customer support tickets specific to those versions). 3. Ask developers what the impact is for us internally if we consider dropping or continuing support for a version. 4. If we decide to drop support for a version, work with product managers and developers to plan for updating the version information in all relevant places, including but not limited to: in the product itself (such as the mobile app), Changelogs and README GitHub pages. ## Desktop Apps | Operating System | Guideline | | ---------------- | --------------------------------------------------------------------------------------------------------------- | | Windows | Supported versions by Microsoft - [reference](https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions) | | Mac | Supported versions by Apple - [reference](https://en.wikipedia.org/wiki/MacOS_version_history) | | Linux | Fixed to Ubuntu LTS releases 16.04 or later | ## PC Web | Browser | Guideline | | ------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Chrome | Chromium version of latest Mattermost Desktop App | | Firefox | Supported versions by Mozilla - [reference](https://www.mozilla.org/en-US/firefox/organizations/) | | Safari | Safari version available in the minimum supported macOS version - [reference](https://en.wikipedia.org/wiki/Safari_version_history) | | Edge | Latest release | ## Mobile Apps | Operating System | Guideline | | ---------------- | --------------------------------------------------------------------------------------------------- | | iOS | Latest and next-to-latest versions - [reference](https://en.wikipedia.org/wiki/IOS_version_history) | | Android | Supported versions by Google - [reference](https://en.wikipedia.org/wiki/Android_version_history) | # Jira ticket lifecycle In addition to GitHub Issues, we also use Jira tickets for managing chunks of work to be performed. ## Ticket triage Ticket triage happens within the team's normal sprint cycle. At that meeting, the team reviews all new tickets, assessing the scope, effort, and impact of each ticket. They make a decision on the priority of the ticket. Once it's decided in triage meeting that the ticket should be worked on, the ticket moves into the [To Do](#to-do) state. ## Ticket states Tickets are in one of several states, and transition between states is typically linear. The beginning to end flow is described below. ### Backlog Ticket reach this state by being [created](https://handbook.mattermost.com/operations/research-and-development/product/development-process/new-bug-tickets). A ticket usually needs [triage](#ticket-triage) to proceed further. One notable exception is an urgent bug fix, which moves to "In Progress" as soon as the implementer has bandwidth to address the issue. ### Will Do Ticket reach this state by having been assigned a sprint (could be the "Queued" sprint) and having been identified in triage as something the team desires to achieve. Tickets in this state typically do not have anyone assigned to them. This state is synonymous with "Select for Development". ### To Do Tickets reach this state by being assigned to the implementer, who has clear intention to work on the ticket soon (within the next sprint or two). A ticket moves back to [Will Do](#will-do) if the implementer no longer has present or future bandwidth to do the work in the ticket. ### In Progress Tickets reach this state by the implementer beginning to perform the work needed to finish the ticket. A ticket can be in progress for an indefinite period of time, but if tickets are routinely in progress across multiple sprints, it is likely a sign that the tickets need better definition or reduction in scope. A ticket moves back to [To Do](#to-do) if the implmenter is no longer working towards completing the ticket. ### Submitted For tickets that require code changes, tickets reach this state by the implementer opening a pull request. Many tickets can be tested by QA at the time of the pull request. For such tickets, the QA steps to test and verify should be added to the ticket when moving the ticket to the "Submitted" state. Tickets can be in submitted state indefinitely as long as forward progress is being made in the pull request review. A ticket moves back to [In Progress](#in-progress) if are too many issues with the pull request for it to make sense to keep the pull request open. ### Done Tickets reach this state by having a pull request merged. Once moved to this state, tickets trigger additional work to be performed by the QA team. Tickets move back into [In Progress](#in-progress) from this state if QA detects there are defects or regressions because of the work merged by the ticket. A ticket could also move to "Done" from any state if it is decided that the work or change will not be performed or accepted. Common reasons for this include: * The ticket is a duplicate of another. * The ticket is no longer relevant. * Priorities changed enough that the ticket will never be worked on. * A bug ticket can not be reproduced. * What is observed in the bug ticket is deemed acceptable behavior. ### Close A ticket reaches this state after QA verifies through testing that the change has been completed as anticipated. # Creating new Jira bug tickets Bugs are any “obvious errors” on how the product or a feature is functioning as well as any UI issues. If you’re not reporting an obvious error, please file a Story ticket instead. Errors on [unsupported platforms](https://docs.mattermost.com/install/software-hardware-requirements.html) are not considered bugs. ## 1. Check that you have permissions to create tickets in Jira * If you don't already have a Jira account or permissions to create Jira tickets, you can request access through [the Mattermost IT helpdesk](https://helpdesk.mattermost.com/support/home). ## 2. Confirm you’re filing a new issue * Search existing tickets in Jira's "Mattermost" project to confirm your issue isn’t already filed by someone else. ## 3. Confirm the bug is not a confidential issue * If your issue involves security or if it involves confidential information or customer information, please mark the bug ticket as internal. ## 4. Information needed on Mattermost bug tickets * **Steps to reproduce:** How can we reproduce the issue. * **Expected behavior:** Describe what you’re expecting to see. * **Observed behavior:** Describe your issue in detail. What did you see happen? Please include relevant error messages and/or screenshots. * **Severity:** Choose appropriate severity from the drop-down. Severity levels and descriptions are documented [here](https://handbook.mattermost.com/operations/research-and-development/product/development-process/new-bug-tickets/bug-severity-guidelines). ## 5. Additional helpful information * **Labels:** Add a `customer-bug` label if the ticket is based on a customer bug report. Add a `community-bug` label if the ticket is based on a community bug report. * **Environment:** There is an `Environment` field with drop-down options to choose whether the bug was found in Cloud test servers, Cloud production servers, Self-Hosted test servers, Self-Hosted production servers, Desktop app, Mobile app, or in Master/PR testing. * **Attachments:** Please include screenshots and/or videos of any helpful error messages and snippets of what you are seeing. * **Possible fixes:** If you can, link to the line of code that might be responsible for the problem. * **Regression:** Please re-test your issue (if possible) on the previous Mattermost version at to see if the bug is a recent regression. * Add any additional relevant details if it helps make the bug more clear. For example, you can add details on Mattermost server and version, OS and version, Mattermost mobile app version, Mattermost desktop app version, and any notable Mattermost configurations (such as HA, Elasticsearch, image proxy, SSO). ## 6. Assigning new tickets to a team * If you know which team would own fixing the bug, you can assign the ticket directly to that team. * Otherwise, you can leave the team `Unassigned` and the Program Manager assigns the ticket. The Program Manager follows the \~Bugs channel on a daily basis. # Priority levels for tickets | **Priority** | **Definition** | **Example Issues** | **Target Resolution** | **Release Guidelines** | | ------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------- | :------------------------------------------------------------------------------------------------------------------------: | | **High** | **A customer-reported issue or blocker that prevents or severely delays a user’s goal.** | App crash, data loss, broken website forms, broken authentication flow | Fixed within 30 days | Fix can be committed after T-10 Code Freeze | | **Medium** | **A frustrating friction point or an issue so “cringey” it erodes trust.** | Documentation gaps, misleading error text or guidance, complex UX, inconsistent user interactions, functional regressions | Fixed within 60 days | Fix can only be committed before T-10 Code Freeze | | **Low** | **An inconsistency that affects polish.** | UI misalignment, unclear labels, minor documentation errors, cosmetic regressions | Fixed within 90 days | Fix should be committed before T-19 Code Complete, if submitted after Code Complete it may get bumped to the next release. | ## Assigning priority levels Priority levels on Jira tickets should be filled in by the ticket reporter using the **Priority** field. The triage team will review and update priority levels based on the guidelines above. Bug tickets are sometimes assessed on a case-by-case basis and further considerations may be applied, such as whether the bug is a recent regression or not, how risky the bug fix is, or whether it’s more effective to revert code that initially caused the bug. ## Frequently Asked Questions **Why are we doing this?** * We want to consistently deliver high quality products and interactions with our customers. Priority guidelines enable us to prioritize and address quality issues that can erode trust in our brand. # Jira fix versions Developers, Product Managers, Release and Quality Assurance teams use the Fix Version field for the following purposes: * Developers: * Fix Version field is the one that shows up on individual tickets in the backlog view. * For Story tickets, the Fix Version is used for soft guidelines for what is targeted for what release. * For Bug tickets, the Fix Version is used to know which bugs are priority based on where we are in the release cycle. * Product Managers: * To prioritize backlog. * To estimate/plan what Story tickets ship in what release. * Release Manager: * Follow status of resolved, open and submitted tickets for current release. * Compose various release metrics. * Quality Assurance: * Prioritize testing of tickets and associated PRs for the next release. * Assess completeness of a release before cutting final. * Track when changes actually went in, to help investigate bugs and expected behavior. * Report on issues, changes, and tests by release. # Release process Learn more about our release planning strategy and processes. # Release overview Mattermost ships with a new version once a month for both cloud and self-hosted customers. ## Release numbering Mattermost numbers stable releases in the following format: **\[Major Build Number].\[Minor Build Number].\[Patch Build Number]** **Major build number:** * Purpose: Major system releases introduce significantly new functionality or change existing product behavior * Release frequency: Once a year. Major system releases are infrequent * Example: v1.x.x, v2.x.x **Minor build number:** * Purpose: Introduce new features, bug fixes and performance improvements * Release frequency: Monthly cadence * Example: v1.2.x, v1.4.x **Patch build number:** * Purpose: Patch existing releases when severe bug fixes or security patches are required * Release frequency: As required * Example: v1.2.5, v1.2.6 ## Objectives The goal is to deliver value to users quickly by a) shipping fast to get features to customers quickly for experimentation/feedback, and b) iteratively behind feature flags as a protection if any issues arise. This document outlines the principles and guidelines for how we release a new update of each product line on a monthly basis. ## Release Principles 1. **Focus on High Impact by shipping every new feature and any riskier code changes behind a feature flag** * Each development team is individually responsible for quality and deciding if a feature should be included in a release or not (with the release team giving guidelines). This may mean shipping more patch releases, but we can manage some of this by using feature flags. This also requires good test automation coverage. 2. **Automate** * Automate release processes and tasks. * Automate release tests and have E2E tests for features. 3. **Earn Trust by communicating to external and internal stakeholders clearly** * Enables us to make expectations for releases clear for all stakeholders. * Make expectations for each release clear (release dates, etc.). Communicate. Ensure that everyone on the team is familiar with the release processes. * Release notes, minimum version requirements, and any important upgrade notes need to be available for customers and communicated via docs, blog, emails, and channels. 4. **Earn Trust by including all stakeholders (Tech Writers, Marketing, QA, etc.) early in the release process** * Enables us to avoid missing key tasks and to avoid last minute work. * E.g. When opening a PR, add a “Docs/Needed” label for any PRs that need docs and communicate to Tech Writers. This ensures that we have time to complete docs on time. * Make tracking bugs and testing requirements easy. E.g: * Resolve Jira tickets for QA when PRs are merged (and cherry-picked). * Add QA test steps to Jira tickets and/or PRs. * Add Fix Versions and Milestones in Jira/PRs for bugs/tickets for easy tracking. * Add clear Release Notes on PRs. 5. **Achieve Customer Obsession by doing retrospectives on release issues and monitoring customer/community release bug reports after releases** * This allows us to learn from issues so that they don’t happen again and to fix critical bugs asap. * Retrospectives for issues and dot releases are important. * Monitor community and customer reports in GitHub, Forum, and channels like Ask PDE, in partnership with the Support team. ## Release Cycles We follow [the Agile Release Train method](https://www.scaledagileframework.com/agile-release-train/). If releases are not approved by a certain date, then we miss the release train. * Cloud/self-hosted [release process is outlined here](https://handbook.mattermost.com/operations/research-and-development/product/release-process/feature-release). * [Mobile app](https://handbook.mattermost.com/operations/research-and-development/product/release-process/mobile-release) releases follow the same release cadence as cloud/self-hosted. * [Desktop app release process](https://handbook.mattermost.com/operations/research-and-development/product/release-process/desktop-release). * When issues are found that warrant a patch release, we follow the [dot release process outlined here](https://handbook.mattermost.com/operations/research-and-development/product/release-process/dot-release). ## Release dates communication Release dates are currently communicated in the following ways. 1. Channels * The [Release Announcements channel](https://community.mattermost.com/core/channels/release-announcements) functions as the main location for important announces about Cloud test server updates, and for release dates and feature complete deadlines. Specific teams or people may be at-mentioned if the announce is targeted at someone. * The [Announcements channel](https://community.mattermost.com/private-core/channels/announcements) functions as the central place to find the most important announcements for new releases with links to changelogs and/or blog posts that can be easily shared with external stakeholders including MLT and customers. 2. Mattermost Release Dates Calendar * Lists key release dates and deadlines. 3. PM and PDE meetings * Updates are provided on upcoming key dates and/or features as needed. 4. Productboard * [Productboard](https://mattermost.productboard.com/data/releases) - A milestone overview of what releases + features are coming up. 5. Spreadsheet * [Overview of release deadlines and cherry-picking guidelines](https://docs.google.com/spreadsheets/d/1jGEnuaZxosmC-JSUXFeZOR7I34ORFtNjPVw8hvzCIC4/edit#gid=0). ## Plugin Release Processes * The sample [Plugin Release Playbook](https://community.mattermost.com/playbooks/playbooks/f4oh16ardfbyfgkas1cb6intmw/outline) helps give an overview of needed steps for plugin releases. ## Tracking feature flags Details on feature flags: . ## Adding milestones on PRs and Jira tickets * If the PR is scheduled for a specific Mattermost release, please add the `Cherry-pick Approved` label and self-managed milestone on the PR. The Release Manager keeps track of PRs with the `Cherry-pick Approved` label and self-managed milestone on a daily basis. * The Release Manager also tracks regression bugs and aims to ensure that they get fixed for the next release. * A fix version is added in Jira to track regression bug fixes for Mattermost releases. ## Triaging Mattermost customer issues When triaging a bug report, consider the following: * Impact of the bug on customers. * Severity of the issue. * Risk and effort of reverting to the last version or fixing a bug. **Criteria** 1. "We need to revert to the last version" process: * Crash or all services are down due to a bug; affects some to all Mattermost Cloud customers. 2. "We need to release this ASAP" process: * A severe regression or loss of functionality; affects some to all Cloud customers. 3. "It's OK to wait until next release" process: * Loss of function, but little impact on Cloud customers. **Responders** * Who is making the decision on which process above we need to follow? * In some cases it's the customer support teams or Cloud teams, and in some cases it's other people such as the Release Manager or developers who notice or get notified about the report. * Bugs will be fixed by either the CRE team or by respective development teams, depending on availability and expertise. ## Frequently Asked Questions **Q: What is the release cycle for the React Native mobile apps?** * A: The mobile apps follow the same monthly release cycle as Mattermost Server/Webapp, releasing on the 16th of each month. **Q: What is the release cycle for the Mattermost Desktop app?** * A: Desktop releases are shipped every 3 months starting in March, 2023. For more details, see . **Q: When do I need to have a feature PR to be included into the next release?** * A: Aim to have the PR merged before the Feature Complete deadline. The earlier in the monthly cycle the PR is merged, the higher the chances are for it to be included in that month's release. The quality of our releases is important and feature PRs are not normally cherry-picked to a release branch. **Q: How can I determine if my merge request will make it into the next release?** * A: The Release Manager adds PR milestones and Jira fix versions for tracking. You can also check the release branches (e.g. in the mattermost repo) to see what's included. **Q: Do we use Playbooks for releases?** * A: Yes, playbooks are used for cloud & self-hosted, mobile and desktop releases, and for dot releases and plugin releases. **Q: How are PRs merged for release?** * A: PRs are first merged to master. As needed, the dev who submitted the fix is also responsible for cherry-picking it to the release branch after a release branch has been cut. **Q: How is cherry-picking done?** * A: See the [cherry pick process documentation](https://developers.mattermost.com/contribute/getting-started/branching/#cherry-pick-process-developer/) for details. **Q: What version is community.mattermost.com kept on?** * A: Normally on `master` branch and it updates daily. **Q: How to remove a feature/bug from a release?** * A: The feature flag is turned off. Another option is reverting the feature from the `master` and `release` branches. **Q: How are NOTICE.txt PRs submitted?** * A: PRs are first merged to `master`. The dev reviewer is responsible for helping cherry-picking it to the `release` branch as needed. **Q: Is an improvement a feature or a bug?** * A: Usually features/story tickets. **Q: How does release team monitor what changes went into a release?** * A: Monitor the commit history of the respective `release` branch, e.g., contains commits that shipped with `mattermost-server v7.5`. Jira ticket is resolved after cherry picking is done. **Q: How does translations branching work?** * A: The translation PR will be submitted against the master branch. **Q: What is the process for community PRs?** * A: Review, merge, and cherry-pick as needed. **Q: What information does the Customer Support team need for Cloud releases?** * The Announcements channel in the Staff team is used for release updates and for posting the changelog. # Feature release process Mattermost core team works on a monthly release process, with a new version of cloud and self-hosted shipping successively once a 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. Please refer to [the cloud & self-hosted release playbook](https://community.mattermost.com/playbooks/playbooks/7ya8gsijg3f1dkx84txzek6t1r/outline) for the release checklist. A single release is qualified for both cloud and self-hosted at the same time, with both versions labelled as `vX.Y.Z`. Outside of patch releases, no changes are released to self-hosted customers before they are first released to cloud customers. ## Release Timeline Note: T-minus counts are measured in "working days" (weekdays, Monday through Friday, excluding [the listed statutory holidays](https://handbook.mattermost.com/operations/workplace/people/working-at-mattermost/paid-time-off#holidays)) prior to release day. * Feature Complete and Release Branch Cut at T-24 * All major features must be complete and merged approximately five weeks prior to the self-managed release date. Prior to this day, the release manager makes sure everyone is aware of the impending deadline by posting reminders in the `Release Announcements` and `Release: Self-Hosted & Cloud` channels and messaging team leads. If any pull requests are not merged by this date, then the release manager changes release milestones in Jira after checking with team leads that those features can be pushed to a future release. Updates to prepackaged plugins should also be complete and merged by this date, with room to address bugs before code freeze. This is also the date when the `release-X.Y` branch is cut from master. Any additional changes to the release must first be merged to master before being cherry-picked to `release-X.Y`. All test servers are configured to update daily from this branch. * Judgment Day at T-19 * Approximately one week after feature complete, the release manager reviews the status of all features and issues. Regression bugs are identified naturally in Community as well as on the release branch by the QA team. If anything needs to be cut, the Release Manager informs internal stakeholders in the `Release: Self-Hosted & Cloud` channel and asks the feature owners to revert the code. There should be no known major issues included with the release. A feature should be reverted if any [Severity 1](https://handbook.mattermost.com/operations/research-and-development/product/development-process/new-bug-tickets/bug-severity-guidelines) blockers or more than five Severity 2 issues found. RC-1 is cut on this day. * Release Qualification Starts at T-18 * Immediately after judgment day and any reverts are completed, the release team officially begins release qualification. This includes verifying and closing tickets resolved for the release; running Rainforest release test run groups, Cypress automated tests, and release smoke tests; executing manual tests; and triaging new issues and re-testing as fixes become available. Progress is tracked in the [QA Approval playbook](https://community.mattermost.com/playbooks/playbooks/rpsa3y78t3gsun9ba8185s5gto/outline). Qualifying any individual issue occurs in both self-hosted and cloud test servers simultaneously, as the same artifacts will ship unchanged into each environment. * Code Freeze at T-10 * Ten business days prior to the release date, and near to the end of release qualification, code freeze prohibits all further changes to the release branch. No further code changes will be accepted, preventing last-minute regressions, fixes, and additional testing. A final release build is cut and pushed to , but marked as pre-release. The delivery team continues to triage and push minor bugs to the next release. * If a showstopper issue is found, a patch release is required that may risk the remaining milestone dates. Minor bugs or issues found after code freeze should generally be deferred to the next release, but it is occasionally necessary to patch the monthly release to address show stopper bugs or security issues. Introducing a patch increments the patch version (`vX.Y.Z+1`) and may delay the cloud or self-hosted release dates. We bump the patch version here to preserve the integrity of the code freeze deadline. We also schedule a retrospective to better understand how the issue was introduced and discovered so late in the release cycle. * Release Approval at T-8 * Approximately two weeks after starting release qualification, the delivery team formally signs off on the complete release qualification. * Cloud Beta Release at T-7 * The qualified release is rolled out to the cloud beta production servers for final QA smoke testing. * Cloud Freemium Release at T-6 * After final QA release approval, the release is rolled out to the freemium ring. * Cloud Professional Release at T-5 * Two business days after soaking in cloud beta, the release is rolled out to customers in the professional ring. * Cloud Enterprise Release T-3 * Once stabilized in cloud professional, the release is rolled out to customers in the enterprise ring. The actual date may be two or three business days later to avoid releasing to enterprise customers on a Friday. * Cloud Dedicated Release at T-2 * Once stabilized in cloud enterprise, the release is rolled out to enterprise customers with dedicated clusters. As with T-3, the actual date may be one or two business days later to avoid releasing to dedicated customers on a Friday. * Self-Managed Release at T-0 * On the first business day on or before the 16th of the month, the same build already qualified in cloud is released for self-hosted customers. No rebuild is required. Marketing communications begin to roll out, and the release is communicated on the blog and other marketing channels. The pre-release bit on the corresponding GitHub release is manually removed. Note that this may be `vX.Y.1` or a later patch release if fixes were required after code freeze. Release documentation, including the changelog, is merged on this day. # Dot release process Dot releases are done for high priority and high severity security issues and customer bugs. The general steps are: 1. The issue is escalated by customers, customer support team, community members or internally. 2. Our developer team investigates the issue as soon as possible. 3. A pull request for the issue is submitted and dev/QA reviewed, and then merged. 4. The bug fix is cherry-picked to the relevant release branch. 5. A release candidate (e.g. 7.2.1-RC1) is cut for quick final smoke tests. 6. After QA approval, a final release build is cut (e.g. 7.2.1) which is ready to be shared with the customer. The time-to-fix varies, but urgent dot releases are always prioritized. Please refer to [the Dot Release Playbook](https://community.mattermost.com/playbooks/playbooks/hjn1xnc3gfnmzeqwssyu6dsa3w/outline) for a most up-to-date checklist. # Security release process Security dot releases are done for high, medium and low level severity security issues based on [the backport policy](https://handbook.mattermost.com/operations/security/product-security/product-vulnerability-process#backport-policy). The general steps are: 1. A pull request for the issue is submitted and dev/QA reviewed, and then merged. 2. The bug fix is cherry-picked to the relevant release branch. 3. A release candidate (e.g. 7.2.1-RC1) is cut for quick final smoke tests. 4. After QA approval, a final release build is cut (e.g. 7.2.1) which is ready to be shared with the customer. Please refer to [the Dot Release Playbook](https://community.mattermost.com/playbooks/playbooks/hjn1xnc3gfnmzeqwssyu6dsa3w/outline) for a most up-to-date checklist. # Mobile app release process The Mattermost team works on a monthly mobile app release process, with a new version submitted to the iOS App Store and Google Play Store on the 16th of each month. Please refer to [the Mobile Release Playbook](https://community.mattermost.com/playbooks/playbooks/yxb6yyckgbrebe8eiuzmb6w8co/outline) for the release checklist. **Note: iOS App Store approval may take a few days after the 16th.** ## Release Timeline Note: T-minus counts are measured in "working days" (weekdays, Monday through Friday, excluding [the listed statutory holidays](https://handbook.mattermost.com/operations/workplace/people/working-at-mattermost/paid-time-off#holidays)) prior to release day. The Mobile app release schedule follows the cloud/self-hosted release schedule to align all release testing cycles. **Schedule for Mobile App releases**: * Feature Complete at T-24 * This is the Feature Complete deadline for the release. * Cut the release branch based off the `main` branch. * RC-1 cut at T-19 * Cut RC builds based off the release branch for QA release testing. Release testing begins. * Note: More frequent RC builds may be requested by the QA team and the Release Manager as we get closer to the release date and as more regression fixes get merged. * Code Freeze at T-10 * Release testing is completed. * [QA approval](https://community.mattermost.com/playbooks/playbooks/9znffdsm9p8ixpanycpnb1mwkh/outline) should be ready by T-10. * Release Day at T-0 # Desktop app release process This document outlines the release process for the Mattermost desktop app. Desktop app releases follow a fixed schedule of 4 releases per year. Releases ship quarterly by the 16th of February, May, August, and November of each year. A dot release will be prepared sooner if [Electron](https://github.com/electron/electron/releases) releases a security update, or if other urgent bugs are found. Please refer to [the desktop app release playbook](https://community.mattermost.com/playbooks/playbooks/h3a39biacpnuim7ufmwiuuoxfo/outline) for the release checklist. For the desktop app release build process, please refer to [this document](https://developers.mattermost.com/internal/desktop-release-process/). ## Release timeline Note: T-minus counts are measured in "working days" (weekdays other than major holidays concurrent in US and Canada) prior to release day. Every 3 months, the Desktop app release milestones follow the cloud/self-hosted release milestones to align all release testing cycles. **Schedule for Desktop App releases**: * Cut release branch at T-24. This is also the Feature Complete deadline. * Cut RC-1 at T-19. * Code Freeze at T-10. * [QA approval](https://community.mattermost.com/playbooks/playbooks/h798dt39mpbymb8z5uoiuf4hdo/outline) should be ready by T-8. * Release Day at T-0. # Release tips **Bug bashes** * Run a bug bash at least for major releases. * Bug bashes can either be run asynchronously/individually or as a group. * Use a playbook to run bug bashes - [example bug bash playbook](https://community.mattermost.com/playbooks/playbooks/raxoo6hua3gpdpthaqmpmdzptw/outline). * PMs can assign test assignments and testers under the "Testing areas" checklist item. * Decide environments to test on - normally community or rc.test.mattermost.com + include Mobile and Desktop app environments. * Decide date(s) for the bug bash. * Announce bug bash on the day when the bug bash starts. * Invite community members to participate in the bug bash. * Triage owner (normally Release Manager) - review reported issues to identify what to fix for the upcoming release and open/assign tickets to teams. **Changelog checklist** * Features * State benefits first. * Order features based on benefit for end users. * Include links to docs where appropriate. * Bugs * Check/test if the issue was in previous server version. * All sections * Check that all sections are written and formatted the same way as in previous changelogs. * API/Websocket/Database * Work with Devs on this section. * Next version * If the changelog mentions items regarding upcoming versions, move them to the bottom of the changelog. **Ways to meet deadlines** * Post a list of dates for next release at or soon after T-0 and ping all of the teams. * For features and bugs, start pinging early enough before due dates and make public posts. * When pinging people, provide a clear due date and give a reason for the due date (e.g., Code Complete on Monday). * Ask if people need any help or have any questions. **Translations** * Monitor progress of translations at and ping language maintainers a few days before due date if they're not getting to 100%. * Ask DevOps to submit a new translations PR if a translation deadline extension is requested. * Target date for final translations PR is T-24 (feature complete deadline). **Ways that** [**features/bugs guidelines**](https://docs.google.com/document/d/1QxB_A1qkEJBKAvQpRa7JiSQLZhwg6HAEajNRNa7ldGg/edit) **are currently enforced** * Features guidelines: * Start to ping people already at T-30 for feature PRs that are still open. * Bugs guidelines: * Need to focus on fixing only S1 and S2 bugs after RC-1 has been cut to avoid missing T-10 deadline for cutting the final. **Ways to ensure features are tested for HA/Mobile/Scale** * HA: Test server available. * Scale: Via loadtests. **Release marketing** * Blog post: * Follow [guidelines](https://handbook.mattermost.com/operations/messaging-and-math/how-to-guides-for-m-and-m/how-to-create-release-announcements). # Release scorecard definitions * [Spreadsheet](https://docs.google.com/spreadsheets/d/1Aoj4OTaWoyrKIcQNiHH1MVoRG51T20Y_0w2tg5oVw-M/edit#gid=825551144) ## Release Hearbeat | Metric | How to Measure | | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Date/time RC1 cut (PST) | Check Release Self-Hosted/Cloud channel history for date/time RC1 was cut. | | Total number of RCs cut | Check Release Self-Hosted/Cloud channel history for how many RCs were cut for that release. | | Number of days the final build is cut before the 16th | Check Release Self-Hosted/Cloud channel for post with official release build. Oxygen = 16th - Day Final RC is cut | | Community + customer bugs reported during release timeframe (17th to 16th) |

With a new or existing Jira filter, with:

  1. Project = Mattermost
  2. Fix Versions = Latest released version
  3. Issue Type = Bug
  4. Label = Customer-bug and Community-bug
  5. Created Date = 17th of the previous month
  6. Release Date = 16th of the current month
| | Number of bugs reported within a week after the release |

With a new or existing Jira filter, with:

  1. Project = Mattermost
  2. Issue Type = Bug
  3. Status = Open
  4. Label = Customer-bug and Community-bug
  5. Created Date = Between the 16th and 23rd of the month
| | Number of customer bugs fixed during release |

With a new or existing Jira filter, with:

  1. Project = Mattermost
  2. Fix Versions = Latest released version
  3. Issue Type = Bug
  4. Status = Closed and Resolved
  5. Label = Customer-bug
| | Total valid bug fixes in fix version |

After closing current release:

project = Mattermost AND issuetype = Bug AND resolution not in (Duplicate, "Cannot Reproduce", "Won't Fix") AND fixVersion = latestReleasedVersion()

| | Total valid regression fixes in fix version |

After closing current release:

project = Mattermost AND issuetype = Bug AND resolution not in (Duplicate, "Cannot Reproduce", "Won't Fix") AND fixVersion = latestReleasedVersion() AND label = rc2, rc3

| | Valid bugs found after RC1 is pushed to next release |

After closing current release, adjust dates as per above, and use this Jira query:

project = Mattermost AND issuetype = Bug AND resolution not in (Duplicate, "Cannot Reproduce", "Won't Fix") AND created > "START" AND created < "END" AND fixVersion = earliestUnreleasedVersion()

| | Valid bugs found after RC1 fix version = other (eg unscheduled, not set) |

After closing current release, adjust dates as per above, and use this Jira query:

project = Mattermost AND issuetype = Bug AND created > "START" AND created < "END" AND resolution not in (Duplicate, "Cannot Reproduce", "Won't Fix") AND (fixVersion not in (latestReleasedVersion(), earliestUnreleasedVersion()) OR fixVersion is EMPTY)

| | Total valid bugs found after RC1 is cut |

After closing current release, adjust dates as per above, and use this Jira query:

  1. Check Jira timezone + Community server timezone and make sure times match
  2. Replace START with date (yyyy-MM-dd HH:mm) RC1 was cut
  3. Replace END with date (yyyy-MM-dd HH:mm) release was published

project = Mattermost AND issuetype = Bug AND resolution not in (Duplicate, "Cannot Reproduce", "Won't fix") AND created > "START" AND created < "END"

| | Number of PRs reverted | Check recently merged GitHub PRs (with the word "Revert" in the PR title). | | | | | (Non-security) Bugs requiring patch release | After any patch release goes out (after the normal release date): Check Changelog for total number of non-security patch releases. | | Total features/improvements in fix version |

With a new or existing Jira filter, with:

  1. Project = Mattermost
  2. Fix Versions = Latest released version
  3. Issue Type = Story
  4. Status = Closed and Resolved
| # How-to guides for Product --- [Next Page](/llms-full.txt/1)