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