Set up codeowners notifications for Facilities in CMS repo

[jilladams]

User story

AS A: CMS contributing team I WANT: a clear indicator when changes are made that might affect my team's products SO THAT: I can ensure operational stability

Description

In the spirit of the CMS as a platform where many product teams can be contributing: we want to support a clear definition of ownership where possible. Meaning: which teams own which files and features, and should be notified to code review any changes being made to those files.

The .github/codeowners file is a mechanism that can help with this. Codeowners files articulate:

• filepath
• User group(s) who "own" that file path

When Pull Requests make changes to files with listed owners, owners will be automatically added as Reviewers.

In vets-website & content build, this is used to help ensure that if another team modifies your team's file(s), you'll be notified and can vet the changes: https://github.com/department-of-veterans-affairs/vets-website/blob/main/.github/CODEOWNERS

In CMS, the codeowners file is not set up this way to notify PW / Fac teams yet. We should do that: https://github.com/department-of-veterans-affairs/va.gov-cms/blob/main/.github/CODEOWNERS

Tasks:

• [ ] Evaluate what portions of CMS code the Facilities engineers should be notified about, if changes are initiated by other teams
• [x] Figure out if we already have user groups that we can use for this, or need to make them.
  • No - we have CMS teams: https://github.com/orgs/department-of-veterans-affairs/teams/?query=cms
  • We have Facilities frontend team: https://github.com/orgs/department-of-veterans-affairs/teams/?query=facilities
  • We'll need to decide a team name and make the team, notes in comment
• [ ] If we need to make them, make them.
• [ ] Add those lines to the codeowners file with the appropriate user group

Acceptance Criteria

• [ ] I expect the codeowners file reflects Facilities ownership of Facilities feature related code

[jilladams]

I can set up the codeowner team for this in VA (or anyone may be able to). Existing CMS teams: https://github.com/orgs/department-of-veterans-affairs/teams/?query=cms

I would suggest calling this codeowner team facilities-cms and limiting this to Drupal changes. But: if it makes more sense to make it a facilities-backend, we could use that for other Lighthouse / facility Locator related things as well, if that's relevant in the CMS repo. @swirtSJW @omahane @maxx1128 can opine on that when we refine.

[jilladams]

I went ahead and made https://github.com/orgs/department-of-veterans-affairs/teams/facilities-cms/members, and I can edit the team name if we land on something different during refinement.

[jilladams]

Sister ticket for Public Websites ^ #14061. In that ticket, PW folks flagged some overarching questions / things to think through that we'd like to vet with POs in PW Refinement on Thurs 6/15 that will help determine how far down the rabbit hole we want to go as product teams vs. what should be carved off for CMS team to own as product owners, etc.

Issues/concerns

• CMS code could be optimized to make structure more amenable to shared ownership.
  • To what extent does the existing codebase structure limit this effort? Ideally, shouldn't block us doing what we can now. Is that realistic?
  • Would ideally be prioritized / owned on CMS team
  • Will be limited in some cases by Drupal native code structures / behaviors like the /config directory (one big slush pile folder, and spread across db tables
• Things that will probably be easy to articulate as code paths for product teams to own:
  • Custom modules for product team features / functionality
  • Contrib modules that are used / added specifically by product teams for product features
  • Template files for product features
• How do we avoid being required reviewers for maintenance work from CMS team that doesn't affect product behavior?
• Drupal elements to consider
  • VAMC content types
  • Vet Centers content types
  • Facility Locator, if any migration files, etc.
  • Lighthouse migration files
  • NCA
  • VBA
  • VA Services taxonomy
  • Any menus specific to Facilities content
  • Custom block configs specific to Facilities content
  • Facilities content views
• Depending on our evolved thinking, this might constitute enough work to become an epic.

[swirtSJW]

I am ok with facilities-cms and we would need a facilities-fe, though for cross-functionality maybe it makes more sense to just have facilities? and have it encompass both CMS and FE? It would be a bit noisier but help us not get stuck when Max is temporarily the only FE on the team or when I am on vacation and Christian needs someone else from our team to look at it.

[jilladams]

We have https://github.com/orgs/department-of-veterans-affairs/teams/vsa-facilities-frontend/members already, and that's actively in use on content-build and vets-website repos today.

[mmiddaugh]

@xiongjaneg @jilladams I've submitted this topic for the next Scrum of Scrum sync - fyi