RFC: TypeSpec Planning 2026 - 2027#4633
Conversation
Introduces a comprehensive planning document covering TypeSpec ecosystem strategy for Summer 2026 and beyond, organized into 9 workstreams with user stories and user-impact metrics for each feature area. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
markcowl
changed the title
|
No changes needing a change description found. |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
You can try these changes here
|
⚡ Benchmark Results
Full details – comparing
|
| Metric | Baseline | Current | Change |
|---|---|---|---|
| total | 🔴 486.6ms | 🔴 588.8ms | +21.0% 🔴 |
| loader | 🟢 125.5ms | 🟢 158.8ms | +26.6% 🔴 |
| resolver | 🟢 15.2ms | 🟢 20.1ms | +32.3% 🔴 |
| checker | 🟢 146.4ms | 🟢 190.8ms | +30.3% 🔴 |
| validation | 🟢 34.5ms | 🟢 44.1ms | +27.6% 🔴 |
| ↳ validation/@azure-tools/typespec-azure-core | 🟢 5.1ms | 🟢 6.4ms | +25.5% 🔴 |
| ↳ validation/@typespec/http | 🟢 4.4ms | 🟢 5.5ms | +24.7% 🔴 |
| ↳ validation/@typespec/rest | 🟢 0.5ms | 🟢 0.8ms | +52.6% |
| ↳ validation/@typespec/versioning | 🔴 22.8ms | 🔴 29.4ms | +29.3% 🔴 |
| ↳ validation/compiler | 🟢 1.4ms | 🟢 1.8ms | +30.7% |
| linter | 🟢 104.2ms | 🟢 131.8ms | +26.4% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/auth-required | 🟢 0.0ms | 🟢 0.0ms | +19.9% |
| ↳ linter/@azure-tools/typespec-azure-core/bad-record-type | 🟢 0.2ms | 🟢 0.2ms | -4.4% |
| ↳ linter/@azure-tools/typespec-azure-core/byos | 🟢 4.7ms | 🟢 5.8ms | +22.1% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/casing-style | 🟢 0.6ms | 🟢 0.6ms | +15.3% |
| ↳ linter/@azure-tools/typespec-azure-core/composition-over-inheritance | 🟢 0.1ms | 🟢 0.1ms | +26.8% |
| ↳ linter/@azure-tools/typespec-azure-core/documentation-required | 🟢 0.8ms | 🟢 0.9ms | +11.7% |
| ↳ linter/@azure-tools/typespec-azure-core/friendly-name | 🟢 0.5ms | 🟢 0.6ms | +13.6% |
| ↳ linter/@azure-tools/typespec-azure-core/key-visibility-required | 🟢 0.1ms | 🟢 0.2ms | +24.5% |
| ↳ linter/@azure-tools/typespec-azure-core/known-encoding | 🟢 0.3ms | 🟢 0.3ms | +2.3% |
| ↳ linter/@azure-tools/typespec-azure-core/long-running-polling-operation-required | 🟢 0.2ms | 🟢 0.3ms | +32.5% |
| ↳ linter/@azure-tools/typespec-azure-core/no-case-mismatch | 🟢 0.2ms | 🟢 0.3ms | +27.4% |
| ↳ linter/@azure-tools/typespec-azure-core/no-closed-literal-union | 🟢 0.2ms | 🟢 0.3ms | +44.9% |
| ↳ linter/@azure-tools/typespec-azure-core/no-enum | 🟢 0.0ms | 🟢 0.0ms | +29.8% |
| ↳ linter/@azure-tools/typespec-azure-core/no-error-status-codes | 🟢 0.1ms | 🟢 0.1ms | +24.0% |
| ↳ linter/@azure-tools/typespec-azure-core/no-explicit-routes-resource-ops | 🟢 0.1ms | 🟢 0.1ms | +34.8% |
| ↳ linter/@azure-tools/typespec-azure-core/no-format | 🟢 0.5ms | 🟢 0.6ms | +18.7% |
| ↳ linter/@azure-tools/typespec-azure-core/no-generic-numeric | 🟢 0.5ms | 🟢 0.4ms | -10.8% |
| ↳ linter/@azure-tools/typespec-azure-core/no-header-explode | 🟡 14.2ms | 🟡 18.3ms | +28.5% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-legacy-usage | 🟢 0.9ms | 🟢 1.1ms | +20.7% |
| ↳ linter/@azure-tools/typespec-azure-core/no-multiple-discriminator | 🟢 0.1ms | 🟢 0.1ms | +27.6% |
| ↳ linter/@azure-tools/typespec-azure-core/no-nullable | 🟢 0.2ms | 🟢 0.3ms | +4.4% |
| ↳ linter/@azure-tools/typespec-azure-core/no-offsetdatetime | 🟢 1.0ms | 🟢 1.2ms | +16.2% |
| ↳ linter/@azure-tools/typespec-azure-core/no-openapi | 🟢 1.6ms | 🟢 2.1ms | +27.0% |
| ↳ linter/@azure-tools/typespec-azure-core/no-private-usage | 🟢 1.6ms | 🟢 2.0ms | +30.1% |
| ↳ linter/@azure-tools/typespec-azure-core/no-query-explode | 🟡 14.8ms | 🟡 18.6ms | +25.4% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-response-body | 🟡 17.8ms | 🔴 22.5ms | +26.4% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-rest-library-interfaces | 🟢 0.0ms | 🟢 0.0ms | +18.2% |
| ↳ linter/@azure-tools/typespec-azure-core/no-route-parameter-name-mismatch | 🟢 3.6ms | 🟢 4.7ms | +29.8% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/no-rpc-path-params | 🟢 0.1ms | 🟢 0.2ms | +21.8% |
| ↳ linter/@azure-tools/typespec-azure-core/no-string-discriminator | 🟢 0.0ms | 🟢 0.0ms | +7.3% |
| ↳ linter/@azure-tools/typespec-azure-core/no-unknown | 🟢 0.2ms | 🟢 0.2ms | -1.0% |
| ↳ linter/@azure-tools/typespec-azure-core/no-unnamed-union | 🟢 0.3ms | 🟢 0.4ms | +16.2% |
| ↳ linter/@azure-tools/typespec-azure-core/operation-missing-api-version | 🟢 0.1ms | 🟢 0.2ms | +31.9% |
| ↳ linter/@azure-tools/typespec-azure-core/request-body-problem | 🟢 0.3ms | 🟢 0.3ms | +25.1% |
| ↳ linter/@azure-tools/typespec-azure-core/require-versioned | 🟢 0.0ms | 🟢 0.0ms | +28.3% |
| ↳ linter/@azure-tools/typespec-azure-core/response-schema-problem | 🟡 17.4ms | 🔴 22.4ms | +28.9% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/rpc-operation-request-body | 🟢 0.2ms | 🟢 0.3ms | +23.3% |
| ↳ linter/@azure-tools/typespec-azure-core/spread-discriminated-model | 🟢 0.3ms | 🟢 0.3ms | +5.7% |
| ↳ linter/@azure-tools/typespec-azure-core/use-standard-names | 🟢 3.8ms | 🟢 5.4ms | +43.0% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-core/use-standard-operations | 🟢 0.1ms | 🟢 0.1ms | +25.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-common-types-version | 🟢 2.9ms | 🟢 3.8ms | +29.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-custom-resource-no-key | 🟢 0.1ms | 🟢 0.1ms | +23.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-custom-resource-usage-discourage | 🟢 0.1ms | 🟢 0.1ms | +8.3% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-delete-operation-response-codes | 🟢 3.9ms | 🟢 4.8ms | +21.5% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-no-path-casing-conflicts | 🟢 3.2ms | 🟢 4.1ms | +28.3% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-no-record | 🟢 0.4ms | 🟢 0.4ms | +1.7% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-post-operation-response-codes | 🟢 0.3ms | 🟢 0.4ms | +28.2% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-put-operation-response-codes | 🟢 0.0ms | 🟢 0.0ms | +18.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-action-no-segment | 🟢 0.2ms | 🟢 0.2ms | +38.2% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-duplicate-property | 🟢 0.1ms | 🟢 0.1ms | +10.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-interface-requires-decorator | 🟢 0.0ms | 🟢 0.0ms | +26.6% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-invalid-action-verb | 🟢 0.1ms | 🟢 0.1ms | +26.3% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-invalid-envelope-property | 🟢 0.1ms | 🟢 0.1ms | +6.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-invalid-version-format | 🟢 0.0ms | 🟢 0.0ms | +34.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-key-invalid-chars | 🟢 0.2ms | 🟢 0.2ms | +17.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-name-pattern | 🟢 0.0ms | 🟢 0.0ms | +19.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-operation | 🟢 0.1ms | 🟢 0.2ms | +19.7% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-operation-response | 🟢 3.4ms | 🟢 4.4ms | +30.1% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-patch | 🟢 0.2ms | 🟢 0.3ms | +26.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-path-segment-invalid-chars | 🟢 0.2ms | 🟢 0.2ms | +18.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/arm-resource-provisioning-state | 🟢 0.1ms | 🟢 0.1ms | +16.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/beyond-nesting-levels | 🟢 0.1ms | 🟢 0.1ms | +18.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/empty-updateable-properties | 🟢 0.1ms | 🟢 0.1ms | +15.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/improper-subscription-list-operation | 🟢 0.0ms | 🟢 0.0ms | +29.6% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/lro-location-header | 🟡 10.0ms | 🟡 13.4ms | +33.7% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/missing-operations-endpoint | 🟢 0.0ms | 🟢 0.0ms | +42.8% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/missing-x-ms-identifiers | 🟢 0.3ms | 🟢 0.3ms | +4.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-empty-model | 🟢 0.1ms | 🟢 0.1ms | +25.4% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-override-props | 🟢 0.1ms | 🟢 0.1ms | +2.9% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-resource-delete-operation | 🟢 0.1ms | 🟢 0.2ms | +31.7% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/no-response-body | 🟡 16.8ms | 🔴 20.3ms | +21.2% 🔴 |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/patch-envelope | 🟢 0.1ms | 🟢 0.1ms | +22.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/resource-name | 🟢 0.1ms | 🟢 0.1ms | +15.5% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/secret-prop | 🟢 2.0ms | 🟢 2.7ms | +34.5% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/unsupported-type | 🟢 0.4ms | 🟢 0.4ms | +2.0% |
| ↳ linter/@azure-tools/typespec-azure-resource-manager/version-progression | 🟢 0.0ms | 🟢 0.0ms | +13.9% |
| ↳ linter/@azure-tools/typespec-client-generator-core/property-name-conflict | 🟢 0.8ms | 🟢 1.1ms | +25.3% |
| ↳ linter/@azure-tools/typespec-client-generator-core/require-client-suffix | 🟢 0.2ms | 🟢 0.2ms | +32.4% |
| emit | 🔴 4.56s | 🔴 5.88s | +29.0% 🔴 |
| ↳ emit/@azure-tools/typespec-autorest | 🟢 127.5ms | 🟢 199.3ms | +56.3% 🔴 |
| ↳ emit/@azure-tools/typespec-python | 🔴 3.26s | 🔴 4.27s | +30.8% 🔴 |
| ↳ emit/@typespec/http-client-js | 🔴 946.7ms | 🔴 1.15s | +21.7% 🔴 |
| ↳ emit/@typespec/openapi3 | 🟢 130.2ms | 🟢 151.3ms | +16.2% 🔴 |
| ↳ emit/@typespec/openapi3/compute | 🟢 112.6ms | 🟢 131.6ms | +16.9% 🔴 |
| ↳ emit/@typespec/openapi3/write | 🟢 17.7ms | 🟢 20.2ms | +14.3% 🔴 |
Averaged across 3 specs (azure-arm-resource-manager, azure-core-dataplane, azure-full).
Threshold: changes > ±5% are highlighted.
🟢 Fast · 🟡 Moderate (stages >200ms, rules >10ms) · 🔴 Slow (stages >400ms, rules >20ms)
…oundaries - Normalize 'service team member' to 'service team' throughout - Differentiate user stories across CI subsections to reduce overlap - Clarify Spec Rollout Tools as orchestration (vs source emitter as engine) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Run prettier on the planning document - Add 'unreviewed' to cspell.yaml dictionary Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| | False positive rate | TBD | < 5% | | ||
| | Service team satisfaction (quarterly survey) | TBD | > 4/5 rating | | ||
|
|
||
| ### TypeSpec Breaking Change Detection |
There was a problem hiding this comment.
Are we talking about RestAPI breaking changes, or SDK breaking changes or both?
Who is responsible to define the rules on each side? Are we in a situation like the linter, where the ARM team and/or SDK team is responsible to define those rules?
Also, it's not clear if this tool support suppressions, it's not explicitly mentionned
There was a problem hiding this comment.
I believe from previous discussion this is only about rest api breaking change detection. The SDK breaking change should be moved to the SDK validation checks if we could actually rely on them
There was a problem hiding this comment.
This is about rest api breaking changes. If needed, we could add in some sdk breaking changes, but I think the only way to get a definitive list would involve emitter-specific considerations, so not in plan at the moment.
|
|
||
| ### TypeSpec Examples Tooling | ||
|
|
||
| - **Pri 0** — TypeSpec-native tools for generating, validating, and managing JSON examples |
There was a problem hiding this comment.
Let's not put JSON as a format, @timotheeguerin is already making prototype with other format. Reading the rest, we just need to remove the word JSON. The meaning stays the same, but we're less opiniated in the format itself.
There was a problem hiding this comment.
This is more about the wire format than the example format - we can have yaml examples that describe json wire formats
| - Reduce required examples for new API versions to only changed operations/models | ||
| - New processes to identify which examples need updating when spec changes occur | ||
|
|
||
| **User Stories:** |
There was a problem hiding this comment.
Let's add a story for the Skills team:
As a doc writer in the Skills team, I can include my sample snippets in the documentation
Or something similar
| | Example generation correctness (valid on first attempt) | TBD | > 95% | | ||
| | Service team satisfaction (quarterly survey) | TBD | > 4/5 rating | | ||
|
|
||
| ### SDK Language Team Migration |
There was a problem hiding this comment.
This one doesn't have a priority. It feels P0 to me, at least until we're sure the deprecation of autorest has little impact on them.
I feel there is two different stories, connected but not the same:
- Make sure that the deprecation of autorest doesn't impact them. What about plugin they wrote? Consuming generated Swagger that is a little different than the manual one? Etc.
- Move them to TypeSpec for their plugin generation
On top of that, make sure project Cirus starts on good fundation (ideally straight TypeSpec)
|
|
||
| ### CI Log Normalization and Simplification | ||
|
|
||
| - **Pri 0** — Normalize and simplify log output for azure-rest-api-specs CI tools |
There was a problem hiding this comment.
Let's add a sentence about AI able to extract better context for auto-repair
|
|
||
| **Goal:** Extend TypeSpec to support emerging Azure service patterns that aren't well-served by current abstractions. | ||
|
|
||
| ### New ARM Patterns |
There was a problem hiding this comment.
Are we aware of something in particular?
| | Time saved by reusing standard models instead of redefining them | TBD | > 1 hour per resource | | ||
| | Time to author a new ARM spec without custom workarounds | TBD | < 2 hours | | ||
|
|
||
| ### Streaming Support |
There was a problem hiding this comment.
I thought we were done with streaming at the TSP level? Is this about emitter?
As far as I'm aware, nobody is askinng for it, so it's P2
|
|
||
| ### Azure AI and Foundry APIs | ||
|
|
||
| - Better support for Azure AI service patterns |
There was a problem hiding this comment.
Do we have specific expressed needs?
|
|
||
| ## 11. Quarterly Roadmap and Capabilities | ||
|
|
||
| ### Summer 2026 (July–September) |
| - Measure initial AI skill library usage and token costs | ||
| - Example authoring time baseline established | ||
|
|
||
| ### Fall 2026 (October–December) |
There was a problem hiding this comment.
Feels reasonable, but difficult to conclude just yet
|
|
||
| ## 1. AutoRest Retirement / TypeSpec Native CI Tools | ||
|
|
||
| **Goal:** Complete the transformation from OpenAPI-centric tooling to TypeSpec-native CI pipelines, eliminating dependencies on AutoRest and OpenAPI 2.0 workflows. |
There was a problem hiding this comment.
Just curious if there's been any thoughts about changing downstream docs generation for ms learn? will we continue requiring that all service teams check in swaggers for this purpose?
There was a problem hiding this comment.
Over the long term we might not want to keep checking in the swagger, I doubt docs team will be writing a TypeSpec emitter any time soon but at some point, we might be able to get them to run the script to generate the swagger if they are the only ones that care about it.
But I believe too many other partners rely on the swagger still.
There was a problem hiding this comment.
There's a also a possibility of getting to openapi3 at some point
|
|
||
| ### TypeSpec Linting Tool (Replaces LintDiff) | ||
|
|
||
| - **Pri 0** — Normalize TypeSpec suppression mechanisms and replace LintDiff with a TypeSpec-native linting tool |
There was a problem hiding this comment.
By "Normalize TypeSpec suppression mechanisms" just to be 100% clear, you mean we will identify tspconfig.yaml and inline tsp suppressions for suppression review, anything else to factor in? <- you are referring to the suppression tool here, correct?
There was a problem hiding this comment.
"native linting tool" to replace lintdiff is mainly a new typespec ruleset
There was a problem hiding this comment.
Well, that and the capability to recognize new suppressions
There was a problem hiding this comment.
Recognizing new suppressions is part of the suppression tool which is a separate item in the plan
|
|
||
| - **Pri 0** — Normalize TypeSpec suppression mechanisms and replace LintDiff with a TypeSpec-native linting tool | ||
| - Provide equivalent or better lint coverage compared to existing OpenAPI-based LintDiff | ||
| - Support suppression comments, baseline files, and incremental linting for PR workflows |
There was a problem hiding this comment.
What does "support suppression comments" mean? If this is a linter ruleset doesn't typespec automatically support suppression comments?
There was a problem hiding this comment.
I think this should be carified - the main thing about suppression comments is:
- They should be part of what is displayed in the pr with the suppresison
- A change in the suppression comment is a new suppression, effectively, so the diff mechanism needs to handle this.
There was a problem hiding this comment.
ok then this section belongs with the suppression tool description
There was a problem hiding this comment.
Let's put this in a separate section
| **User Stories:** | ||
|
|
||
| - _As a service team_, I can run TypeSpec linting locally and get the same results as CI, so I fix issues before pushing. | ||
| - _As a spec reviewer_, I see clear, actionable lint errors in PR checks with suggested fixes, reducing back-and-forth with authors. |
There was a problem hiding this comment.
In regards to suggested fixes, in your experience is this based on the rule description?
There was a problem hiding this comment.
Here the primary mechanism is codefixes, but the descriptio and examples also propvides useful; data, so a link to the doc page is an important piece of information that goes with a violation
| | Time to resolve lint errors per PR | TBD | 50% reduction | | ||
| | Number of PR round-trips caused by lint failures | TBD | 60% reduction | |
There was a problem hiding this comment.
Is there a baseline that we already have measured here to compare against?
There was a problem hiding this comment.
This is one of the things we need to figure out.
| | Time to resolve issues discovered post-check-in | TBD | 70% reduction | | ||
| | Stale/unreviewed CI suppressions | TBD | 0 (within 30-day review SLA) | | ||
|
|
||
| ### Lint Suppression Review Tooling |
There was a problem hiding this comment.
Ok now that I see this separate entry for the suppression review tool, I'm even more curious what the suppression info under the linting tool section was referring to. To be clear, I agree that the suppression review tool is an independent item from the linting tool.
| | SDK-facing issues discovered post-check-in | TBD | 90% reduction | | ||
| | Time spent on post-merge spec corrections for SDK generation | TBD | 80% reduction | |
There was a problem hiding this comment.
do we have the initial baseline established for comparison?
There was a problem hiding this comment.
Is 80-90% feasible based on today's flow?
|
|
||
| ### Spec Validation and Simplification | ||
|
|
||
| - AI-driven tools to validate specs against Azure guidelines |
There was a problem hiding this comment.
Arent the lints and breaking changes checks covering this specific point? Seems this is more about keeping specs up to date with latest TypeSpec/TypeSpec Azure updates. The other 2 points below are interesting to help keep specs up to date
| - Preserve authoring intent while modernizing spec structure | ||
| - Enable bulk migrations across the spec repo |
There was a problem hiding this comment.
isn't this similar to the AI skills about helping update the specs to new patterns? should those AI solutions simply be leveraged here on a larger scale?
| ### Complex Versioning Patterns | ||
|
|
||
| - **Pri 1** — Versioning mechanism for template instantiation parameter changes | ||
| - **Pri 1** — Versioning decorators for decorator application (including new syntax) |
There was a problem hiding this comment.
this would be great as we recently saw 2 cases, one with storage needing to add a whole new operations simply due to the fact that we cant version decorators
| - Generate valid JSON examples for operations directly from a TypeSpec spec | ||
| - Validate existing JSON examples against a TypeSpec spec (replacing OpenAPI-based validation) | ||
| - Reduce required examples for new API versions to only changed operations/models | ||
| - New processes to identify which examples need updating when spec changes occur |
There was a problem hiding this comment.
on top of Laurent's comments, the tooling in the proposal would include that I believe, when you have a new api version you run the tool to generate new examples, either in an iteractive manner or by default it would add new example for all operations that might have something new showcasing it.
| | Number of examples required per new API version | TBD | Reduce to changed-only (est. 60% reduction) | | ||
| | Example validation accuracy (vs. spec) | TBD | 100% | | ||
| | Example generation correctness (valid on first attempt) | TBD | > 95% | | ||
| | Service team satisfaction (quarterly survey) | TBD | > 4/5 rating | |
There was a problem hiding this comment.
another metric though hard to quantify is review pain, how much time is wasted navigating the github pr UI when it is swarmed with examples files.
5 participants
Overview
This PR introduces a comprehensive TypeSpec planning document for Summer 2026 and beyond.
Document Location
fc/typespec-futures/typespec-planning-2026.md\
Workstreams Covered
Each section includes user stories and user-impact-focused metrics.
Additional Sections