Open davidmpickett opened 1 year ago
jilladams
commented
1 year ago For figuring out where this goes next, I'm curious about ACs. I could see this as a UX / FE conversation, but we do need to verify with VBA stakeholders, it sounds like. I think we're also proposing without proposing it here that: if we decouple FE display from Term name, we're saying we might need a solution for FE display per administration, or use case, for the term?
davidmpickett
commented
1 year ago For figuring out where this goes next, I'm curious about ACs. I could see this as a UX / FE conversation, but we do need to verify with VBA stakeholders, it sounds like.
I don't know that VBA stakeholders are the ones we need to consult here. We already have enough data from how these services are described on VHA and VBA sides to know there's overlap.
The edges/boundaries of a single service in taxonomy terms is more of an OCTO decision. As in Facilities talking to CAIA and/or Sitewide CMS. This is a question about the fundamental unit of our system. This is the content model equivalent of deciding what how components should be handled in the VA Design System.
I think we're also proposing without proposing it here that: if we decouple FE display from Term name, we're saying we might need a solution for FE display per administration, or use case, for the term?
Yes, if we're going to pursue this, we'd need to have a clear model on what the new source(s) of truth are and how they map to Drupal content model and FE output
davidmpickett
commented
1 year ago Update from UX refinement - first step down this path would be a spike to explore what this effort would entail and creating relevant tickets
User Story or Problem Statement
As a product referencing the Service Taxonomy, I need to be able to reliably reference a source of truth (Term label) AND account for the unique context of users who are viewing my product (FE display name).
As a maintainer of service data, I need each Term to represent a unique service offering and not unnecessarily split terms every time a product needs a different FE display name.
Context / Use Cases
Lovell
During the Lovell rollout, we considered adding a field that would allow TRICARE-specific term names, but then decided to handle the few instances where this was needed by duplicating the terms and making some terms "TRICARE specific".
I believe the rationale was that it didn't make sense to engineer a whole solution to having multiple display names for something that was a tiny fraction of the use case.
Given that these duplicative terms are strictly limited to TRICARE facilities / the Lovell system, they don't pose a huge risk to the long-term stability of the taxonomy, however, if a solution were implemented that could support separate display names, these should be reviewed for merging.
VBA Regional Office MVP
The list of VBA Services for MVP includes some terms that may overlap with existing terms, however those terms are currently worded in a way that implies a healthcare-specific context. Are the services offered at VBA for these truly distinct from those offered at VAMC and Vet Centers? Or should they be unified terms that might need different FE display names?
Also Veteran Readiness and Employment still has the old branding. Do we want to enforce the branding across VAMCs? Are there two separate services to distinguish?
Acceptance Criteria
Design principles
Veteran-centered
Single source of truth: Increase reliability and consistency of content on VA.gov by providing a single source of truth.Accessible, plain language: Provide guardrails and guidelines to ensure content quality.Purposely structured content: Ensure Content API can deliver content whose meaning matches its structure.Content lifecycle governance: Produce tools, processes and policies to maintain content quality throughout its lifecycle.