Define imposter component in appropriate guidance

[shiragoodman]

User Story

As a VFS team member, I want to understand what an imposter component is so that I can prevent them from being used in my product, or learn how to address them if/when an imposter component is flagged at Staging Review.

Assignee: @allison0034 Peer Reviewer: @KKitagawa-Bosch

Description

There is currently no guidance on Platform Website or on VADS that explains what an imposter component is. If we're going to use this language in Staging Review and throughout the Collaboration Cycle, then we need to define an imposter component and provide guidance on how it is flagged and how to handle it.

The purpose of this ticket is to write guidance on Imposter Components, as well as identify where the guidance should live. (Shira's vote is for VADS).

Impacted Artifacts

Live pages

• Components overview

Drafted pages

Tasks

• [x] Identify where the new Imposter Component guidance should live
  • Note: we don't necessarily need to create a new page dedicated to imposter components. Would it make sense for the guidance to live within an existing page?
• [x] Identify if we need to reference the Imposter Component guidance in any other existing guidance documentation
• [x] Draft guidance on the imposter component, including labels used (both exp-std label and imposter component label)
• [ ] Peer review
• [ ] Once approved, publish the guidance
• [ ] Would it make sense to link to this guidance in future imposter component staging review findings tickets? If you think so, please create a ticket for the Governance backlog and tag Shira

Peer Review

To be completed by peer reviewer

• [ ] User story and acceptance criteria are met

Acceptance Criteria

• [ ] Governance has published guidance for VFS teams on imposter components

Team Notification

• [x] Slack post on #platform-governance-team
• [ ] Presentation at Weekly Initiative Meeting
• [ ] No notification needed

How to prepare this issue

Refinement

• [x] Ticket has user story, description, tasks, and acceptance criteria
• [x] Ticket has been sized
• [x] Once all above items are checked, add the 'Ready' label.

  Planning

  If this ticket is picked up from the Backlog mid-sprint, connect with Shira to ensure the below items are completed correctly

• [x] Ticket has been discussed as a team at Planning
• [x] Ticket has been assigned to appropriate initiative or quarterly epic
• [x] Ticket has been assigned to a Sprint
• [x] Ticket has been moved to the Planned pipeline in the Governance team board
• [x] Ticket as an assignee and peer reviewer

[allison0034]

Working with Ian on "technical" wording.

[allison0034]

@shiragoodman I have a question about...

Draft guidance on the imposter component, including labels used (both exp-std label and imposter component label)

We do not include any labels for any other violations we log at Staging review. I am thinking we do not want to start listing specific ones in the guidance for DS (which is where this will be going). The experience standard and label are included in our internal guidance.

Is it ok to not add the label and experience standard to DS guidance? For what it is worth I will likely be adding it to this page.

[allison0034]

@erinrwhite wanted to get your opinion. I am planning on putting something like this (gonna have Keegan and Ian look at the content)...

Imposter components Most components are listed in Storybook. If your team is not using the components and their code in Storybook, then that is considered an imposter component and will be flagged at a Staging Review. This includes components that are coded to look like the ones in Storybook, but do not use the Storybook code.

...after the alert on this page.

[shiragoodman]

@allison0034 I am okay with us not adding info on the experience standard or labels. If we ever feel like it is needed, we can always add it in.

[erinrwhite]

@allison0034 I like the idea of updating the components page and putting this info where the current h3 Governance rules for using v3-based components is. Maybe transform that heading to be more broad, something like...

Governance rules for components

Avoid imposter components

Most components are listed in Storybook. If your team is not using the components and their code in Storybook, then that is considered an imposter component and will be flagged at a Staging Review. This includes components that are coded to look like the ones in Storybook, but do not use the Storybook code.

Use newest component versions when possible; when not possible, be consistent

v3-based versions of the components are designed to sit alongside our current v1 based components and the foundational elements of the Design System. Teams must use the new versions of our web-components and following these rules:

[ ... ]