Development Process

Mattermost core team plans to work on a monthly release process by end of 2015. Ideally we’ll be shipping on the 16th of each month, however our v0.7.0 release is scheduled for September 4, 2015 and we’ll need to adjust a few of our fall 2015 releases to move gracefully to a release cycle on the 16th.

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.

This is a working document that will update as our process evolves.

Principles

Our development process centers about three principles:

  1. Make something people love – Talk to users constantly. Shape and adapt plans based on feedback and data.
  2. Big rocks first – Queue large, important, potentially destabilizing features early in a release cycle. Leave plenty of time for stabilization and testing.
  3. Slow is smooth, smooth is fast – Thinking carefully and building predictably at high quality are more important than jamming in any one feature.

When we’re not sure on a decision, these principles are our tie-breakers.

Roles

Responsibilities across the development process are divided into roles. Team members may take on one or more roles depending on skills, interests and product priorities. For example, some developers might also serve as part time product managers, or some product managers may be part-time designers.

Here’s how responsibilities lay out across roles:

  • Everyone
    • Talk to users over community channels
    • Use and test the product, and file clear tickets
  •  Developers
    • Partner with product management in defining roadmap and strategy
    • Lead, analyze, and discuss technical decisions
    • Write, test and review code
    • Manage build and technical release process
    • Support and engage technical community
    • Author technical guidance and documentation
  • Product Managers
    • Partner with developers in defining roadmap and strategy
    • Manage product planning, issue tracking, triage and release processes
    • Write and manage specifications and tickets
    • Support technical community
    • Author general guidance and documentation
  • Designers
    • Write and manage specifications and tickets
    • Create wireframes, full fidelity UI renderings, front end code
    • Develop and author design and branding standards
  • Operations
    • Manage day-to-day team processes and checklists  
    • Lead testing and monitoring of product quality
    • Review resolved issues and close or re-open as appropriate

Process

With this in mind, below is the Mattermost development process.

  1. Sprints
    1. Sprints start and end on Fridays at 10am PST and last two weeks. Sprints continue regardless of release process.
    2. (Daily)
      1. PM triages incoming tickets
        1. Bugs are added to active sprint. Feature are added to the backlog, assigned to a dev, component and fix version
      2. Devs add estimates to tickets assigned to them
      3. Operations reviews resolved tickets.
        1. Tickets are closed if they are complete, re-opened if there is something significantly wrong, or opens new tickets if there are minor issues that need to be addressed in a resolved ticket.
    3. (End of Sprint)
      1. Devs demo features
      2. PM organize the next two-weeks of sprint tickets based on dev estimates
  2. Release (cut-off times based on 9am PDT)
    1. (10 weekdays before release date) Cut-off for major features
      1. No major features can be committed to the current release after this date
      2. Dev joins PM in triage meetings to prioritize the final tickets of the release.
    2. (8 weekdays before release date) Feature Complete and Stabilization
      1. After the cut-off time for Feature Complete, Dev prioritizes reviewing PRs and committing to master so Stabilization period can begin, with testing and high priority bug fixes.
      2. During Stabilization period only BUGS can be committed to master, non-bug tickets are tagged for next version and wait until after a release candidate is cut to be added to master.
    3. (5 weekdays before release date) Code Compete and Release Candidate
      1. On this date, the release is considered “Code Complete”. Master is tagged and branched and “Release Candidate 1” is cut (e.g. 0.7.0-RC1)
        1. Following the branch, devs can go back to committing to master for tickets scheduled for the next release.
      2. RC1 is pushed to an acceptance server (RELEASE_VERSION.ACCEPTANCE_SERVER.com) by a dev or PM following the installation instructions step-by-step (developer running install should rotate so we get fresh eyes)
      3. Final testing is conducted by the team on the acceptance server and any issues found are filed.
        1. If a serious issue is found and deemed by PM and dev to be “blocking” a release, a hot fix is made to the release branch and a new RC is cut and tested.
        2. If no blocking issues are found, Operations signs off on the release
    4. (2 weekdays before release date) Release
      1. Dev tags a new release (e.g. 0.7.0) and runs an official build which should be essentially identical to the last RC
        1. Any significant issues that were found and not fixed for the final release are noted in the release notes.
      2. If an urgent and important issue needs to be addressed between major releases, a hotfix release (e.g. 0.7.1) may be released, however this should be very rare, given a monthly cadence.