Skip to content

Project Process

yoyo edited this page Dec 12, 2018 · 5 revisions

Releases

MRTK strives for quarterly releases, though we depending on state and current features we may forego a quarter. An indicator of project health is that we hit each release. Roadmap defines the high level goals we are looking towards each year.

MRTK uses semantic versioning to indicate changes in each release. Our goal is to provide an MRTK that is easily upgradeable for the current major release:

  • MAJOR version for breaking changes. Once per year.
  • MINOR version for add-on features or critical breaking changes
  • PATCH version for fixes that include no breaking changes.

Iterations

We work in monthly iterations on the items on the roadmap. Iterations are roughly month based, rather than week based. We will begin a milestone on a Monday and end on a Friday, meaning that each milestone can have a different duration, depending on how the weeks align.

At the end of each iteration, we want a stable MRTK which developers can consume and get feedback.

Planning

Before each milestone, we will prioritize features to implement and bugs to fix in the upcoming iteration. Issues are assigned a milestone for the iteration. We don't accept new features after planning, but the next iteration is right around the corner. We will take additional fixes each iteration, aiming for continuous improvement.

Definition of Done (TODO: vscode's example below)

  • Test Plan Item created
  • Key board accessible
  • Screen reader accessible
  • Works with the different themes, including the high contrast theme
  • Telemetry events in place
  • Release notes updated

Inside an Iteration

Triage

Issues/Feedback in the current Development Branch – Get to Done items

  • 2018 Adoption Blocking – this is the set of issues that would block adoption of the 2018 release
    • Graham and Yoyo will work to gather feedback from internal ISV, and community forums
    • Triage DRI – Yoyo
    • Dev DRI – David/Kurtis
  • 2018 Documentation – this tracks the set of documentations needs for the 2018 release
    • Graham and Yoyo will work to gather feedback from internal ISV, and community forums
    • Triage DRI – Graham/Yoyo
    • Dev DRI – David/Kurtis
  • 2018 Feature Change – Think of these as DCR
    • Triage DRI – Yoyo/Chris
    • Dev DRI – Chris

Feedback on the current release – Servicing/maintenance items

  • Bug – This represent a bug in our release code
    • Must include repro steps
    • Triage DRI – Yoyo
    • Dev DRI – David/Kurtis
  • Suggestions – This is a request to change the current design
    • Must include reasons and impact
    • Triage DRI – Yoyo
    • Dev DRI - Chris
  • Feature Request – This is a request to add a feature
    • Triage DRI – Yoyo
    • Dev DRI – Chris
    • We can categorize the feature request into buckets. This is also where our researcher Nick Gorlovski would be able to help.

Weekly

End Game