Skip to main content
Skip table of contents

CMS Request

Last Updated:

The CMS Request is where teams building products/features on the Drupal Content Management System (CMS) get feedback and guidance on their product/feature to ensure it meets experience standards for design, content, information architecture, quality assurance, accessibility, and research. Teams engage with the CMS Request throughout their product’s/feature’s lifecycle.

Owner

CMS Team

Timing

Request this touchpoint when your product is in kick-off request, allowing enough time to implement feedback. CMS Team reviews are not required for non-editor-facing modifications.

Format

Asynchronous review. We may request an asynchronous 30-minute meeting for review.

Objective

To ensure your feature meets CMS UX and Engineering standards.

Request

VFS Product Manager submits a CMS Request ticket

Stakeholders from the requesting team

  • OCTO-DE product lead

  • Product manager

  • Lead engineer

  • UX Designer

  • Accessibility

  • Quality Assurance (QA)

Questions to be Answered

The following product or feature descriptions may be answered with a reference link to the team’s documentation. However, the provided links must be specific to the request.

We ask these questions to maintain UX consistency throughout the editor experience.

  1. Please describe what problem this product or feature solves.

  2. Is this a net-new feature not previously available?

    1. If so, is your team utilizing any custom code?

    2. If not, are there any revisions or changes required of which we should be aware?

      1. The CMS team needs to understand if this change is helping them work towards greater consistency within both the editor experience and CMS infrastructure so that we can continue to scale the CMS sustainably.

  3. Will VA editors require assistance in comprehending how to utilize and/or navigate this change?

    1. The CMS team needs to understand whether the change will require updates to the CMS Knowledge Base. The CMS Knowledge Base provides VA editors with instructions on how to navigate the CMS.

  4. What is the content model your team will be using for the feature change?

    1. The CMS team needs to understand how the team plans to structure the content model and what this entails. If this also involves front-end development, we will need a screenshot with annotations to show the different Drupal fields and content types, or any fields used to build the front-end mockup.
      We want to ensure everyone knows and understands the content model. It's important to determine if any changes to fields or content types can be made in isolation or if they will have broader impacts beyond your specific needs.

  5. What are the content types your team will be changing and/or creating for this work?

    1. The CMS team needs to understand the different content types that product teams are changing or creating to account for larger impacts.

Artifacts

Please provide the following documentation as links or attachments:

  1. Product Outline

  2. User Flows

  3. Content Model Wireframe with field annotations

  4. Optional: Research

QA - Quality Assurance

As you continue through the Collaboration Cycle and reach the Staging milestone, the CMS team has outlined the QA requirements as follows:

QA Artifacts

Please provide the following documentation as links or attachments:

  • Regression test plan (required)

  • Test plan (required)

    • In addition to current Platform test plan standards, the CMS team requests that scenarios in the Test Plan be denoted as “critical” or “non-critical”. Critical test scenarios should be indicated whether they have been covered by an E2E test, and the percentage of “critical” tests covered by E2E tests should be provided.

  • Traceability Reports

  • E2E tests (provide a link to the product’s code) (required)

  • Code coverage (provide a link to the product’s code) (required)

“Critical” v. “non-critical” tests:

  • Tests covering functionality core to the feature under test should be classified as “critical”, while tests covering less impactful edge cases should be classified as “non-critical”.

  • “Critical” tests will often tie directly back to the User Flows outlined at the earlier Design Intent touchpoint.

Details on how these artifacts are evaluated during the Staging Review can be found on the Platform’s QA Standards page.

Additional information

Please take a look at Platform Collaboration Cycle on the Platform website for more information about the Collaboration Cycle.

Platform provides a list of concrete action items in a GitHub ticket that must be addressed before you roll out your product.


JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.