Make "Component" a multi-value field, or allow sub-components

Sure. But shouldn't we tackle the bigger problem of tagging, and the need for better fields all around, or is the thought to just do it incrementally? I think there is a d.o issue on more better fields somewhere.

I think there was something about making the component field match with what is in maintainers.txt ... and have hierarchy to it, so people would pick views first and then something more specific. If I can find a link, I'll come back and add it.

Re #2 mention about making maintainers.txt match components:
#2102141: Make MAINTAINERS.txt database section friendlier for parsing

For Drupal.org deployment, changing an issue field from single to multi-value is a re-indexing of all issues, adding another table. Queries would be a bit slower when searching on components, it is another join, but not any more noticeable to humans than the others, like searching on tag. Overall, this is certainly doable, with being careful on deployment.

Some sanity checks - Does core has too many components? Is separating views and views_ui good? Are these changes good for non-core projects too? (Just a thought, I don't have enough first-hand experience to have a good opinion.)

I do think working on tagging (and maybe other fields) would be great. But free tagging, with some structured tags, isn't a replacement for a curated list of components. At least not in the near future.

another example: #2589237: Menu links parent migration is broken which is both migration and menu system

#2702321: Group core components into broad categories has some ideas for the governance side of this.

"Shut up and take my money!"

Read: yes, this would be great to have.

Coming here from #2660144: [Plan] Update core components and Bug Smash Initiative

Different people seem to want different things from this. In Slack, @xjm wrote:

So the goal of the components list is to reduce the list from 80-100 things to a sane 20. A lot of that comes from grouping things into sub-topics, e.g. "Entity Field API" covers multiple components. However, maintainers also still want to be able to sort things more granularly. So "Entity Field API" would be the component and "Field UI" might be the sub-component. Or "Views UI" would be a sub-component for "Views".
...
The [subcomponent] would be optional and would be a subselect
And you could search both
This was the conclusion based on a lot of convos with subsystem maintainers and committers, that we would need the subcomponent functionality

But @YesCT in #6 is saying:

another example: #2589237: Menu links parent migration is broken which is both migration and menu system

That wouldn't be solved by the proposal for subcomponents, only multi-valued components. The two ideas in the title and summary are at odds with each other, we can't really do both.

There's a lot of prior discussion and history to this, so I don't want to do unilaterally make changes, but can someone with authority please decide which of these problems we're solving and update the title and summary accordingly?

Meanwhile, subcomponents would be a fair bit of work:

1. UI to define subcomponents on project nodes.
2. Add another dependent field to project_issue nodes using this (with upgrade path).
3. Perhaps expand dereference_list to be able to handle this.
4. Add this to the block displaying issue meta data on issue nodes.
5. Make sure the code to update the issue metadata (on issue edits or comments) properly handles this, that if you change the component, you refresh the list of subcomponents via AJAX, that the validation is all solid, etc.
6. Add this as another filter to the Search API Views for issues (probably with fancy JS dependent drop-down stuff).
7. Decide how to display it in the issue views (either add Yet Another Column or merge component and subcomponent into a single column)?
8. ...

Are we sure that's all necessary and that we can't actually solve this with some creative use of issue tags? I don't see that discussed / ruled out either here nor at #2660144: [Plan] Update core components.

Is there a smaller change we could make to how issue tags work that would give us what we need with less effort that the list above? That might also make life better for contrib issue queues, too (unlike sub-components, which seems like it's only be used by the core queue).

If we're going to invest a big effort in retooling our tools, I'd like to know we're getting the most benefit for the effort.

Thanks!
-Derek

I posted about this in: #2702321-15: Group core components into broad categories

When I interviewed both subsystem maintainers of components we wanted to merge and core committers, there was widespread concern that tags were not discoverable, consistent, etc. enough. For the ideal user experience, we would have a hierarchical-type select (a11y and UX validation needed) that allowed selecting a required component and optional sub-component.

I'm more on the fence about making it multivalue. I think multivalue issues are more the 10% case. So maybe we should treat that as a separate scope.

Multivalue would be useful for migrate and similar systems - I recently moved an issue from migrate_system to node, and then it got moved back to migrate_system by the migrate maintainers. This also happens with entity system and specific entity implementations sometimes.

One thing that crossed my mind thinking abou this, in between tags and a subselect, would be two flat lists. The shorter list required and single choice, then the longer list (maybe using better select or similar) optional with all the subcomponents and multiple choice.