Update Arch Board Review wiki page and relevant email/calendar body templates to include info on namespace approval

[ladonnaq]

Since namespace/naming approval is done as part of the Introduction meeting or initial SDK review for data plane, we should include information on this page https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/667/Azure-SDK-Archboard-Review so that service teams are prepared and understand what they need to do.

• Update the arch board Intro meeting wiki to include information regarding namespace/naming approval for new initial SDKs.
• Update the calendar body or any relevant email templates to include information about namespace/naming approval for new initial client libraries. If the meeting invite is associated with a product, then the Azure Devops onboard work item field, circled in the screenshot, can be used to determine if this is a new initial SDK.
  

[maririos]

Update the calendar body or any relevant email templates to include information about namespace/naming approval for new initial client libraries. If the meeting invite is associated with a product, then the Azure Devops onboard work item field, circled in the screenshot, can be used to determine if this is a new initial SDK.

Not sure what the concrete ask for the Scheduler tool is here. Could you please expand more?

[ladonnaq]

Update the calendar body or any relevant email templates to include information about namespace/naming approval for new initial client libraries. If the meeting invite is associated with a product, then the Azure Devops onboard work item field, circled in the screenshot, can be used to determine if this is a new initial SDK.

Not sure what the concrete ask for the Scheduler tool is here. Could you please expand more?

For data plane, Introduction meetings also cover namespace approval for new initial client libraries. This is not mentioned in the scheduling tool when you create the invite, in the wiki as an activity that will happen, in the GitHub issue that is created, or the calendar body. Do you know how the namespaces get into APIView for data plane? Does the service team have to do something or are they generated somehow?

[maririos]

Do you know how the namespaces get into APIView for data plane? Does the service team have to do something or are they generated somehow?

When the service is working on the SDKs, part of that code says what is the package name they want for the SDK. I know for the independent languages where the data comes from.
If they use TypeSpec they can specify the package name => https://azure.github.io/typespec-azure/docs/howtos/DataPlane%20Generation%20-%20DPG/00howtogen

This is not mentioned in the scheduling tool when you create the invite, in the wiki as an activity that will happen, in the GitHub issue that is created, or the calendar body

Agree that the documentation in https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/667/Azure-SDK-Archboard-Review needs to be updated. @ronniegeraghty is this the place you want for the archboard documentation to be? or https://azure.github.io/azure-sdk/policies_reviewprocess.html ?

[ronniegeraghty]

Agree that the documentation in https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/667/Azure-SDK-Archboard-Review needs to be updated. @ronniegeraghty Ronnie Geraghty FTE is this the place you want for the archboard documentation to be? or https://azure.github.io/azure-sdk/policies_reviewprocess.html ?

Let me speak with @kyle-patterson on which location is better. In the mean time I can work on updating the docs in our github.io page.
What needs to be update on the wiki?

[maririos]

What needs to be update on the wiki?

It is missing information about the package name approval.

If we want to consolidate both sources of data, I like the format of the wiki as it makes things easier to read and it is conscise. We could either update the github.io doc and make the wiki point there, or whatever else you dedice.
In terms of the github.io:

• The process to schedule a meeting needs to be updated.
• I also wonder if the appropiate name should be Azure SDK Review instead of API Review as API Review is what is more used for the API Stewardship board meetings

[ladonnaq]

What needs to be update on the wiki?

It is missing information about the package name approval.

If we want to consolidate both sources of data, I like the format of the wiki as it makes things easier to read and it is conscise. We could either update the github.io doc and make the wiki point there, or whatever else you dedice. In terms of the github.io:

• The process to schedule a meeting needs to be updated.
• I also wonder if the appropiate name should be Azure SDK Review instead of API Review as API Review is what is more used for the API Stewardship board meetings

I used to refer the the Azure SDK reviews as Client API reviews because service partner would often get confused between REST API Review and API Review (arch board). I think that most service partners would understand SDK review includes all of the client libraries (each language).

[maririos]

Last week there was a change in the calendar invite title for the SDK meetings because of feedback provided by the architects. The title now says Azure SDK Review.
At the end, the important thing is that we are consistent everywhere with the name of the meeting, so our users can put all the pieces together.

@ronniegeraghty let me know if, from tooling perspective, we need to make a change

[ronniegeraghty]

@maririos We're going to have a discussion on this tomorrow. But I do agree the naming should be consistent across the board. So wherever the information ends up staying it should go by the Azure SDK Review name and not API Review, so we don't get confused with API Stewardship Review Board.

[ronniegeraghty]

Looking at the original ask in the comment description are we just looking to add a row to the prerequisites table for the intro meeting on what the service team needs to bring the meeting in regards to working on their library naming? I'm pretty sure the answer is just that they need to bring someone who has the authority to approve any naming decision from the service side so that the SDK and Service teams can agree on and approve a name to use in the meeting.

[maririos]

Good question. That would help. Also, do they need to come with name proposals? or how does that work?

[ronniegeraghty]

I don't think they need to have proposals ready but they need to be ready to discuss the topic with the architects and should plan to have a naming decision made in the meeting. So maybe it could be listed as an optional requirement, with the description stating that names will be decided on in the meeting.

[ronniegeraghty]

Also since we're expecting certain tasks to be done in the intro meeting, is it a good idea to have a meeting checklist or sample meeting agenda that lists the type of conversations that need to happen in the meeting?

[maririos]

So maybe it could be listed as an optional requirement, with the description stating that names will be decided on in the meeting.

Thanks for explaining Ronnie! If we have any docs or examples of guidalenes they need to follow for naming, that would be helpful too

[maririos]

Also since we're expecting certain tasks to be done in the intro meeting, is it a good idea to have a meeting checklist or sample meeting agenda that lists the type of conversations that need to happen in the meeting?

You could modify the format to follow what the API Stewardhip board is doing: https://dev.azure.com/azure-sdk/internal/_wiki/wikis/internal.wiki/665/Azure-REST-API-Stewardship-Review?anchor=what-happens-during-the-review
They have what to expect (like agenda) and then the next steps

[maririos]

@ronniegeraghty I think this issue is done, right? can we close it?

[ronniegeraghty]

Yup all done.