need feedback: clarify internal vs. external team trust framework

[leahbannon]

Hypothesis

Our current model of trust is organized around internal vs. external teams — it needs clarification, especially as we grow. This also affects several other decisions (linked below). Priority: Iterate on Platform MVP

Current approach:

A VFS (platform, web, or apps) internal team reviewer must review any suggested changes or PRs to VA.gov.

• internal = USDS contractor and their sub?
• external = a VA contractor team currently on the Platform Also?
• middle? = what about offices/projects we trust that aren’t under VFS?(Ex: appeals team or team CTO shipping on va.gov)
• subdomains we don’t manage (Ex: MHV, EBN, developer.va.gov)

This question primarily arises when teams need to push a change to VA.gov. For PR reviews: For all teams, pull requests are reviewed by another team member on a project. Then,

• Internal teams: proceed to merge.
• External teams:
  • request 2nd review by an internal team reviewer (USDS, Ad Hoc, and their subs).
  • once approved, external teams then merge their pull request. (Note: I don’t think external teams immediately have the rights to merge their own pull requests. I think Liz said she envisioned teams would get this after the first few weeks

Related:

• We need to Document Strategic Outline for an ATO Process that includes External Teams
• Hypothesis: In order to scale, we should outline quantitative and qualitative standards before launching from staging to production for (everyone? just external teams to start?). We’ll start with a foundation set by the KPIs from the VFS website and apps teams (related work on the Scorecard will also help this). Issue to track KPIs from product teams
• Code reviews
  • done: Clarify the types of reviews done by different team members
  • done: Update code review norms with types of reviews

[andrewhughey]

I hope whatever we come up with isn't limited by the current model. Ideally, all teams building on the platform would have to play by the same rules.

Some other ideas besides the external / internal team model:

• only merge managers can merge: we give a group of engineers merge rights, that way it's not tied to a team, but a responsible individual. We'd need criteria for what qualifies someone to be a merge manager and some standards around merging, but it takes it out of the external / internal model and puts it in the hands of folks doing the work.

• only the merge team can merge: every team is the same, no one has merge rights. Any PR requires a review from the merge team (part of the platform team). Lots of overhead here and keeps merge control centralized

[rroueche]

Initial thoughts (more to come): a "light track" might naturally sort itself out w/o needing an actual separate process. Hypothesis: teams who're used to building in the DSVA style will pass the checkpoints more quickly/easily and w/less help needed, and thus de facto will on a quicker, lighter support track. The checkpoints will need some discrete criteria that incentivize the right things (human centered design etc) but also make it so that reviews aren't subjective.