Update CODEOWNERS

[ReilleyMilne]

Request for a standard CODEOWNERS file across all SDK Language Repositories.

CODEOWNER changes:
Sorting Client/Data plane libraries.
Entry formatting.
Client SDKs renamed to Client Libraries and added Management Libraries as well.

[Copilot]

Pull Request Overview

This PR standardizes the CODEOWNERS file format across Azure SDK repositories by reorganizing and reformatting the ownership sections. The changes improve consistency and readability by sorting client libraries alphabetically and introducing a new management libraries section.

• Reorganized client library entries with consistent formatting and alphabetical ordering
• Renamed "Client SDKs" section to "Client Libraries" for standardization
• Added a new "Management Libraries" section placeholder

[Copilot]

[nitpick] The path entry /sdk/cosmos/ has inconsistent spacing compared to other entries. Consider aligning the spacing with other path entries like /sdk/keyvault/ and /sdk/storage/ for better readability.

Suggested change

	/sdk/cosmos/ @analogrelay @Pilchie @kirankumarkolli @tvaron3 @FabianMeiswinkel @kundadebdatta @nehrao1 @kushagraThapar
	/sdk/cosmos/ @analogrelay @Pilchie @kirankumarkolli @tvaron3 @FabianMeiswinkel @kundadebdatta @nehrao1 @kushagraThapar

[Copilot]

[nitpick] The comment order is inconsistent across entries. The ServiceLabel comment appears after the path entry for Cosmos but before for other services. Consider maintaining a consistent comment order (e.g., ServiceLabel, AzureSDKOwners, ServiceOwner, PRLabel) across all entries.

Suggested change

	# ServiceOwner: @Pilchie
	# ServiceLabel: %Cosmos
	# AzureSDKOwners: @heaths
	# ServiceOwner: @Pilchie
	# PRLabel: %Cosmos
	/sdk/cosmos/ @analogrelay @Pilchie @kirankumarkolli @tvaron3 @FabianMeiswinkel @kundadebdatta @nehrao1 @kushagraThapar

[heaths]

Seems mostly reformatting, and incorrectly. Why is this PR necessary? Please provide some context in the PR.

[heaths]

Comments are out of order and harder to maintain.

[heaths]

And what's going to make sure there's a "standard order" in PRs? Is it a PR check or some bot action running nightly, etc. Do we really need another barrier for contributors?

[weshaggard]

@heaths - @jsquire and @ronniegeraghty can give the details but the goal here is to try to standardize the CODEOWNERs files a little so we can create some MCP tools that can update them.

[heaths]

Standard format, sure. Why should order matter? Enforcing that just puts more of a burden on human contributors. In any case, the labels in this PR aren't in the correct order.

[ronniegeraghty]

Standard format, sure. Why should order matter? Enforcing that just puts more of a burden on human contributors. In any case, the labels in this PR aren't in the correct order.

We're trying to organize them alphabetically by service label. Ideally this will make it easier for human contributors to find the CODEOWNERS block they are looking for if they're sorted alphabetically.

They appear to be in alphabetical order to me by service label. Cosmos -> Key Vault -> Storage.
@heaths, am I missing what you are seeing?

[heaths]

Standard format, sure. Why should order matter? Enforcing that just puts more of a burden on human contributors. In any case, the labels in this PR aren't in the correct order.

We're trying to organize them alphabetically by service label. Ideally this will make it easier for human contributors to find the CODEOWNERS block they are looking for if they're sorted alphabetically.

They appear to be in alphabetical order to me by service label. Cosmos -> Key Vault -> Storage. @heaths, am I missing what you are seeing?

@weshaggard, @ReilleyMilne, and I talked offline and the comments should be grouped together with path - above it, specifically. That's how it's generally been. Some comments for KV are below /sdk/keyvault, for example. That's the blocker here.

My long-term concern is about putting yet another barrier for devs. They have to alphabetize entries in CODEOWNERS? That's more of a burden for people than bots which could just, for example, add them to the end or at least find the first place alphabetically to add them going down the list. There will still be human contributors, so it feels like we're overoptimizing for automation that can do whatever we want and making the experience worse for people that don't read often read the guidelines and will just see build breaks saying something like, "You must alphabetize the CODEOWNERS file." That's overly burdensome, IMO.

And when you going to do that? During PRs? Some nightly run that will create PRs we have to review? I don't see what value this adds. Yes, having a standard format - which we more or less already had - makes sense, and why I asked for changes here: it wasn't followed in the case of KV, at least. Sorting it doesn't really make sense. There's no reasons machines need it to be sorted in this case.

[ronniegeraghty]

Standard format, sure. Why should order matter? Enforcing that just puts more of a burden on human contributors. In any case, the labels in this PR aren't in the correct order.

We're trying to organize them alphabetically by service label. Ideally this will make it easier for human contributors to find the CODEOWNERS block they are looking for if they're sorted alphabetically.
They appear to be in alphabetical order to me by service label. Cosmos -> Key Vault -> Storage. @heaths, am I missing what you are seeing?

@weshaggard, @ReilleyMilne, and I talked offline and the comments should be grouped together with path - above it, specifically. That's how it's generally been. Some comments for KV are below /sdk/keyvault, for example. That's the blocker here.

My long-term concern is about putting yet another barrier for devs. They have to alphabetize entries in CODEOWNERS? That's more of a burden for people than bots which could just, for example, add them to the end or at least find the first place alphabetically to add them going down the list. There will still be human contributors, so it feels like we're overoptimizing for automation that can do whatever we want and making the experience worse for people that don't read often read the guidelines and will just see build breaks saying something like, "You must alphabetize the CODEOWNERS file." That's overly burdensome, IMO.

