Roadmap to experimental Project Browser in Drupal Core

From the Priority TBD section in the issue summary:

Make the Svelte app customizable by other themes OR get agreement on a policy on why this isn't necessary (this being a portal to a collection on an external site seems like a way to sell that)

In my opinion, this is a must-have for core inclusion for two reasons:

• Once Project Browser is in core, then it's part of core's admin UI, and admin themes like Gin would quite reasonably expect to be able to theme it to look like it fits with the rest of Gin's design.
• This would be our first Svelte app being committed to core, which also means adding Svelte itself into core's toolchain. The hypothesis we had in deciding on Svelte was that we could implement themability for it in a reasonable way. In my opinion, we need to validate that hypothesis before committing Svelte into core's toolchain. Showing how that would work for Project Browser is a great way to validate that hypothesis.

Meanwhile, tagging this issue for review from all the core committer roles to make sure we're all aligned on the roadmap to core inclusion, starting with giving feedback on the other 3 bullet points in the Priority TBD section.

#6: this is not in the Drupal core issue queue, so do those tags have any effect?

Also, this roadmap seems incomplete/outdated?

Also, do you intend to reuse the decade-old #1841788: Add project browser or do you intend to open a new core issue?

Having a look at that one, I *think* it makes sense to open a new, clean one, so we're not muddied by the previous attempt. And yes, I think still incomplete.

I just took a look through this, and most of the stuff I'm concerned about is in the Usability meta already. I'm not sure if that meta contains everything that is strictly _necessary_ for MVP or not.

I did add one consideration which is the Project "Detail" page (vs. just reverting back to "link to drupal.org page") - though the Site Builder Subcommittee has been working hard on that piece of the puzzle to try and identify the most important aspects of those pages, so I think we could do it considering most of the plumbing is in place.

Lastly, I only have a question as I'm unfamiliar with the process. Is there any non-code documentation required before it could go into core? Would it need a handbook page or something of that nature? If so, an issue should be created for that.

In my experience, we consider a roadmap not actually a roadmap until there's zero meta issues left, because otherwise it's impossible to get a sense of the remaining size of work. (Because it's possible to add/remove issues to the meta issues, and that won't result in updates of this roadmap issue.)

Right now this lists 5 issues, which seems a tiny amount of work, but probably each meta issue has a number of issues associated with it? And are each of those 5 metas fully scoped out?

Yes, each module providing any API must have a *.api.php file, any module regardless of API or not must have a handbook page, and each module must also have a hook_help() implementation.

I came upon #3219457: Project Browser MVP Document which has had not activity, catch suggested to close this as a duplicate. This issue seemed the best fit so I have closed it as a duplicate of this issue.

RE #14 @quietone - yes, 100% the right thing to do. Thanks!

Just a note that I have made marked updates to this and to the entire queue. This is following several triaging meetings with this team + Lauri. So, this is updated now and will be our path forward. Exciting!

Per discussion with @chrisfromredfin, @Gábor Hojtsy, @leslieg, and @thejimbirch, Recipes support is a Starshot blocker. However, as Gábor pointed out, it requires extensive API changes in PB, which means that we'll have the best success if we also treat it as a beta blocker for core. I didn't update the IS because I'm hoping someone from the initiative can confirm. Thanks!

The issue summary states that many of the UI decisions need a decision. So, getting a usability review would help smooth the path to beta.

saving to get re-draw ¯\_(ツ)_/¯

I think the current status in regards to package manager, is that if only project browser is installed, it uses core's package_manager, but if automatic_updates is installed, it uses the package_manager shipped with automatic_updates.

For general stability and wider testing, it would be great if automatic_updates stopped shipping a copy of package_manager, but this really needs a beta package_manager in core, which has a couple of remaining blocking issues per #3319030: Drupal Core Roadmap for Package Manager and Update Manager.

Crediting discussion participants from #53... Or was about to, but this ain't my queue. 😅 Pasting this in the "Credit others" field will do the trick quickly and easily.

xjm, chrisfromredfin, Gábor Hojtsy, leslieg, thejimbirch

I am officially postponing this. I am unsure the path into core for Project Browser, if it's even necessary. So I can re-open and re-triage issues for core inclusion if that's something that presents itself as an actual need for more successful adoption of PB, or of Drupal itself.