Issue Workflow

Wiki in progress.

Figma: Designer and Developer Workflows (In Progress)

Design Lead - Issue Creation

• Creates a new issue.

PM - Issue Prioritization (and Slide making)

• Creates a slide for the issue on the Staging Deck and updates the spreadsheet TDM: Staging: Issues Check.
• Removes the “deck: add to staging” label.
• Adds the “deck: staging” or “deck: not for stakeholders” label as appropriate.
• Prioritizes the issue.

Designer - Assignment and Work

• Selects an issue based on complexity and then by priority.
• Assigns themselves to the issue.
• Moves the issue from the Prioritized Backlog column to In Progress column.
• If you have any questions, read Where to Direct Questions and Answers
• In Figma, moves a blank page to the Design section.
• Changes the Figma page's title to have the format "#Issue Number | Title | Assignee Name".
• Copies contents from the Figma Template page to the issue's Figma page.
• Includes a link to the issue's Figma page in the GitHub issue.
• Uses the Figma page to design solutions.
• Every week, updates the GitHub issue with a comment.
• Once the issue is ready for review:
  • Tags their design lead in a comment, letting them know that the issue is ready for review and what design choices to be aware of.
  • Adds their team's ready for design lead label.
  • Moves the issue in GitHub from the In Progress column to the Visual Review column.

Action Items

• Once a design issue is ready to be reviewed, move it to the Visual Review column and add the label "ready for design peer review"
• Review labelled issues with the design team during the weekly meeting and get peer reviewed. Implement feedback as necessary
• Change label to "ready for product" on the issue
• Use presentation structure to review proposed designs with the product, development, and research teams. Implement feedback as necessary
• Create a new slide (or edit one if it already exists) in the staging deck, and add images and appropriate text
• Receive design approval from stakeholders and implement feedback as necessary
• Add any annotations to the Figma design that would help the developer with implementation
• Create a Ready for Dev section around the final designs on the Figma page
• Update the Figma Design System with changes resulting from the issue's final design, if applicable
• Update the Style Guide Presentation, if applicable
• Add a comment to the issue that references the final design and adds any annotations that would help the developer with implementation
• Create a development handoff issue that references the comment
• Move the Figma page to the Development section of the Figma file
• Add the development issue's number in parentheses at the beginning of the title of the Figma page
• Include the development handoff issue number in the GitHub section below
• Reassign any previous assignees to this issue
• Close this issue

Design Lead - Review

• Leaves feedback on the design in the form of a comment in the issue, with the designer tagged.
• Removes their team's ready for design lead label.
  • If the issue is not approved:
    • Moves the issue from Visual Review back to In Progress on the GitHub board.
  • If the issue is approved:
    • Adds the "ready for design lead - George" label.

Design Director - Feedback & Stakeholder Presentation

• At the Design Meeting:
  • Gives feedback on the issue.
  • If the issue is not approved:
    • Removes the "ready for design lead - George" label.
    • Moves the issue from Visual Review back to In Progress on the GitHub board.
    • Leaves written feedback on the issue, tagging the designer and design lead of the team.
  • If the issue is approved, presents it to the product, development, and research teams at the Team Meeting.
• At the Team Meeting:
  • If the issue is not approved, follows the same steps as when the issue is not approved at the Design Meeting.
  • If the issue is approved:
    • Updates the associated slide on the Staging Deck with design mockup(s).
    • Add the waiting for stakeholder label if It's not already added
    • Adds a comment on the slide that the issue is ready for PM review and adding to the stakeholder release deck
• Presents the issue's design at the next Stakeholder Meeting.
• If stakeholders need time to generate input, feedback, or make a decision:
  • Makes a note of what is needed from stakeholders on the slide.
  • Ensures that the slide is copied over to the next Stakeholder Deck.
  • Moves the issue to the Questions/Clarifications column on the GitHub board.
  • Add the waiting for stakeholder label if It's not already added
• If the issue is not approved:
  • Removes the "Waiting on Stakeholder" label from the GitHub issue.
  • Removes the "deck: stakeholder presentation" label.
  • Adds the "deck: staging" label.
  • Moves the deck slide back to the staging deck.
  • Updates the link in the issue to the staging deck to new slide link (when you copy it, it gets a new URL)
  • Moves the issue from Visual Review back to In Progress on the GitHub board.
  • Asks the designer to implement the feedback given during the following week(s) and then present their updated design at the next Design Meeting.
• If the issue is approved:
  • Removes the "Waiting on Stakeholder" label from the GitHub issue.
  • Leaves a comment.
    • Tags the designer/assignee.
    • Alerts the designer that the issue's design has been approved.
    • Adds stakeholder feedback, if any.
    • moved issue back to in progress column.
    • Asks the designer to complete their action items before closing the issue.

Designer - Handoff to Dev

• Implements stakeholder feedback, if applicable.
• Adds any annotations to the Figma design that would help the developer with implementation.
• Creates a Ready for Dev section around the final design in Figma that uses a Ready for Dev status label.
• Updates the Figma Design System with changes resulting from the issue's final design, if applicable.
• Updates the Style Guide Presentation, if applicable.
• Adds a comment to the issue that references the final design and adds any annotations that would help the developer with implementation.
• Creates a development handoff issue that references the comment.
• Moves the issue's Figma page to the Development section.
• Adds the development issue's number in parentheses at the beginning of the title of the Figma page.
• Includes the development issue number in the GitHub section of the design issue.
• Reassigns any previous assignees to the GitHub issue.
• Closes the issue.

GitHub

• Automatically moves the design issue to the On Dev column on the project board.

PM - Slide & GitHub Maintenance

• Reviews the issue in the On Dev column, updates the slide if necessary
• moves the slide to the Release Deck and updates the issue with the new link
• Moves the design issue from On Dev to Done on the GitHub project board.
• Moves the development issue from the New Issue Approval column to the Prioritized Backlog column on the GitHub project board.

Developer - Assignment and Work

• Assigns themselves to the development issue.
• Moves the development issue from the Prioritized Backlog column to the In Progress column on the GitHub project board.
• Uses the associated Figma page's Ready for Dev section as a visual reference.
• If a PR (Pull Request) is created for the development issue, moves the issue to the Technical Review column.
• If the development issue instead gets closed manually and does not have a PR, moves the issue to the On Dev column.

Slack

• A GitHub bot notifies the Design team that the development issue has been implemented on the TDM Dev site via the #tdm-ui-prs channel

Design Lead

1. Go through the Slack posts, find the issues without a label emoji 🏷️
   • add the label QA: review needed by: design to the issue if there is a design issue associated with the dev issue
   • add the label QA: review needed by: product to the issue if there is no design issue associated
   • add the emoji 🏷️ to the slack post
2. The Design agenda will have a link to all the issues that have the label QA: review needed by: design and will be assigned at the design meeting, ideally, to the person who did the design.
3. The Product agenda will have a link to all the issue that have the label QA: review needed by: product and will be assigned at the design meeting, ideally, to the person who found the problem.

Designer - Post Development Review (QA)

• Tests the TDM Dev site to ensure that the design has been correctly implemented.
• Enters any uncovered bugs as separate issues. See How to Write a Bug Issue
• Once testing is completed, leaves a comment on the handoff issue and the PR issue with the following information:
  • Tags the development lead.
  • Includes a list of entered bugs.
  • States that the review has been finished.
• Moves the associated Figma page from the Development section to the Completed section.

Development Lead - GitHub Maintenance

• Once a build with the associated development issue gets released to the production site, moves the issue to the Released column.