[Policy] Can we adopt standards for interoperability of recipes and to prevent conflicts and duplication?

Has anyone successfully done this in an open-source community?

Starshot and Project Browser can limit the recipes they allow, but beyond defining naming standards and documenting best practices, what else can be done to resolve this?

RE: Starshot and Project Browser can limit the recipes they allow.

For now, recipes that have been registered with Packagist can be installed with composer and should install into /web/recipes/contrib.

Short term, the community Cookbook Page → may organically grow into a directory of available recipes. (This not the one-click solution we are after, but should help people get started for now.)

To prevent duplicated efforts, maybe there could be a recipe-schema.yml type of file, to hold metadata and recipe tags?

This is a really interesting line of thought.

Has anyone successfully done this in an open-source community?

I chuckled at this because this thought crossed my mind immediately :)

How do we manage duplicated effort on recipes? (For example, having multiple recipes for building a news site)

I'm not sure that this is necessarily means duplicated effort. There is no one single 'news site' setup that would work for everyone, so I think it's fine if there are multiple. The challenge really is how to describe what recipes are doing so that users can choose the one that best fits their use case. This has come up in a few discussions already and there's no obvious answer other than 'have a good description on the project page'. More in #15.

The good thing with recipes is that we won't run in to the problem that modules have of trying to describe multiple versions (of the module, and even of Drupal) and other considerations such as how to set up (since the recipe does that for you). There should really only be one version of a single recipe project at any given time (other than maybe dev vs the tagged release). So it should be easier to have a concise, up to date description?

RE:

how to describe what recipes are doing so that users can choose the one that best fits their use case

This is where I'd like to see a schema/vocabulary type file, that holds as much or as little info as needed for a recipe.
For a recipe, we have ingredients, place to purchase them, steps to cook, steps to prepare and serve, kitchen cleanup.

A Recipe Card for Drupal Systems. (.yml)

For "standards for interoperability" compliance, we could have a published list of best practice "ingredient tags". This would let us filter.

What quality signals for recipes can we use to promote the 'best' ones in the project browser?

I believe there should be a governance group that would validate and promote 'best in class' recipes. These ones I would envision show up on the homepage of Project Browser when browsing available recipes or when creating a new site from scratch as these ones would be "verified" (maybe even with a badge in their recipe thumbnail to show this) by the governance group/community to work well out-of-the-box.

Another metric I presume we can use would be a "sites installed" count like we have for modules. This is one metric I was taught when staring out as a Drupal dev when validating quality and support of a module and I presume the same would apply for recipes as well. I'm not certain how D.O calculates the "sites installed" metric on module pages, but presumably we'd have that same capability as well?

Trying to put myself in the shoes of a brand new person to Drupal but an ambitious site builder looking to start using Drupal having something that tells me "this will work well and has been tested" would certainly give me a vote of confidence when trying to choose a recipe.

How do we manage duplicated effort on recipes? (For example, having multiple recipes for building a news site)

Maybe we start with a Meta page discussing what folks would find valuable as a recipe and create child issues that would be in the individual recipes themselves? If we start from what the wireframes showed in us Project Browser we'd have a couple we could start to look at immediately. Then would need to determine what exactly comes with those recipes.

One of the issues I keep coming back to regarding this is how do we prevent running into duplicate machine names of field names. This seems like something we'll constantly run into without a managed effort to prevent it.

Another area I think needs thought around is the size and scale of recipes. A recipe could be something as small as a paragraph component with fields while another could be effectively a fully built out site with multiple content types, views and various view modes. And in that scenario how do we keep from re-inventing the wheel when it comes to those smaller components, i.e simple "card" paragraph type effectively duplicated across multiple recipes?

Maybe the best way to prevent that duplicated effort is to create small bite-sized recipes like what Standard install recipe has done for each content type and make those available ASAP to the Cookbook Page →

I'm very curious to hear other's thoughts on this.

I agree/like:

... governance group that would validate and promote 'best in class' recipes

"'verified' (maybe even with a badge in their recipe thumbnail)"

work well and has been tested" would certainly give me a vote of confidence.

Presenting the highest quality in Drupal is critical. A flood of garbage recipes that whitescreen people would be bad.

"verified" (maybe even with a badge in their recipe thumbnail " )

Personally, I like/want this. ^^

duplicate machine names of field names

On some levels this is a best practice situation. Unique prefixes help prevent name collision with fields.

Maybe we start with a Meta page discussing what folks would find valuable as a recipe and create child issues that would be in the individual recipes themselves?

This would be interesting to watch (and learn from.)