And when you going to do that? During PRs? Some nightly run that will create PRs we have to review? I don't see what value this adds. Yes, having a standard format - which we more or less already had - makes sense, and why I asked for changes here: it wasn't followed in the case of KV, at least. Sorting it doesn't really make sense. There's no reasons machines need it to be sorted in this case.

I see the points you are making on this adding burden to human contributors. The real issue is the alternative approach of adding new entries to the bottom or even to the top of the file. GitHub scans the CODEOWNERS file from bottom to top looking for the first file path that matches the path of a file changed in a PR and uses that first found line to add a reviewer to the PR.
If our tooling for partner teams added every new entry to the bottom of the file one team could override another's entry by adding a less specific path.

For example:
Group 1 adds an entry for the path /sdk/keyvault/keyvault-keys/
Group 2 adds an entry for the path /sdk/keyvault/
In this case all the files in the /sdk/keyvault/keyvault-keys will get reviews assigned based on the entry for /sdk/keyvault/ since it is lower in the file.

So we need some sort of sorting to make sure entries with more specific paths are always below entries with less specific paths.

[heaths]

Couldn't the MCP just as easily sort its new entries, such that it would put that narrower path after the wider one? It could even check if there are any wider entries below that (for different nesting).

Again, though, that's not what's blocking this PR. We can discuss offline rather than burden this PR.

[RickWinter]

@weshaggard, @ronniegeraghty Do we have a database or single source of truth for who owns what service. The repos have different structure so you'll never have the same files across all repos. If you had the database of who owns what service then CoPilot (no MCP needed) could be told what to do with a simple prompt.

[weshaggard]

hat to do with a simple prompt.

I wish we did have this, and we could have automation (no copilot or mcp necessary) to sync the codeowners across all the repos. Unfortunately, we don't have a good source for this information and so we are trying to gather it from the folks that are actually working on the SDK while they are working on it.

[ronniegeraghty]

@weshaggard, @ronniegeraghty Do we have a database or single source of truth for who owns what service. The repos have different structure so you'll never have the same files across all repos. If you had the database of who owns what service then CoPilot (no MCP needed) could be told what to do with a simple prompt.

Yeah, there is no good source for tying the libraries to their service owners like Wes mentioned.
With this update and the work to add Label and CODEOWNERS steps to the AI Agent workflow for services teams we discussed starting to keep track of the Service Labels tied to each service tree product/offering. But that will be a source that will be built slowly as more teams use the tooling.

[ReilleyMilne]

@heaths The linter is currently failing because in the original file ServiceOwners is misspelt and is ServiceOwner (no 's'). This causes it to not be parsed by the linter and incorrectly pass, however, after I fixed the spelling mistake it throws a lint error as a codeowners entry cannot have a ServiceLabel, ServiceOwners, and Path in the same entry. The solution to this is adding the spacing in between a service's path and ServiceLabel.

[jsquire]

This, for example, is invalid because the blocks run together. The linter should have flagged this....

[ReilleyMilne]

It wasn't being flagged due to a spelling mistake in ServiceOwners.

[jsquire]

I talked offline and the comments should be grouped together with path - above it, specifically. That's how it's generally been. Some comments for KV are below /sdk/keyvault, for example.

@heaths: Not sure exactly what you meant, but blocks cannot be grouped as I believe you're describing due to how the automation works.

GOOD

#ServiceLabel:  %KeyVault
#ServiceOwners:  @someperson @otherperson

#PRLabel: KeyVault
/sdk/keyvault/Azure.Security.KeyVault   @someperson @otherperson @ionlyreview

WON'T WORK

#ServiceLabel:  %KeyVault
#ServiceOwners:  @someperson @otherperson
#PRLabel: KeyVault
/sdk/keyvault/Azure.Security.KeyVault   @someperson @otherperson @ionlyreview

[weshaggard]

@jsquire why is that? Based on the documentation https://github.com/Azure/azure-sdk-tools/blob/main/tools/codeowners-utils/METADATA.md I assumed they could all be attached and should be attached to the path if there is a path.

I guess the only thing that should be there are the ServiceOwners if it is attached to a path the owners are defined by the path. So, the only time they would be separate is if the code owners and the service owners are different.

Should we try to have folks have a combined set of owners? I would think yes but you would know more about the practical side of that.

[heaths]

I talked offline and the comments should be grouped together with path - above it, specifically. That's how it's generally been. Some comments for KV are below /sdk/keyvault, for example.

@heaths: Not sure exactly what you meant, but blocks cannot be grouped as I believe you're describing due to how the automation works.

GOOD

#ServiceLabel:  %KeyVault
#ServiceOwners:  @someperson @otherperson

#PRLabel: KeyVault
/sdk/keyvault/Azure.Security.KeyVault   @someperson @otherperson @ionlyreview

WON'T WORK

#ServiceLabel:  %KeyVault
#ServiceOwners:  @someperson @otherperson
#PRLabel: KeyVault
/sdk/keyvault/Azure.Security.KeyVault   @someperson @otherperson @ionlyreview

I didn't realize that. At the very least, can we still keep the comments above the path line instead of a mix of above and below? If we're going for consistency, let's keep it consistently above e.g.,

#ServiceLabel:  %KeyVault
#ServiceOwners:  @someperson @otherperson

#PRLabel: KeyVault
/sdk/keyvault/Azure.Security.KeyVault   @someperson @otherperson @ionlyreview