Onboarding¶

Developer Meeting¶

Open to the public - (Developers - 1-2 hours/week) Wednesdays 10:00 (San Francisco Time)

• Goal: Discuss developer issues across Mattermost Inc, key contributors and the contributor community.
• Attendees: (required) Mattermost Inc developers, (optional) key contributors, contributors and anyone who would like to join.

Procedure:

1. (Chair): Post meeting agenda in Developers channel (open to the public), tagged with #devmeeting

2. (Team and Public): At the time of the meeting:

   • Join the Hangouts link posted in the meeting agenda in the Developers channel

To review past agendas for the Developer meeting in the Developers channel click on the #devmeeting hashtag in any of the meeting notes, or search for it directly.

Sprint Planning¶

Mattermost Staff Only - (Developer - 5-10 minutes/week) Tuesdays between 10:00 and 11:00 (San Francisco Time)

• Goal: Review and discuss tickets selected by developer for next sprint
• Attendees: (required) Each developer in sequence, plus spint planners (one dev, one PM), (optional) Mattermost staff colleagues welcome

Note:

• This meeting uses a special Mattermost staff-only BACKLOG query showing tickets by sprint, with tabs across the top for each developer
• Prior to meeting, developers drag and drop tickets from their backlog to next sprint based on team priorities
• Developers are welcome at any time to discuss reassigning tickets with colleagues using common sense (if both are okay with the change, add “triage” tag to fix version with comment and triage team will review to make the change)
• During the meeting, developer’s next sprint is reviewed, discussed, possibly adjusted and locked

Procedure:

1. (Chair): Just prior to meeting, post Hangout link in Standup private channel
2. (Developer): Replies in Standup private channel when sprint is ready for review
3. (Chair): Will (at)mention next developer to join Hangout to review tickets. Developer joins, tickets are discussed and finalized for next sprint. Developer leaves Hangout and next developer rotates in.

Triage Meeting¶

Mattermost Inc-only - (Triage team - 1-3 hours/week) Monday, Wednesday, Friday 09:00 (San Francisco Time)

• Goal: To provide consistent review, prioritization and ownership assignment of all tickets
• Attendees: (required) dev and PM from Mattermost Inc., typically leads (optional) other Mattermost Inc. colleagues welcome

Note:

• ONLY TRIAGE TEAM should set or change the Fix Version of a ticket.

  • When tickets are first created, they go to triage to be reviewed for clarity and priority and assigned a Fix Version. Unclear tickets may be assigned to their creator for more information.
  • The Fix Version determines the sequence in which tickets are addressed and triage team is accountable for that sequence.

• If you’re ever unsure about a ticket (if it’s not clear, or doesn’t seem appropriate) add a comment and add triage to the Fix Version field, which will trigger a review by the triage team in 1-2 working days.

  • It’s the responsibility of the triage team to make sure tickets are clear before they’re assigned a Fix Version.

• ONLY TRIAGE TEAM can close a ticket resolved as Won’t Fix or Won’t do

  • These tickets resolved in such a way are reviewed by triage team.
  • Only resolve a ticket as Won’t Fix or Won’t Do if you’re highly confident it’s the correct decision, otherwise, add “triage” to Fix Version for review. In either case, include a comment with your reason.

Procedure:

1. (Chair): Just prior to meeting, post Hangout link in Standup private channel (Mattermost Inc. only)
2. (Attendees): Join the link
3. (Attendees): Review query for tickets needing triage and assign owner and fix version

Leads Meeting¶

Mattermost Inc-only - (Leads - 1-3 hours/week) Monday and Wednesday (9:00 San Francisco Time)

• Goal: Address leadership and process topics
• Attendees: (Required) Dev, PM, community/marketing leads from Mattermost Inc., with sales lead and other Mattermost staff optional.

Note:

• Decisions should go to Leads meetings when there is lack of clarity or ownership, or to discuss special case topics where process is not well defined.

  • When possible, decision-making should belong to the people closes to details
  • Individual developers or PMs should make most decisions, and raise to developer or PM team if things are unclear, and go to Leads if lack of clarify persists.

• To queue an item for Leads ask the dev or PM lead

• Leads is also used for cross-discipline Q&A

  • Rather than randomize individual contributors, cross-discipline discussion (e.g. marketing to PM, community to dev, etc.) can happen in leads

Procedure:

