[Plan] Simplify core component list

Here is a suggested start. It does not cover all the current components.

• configuration - configuration entity system, configuration system, config.module
• database - mysql db driver, postgresql db driver, sqlite db driver
• entity
• fields - field_ui.module, number.module, options.module, link.module, telephone.module, text.module
• help
• layout -
• localization - language system, language.module, locale.module
• meetings
• menu - menu system, menu_ui.module, menu_link_content.module, path.module, path+alias.module
• migration
• plugin system
• render - ajax system, asset library system, forms system, theme system, markup
• routing - routing system
• single directory components
• testing
• themes - claro, engines, olivero, stable9, stark, starterkit_theme
• translation - transliteration system, content_translation.module, config_translation translation_entity.module
• umami demo
• update - database update system, update.module, automatic updates
• views - views.module, views_ui.module
• web services - basic_auth.module, jsonapi.module, rest.module, serialization.module

would it be possible to alphabetize the components as well?

No solutions but possible problems:

Entity and fields is tricky, the individual field types are not part of the entity API, but the field API very much is, and issues could end up in the wrong place because of that. We sometimes get the same issue with node/user/comment/taxonomy issues that could be entity-type-specific, could be entity system but just discovered via a specific entity type. Same with content_translation and entity where there's a lot of overlap.

I wouldn't put the database update system and update module together because they're dealing with very different things, but this is complicated by automatic updates module which is dealing with both.

In the hope of generating discussion I made a suggestion in the IS. It is limited to D8+ components and I am sure there are mistakes.

I get that we want to reduce the amount of labels/components, but I'm not sure about grouping together different modules and things that have different maintainers. As a maintainer of a subsystem, I need a way to filter my issues.

Examples for that would be different database backends, but also config/translation being *very* different beasts that have little to no overlap. But also themes, olivero and claro have completely different maintainers.

So IMHO, the components for issues should be based on the components we have in MAINTAINERS.txt and if we want to clean up, we should start there?

Another problematic use case is things that we remove from core. For example you put the form system and inline_form_errors in the same component. if we were to remove the module from core it would be _very_ tedious to find all relevant issues and move them to the contrib module.

IMHO, the solution for that with gitlab issue labels would be multiple labels. For example, both localization and translation could actually be a common multilingual label but then each module within that would also have it's "sub-label" and we'd add both to an. That would of course result in even more labels technically speaking, but that's going to happen anyway because we'll also need to make all tags labels?

+1 that whatever we do, it should align with MAINTAINERS.txt, including if that means modifying MAINTAINERS.txt.

But also themes, olivero and claro have completely different maintainers.

Agreed. As a Claro maintainer it's really useful to filter by component.

Yes, the components and MAINTAINERS.txt should be more in alignment. And because of that I don't think it is necessary to start this discussion on how to group the components in a new issue about MAINTAINERS.txt. We just need to keep in mind the two places these 'groups' are used.

For some reason I did not mention in the IS that we could use scoped labels. I am guessing that this is the sub-label referred to in #8. That will allow us to maintain the module or theme granularity.

@Berdir, are you suggesting this change?
Replace

1. localization - language system, language.module, locale.module
2. translation - transliteration system, content_translation.module, config_translation

with

1. multilingual - language system, language.module, locale.module, transliteration system, content_translation.module, config_translation

Moving to plan.

But also a +1 to redoing MAINTAINERS.txt as we currently have 26 gaps in it.

> @Berdir, are you suggesting this change?

If and only if we keep the specific components/labels for the specific modules (whatever they will be called), yes. The separation between localization and translation seems arbitrary to me.

That was just one example, I'll try to take another closer look under that assumption and make more suggestions.

Updated the IS to include the preference for keeping the extension granularity and the 'multilingual' suggestion. Also, sorted the items on the right side of the hyphen by system then by extension.

@Berdir, thanks. I am looking forward to your suggestions.

There has been little engagement with this issue and I also think this is a difficult task to do in an issue. A few days ago I thought a card sort exercise of some sort will help. I am only just starting to explore that.

Also, I updated the IS to show that there is agreement on keeping this in sync with MAINTAINERS.txt. I have moved the point about agreement on keeping the module level distinction to a remaining tasks for further discussion. I did that because of my experience as a migrate maintainer. Quite a few migration issues were neglected because they were filed in some module component. It was purely by accident that I found one and then added extra searching to my habits. I'd like to consider that a bit more and hear other opinions.

As the D7 EOL is in January 2025, I am curious what exactly does this mean?

This list does not include components that have been removed from D8+ or are D7 only.

Don't we need to preserve D7 components until the EOL?

@poker10, yes, the D7 world needs to be included in some way. When I made this is seemed that starting with D8+ only would make this simpler due to less components, but also to encourage long term thinking.

How about the D7 components are added but say, in italics, so we can see the difference. You are invited to add them to the IS :-)!

I checked the list of components and compared it with the proposal in the IS. Here are my thoughts:

D7 only components which are missing in the proposal:

• base system - add to the group "base"?
• xml-rpc system
• aggregator.module
• blog.module
• color.module
• dashboard.module
• menu.module - add to the group "menu"?
• openid.module
• overlay.module
• php.module
• poll.module
• profile.module
• rdf.module
• simpletest.module - add to group "testing"
• trigger.module
• Bartik theme - add to group "themes"
• Seven theme - add to group "themes"

I also found few D7/D10 components which are missing:

• action.module - D10 only, missing in the proposal
• book.module - D7 + D10
• forum.module - D7 + D10
• tour.module - D10 only, missing in the proposal
• tracker.module - D7 + D10
• documentation - not included anywhere in the proposal

I have not updated the IS with these two groups yet, as I think it would be better to check if some of them could be assigned to existing groups in proposal, instead of adding all of them as new groups. Once we reach consensus, we can update the IS according to this.

I had the idea that a card sort would help us resolve this. I reached out to https://maze.co/ and https://support.optimalworkshop.com for support. They both replied in the negative.

Anyone have other ideas to make this easy for us?

@poker10 the Drupal 10 ones that are missing are (I assume) because those modules are planned to move to contrib for Drupal 11. Maybe we can apply @quietone's italics idea for those too.

Documentation for me is more of a topic than a component, although sometimes it's used for documentation for core on Drupal.org which is kind of a grey area compared to the actual documentation queue.