Project Hierarchy For Contributed Sub-Modules

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

What's your idea?

Implement a hierarchy of modules. For example, allow a module maintainer to specify that the module is designed specifically for xyz module. Let's take the Commerce module as an example. There are countless modules for the Commerce project, but trying to find and filter for the modules that only work with and were specifically designed around Commerce, is near impossible and extremely time consuming. The most efficient solution is for the Commerce Guys to create their own website and list all of the modules that are designed around it, at which point they point back to D.O. That is only one of a handful of projects which takes this approach. What about the countless other modules that have no central point of interest? That leaves us as users with the only option of pouring over the countless unorganized list of modules on D.O.

What's your idea?

Implement a hierarchy of modules. For example, allow a module maintainer to specify that the module is designed specifically for xyz module. Let's take the Commerce module as an example. There are countless modules for the Commerce project, but trying to find and filter for the modules that only work with and were specifically designed around Commerce, is near impossible and extremely time consuming. The most efficient solution is for the Commerce Guys to create their own website and list all of the modules that are designed around it, at which point they point back to D.O. That is only one of a handful of projects which takes this approach. What about the countless other modules that have no central point of interest? That leaves us as users with the only option of pouring over the countless unorganized list of modules on D.O.

What are the benefits?

Finding sub-modules that are designed specifically for a particular parent module, reducing the time needed to find the same modules which are scattered all over the place. It will also open the door for people to find modules that would otherwise never be found. It will also help reduce the "duplication of modules" that seems to be very common among maintainers who spend a little bit of time looking for a module to do what they need but cant find, so they re-invent the wheel.

What are the risks?

Getting existing module maintainers to update their projects.

How can we measure the impact of this idea? (metrics)

Implement it for a small set of modules like Commerce, Views, Panels, Webform, etc. that are known for having countless sub-modules to see how it is received.

Who directly benefits from / will use this improvement? (target audiences)

Site developers searching for modules to use for their sites.

Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)

For the most part, I believe a simple taxonomy with hierarchy to tag the parent module would be sufficient. On the parent module page, a view or link to a view page that would list the sub-modules which have been tagged would work quite well.

Additional Thoughts

I believe there is already an issue queue for this request but finding it is like looking for a needle in a haystack... If you know of the issue, feel free to post a link in the comments.

Drupal.org 2014 roadmap brainstorming

Group organizers

Group categories

Difficulty to implement

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: