[DRAFT] Add a CODEOWNERS file designating oversight of certain Evolution repo content to relevant teams

[stmontgomery]

This PR adds a GitHub CODEOWNERS file to this repo, assigning ownership and oversight responsibilities for certain content to relevant teams. But (importantly) it leaves the top-level /proposals directory without a specific owner.

Note: This PR is a draft currently, and I intend to discuss this with the relevant teams before proceeding.

Motivation: This originally came up because some of us on the Testing Workgroup would like to have greater awareness of PRs which modify proposals and other files related to Swift Testing. When I discovered that there was no CODEOWNERS file I drafted the file posted here, which assigns ownership of a few other important files and directories in the repo to people or teams I believe are responsible for them as well. The exact owners listed are of course up for discussion!

My understanding of CODEOWNERS files in GitHub (per documentation) is that this file alone will not prevent anyone from landing a PR, even if none of the code owners listed have approved it. To begin enforcing such a rule, this repo would need to enable branch protection, and I'm unsure whether that is enabled currently. So this PR, on its own, is not intended to restrict any PRs, although that is a policy we could consider separately.

[shahmishal]

Suggested change

	/proposals/
	/proposals/ @swiftlang/ecosystem-steering-group @swiftlang/language-steering-group @swiftlang/platform-steering-group @swiftlang/core-team

Let's start with top level reviewer to be the steering groups and core team.

[stmontgomery]

Thanks. My only concern is that the top-level /proposals directory is fairly high-traffic today, and specifying multiple teams as its code owners might be noisy for the members of those teams since (presumably) they will become default reviewers for each new PR in that space. So I guess it's up to those teams to decide whether they want that.

[shahmishal]

We can always change it if it gets noisy.

[rjmccall]

Our directory structure doesn't really follow the workgroup structure, which doesn't make this easy, sorry. I wonder if we can make a user group that's, like, the chairs of all the various evolution workgroups, so that we'd at least be spamming fewer people.

[rjmccall]

I feel a little uncomfortable claiming code ownership of this, even if I am in fact likely to be involved with any changes to it.

[rjmccall]

This is not actually true; visions are products of the evolution workgroups just like proposals are. It's just not as high-traffic as proposals/ is.

[rjmccall]

Again, this is something that individual evolution workgroups are empowered to do.

[stmontgomery]

I wonder if we can make a user group that's, like, the chairs of all the various evolution workgroups, so that we'd at least be spamming fewer people.

I like that idea a lot, actually! One of my concerns (voiced in this comment too) is having this change begin spamming whole workgroups, when the intention is just to ensure some modest amount of visibility and having at least one representative from each workgroup could achieve that.

[FranzBusch]

Our directory structure doesn't really follow the workgroup structure, which doesn't make this easy, sorry. I wonder if we can make a user group that's, like, the chairs of all the various evolution workgroups, so that we'd at least be spamming fewer people.

What if we change this though? What if we put evolution proposals into either project specific folders or steering/work group specific folders? If we started to organize this repo differently we could assign code owners quite easily.

[stmontgomery]

What if we change this though? What if we put evolution proposals into either project specific folders or steering/work group specific folders? If we started to organize this repo differently we could assign code owners quite easily.

I think that'd be great, I had that same thought. I just don't know how to accomplish it without breaking existing links to proposal documents. (I researched this once and couldn't find a straightforward way to set up redirects within a GH repo.)

Or maybe you're suggesting to establish directories for all new proposals going forward, and keep the existing ones at their current locations? That could potentially work.

[ktoso]

I think that'd be great, I had that same thought. I just don't know how to accomplish it without breaking existing links to proposal documents. (I researched this once and couldn't find a straightforward way to set up redirects within a GH repo.)

Or maybe you're suggesting to establish directories for all new proposals going forward, and keep the existing ones at their current locations? That could potentially work.

That does sound like a good idea, I think we could can make it work without breaking old links.

A middle ground to not break historical links here would be to keep move them all into a new directory and symlink all the "old" files into that; github understands symlinks, so the old links work, and we don't have to have copies of the docs. Moving forward we'd use the new locations consistently.

[shahmishal]

We should separate the restructuring of the folders proposal into a different PR. Additionally, we should merge this PR with the appropriate steering groups in the CODEOWNERS file.