Create Engineering and Security Governance in Collaboration Cycle

[andreahewitt-odd]

Problem Statement

Currently, Collaboration Cycle provides governance and support for Content, Design, IA, Accessibility, and QA. As VFS teams have grown, there is a need to provide engineering and security governance and support. Since Collaboration Cycle already has the infrastructure to work with VFS team, we want to integrate engineering and security standards into the current process.

Currently, Platform teams do not go through collaboration cycle consistently. The experience standards are not usually relevant to them but these new engineering and security standards will be.

How might we validate early in a VFS or Platform team's development that they are building with the shared products that Platform provides and. engineering and security standards in mind?

Hypothesis or Bet

If we can validate that VFS and Platform teams are following engineering and security standards early, those teams will not waste cycles building out a product that does not follow the standards.

We will know we're done when... ("Definition of Done")

VFS teams can easily follow Engineering standards VFS teams can easily follow Security standards Platform teams can easily follow Engineering standards Platform teams can easily follow Security standards The Engineering and Security Governance team can provide feedback to VFS and Platform teams early The Engineering and Security Governance team sees all technical projects before they go to production

Known Blockers/Dependencies

Projected Launch Date

First phase of user testing of standards around August 1st TBD

Launch Checklist

Guidance (delete before posting)

This checklist is intended to be used to help answer, "is my Platform initiative ready for launch?". All of the items in this checklist should be completed, with artifacts linked---or have a brief explanation of why they've been skipped---before launching a given Platforminitiative. All links or explanations can be provided in Required Artifacts sections. The items that can be skipped are marked as such.

Keep in mind the distinction between Product and Initiative --- each Product needs specific supporting documentation, but Initiatives to improve existing Products should reuse existing documentation for that Product. VSP Product Terminology for details.

Is this service / tool / feature...

... tested?

• [ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
  • [ ] ... and issues discovered in usability testing have been addressed.
  • Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
• [ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
• [ ] (if applicable) New functionality has thorough, automated tests running in CI/CD

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [ ] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline
• [ ] External-facing: a User Guide on Platform Website exists for this product/feature tool
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. customer-facing meetings)

... measurable

• [ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
  • For help, see: Analytics team
• [ ] This change has an accompanying Platform Release Plan.

When you're ready to launch...

• [ ] Configure your communication to teams about your work using the Change Communication Guide
• [ ] Conduct a go/no-go when you're almost ready to launch.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• User Guide: link to User Guide

Testing

• Usability test: link to GitHub issue, or provide reason for skipping
• Manual QA: link to GitHub issue or documented results
• Automated tests: link to tests, or "N/A"

Measurement

• Success metrics: link to where success metrics are measured, or where they're defined (Product Outline is OK), or provide reason for skipping
• Release plan: link to Release Plan ticket

TODOs

• [ ] Add this initiative to the Digital Experience Product Board using these instructions

[humancompanion-usds]

Requirements to start a new Collab Cycle

1. Fledgling Standards
2. Define the touchpoints
3. What are the assets teams need to produce at each touchpoint?
4. What type of changes need to come to this Collab Cycle?
5. What is launch-blocking at Staging?

Goal: Pilot with Security

• Goal is to pilot with Security after 8/1
• Security standards to be ready by 8/1
• AndreaH to PM the effort
• Current members of security team to create the security standards
• NOTE: Ray will be at officer candidate school in August
• Security standards to go on Platform content site
• Engineering tickets to be public but Security tickets to be private -- Jonathan wants to think more about how we do this
  • Networks maps shouldn't be public
• Agreed on the 3 minimum touchpoints:
  1. Architectural intent (optional but highly encouraged)
  2. Mid point review (optional)
  3. Staging review (required)
• Security has a list of questions that will be asked of teams for the first touchpoint.
• Assign a platform content person to work with Security folks on updating CollabCycle docs

[humancompanion-usds]

• Ragesh, Bill, Don, and Jeff met last week on what the cycle should be. Not going to be a PR review. Touchpoint on architectural changes to the platforms.
• Going to come up with the architectural intent questions. Don has a draft of that. Bill has reviewed it. Jeff to review.
• What are going to do first for a pilot for the arch. intent?
  • Preview environments
  • PatrickV has a testing framework
  • User profile API (EVSS to PCIU)
  • Status project between Forms team and Auth. Exp. team
• Should have first pilot scheduled by 8/1
• Invite AndreaH to start PMing the effort
• Don to attend a Design Intent
• Engineering and security will share the architectural intent touchpoint
• Review time SLA will be 2 days. Trying to keep it a lightweight review.
• Structure the meeting
• Launch blocking at Staging remains to be done.
• Matt to add SteveA, AdrianR, Sanja, Sam Wiley, to the Mural board for Governance