RFC: The Development Kitchen 🍳

[SiAdcock]

Proposal

Extending design systems requires a lot of deep thought and collaboration across disciplines (design, UX, engineering). However there is value in moving quickly, experimenting with new ideas and sharing those ideas for wider input.

The development kitchen is where new components and patterns can be cooked up, tested and shared. There are minimal acceptance criteria. It’s okay to duplicate and break things. If a kitchen component proves valuable, its status may be updated to stable and it will move out of the kitchen.

Ownership

Kitchen components are unsupported by CSTI and owned by the team or teams consuming them. We don’t recommend individual contributors taking ownership of a component, as an individual may change teams, leave the company or otherwise become less inclined to support it.

Owners are defined in the CODEOWNERS file in the GitHub repo.

Changes to components should be coordinated with their owners.

Evolution

Changes to kitchen components are to be expected. Components in the kitchen should be considered experimental and likely to change in ways that break things.

Owners of kitchen components have visibility over where they are currently being used. Owners should notify consumers of their component that changes are being considered, to ensure everyone is kept in the loop. This could happen at the pull request stage.

Components that are valuable may be promoted to stable. In order to achieve this, the component must meet Source’s acceptance criteria. The best way to meet these is for developers to work in close collaboration with design and UX when building and evolving a component. Not all code components have an equivalent in Figma, but components should express some pattern, rule or aspect of design that is governed by Source.

What problems does this solve?

Source is a library where teams can expect to find shared components. However Source requires components to be high quality and as such it takes a long time and a lot of effort for components to land in Source. Potential contributors are put off contributing directly to Source, as they they find it hard balance the time investment against their team's priorities. The cost of this is two-fold:

• The number of high quality components available in Source is lower than what it could be
• Potentially sharable components are built directly into applications, leading to fragmentation, inconsistency and duplication

We believe the Development Kitchen will help teams share components quickly, by lowering the barrier to entry. It will allow teams to get fast feedback on new components, both from users and from other developers.

By providing an agile mechanism for iterating and improving, components can be brought up to the level of quality expected of Source components, and everyone can benefit from the work put into them.

Comments?

Does this sound like something you would use? Can you think of any other benefits, or do you have any concerns? Do you have any ideas for its implementation, or questions about how it would be consumed or maintained?

We are keen to hear from as many people as possible

[oliverlloyd]

❤️ Great write up! ❤️

It's interesting that you mentioned ownership. I've been subtly pondering the future of repos like atoms-rendering. The people who worked most on this repo are set to leave Dotcom or the Guardian (😢 ) which creates the risk that this code gets dusty. It happens. Could the kitchen be a place we can put things like this to try to keep them fresh? Not sure if location alone solves this problem but discoverability and visibility is certainly a factor.

[SiAdcock]

Thanks @oliverlloyd

The @guardian/client-side-infra team have been thinking about this very thing. It does seem to make sense for discoverability that shared components, including highly composite components like atoms-rendering live within Source. The naming of these repos is unfortunate because they expose React components rather than a rendering service like dotcom-rendering. They are closer to Organisms as defined in Brad Frost's Atomic Design.

Whether components like this are defined in Source, or in some journalism-specific component library is a matter for discussion. I'm starting to think that everything that is shared should eventually be defined in Source, or some centralised components library, as long as it reflects our visual language and is understood and signed-off by design. Where something is used is a matter for designers – the component library need not, from a developer's perspective, reflect the design intention.

That said, I'm afraid I'm opening a new dimension to the discussion and I don't want to derail too much from the kitchen concept, at least in this thread. If needs be, I can start another discussion to cover this topic.

[oliverlloyd]

At what level of completeness should components in the kitchen be thought of? experimental, alpha or can we have proper releases at v1 and the fact it is in the kitchen is enough?

It's a tricky balance. We want to communicate that things might change but at the same time you want to encourage usage.

[SiAdcock]

Thanks for the feedback @oliverlloyd I think this is something that we will have to iterate on, as I don't have a good sense right now.

In order to drive improvement of kitchen components (i.e. an owner should not be afraid to make changes to a kitchen component), we would have to assume they are experimental. If an experiment is successful (whatever that may mean!), the component would be promoted up to the core component library. Otherwise, I expect it should be deleted.

We want to communicate that things might change

Absolutely, this is a fundamental underpinning of the development kitchen idea. In order to improve, we might need to break things.

but at the same time you want to encourage usage

Yes, it is desirable that kitchen components gain adoption to prove they are useful in a variety of contexts. This ought to be one of the criteria for promotion – ideally no component in the core component library will be used in only one context.

Another approach is to have various stages in the component cooking process. Components are tagged as alpha or beta:

• alpha: not stable, not supported. Incomplete docs. Expect breaking changes
• beta: no further breaking changes. Acceptance criteria not met, but being actively worked on. Will likely be promoted to core component library one day.

I'd love to hear any more ideas for approaches.

[sndrs]

this came into being in #963