Design: Open an Issue - hackforla/tdm-calculator GitHub Wiki
Anyone on the design team can open an issue.
Use the Details element in GitHub when uploading images, GIFs, or videos. An example of a Details element is shown below.
Click here!
The Details element is used to reduce the amount of vertical space in GitHub issues and thus reduce the time spent scrolling down them. If users want to see media, they can open the detail element by clicking it.
You can use the code below as a template for the "details" element.
<details><summary>Summary of the media</summary>
</details>
You'll notice that the above image is pretty large. If you want to make your images take up less space, you can replace this image format that GitHub automatically uses...

...with this format:
<img src="URL of uploaded image" width=500px>
And replace the "500px" with whatever image width you want. Then you can make the above super-wide image look like this:
Click here!

If you want to upload a video, please convert it to a GIF. The only exception to this rule is if the video requires audio narration.
- If possible, include labels for all of the following categories:
-
deck: Whether the issue has had a slide created for it on the Staging or Stakeholder deck.
- Please leave this as "deck: missing" so that the PMs can add a slide to the appropriate deck.
-
feature: Which part of the project the issue pertains to. An issue can pertain to multiple features, such as a:
- page, like Create Project Page 3
- functionality, like the Reset Project button
- deliverable, like the Style Guide
- level: How much skill the issue takes to complete. The higher the level, the more senior the team member should be who is assigned to it.
- milestone: By what point in the project's timeline the task needs to be completed. This will usually be selected by a member of the production team.
- priority: How important it the issue is compared to other issues. This will usually be selected by a member of the production team.
- role: Which team will work on the issue.
- size: How long the issue will take to complete.
-
deck: Whether the issue has had a slide created for it on the Staging or Stakeholder deck.
- If you don't know the correct label for a category, leave it as "missing".
- If an issue is still being worked on and isn't ready to be prioritized, add the "draft" label.
- If you need additional information from a specific team or lead, add the appropriate Ready for Lead label. Direct your question to the appropriate team lead.
- If an issue is ready to be prioritized, add the "ready for prioritization" label.
- Keep the title as short as possible. Titles should not be more than twelve words long.
- All design issues must begin with "Design:". This is to make it easier to see which team is working on the issue at a glance.
- If one or more issues must be closed before the new issue can be worked on, include a Dependencies section at the top with the required issues listed in an unordered list.
- In the Overview section, explain what the requested task is in one sentence with the format "Please [create requested solution] so that [user problem can be solved]." For example, "Please design a sort icon so that users will know which column is being sorted."
- Sometimes a specific solution will not be requested, in which case the format can be expressed as "Please [solve user problem]." For example: "Please design a way for users to know which column is being sorted."
- In the Details section, provide all available context that the designer can use to better understand the problem and possible solutions. This can include:
- Who requested the issue
- What problem caused the issue
- Screenshots from the development site
- Mockups from previous designs or similar ongoing issues
- Constraints the designer's solution must meet
- Details about the problem
- In the Action Items section, list any steps the designer must take to complete the task. Most of these will be automatically included in the selected template.
- In the Resources section, list the steps required to reproduce the design problem being described in the issue. Additionally, list links to resources that would help the designer solve the issue, such as:
- Other GitHub issues that affect or are affected by the problem
- TDM Dev site pages
- Figma pages
- Helpful research or design information
- Other applications that have potential solutions