Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.With the ever-increasing, already overwhelming amount of contributed modules, Drupal.org could do well with a "collaborative categorisation" with more direct feedback for all those that are either strangely categorised or just pile up under "Other". (btw, I agree with whoever suggested to rename "Other" to "Uncategorized" somewhere in these discussions.)
I think that we should explore how we can integrate the modules page category related search features with data on d.o. so that the related ongoing content management becomes less daunting. Using our own tools to eat our own dog food, so to speak.
If implemented well, this should be valuable for further improvements on d.o. as well.
Ref. the discussion in the following issues:
- #1348692: Vertical Tabs for the Modules page, comment #6 by eigentor: "Totally agree with the reorganization of categories being necessary."
- #1355292: Come up with better alternatives for groupings on the modules page, comment #21 (and #2) by webchick: "If we're going to do categories, let's please re-use the list on Drupal.org. No sense in developing two separate taxonomies for modules.
" - Related feature request by webchick: #1355358: Allow searching for modules on Drupal.org from the modules page
- Main thread/overview: #538904: D8UX: Redesign Modules Page
The essence of these discussions deals with:
- finding available, perhaps disabled modules, on the current Drupal site, including the case where you dont know exactly what you are looking for (namewise) - as for newbies, etc.
- finding modules of relevance to the locally available modules, through extended search into the metadata at d.o.
"Categories" are a natural extension of "searching"; as Taxonomy terms they are extremely useful as filters that help narrow down searches, in particular at the stage before you know exactly which words you will/should search for.
Search and Categories belong together, at the same place in the user interface of the module page.
Concerns to address:
- The usefulness and logic of the existing metadata (category/project name/package/groupings)
- The challenge of dealing with a categorisation scheme that is prone to changes and likely to grow not only in amounts of modules, submodules, but also the top-level "category containers" themselves will change over time. New web services will appear, new modules will be made to support them, new categories added for this, etc.
- IMHO, it will prove close to impossible to deal with all this in a practical way without filtering on some d.o. metrics based on such parametres as stable-release, popularity, quality-stamps like inclusion in major distributions, maintainer activity, maintainer "rating", etc.
We really need to deal with this dynamic data in ways that does not get us deeper and deeper into the mire as the amount grows. The best (and most exciting, in fact) solution I can think of is to leverage one of our greatest assets: the community itself.
Example:
An (separate/optional?) "update modules"-style function on the modules page that could connect to d.o. and EXCHANGE new "updated" category information. Site administrators could enter new category suggestions directly on a text field beside each module on the module page and both have it sent to d.o., but also fetch "most used alternative" categories from the data that d.o. has already collected about the module in question. If these category words were searchable, then people could find new/related modules from right within their own module page. Although I personally find the current "Related modules" block on d.o. mostly illogical, surprising and confusing and thus IMHO very ripe for renewal, that kind of information could also be used in context of these searches, in another form. I think that we should collaboratively "suggest" related modules, and through "automated popularity counts", such relations could be dynamically set, updated and syndicated.
So, this involves improvements on two fronts:
- module page search functionality in Drupal core + metadata service(s) at d.o. (drupal.org)
Comments
Comment #1
webchickJust flagging that there are pretty significant security concerns if we want to make this a two-way exchange.
If it were one-way only, the existing XML feed that update status provides could likely just be expanded with this data.
Comment #2
Taxoman CreditAttribution: Taxoman commentedyes, I expect that this suggestion will need to be worked out into a plan consisting of several steps.
The d.o. end of this is a major undertaking, that also touches on a broader strategic view about d.o.
I am considering a GSOC project proposal for this.
So short term, I think this should be started with the data and services that are already available, and design the modules page to connect to that first. However, I think it would be a good thing to outline a direction and gather momentum for that very early on, so that several efforts can support each other as we move onwards. I hope the discussion in this issue will develop in such a direction.
This may also touch on some revenue-generating opportunities for d.o. regarding data mining related things, which I think should be led by the D.A. I am going to do a separate post about my ideas for that later.
Comment #3
mgiffordThis is a problem that has only grown since 2011.
Perhaps a simple option to suggest a related module might work.
Comment #4
lpalgarvio CreditAttribution: lpalgarvio commented