2022-11-21 Meeting notes

[inform] Published alpha release of design tokens

@Adam Stankiewicz

• v21.0.0-alpha.1

  • Maintaining an early alpha release will make QA/testing easier to consume the design tokens work in consuming applications (e.g., MFEs) for Raccoon Gang.

  • In theory, an alpha release could be used to try to source early feedback from consumers as well. This is an agenda item to discuss with the FedX/FWG team to better define a strategy for alpha / beta pre-releases.

• Understanding the impacts to our @edx/brand-edx.org and @edx/brand-openedx theme repositories.

Maintainers OEP pilot

@Adam Stankiewicz

• [inform] Added Paragon to https://backstage.openedx.org/catalog?filters%5Bkind%5D=component&filters%5Buser%5D=all (see these docs)

  • Owner is listed as the openedx/paragon-working-group Github team:

    • https://github.com/orgs/openedx/teams/paragon-working-group

  • [discuss] Should this group have at least one+ designer on it (looking at you Gabe )?

[from Maintainers OEP] Jobs of the maintainer

• Community Stewardship

  • [Adam] PWG does a pretty good job of this already, between connected Slack channels and an open weekly meeting. We are supportive and welcoming of contributions.

    • Speaking of Slack, the connected Open edX channels are private, which means they’re not discoverable…

      • [from Ned] “infosec was worried that openedx is open to the public, so bad people could come in there and phish 2u via the shared channels”

    • [discuss] How do we encourage folks to find/use the private, connected channel?

  • [Adam] Our documented contribution process is outdated (refers to using Jira).

    • It also leans more towards “How I propose / contribute a new component?”; not, “How do I propose an update to an existing component?”

• Project Management

  • [Adam] We are currently able to resource technical maintenance of Paragon through Raccoon Gang engineers.

    • May need to better define a prioritization process for ensuring things like security vulnerabilities get caught/addressed more proactively.

    • FED-BOM can (and has) helped here, as needed, too.

  • [Adam] PWG supports and facilitates Paragon contributions from product teams through the review process.

  • [discuss] Design maintenance?

  • [Ben] Managing communication between teams with respect to Paragon design system.

• Quality Assurance

  • [Adam] We have processes in place to ensure technical quality in Paragon (e.g., PR reviews, automated tests, deploy previews).

    • Looking visual regression testing with Chromatic.

  • [Adam] We’ve occasionally sent out a survey to collect feedback from stakeholders.

    • Feedback loop.

  • [Adam] There’s probably an opportunity to improve our documentation around technical standards (e.g., technologies used, architectural patterns, etc.).

  • [discuss] Design QA?

• Technical Vision

  • [Adam] There is a documented technical vision for Paragon on Confluence that should be updated. Many of the items on that page have been addressed/considered. Some items are not accounted for (e.g., re-architecting our styles to use design tokens, etc.).

  • [Ben] Repeated process for updating/maintaining.

    • Should there be a cycle for updating/reviewing?

• Project Documentation

  • [Adam] We have a solid documentation website that we keep improving/investing in

  • [Adam] We have a Figma library that “self-documents” in a way, allowing designers to understand the spec for components and drag-and-drop Paragon components into their designs.

  • Outdated documentation (mentioned above)

• Continuous Improvement

  • PWG has a growth mindset; we’re always looking to improve!

  • [Ben] Retros?

    • Making Continuous improvement an intentional process across the entire PWG.

@Michael Leary

• UX resourcing

  • Conversations starting with Ed/tCRIL.

  • Avoiding a breakpoint in communication.

• Revamp new internal design review (encompassing all theme reviews into one consolidated review).

  • use the meeting minutes from this review to drive process improvements in this group.

  • Purpose: Share ideas early, and often (at any fidelity).

    • Prevents redoing work.

• Can/should we share the design review checklist doc more broadly across the design team?

  • Hilary putting together a format of what to share, how to share.

• [Ben] Should Ben/Adam (or any other engineer(s)) go to this design review?

  • Would that catch things earlier?

  • Agenda/share out agenda.

  • Answer: not immediately; let the design team figure out what works for them as they iterate through this process change.

@Ben Warzeski (Deactivated)

Segment tracking

• Link tracking

  • Should this be a Paragon thing? A frontend-platform thing?

• How can we make eventing simpler / more streamlined?

• Probably a FedX/FWG discussion.

• Hoping to set standards.