Project Process
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.
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.
- 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
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.
- 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.
Project Management
Contributing