2022-11-21 Meeting notes

 Date

Nov 21, 2022

 Participants

  • @Adam Stankiewicz

 Goals

  •  

 Discussion topics

Time

Item

Presenter

Notes

Time

Item

Presenter

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


[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.

 Action items

 Decisions