1. (Leads): Queue items in Leads channel for discussion.
2. (Leads): During meeting discuss agenda items in sequence.

Platform Meeting¶

Mattermost Inc-only - (Platform colleagues - 1 hour/week) Thursday’s at 10:00 (San Francisco Time).

Regular team meeting for platform team at Mattermost Inc.

• Goal: Increase team output by effectively reviewing priorities and finding blindspots
• Scope: Mattermost Inc-only meeting given confidential customer issues discussed
• Attendees: Mattermost Inc colleagues working on platform

Platform meeting consists of two parts, Team Operation Review Meeting and Product Staff Meeting.

All Mattermost staff attends the Team Operation Review Meeting. It provides an opportunity to teach and learn between people who don’t otherwise deal with each other much. Includes presentations and demos.

Only the product team attends the Product Staff Meeting, others’ attendance is optional. The meeting consists of people who work closely together. Includes controlled agenda items (e.g. queued items) with an “open session” where staff can bring up anything they want. Staff should arrive at decisions during the meeting or schedule further discussion for the next meeting.

Procedure:

1. (Chair) 3-hours before standup, post reminders in Platform private channel (Mattermost Inc only)

#### @channel Platform Meeting Reminder
Everyone please:
- **Prepare your demos**
- **Prepare your roundtable open discussion**

@[RELEASE MANAGER] please:
- **Prepare your roadmap checkin**

@[WHOEVER] are you ready for your "Ice-breaker"?

2. (Team) At time of meeting:

   • Join the Hangout link in the header of the Platform private channel
   • Open the Notes link in the header to see the agenda

3. (Vice-Chair) Post “Standing Items” template into Platform Meeting Notes

   • Add Follow-ups from previous meeting
   • Add New items queued in Platform private channel (Mattermost Inc only)

Meeting Agenda:

Team Operation Review Meeting

• Warm-up - Currently: “Share something interesting about your weekend.”
• Roadmap check-in - Review of roadmap status in current and next release
• Demos (optional) - Team members show highlights of what’s been completed this week. Relevant follow-ups noted.
• New items - New team relevant items are discussed

Product Staff Meeting

• Roundtable Open Discussion - Each colleague shares something important to discuss with the team. Examples: external customer or user issue, potential process improvement. Follow-ups noted.
• New items - New product staff relevant items are discussed
• Follow-ups - Follow-ups from previous meeting are discussed
• Questions - To find blindspots, meeting does not end until 3 open questions are asked and answered.

Post Meeting:

• Follow-up items are posted to the Platform private channel (Mattermost Inc only)

Warm-ups¶

• 2-3 minute exercises designed to learn more a colleagues at the start of a recurring meeting

• Typically rotates alphabetically by first name, one colleague per meeting

• Examples:

  • “Hobby talk” - sharing about an interesting hobby, past or present
  • “My home town” - sharing something interesting about where you grew up
  • “Two truths and a lie” - share two true facts about yourself and one lie, team guesses which is the lie.

Open Questions¶

• Exercise to find blindspots in team thinking at the end of a meeting

• Meeting does not end until 3 questions are asked and answered, typically at least one of the questions reveals a blindspot or opportunity to improve communication.

• Examples of questions:

  • “What’s the status on X?” // often an important item that got forgotten
  • “Who owns X?” // reveals need for more clarity or communication
  • “Why do we do X?” // let’s us verify if a process is needed, and if we’re handling it the right way

1) Increase precision through unambiguous definitions of useful terms¶

For example, “0/5” and “5/5” help convey the level of conviction behind an opinion. Also, a precise classification of tickets as “Bug” or “Improvement” is critical since it affects scheduling and decision making, and so forth.

2) Increase the speed of communication via a small number of frequently used acronyms¶

LHS and RHS are examples of a very limited number of acronyms to use to speed discussions, specifications, and ticket writing.

3) Reduce repeated mistakes by naming very specific undesirable behaviors¶

Naming specific repeated mistake helps us find patterns, avoid repeated mistakes in future, and helps newcomers avoid making similar mistakes as they learn our organization’s terminology.

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.

Bug¶

An obvious error in Mattermost software. Changes required to accommodate unsupported 3rd party software (such as browsers or operating systems) are not considered bugs, they are considered improvements.

Dead Tarzan¶

