Note: The page didn't even fit on my screen [not even two], so I had to hack the CSS to produce this screenshot.
Introduce tags[] for module .info files.
Remove the details elements that are based on package.
Add a select dropdown to filter by a tag, so admin/modules?tag=foo only shows a filtered list.
Additionally enhance with JS: Expose the tags to the front-end via data-tags=",foo,bar," HTML attributes, and dynamically filter in the front-end.
Tag values:
What exactly constitutes "related functionality"? Let's think ahead of time:
A tag "field" could mean a "field storage", "field type", "field widget", "field formatter" providing module. There will be a lot of field related modules. Just Drupal core alone provides 8+ field type modules out of the box. But what if the user was looking for field storage modules? OTOH, what if the user actually did want to find out about all available field-related modules?
What if tags would additionally be able to be namespaced? E.g., just field, or field/storage, field/type, field/widget, field/formatter (and any combination thereof).
Note that tags do not necessarily refer to module functionality. "mail" would be a tag that refers to E-mail related functionality (for which there is no module in core, only a core subsystem/component).
Likewise, issues like #623544: How to categorize a module as developer module → are seeking for a way to classify certain modules as "pure UI" modules (such as Field UI, Views UI, etc) as well as developer modules, which can be safely disabled on production sites. Such modules could potentially be tagged with just "api/ui" and "dev".
Human-readable categories/keywords vs. internal/machine tags/identifiers
History and experience with human-readable package names essentially eliminates that option for tag values:
🐛
Module packages using different letter-casing appear multiple times
Needs work
Also closely related:
#591682: Config pages are effectively hardcoded to some subcategory of 'admin/config' →
Internal tags/identifiers are more robust, because they refer to identifiers that are usually related to code instead of arbitrary strings that might have a particular meaning today, but not necessarily tomorrow.
Human-readable filter option values will likely become an issue though. We should probably consider to introduce an additional tag-to-label mapping, whereas Drupal core would be expected to provide labels for many tags, not only for the tags it uses itself. This mapping would also have to live in .info files, since the information is needed before a module is enabled.
Tags in a multidimensional, modular system.
The usual drama of 2D vs. 3D. Some contributed modules might use a "thing" tag, while some other contributed modules are using a "things" tag. For example:
#227687: Properly capitalize "User interface" package name →
To some extent, this problem space could be combated by a simple/naive Porter-Stemmer algorithm when tags are collected and processed.
To some further extent, Drupal core can help to combat it by providing a good, consistent, and extensive set of tag names; i.e., if there is an existing tag in core, then contrib will use it, too.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
What is this postponed on? Changing to PMNMI for that information. Is this still relevant with project browser and package manager? It may also be replaced by ✨ Replace .info.yml with composer.json for extensions Postponed . Arguably this could move to the "extension system" component, although system.module is what provides the module install form.
