Redesign of API Readiness App to improve usability and address gaps in engagement experience data model

[ladonnaq]

The API readiness milestone app currently requires a user to go through all steps, which is not always necessary. The GitHub toolchain drives the API Review process via the API Spec pull request (PR). The API readiness milestone should be used to validate that the checks and approvers needed to begin the SDK pre-release work have been completed. These checks/approvers should also be requirements to merge the PR.

This work item is related to this epic. #5670
TODO: Rewrite this issue to reflect the changes we want to make to the API Readiness App to reduce complexity and improve the user experience

Relevant GitHub issues:

• Ask for API version when user associates pull request  #8631
• Only show errors in the clean up validation errors screen of the API readiness app #5670
• Prepopulate the Schedule API Review screen with previously scheduled API Reviews  #6042
• Should we block the completion of the API Readiness app until the PR is merged? #7936
• [Release Planner] Add step for validating CODEOWNERS #7351
• Improve API details section of the Release Plan Summary  #8632
• Tailor the steps/tasks of the workflow based on the release scenario.

Pre-release work:

Management Plane

1. If new initial SDK, then the SDK package namespaces for each language must be reviewed and approved by the arch board.
2. .NET SDK must be generated, samples generated, and testing completed. (Dependent upon completion of Adding initial package for readme verification. #1)

Data Plane

1. If new initial SDK, then the SDK package namespaces for each language must be reviewed and approved by the arch board.
2. All SDKs must be generated, samples written, and testing completed (Dependent upon completion of Adding initial package for readme verification. #1)

Checks and approvers

In API Readiness today
Images show the current checks and approvers in the API readiness milestone

1. These checks are the same for management and data plane.

2. SDK Breaking Changes is only in management plane. In my recent interactions with service partners, they are finding to navigate the PR and figure out what they should address first. I think that if there are breaking changes, we should alert the user in the release planner. If there are no breaking changes, we skip showing them anything. 3. The signoff screen is different for data plane vs management plane.

Gaps in data model

Tasks

Preview Give feedback

1. Ask the user to provide the API version(s) that will be used to generate the SDKs. @josefree - I will work with you to identify the requirements so that the changes can be made in the API readiness UI and back-end.

[maririos]

Looking into this issue and after conversations with the team, I think it will be beter if we:

• Management plane: Hide the steps: Cleanup validation errors, review breaking changes, Preview API docs, and ARM API Review. These steps should be handled by the spec PR itself. The Sign off step currently shows the status of those checks. We can probably just show that.
• Data plane: Hide the steps: Cleanup spec validation errors and Set up API preview docs. Same reason as for management plane