Demetris Roumis

I agree that there are two-ish related dimensions (type and status) that we're perhaps trying to simplify into a single categorization scheme. But Is it useful to specify ~9-16 different...

@Coderambling , thanks for weighing in! You're right that without specific criteria, this would ultimately come down to the Steering Committee's judgment. But IMO, that's consistent with our ecosystem's ethos......

@maximlt , seems like you are circling back to my original proposal as what you've listed is a combination of status and type :)

Either way, I'm happy with this support-level recasting of it. Although I very much don't think `holoviz-plus` is the right name to indicate a reduced support level; it sounds like...

To me, maybe `holoviz-extras` implies a bit more about the support level being not the top priority focus while also being open to any 'type' of repo.

@jlstevens voiced support for `holoviz-extras` naming in the HoloViz meeting today, along with the general scheme of using 'support' level as the organizing principle. No dissenting opinions were raised brought...

## Summary of Discussion The HoloViz project categorization proposal outline evolved from the initial mixed type/status approach to **primarily organizing by support level** across different GitHub organizations: ## Agreed Structure:...

In meeting: @philippjfr slightly prefers keeping Panel-extensions repo separate from the proposed HoloViz-extras, but wouldn't block the migration if consensus is clearly in favor

We're going to have a Panel-focused meeting and make a decision within ~2 weeks

> Should the process above be "road-tested" by applying it to at least one current and one "historical" project? I don't see the risk to the proposed migration. The process...