-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Onboarding feature to automate the identifying APEX release scenarios #7084
Comments
This seems specific to APEX, but this question is generic enough that only asks if the Product targets ARM or data plane. @ladonnaq could you clarify? |
There are products that are in scope for APEX that have no RP (not deployed via ARM, not cloud app) and do not have non-ARM REST APIs (data plane), so they are out of scope for the Azure SDK APEX requirements but they are in scope for other APEX requirements (i.e. security, ...). They still have to onboard with us so we can validate they are out of scope and we still have to keep records. For example, all of the virtual machine skus that are products for the Compute Platform. We still have to ask them to onboard so we have a triage work item to document they are out of scope, then ask them to mark the Azure SDK requirements as Not Applicable, and then we have to go to Cloud Lifecycle and approve all of the Azure SDK APEX requirements as Not Applicable. Right now it seems strange that they have to choose the option of "I am not sure which of the above options apply to my product" because they already likely know.... none of the options apply. :-) |
What do we do with those teams though? they don't have a REST API right? or an SDK? because they are not ARM or data plane... |
There are products that are in scope for APEX but they are not in scope for the Azure SDK APEX Requirements. They still need to onboard with us so that we can validate that they are truly not in scope. In fact, we just had a service team send us an email on this exact issue. They are not in scope and were blocked from onboarding. I told Yoga to tell them to answer unsure and we would change the scope in the triage work item and mark it as out of scope APEX. Of the 100 products now showing up to complete a lifecycle milestone by Dec 2023, about 15 of those are out of scope for Azure SDK APEX requirements. There are scenarios where a service introduces a new product and they are not making any changes to the management plane and/or data plane REST APIs. I see this happen from time to time with SKUs mostly. There are also all of the VM SKUs which are almost always out of scope for us but we still need to keep history (so we know talked to them and they are out of scope) and we still have to go to Cloud Lifecycle and approve their attestation of N/A (Not Applicable). |
If I understand correctly, either way PM team needs to talk to them to understand the scenario and leave the record of the conversation. We can go ahead get full requirements for this and then prioritize or we can keep asking this teams to use the unsure option like they are already doing. Open to whichever option |
I will schedule some time with @ccbarragan this week to discuss and a few other gaps/new requirements that will require UI changes and feedback for overall UX. I believe that we should do this because it is a valid use case and at this time service teams are sending us emails or finding us on teams to ask us "What to I do because the new product will not change any of the existing ARM REST API Spec for to enable so therefore would be not applicable for any of the Azure SDK APEX requirements". We this with many of the VM skus under Compute RP and at times with new SKUs that are only making changes to billing or something that does not require any changes to the ARM REST API Spec. FYI - Here is the triage work item breakdown by state for all, data plane, management plane. So at this time we have 29 products that we have evaluated and determined out of scope for APEX Azure SDK requirements and they are mostly associated with the Compute RP. Here are some metrics from ADO query for triage so you can see the breakdown. |
@maririos I will target looking at this again in Feb 2024. In ADO we have around 31 products (from 2023) that we identified as not in scope for APEX. Our process requires that all products in scope for APEX onboard with us so we have a record we spoke with them and identified the product as out of scope for the Azure SDK APEX requirements. We had several service partners confused because they knew they did not have any ARM or data plane REST APIs but there was no option. We told them to just choose the "I don't know" option so they could complete onboarding but that is really a hack. We should add a checkbox for the user's to self-attest that they have no ARM or data plane REST APIs/SDKs required to enable the new product. |
@maririos I have had several teams mention that not having a "none of the above option" is frustrating and confusing. Remember that we updated our instructions/guidance and the onboarding form is typically completed by engineering or a product PM (who is usually involved in the design of the REST APIs). This feedback from a senior software engineering manager is for a scenario where the product is in scope for APEX but not in scope for ANY of the Azure SDK requirements - I would like this prioritized to be done by beginning of March and a new option added for "My product is not enabled by ARM (management plane) or non-ARM (data plane) REST APIs and SDKs. I would like a link to https://aka.ms/azsdk/onboard as help/guidance for the bullet. It would be good if we could perhaps make the section that describes how to determine API scope a link so it would take user's directly to where they need to go on the docs page. I will update the descriptions so we have a summary of the todos. |
This will be helpful as of right now, reading the comments I am unclear on how to proceed. For example:
|
Just a couple of questions to clarify things~~
|
Just a couple of questions to clarify things~~
|
Implementation feedback:
|
When working on implementation, we missed 2 requirements: .trigger o schedule an Informational meeting and changing the onboading email templates. @ladonnaq Here are the follow up questions about them:
|
|
linking #8841 |
Here is link to the "Unsure" scenario email template - https://microsoft-my.sharepoint.com/:w:/p/ladonnaquinn/EfFiMuJHXm5Ekw5ZzF4pvsIBac9s9n44YuoklZBczdrGRw?e=bxYyhx |
This work is a pre-requisite to completing the requirement of identifying APEX release plans - #6262.
GitHub issues related to this epic:
APEX out of scope scenario: When onboarding the product that are out of scope for Data & Management Plane. There is no option to indicate this, you can only choose the option "I am not sure which of the above options apply to my product". Feedback from service partners who do not have any REST APIs is that they are frustrated in onboarding to the Azure SDK team using the Release Planner app. Since we change the roles of "who" completes the onboard survey in fall 2022, nearly 100% of the scope is correctly identified in the triage work item.
JP's recommendation:
Requirement:mockup.html (2).zip
APEX out of scope scenario UI changes
APEX out of scope scenarios data automation/back-end changes
Identify APEX release scenario: Instead of manually determining if a product that onboarded is in scope for APEX, optimize process by identifying and confirming the product onboarded is in scope for APEX.
Identify if product is in scope for APEX UI changes
Identify if product is in scope for APEX data automation/back-end changes
Azure SDK Info Meeting Required Updates
Updated onboarding email templates based on scenario
Scenario Testing
The text was updated successfully, but these errors were encountered: