Define component release management
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Sarai-WMDE
	Feb 25 2020, 2:21 PM

Description

How can we manage the update (replacement) of new versions of Shared components in the FE of the apps that are currently using said components?

Should we simply notify the teams and have them proceed with the integration on their own? How could the notification be automated (in case it makes sense)?

Note based on Michael's comments: This is somehow a "social" task. Whoever handles this needs a certain awareness of in which apps do components live at the moment. (Is there a way to document this? To automate it? Adding sort of "used by" in the component definition?)

Relevant resources:

Nathan Curtis, Versioning design systems.
Daniel O’Connor, How to version your UI library.
Atlaskit Design System: Versioning

AC:

Document our conclusion on "How to modify existing components" page in Storybook

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Resolved		• Tonina_Zhelyazkova_WMDE	T246108 Define component release management
		Resolved		Sarai-WMDE	T260873 📖 Document: How to modify existing components

Event Timeline

Sarai-WMDE created this task.Feb 25 2020, 2:21 PM

Restricted Application added a project: Wikidata. · View Herald TranscriptFeb 25 2020, 2:21 PM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Sarai-WMDE renamed this task from Component release management to Define component release management.Feb 28 2020, 2:45 PM

Sarai-WMDE updated the task description. (Show Details)

Addshore subscribed.Apr 9 2020, 1:24 PM

Sarai-WMDE updated the task description. (Show Details)May 15 2020, 1:52 PM

raja_wmde edited projects, added Wikidata - DS hike; removed Wikidata Design System.Jun 9 2020, 1:22 PM

Sarai-WMDE updated the task description. (Show Details)Jul 23 2020, 5:23 PM

(This is half picking up what is in the description a half a reaction to a team chat comment about the "versioning system" for the Design System and component library)

I somewhat agree with the notion of "social" task. Technologically, versioning is a solved problem and practically all our software is versioned already one way or another. This also accommodates for possible "shades of gray" between updates (like "something changed but it's not a big deal). We know how to make it happen and it will be comparably cheap to achieve. The uncertainty lies in what information we want to encode in those versions. Instead of focusing on technical terms I suggest we discuss the effect(s) we want to achieve in the real world.

We are implementing design tokens and components. Those will be used in different applications and will influence their individual visual style.

Existing components will be added to applications where needed. Likewise, new components can be crafted as needed and then are used in the application. Up until this point release management is straightforward. A version of the Design System and component library is released when the component is done and "ready" and the application wanting to use it makes use of the version in which it is contained.

However, when design tokens and/or components change, things become more interesting. Assuming the component is already used in one or more application (otherwise there is, of course, no real world impact beyond our Design System's storybook), our applications should swiftly be updated (following my assumption of what we are trying to achieve) to use the latest version of the Design System and component library so that the applications' visual styles

match the visual style as documented in the Design System
are consistent between each other (they could diverge if only one application gets updated and another is not)

I believe that all the aforementioned is relatively easy to achieve if two conditions are met

the ownership of the visual style of the Design System and of the visual style of the applications lie in the same hands - there is no conflict of interest; Design System changes are supposed to influence application styles
- effects of changes of existing components on applications should be anticipated and the result should be incorporated into the decision if that component should change (otherwise the change could be implemented directly in the application, or a new component could be implemented instead of changing an existing one)
Design System changes are not done until they are done (i.e. a Design System change is not finished until it propagated into all consuming applications)
- who ever requests a change to a component should also have the consistency of the system as whole as one of their priorities and acts as a project manager to restore that equilibrium taking on the project management for updates to all applications also using that component

Again, I don't think those are hard tasks. They just have to be - checklist style - seen through for all changes, time and again, and all will be well - at predictable effort.

Thanks a lot, @Pablo-WMDE for your detailed explanation!

Thanks a lot, @Pablo-WMDE for writing this up. I agree with your points and we should document this in some way in our storybook documentation in the "modifying components" section.

Regarding the "effects of changes of existing components..." part: does storybook offer the possibility to "search" for a design token and get back a list of components that use it (directly or as aliases)?

Regarding the "effects of changes of existing components..." part: does storybook offer the possibility to "search" for a design token and get back a list of components that use it (directly or as aliases)?

That is a capability I could totally see as an enhancement once T256792: Show tokens that are used in a component has landed in some way. As soon as we, in the individual components' stories, have some awareness of the tokens used inside of their respective components, using this knowledge to spike the search index should be fairly straightforward.

Maybe the idea should be added to a placeholder story so it is not lost?

Maybe the idea should be added to a placeholder story so it is not lost?

Yes, should have this in another story. I think it is covered here already: T256862

Sarai-WMDE updated the task description. (Show Details)Aug 4 2020, 12:11 PM

List of potential design-driven token and component changes identified so far:

Area of change	Justification
Tokens	As designers, we detect the need to modify our token structure (regrouping, adding, deleting), naming or values, in order to capture and spread the system patterns consistently. Changes may have different impact on versioning depending on whether the modified tokens are in use by one or more components
- Create	The representation of a style was missing (detected by UX team, or imposed by WMF)
- Update: Name	- Correct imprecise name, - Outcome of regrouping/restructuring tokens
- Update: Value	Visual change (decided by UX team based on an improvement, or imposed by WMF)
- Delete	- Unused token, - Tokens are merged as an outcome of regrouping or restructuring
Component: visual (bugs/improvements)	As designers, we may detect the need to modify the visual style of a component that is already in production in order to make it consistent with the system.
- Update value of component-level token	Need to modify the visual style of a component (incorrect style was used, new design decision)
- Update name of component-level token	- A new component variant is created that makes us rethink the c-l token naming, - We decide to modify the naming convention (e.g. button-primary-xx-xx to btn-primary-xx-xx)
- Create: Define missing visual property	-A given style was left undefined while specifying/implementing a component, -Extra functionality is being added to the component (which requires defining extra styles)
- Delete component-level token	- Need to remove unused style (e.g. after replacing it)
Component: interaction (bugs/improvements)	As designers, we detect the need to modify the behavior or expand the interaction of a component that is already in production.
- Update value of component-level token	- Need to modify the simple interaction (e.g. transition) of a component due to previous incorrect value, or new design decision
- Modify component implementation	- Need to expand the interaction or behavior of a component based on new features/user/system needs