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.
Please describe what problem this product or feature solves.
Is this a net-new feature not previously available?
If so, is your team utilizing any custom code?
If not, are there any revisions or changes required of which we should be aware?
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.
Will VA editors require assistance in comprehending how to utilize and/or navigate this change?
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.
What is the content model your team will be using for the feature change?
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.
What are the content types your team will be changing and/or creating for this work?
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:
Product Outline
User Flows
Content Model Wireframe with field annotations
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.
Help and feedback
Get help from the Platform Support Team in Slack.
Submit a feature idea to the Platform.