Discarding an imperfect solution without a clearly thought out and working alternative. Based on idea of Tarzan of the Jungle letting go of a vine without having a new vine to swing to.

Decking¶

A term for shipping something that is 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 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.

Expert Mode (and Crimson Force Field)¶

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 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.

Help Wanted¶

Help Wanted tickets, which are vetted changes to the source code open for community contributions.

Improvement¶

A beneficial change to code that is not fixing a bug.

LHS¶

The “Left-Hand Sidebar” in the Mattermost team site, used for navigation.

Mana¶

An estimate of total energy, attention and effort required for a task.

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 feature added has an initial and on-going mana cost, which is taken into account in feature decisions.

RHS¶

The “Right-Hand Sidebar” in the Mattermost team site, used for navigation.

Windows Vista approach¶

An attempt to add functionality through a massive, complex one-time re-write hoping to improve the architecture, but which likely ends in repeated delays, wasted effort, buggy code and limited architectural improvement (compared to re-writing the architecture in phases). This tempting, high risk approach is named after Microsoft’s “Windows Vista” operating system, one of its most famous examples.

Developer¶

Developers are responsible for architecting and delivering software improvements, and for technical leadership among the Mattermost community.

• Architecture

  • Developers are responsible for researching, analyzing, designing and reviewing technical solutions to achieve functional requirements. Solutions should thoroughly consider trade-offs and be evaluated based on the effectiveness of the end implementation.

• Delivery

  • Based on technical designs, developers estimate, implement, test, maintain, review, debug and release software improvements in collaboration with teammates. This includes working closely with product managers to validate requirements and the output of designs and making appropriate adjustments. The success of implementation is judged on the end results achieved by the changes.

• Technical Community Leadership

  • As leading experts on Mattermost technology, developers support and engage constantly with the broader Mattermost community to accelerate adoption and to discover new ways to improve Mattermost software and processes. This includes investigating and supporting issues from users and customers, reviewing and providing feedback on projects from contributors, and understanding priorities, trends and patterns across the community.

Product Managers¶

Product managers are responsible for aligning teams to strategic priorities, leading and managing the product development process, and working effectively with marketing to bring the full benefits of Mattermost solutions to users and customers.

• Strategy

  • Every project and every team needs to align to strategic priorities and focus on intended outcomes developed through a deep understanding of the market, user, customers and competing products and services. Amid a flood of compelling suggestions, opinions, and data, product managers must find what’s vital, and rally teams around a shared vision.

• Product development

  • Product managers lead both the functional design process (user, customer and competitor research, analysis, ideation, prioritization, functional and user experience design, functional specification, user and customer validation), and the software development process (ticketing, prioritization, roadmap design, scheduling, sprint planning, triage, functional verification, implementation validation with users and customers, documentation, and release logistics).
  • It’s the product manager’s responsibility to see features shipped predictably and at high quality through planning, attention to detail and thoughtful persuasion.

• Marketing connection

  • Delivering benefits to users and customers based on product features is a core responsibility of product managers, working in conjunction with marketing to shape messaging and positioning and delivering collateral, events, and user and customer discussions to support sales.

Developers¶

Books¶

1. Code Complete, Steve McConnell - Best practices and guidelines for writing high quality code.
2. Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (aka “Group of Four”) - Fundamental reading on design patterns. Other design pattern books work too, this is one of the most popular.

Product Management¶

Courses

1. Harvard Business School PM 101

Relevant Docs

1. Design Process

Software Strategy¶

1. Monetizing Open Source (Or, All Enterprise Software) - Required reading for business roles

System Security¶

Papers & Course Materials

1. Framework for Improving Critical Infrastructure Cybersecurity. National Institute of Standards and Technology - Standards for internal Mattermost security processes and safeguards.
2. Computer Security in the Real World. Butler Lampson - Fundamental challenges with system security.
3. Course notes from CS513: System Security (Cornell University). Fred B. Schneider - Well written introduction to system security from one of the leaders in the field.

Additional Training Resources¶

Recommended training materials are recommended by role at three different levels of priority:

1. P1 - Required - Complete within 30 days of starting in role.
2. P2 - Priority - Complete within 30-90 days of starting.
3. P3 - Supplementry - Complete within 180 days.

The following chart outlines training materials by category, with notes on which materials are relevant to which disciplines by P1, P2, P3 priority:

The following table summarizes abbreviations used in the above table: