Consider a unified component section
Problem to solve
Today, we have a separate dependency list and license compliance sections (referring to project section pages, not MR widget sections); displaying results from two different scanners. However, separating them makes a segmented experience; whereas they are closely related. The dependency list shows licenses and the license list shows dependencies; understanding how they related together is hard to achieve on separate UI sections. The user is forced to navigate from one list to the other (example: looking into related dependency for out-of-compliance license).
As new features evolve, so will the fragmented UX caused by the information architecture. Consider policies: today there are policies related to license compliance but not dependencies. If/when we add policies related to dependencies, these would be seen in separate areas, given the current info-architecture.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
- Simone (Software Engineer in Test)
Further details
This supports future goals of 1) showing dependency path/relationship (#198034 (closed) and #213591 (closed)), 2) bill of materials for projects (#214278 (closed)), 3) compliance gates
Job's to be done:
As a developer, I want to remove out-of-compliance licenses and understand the corresponding dependency, so I can remove it as needed (to be in compliance)
When my dependencies have reported vulnerabilities, I want to learn more about the vulnerability cause and implications, so I can make an informed decision on taking action on how to proceed.
When my organization has a compliance policy with dependencies, I want to be aware if I’m breaking a company policy, so I can make sure my project dependencies are in compliance with my org compliance.
When I need to audit 3rd party licenses and dependencies, I want to be able to provide inventory of licenses and dependencies for the auditor, so I can have them on record for auditing purposes and be able to share them with auditors and customers.
When I want to see how dependencies are related, I want to view them grouped by file, so I can access the information faster.
Proposal
An information architecture revision: a component section as an umbrella for 1) dependencies, 2) related licenses, 3) policies
Permissions and Security
Same as current
Documentation
...
Availability & Testing
...
What does success look like, and how can we measure that?
User:
- Does the user find this section when looking for licenses/dependencies?
- Is the sort by effective is displaying related materials?
- (as policy features evolve) does it help user to apply and view policies in a unified section?
What is the type of buyer?
Is this a cross-stage feature?
Yes, as policies evolve in compliance and defend: related to components may be displayed here: 1) policy awareness, 2) violations