Communicating code coverage of each component #37

Open A783270 opened 2 years ago

In GitLab by @tauriedavis on Apr 8, 2020, 22:30

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1804, the status of components that already live inside the GitLab product were moved to Integrated.

I'm curious to hear what would be helpful on the status page. A lot of questions I get are related to why a component in production does not match Pajamas. Even if a component already lives in the product, that does not mean they are fully integrated or used in every instance. How should we be communicating the code coverage of each component? Should that live inside the status page? How can we feasible track this over time?

In GitLab by @tauriedavis on Apr 8, 2020, 22:31

@leipert @mikegreiling @ealcantara @jeldergl @jareko I would love to hear your thoughts on this problem and how we may tackle it.

In GitLab by @tauriedavis on Apr 8, 2020, 22:32

mentioned in merge request !1804

In GitLab by @gitlab-bot on Apr 9, 2020, 05:50

Setting ~"devops::create" ~"group::ecosystem" based on ~"Category:FE/UX Foundations".

In GitLab by @jareko on Apr 9, 2020, 19:26

@tauriedavis Based on the example here, I suggested we create a new column in the proposed new component status table structure, to identify that a component is already integrated, but doesn't conform to the design system. Our design system will change, so naturally some components may become outdated as those changes come in. The new column could be titled Conforms to Pajamas. This way, we can identify components that are in production, but need to be updated to conform to new design system rules.

What does everyone think?

In GitLab by @ealcantara on Apr 13, 2020, 23:54

@tauriedavis

For tracking how integrated a Pajamas component is into GitLab, I imagine this process:

Identify the alternative components used in GitLab for a Pajamas component. For example, GlButton has <button> and GlDeprecatedButton alternatives.
Identify all the use cases for the Pajamas component and those alternative components.
Integration status % = pajamas_component_use_cases / (pajamas_component_use_cases + alt_component_use_cases + alt_component_2_use_cases...alt_component_n_use_cases).

The downside of this approach is that new use cases appear over time and we don’t enforce constraints that ensure developers only use Pajamas components instead of other alternatives. Therefore, that approach only works if it is automated.

In GitLab by @tauriedavis on Apr 13, 2020, 23:57

we don’t enforce constraints that ensure developers only use Pajamas components instead of other alternatives.

Can we write a CI job that ensures old components arent added? At least for non-haml pages? :thinking:

In GitLab by @ealcantara on Apr 14, 2020, 24:05

Can we write a CI job that ensures old components arent added? At least for non-haml pages?

I’m very confident we can although I‘m not an expert on eslint. Eipi and Mike Greiling can confirm since they own the gitlab-eslint-config.

In GitLab by @jeldergl on Apr 14, 2020, 24:05

Yes, this is a tough one because available ≠ used. And used ≠ every instance.

It seems that this table would require us to know a lot of incoming uses data, but should we just focus on outgoing? So, what milestone a component was released in, what version of the component is the latest, etc.

If we can get the data though, I prefer adoption status over integration status.

In GitLab by @tauriedavis on Apr 17, 2020, 24:16

marked this issue as related to #483

In GitLab by @tauriedavis on Apr 21, 2020, 03:13

added to epic gitlab-org&3107

In GitLab by @jeldergl on Jul 13, 2021, 01:21

@tauriedavis since we've determined that this data isn't readily available, and we're looking to remove the status table can we close this?

In GitLab by @tauriedavis on Jul 13, 2021, 04:27

I think providing automatic code coverage is something we want to explore further (although maybe not on the status table if we remove it)

In GitLab by @tauriedavis on Aug 25, 2021, 01:41

mentioned in merge request gitlab-com/www-gitlab-com!88927

KI-SSC-TEST / design.gitlab

Communicating code coverage of each component #37