The proposal should start as a
. Work through the proposal states below to take your proposal from
to
| Status |
|---|
| colour | Blue |
|---|
| title | READY For Review |
|---|
|
to
| Status |
|---|
| colour | Green |
|---|
| title | APPROVED TO ADD |
|---|
|
.
State | Description |
|---|
| The proposal is just an idea. Discussions on the draft serve to gather feedback and help prepare the idea to be | Status |
|---|
| colour | Blue |
|---|
| title | READY For Review |
|---|
|
. |
| Status |
|---|
| colour | Blue |
|---|
| title | READY For Review |
|---|
|
| The proposal is ready for a review when it has: A succinct use case and purpose Similar components in edX or in the wild (links) At least a wireframe General description of behavior or variants
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. The group will consider the following: Review the use case from the and perspectives and come to an understanding of the need.Should this component live in Paragon? Determine if the use case is unique. If so, it should remain be a one-off solution. Do we agree on what to name this component?
Reviews can result in moving the proposal to | Status |
|---|
| colour | Green |
|---|
| title | APPROVED TO ADD |
|---|
|
, , or | Status |
|---|
| colour | Purple |
|---|
| title | NEEDS CHANGES |
|---|
|
|
| Status |
|---|
| colour | Green |
|---|
| title | APPROVED TO ADD |
|---|
|
| An accepted proposal is ready for design and engineering work. A proposal is accepted with three approvals (minus the proposer), one from each UX, UI, A11y, and Eng. Once accepted the proposer should begin building out the component spec with UX/UI/Eng/A11y (if they have not already). |
| A deferred proposal should be designed and built as a one-off where it is needed. Move the proposal to a new folder in this space (TODO: when this happens the first time add a folder in the wiki in an appropriate location) |
| Status |
|---|
| colour | Purple |
|---|
| title | NEEDS CHANGES |
|---|
|
| A proposal needs changes to become | Status |
|---|
| colour | Blue |
|---|
| title | READY For Review |
|---|
|
again. |
- Once a proposal is
| Status |
|---|
| colour | Green |
|---|
| title | APPROVED TO ADD |
|---|
|
, work to should proceed to create a component specification.
Step 2 – Create a component specification
Accountable:
Consulted:
Informed:
develops the proposal into a component specs, filling out the component proposal sections. This spec doubles as design documentation.
Share the component spec in the #paragon-working-group channel.
Step 3 – Implement the component specification
Accountable:
Consulted:
Informed:
Based on the design doc from the previous step:
- : Implements the proposed design and creates dev doc
- :Sends a link to the implementation for designer review
- : Updates the design doc
Step 4 – QA the implementation
Accountable:
Consulted:
Informed:
QA: Identify bugs and design/implementation issues
Step 5 – Finalize the design and technical documentation & 🥳
Accountable:
Consulted:
Informed:
Based on the QA findings from the previous step:
- : Fixes bugs/design implementation issues, and ships
- : Makes any needed updates to design spec for documentation, confirming with and
Announce and evangelize the new design pattern throughout edX!
See the RACI Matrix for detail on role definitions for Responsible, Accountable, Consulted, Informed.
