Frequently asked questions about the Collaboration Cycle.

How can I find out if an initiative needs to go through Collaboration Cycle?

A VFS Product Manager should submit a ticket for an asynchronous Collaboration Cycle Kickoff. We'll respond in the GitHub ticket with the recommended Collaboration Cycle touchpoints, as well as any other additional information the team should know.

Can I skip a Collaboration Cycle touchpoint that was recommended during Kickoff?

No, however, if you feel that touchpoint is unnecessary or if there are extenuating circumstances, comment on your GitHub ticket and tag the Platform PM. You can also come to weekly Collaboration Cycle Office Hours listed in the Collaboration Cycle Calendar and discuss with the team.

Do discovery efforts need to go through Collaboration Cycle?

Maybe. The best way for us to tell what touchpoints, if any, are needed is to fill out a Collaboration Cycle Kickoff ticket. You can also come to weekly Collaboration Cycle Office Hours listed in the Collaboration Cycle Calendar and discuss with the team.

Do I need to have a Midpoint Review before usability testing?

Yes, it is highly recommended that you complete your Midpoint Review before you do any usability testing. We may identify some issues during the Midpoint Review that could impact your testing. If you have your review after the usability testing there is a risk that may make your testing invalid.

My team is doing more than 1 round of usability testing. When should I schedule Midpoint Review?

You should complete your Midpoint Review before your first round of usability testing.

What if I don't have all the artifacts requested in the touchpoint template?

If you are missing an artifact that will prevent us from completing your review, we will need to reschedule your review. Comment in the GitHub ticket with alternative dates and tag the Platform team member who scheduled the review.

Can I schedule a Collaboration Cycle meeting outside of the available time slots?

No, there are a lot of schedules we have to work around and we know those time slots are reserved for Collaboration Cycle meetings only. If you cannot find a time that works, comment and tag the Platform team on your GitHub ticket.

Can I schedule multiple instances of the same Collaboration Cycle touchpoint?

We prefer to have only one instance of a touchpoint, however, if your product requires a second review we can schedule that for you.

Does my team have to fix the issues identified at Staging Review?

Yes, all issues with the label launch-blocking must be fixed before launch. All other issues must be fixed, but it is up to your Product Owner how to prioritize fixes.

A launch-blocking issue was identified at Staging Review, but my team doesn't think it should be launch-blocking. Can I challenge the severity of the issue?

Yes, comment on the GitHub ticket and tag the Platform team member who entered the ticket. Typically we will review any concerns you have with OCTO and decide how to proceed.

How do we handle accessibility issues that are design system or third-party dependencies?

If you find a dependency issue, it is recommended to file a ticket with the third-party vendor. This might be on GitHub, or using the vendor’s own ticketing system.

If you find a design system issue, please follow up with the Platform design system team. You may be asked to open an issue ticket or provide a fix if your product team has available bandwidth.

Why do we have to do foundational accessibility testing?

Product teams are required to do foundational accessibility testing for two reasons:

  1. Product teams are responsible for the quality of their code and this includes making it accessible to the widest possible audience. Foundational testing can help ensure this level of quality.

  2. Accessibility specialists cannot conduct a thorough audit in a short time frame if they have to run foundational and advanced tests.

How should I prioritize fixing accessibility issues?

All accessibility issues should be labeled according to the Accessibility Defect Severity Rubric. Defect 0 and Defect 1 are launch-blocking and must be addressed prior to launch. Defect 2, Defect 3 and Defect 4 can be fixed post-launch with Defect 2 being the highest priority and Defect 4 being the lowest priority.