Update issue-type icons to use default icon style

Description

With the concept of work items maturing, more issue-type- icons added, and these icons being used more prolifically in the UI, I think we could move towards updating the current issue-type- icons to the default outline style. Another reason is that they aren't necessarily a subset or type of issue anymore, but just another work item that is a sibling to a traditional issue.

Another problem this addresses is that work items are in the same list as traditional issues or MRs, and the icon styles clash and provide unnecessary, and additional weight to certain icons.

Examples of mixed icons
Example Notes
CleanShot_2023-08-23_at_12.30.43_2x Two different issue icons are used in the same context. After the update these would be the same, but in a separate effort the icon could be removed from the badge.

Note: Naming is out of scope, since that requires a larger effort and naming isn't fully resolved (e.g., issue type → work item).

Concept

Before After Notes
issue-type-enhancement.svg issue-type-enhancement.svg A NE arrow on its own looks more like an external link than an enhancement. The concept is based in apps where enhancement features are commonly represented by a magic wand. Here, there are dots used instead of sparkles so that this doesn't get into AI territory.
issue-type-feature.svg issue-type-feature.svg A bow is more related to a gift. It's common for a feature to be starred, and in this case it's in a circle to keep it separate from the star icons used for favoriting a project.
issue-type-incident.svg issue-type-incident.svg This just updates the exclamation mark to be more like others in the icons and keeps the rounded rectangle container to separate it from a warning.
issue-type-issue.svg issue-type-issue.svg No need for more than one icon to represent an issue, so this uses the existing issues icon, but just duplicated under this name.
issue-type-keyresult.svg issue-type-keyresult.svg Same concept, only with a more pronounced fletching to give it more optical weight.
issue-type-maintenance.svg issue-type-maintenance.svg Same concept as before, but with another tool added so it doesn't look like the single wrench used for admin.
issue-type-objective.svg issue-type-objective.svg Same concept, only larger.
issue-type-requirements.svg issue-type-requirements.svg Use the existing requirements icon, but just duplicate under this name. This is similar to how issues are handled.
issue-type-task.svg Task icon concept A checkmark with a simplified tray to indicate something that needs to be completed, but without the same appearance as a todo. Context will have to help make this clear.
issue-type-test-case.svg issue-type-test-case.svg Updated to be a little more simple, while taking up more space than its spherical base counterpart.
issue-type-feature-flag.svg issue-type-feature-flag.svg Use existing flag icon, but just duplicate under this name.
issue-type-ticket.svg issue-type-ticket.svg Same concept, only larger.

❖ View working file in Figma →


Checklists

After all of the following tasks are complete you can close this issue:

Assignee tasks:

See tasks:
  1. Create or update an icon
    • If you’re a community contributor, please fork the GitLab Product Icons file when updating or creating an icon.
    • If you’re a GitLab team member, please create a branch of the GitLab Product Icons file. Prefix the branch name with the issue, MR, or epic number, and add your GitLab username as the suffix. For example, #860-new-icon-lvanc. Then update or create an icon.
  2. Update the link to the working file under the Figma link section above.
  3. [-] If work was not done in a branch (a merged branch will automatically be archived), move your working file to the shared Figma project:
    1. For all other changes, move your file to the Misc archive project.
    2. If you’re a community contributor, please consider transferring ownership of your draft file to the maintainer so they can move it to our archive, along with its version history and comments.
  4. When applicable, follow our iconography guidelines. For third-party trademarks, please review the third-party trademark usage guidelines.
  5. Ask a Foundations designer to review your design.
    • If you’re a community contributor, ensure the designer that will be reviewing your file has edit permissions in Figma.
    • If you’re a GitLab team member, request a review in Figma.

Reviewer tasks:

See tasks:
  1. Review the icon in the author’s branch. Add design-specific comments in Figma to maintain context. Add general comments to this issue, including your approval status.
  2. Once review is approved, assign to a Figma maintainer for final review.

Maintainer tasks:

See tasks:
  1. Merge the branch to the GitLab Product Icons file, convert the icon to a component, add keywords and usage notes (optional) in the description, and view it in the Assets panel to ensure it aligns with what’s outlined in the document and asset library structure documentation.
  2. Publish the library changes along with a clear message about the update.

Library addition tasks:

Once the Reviewer or Maintainer has approved your icon design, consider the following tasks to add the icon the gitlab-svgs library.

See tasks:
  1. Create a new merge request (MR) from this issue.
  2. Checkout the new branch locally.
  3. Export the icon component from the Pajamas UI Kit (in Figma) to the /sprite_icons folder in your local instance of the repo. The file name should be lowercase, and use hyphens as a separator between terms.
  4. Open the SVG you just exported in your code editor and remove fill="none" from the <svg> element.
  5. In a terminal window, run yarn run dev to preview the SVG library locally. Find the new icon and test it out by changing settings in the Icon configuration panel of the site. The icon should change color and size with no issues.
  6. After you’ve committed the changes and the pipeline passes, double-check your icon in the review app and test that it matches your expectations.
  7. Assign the MR to be reviewed and merged by a maintainer, and proceed with any changes.
  8. Add a read only (FYI) agenda item to the next UX weekly call to inform everyone of the new icon, linking to this issue.

If you run into any problems, ensure that all other steps in the project README have been followed.


Links / references

Edited by Jeremy Elder