Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

For Paragon Working Group moderators

  1. Prior to the meeting on Wednesday, create a new meeting notes document and solicit topics in the #paragon-working-group channel. Contributors should be encouraged to edit the agenda to add their topics.

  2. Before the meeting, add estimated time and order the topics

  3. At the start of the meeting

    1. Review the topics to be covered.

    2. Assign a note taker if you don’t intend to do take notes yourself

  4. Keep track of time and work to keep the conversations on topic. (Key point: ensure design discussions don’t spend too much time in technical concerns that can be addressed in a future discussion).

Purpose

This meeting is the place where we will review component proposals and discuss topics related to coordinating our efforts or planning for Paragon’s future.

Meeting Time and Cadence

The Paragon Working Group meets weekly for an hour at 11am EST/3pm UTC. If you need access to the invite, check the engineering@edx.org calendar or the /wiki/spaces/AC/pages/1996325015.

Discussing and Reviewing Component Proposals

https://openedx.atlassian.net/wiki/spaces/BPL/pages/1773502564/Component+Contribution+Process#Step-1-%E2%80%93-Start-a-component-proposal

Reviewing a proposal

Proposal Reviews start in person in the Paragon Working Group meeting and continue on Slack if needed. To get on the meeting agenda make a post in the #paragon-working-group channel on Slack. Reviews can result in moving the proposal to APPROVED TO ADD, DEFERRED, or NEEDS CHANGES

During a review the group will consider the following:

  • Are we adhering to our design system Design System Principles ?

    • Embrace reuse and ditch the unnecessary.

    • Strive for universal accessibility.

    • Build open source and theme ready.

    • Act like an owner.

  • Should this component live in Paragon?

    • Is this component a new component or a variant of another one?

    • Is the use case unique? Should it be a one-off solution?

  • Do we agree on what to name this component?

  • Should we adopt an existing package instead of building this ourselves?

  • Do we have any helpful feedback to improve the component’s design?

    • Review the use case from an accessibility, UX, and UI perspective.

  • No labels