Pablo-WMDE added a comment.
(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 <https://semver.org/> 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. TASK DETAIL https://phabricator.wikimedia.org/T246108 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pablo-WMDE Cc: Pablo-WMDE, Addshore, Aklapper, Sarai-WMDE, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Volker_E, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
