For module projects, there should be an auto-complete field to allow project maintainers to list similar modules.

This data should be used to provide a link in the "Resource" section on the project page to "Compare Similar Modules" with data such as:

  • Date of first Release
  • Last Updated
  • Usage
  • and any other automated data which can be useful in module comparison

In addition, this should encourage developers to work together.

Files: 
CommentFileSizeAuthor
#4 Views Related Project.png92.55 KBphilbar

Comments

I like it.

Perhaps, though, ordinary users should be able to add to the block.

i totally agree with this idea

additionally, other features could be implemented on the project data, as listed in these issues for Upgrade Status module:
http://drupal.org/node/936628 (see the drafts >=0.3)
http://drupal.org/node/937738

they are mostly relevant to an upgrade path for future releases/upgrades of drupal, but also comparisons of modules.
these could be project release XML tags, but also general project XML tags.

i'm throwing some more in this issue along with those:
(on the left, the XML tag names; in the middle, which info goes in; on the right, how this info is inputted from the UI)

  • companions: projects which are good companions to this module (related features which integrate well, but don't overlap with the module) - autocomplete, multiple values
  • similars: comma-separated list of projects which are similar in functionality (better or not) - autocomplete, multiple values
  • alternatives: projects which are alternatives in functionality (same or better) - autocomplete, multiple values
  • recommended: projects which are the recommended upgrade/alternatives to this project (the best alternative or more if required) - autocomplete, multiple values
  • activity: active, supported, unsupported, abandoned, deprecated, no info (noinfo) - selection box
  • priority: required, optional, critical, no info (noinfo) - selection box
  • portability: in core (incore), ported backward (portbackward), ported forward (portforward), ported forward extras (portforwardextras), ported major (portmajor), being ported (beingported), no port (noport), no info (noinfo) - selection box
  • versioning: stable, unstable, outdated, in development (dev), no info (noinfo) - selection box
  • feature: test module, data manipulation, content rating, permissions page helper, top menu, dashboard, admin sidebar, etc ... - autocomplete, one value, users can input anything or pick from what is autocompleted
  • notes: release notes - textfield
  • urls: urls with more info (like issues, bugs, how tos, help, etc) - multiple URL fields, like in cck, with their description

multiple values would be stored as comma-separated values inside the XML tags (most cases) or as multiple elements (urls with descriptions).

this way, since they are outputted to XML (example views 6.x), they can be read by modules like Upgrade Status or by Drupal itself.

from the drafts i wrote before:

<version>6.x-3.x-dev</version>
<companions>extras_for_test</companions>
<similars>test1,test2,test3</similars>
<alternatives>test4,test5,test6</alternatives>
<recommended>devel,core</recommended>
<activity>active</activity>
<priority>optional</priority>
<portability>forward</portability>
<versioning>dev</versioning>
<feature>test module</feature>
<notes>"<p>Hello world</p>"</notes>
<moreinfo name="upgrade-info" url="http://www.example.com/node/upgrade" />
<moreinfo name="known-bugs" url="http://www.example.com/node/bugs" />

also, a main category for modules.
the ones that show on Module Categories at http://drupal.org/project/modules

those same categories should be mapped to a short string, like administration, wysiwyg, etc
and be outputted with the XML file as well, perhaps as <category>administration</category>

possible use cases of this category tag:
- filtering modules by category in drupal or upgrade status module
- installing modules inside the corresponding category name at /sites/all/modules
- could also be applied to themes and other project types

for the second use case, there is no problem that i know of. example: /sites/all/modules/administration/admin_menu
i have made setups following that idea, with hundreds of modules, and never had issues.

examples of short name categories and their directories (custom made, not based on drupal project page):
Administration -> administration
Advertising -> advertising
APIs -> apis
Backup -> backup
Blocks -> blocks
Browser -> browser
Calendar -> calendar
Debugging/Development -> development
Content Display -> display
Content Forms -> forms
Evaluation/Rating/Voting/Sharing -> evaluation
Feeds -> feeds
Fields/Content Fields/CCK -> fields
Files -> files
Filters -> filters
Gallery -> gallery
Geography/Maps -> geography
ImageCache -> imagecache
Integrations -> integrations
Interface/UI -> interface
jQuery/Javascript -> jquery
Mail -> mail
Menus -> menus
Multisite -> multisite
Node Management -> nodes
Organic Groups -> ogroups
Other -> other
Overlays -> overlays
Performance/Caching -> performance
Permissions -> permissions
Players -> players
Profiles -> profiles
Projects -> projects
Roles -> roles
Search -> search
Security -> security
SEO/Search Engine Optimization -> seo
Shopping/Commerce -> shopping
Slideshows -> slideshows
Spam -> spam
Statistics -> statistics
Taxonomy -> taxonomy
Theming -> theming
Translation/Language/Multilingual/Internationalization/Localization/i18n -> translation
Uploaders -> uploaders
URLs/Paths -> urls
Userpoints -> userpoints
User Management -> users
Utilities -> utilities
Views -> views
WYSIWYG/What You See Is What You Get -> wysiwyg
...

StatusFileSize
new92.55 KB

Perhaps we should also look to make the "Related Project" block better with this issue. See the attached image...not sure how the algorithm works, but it isn't real accurate for the Views module.

Taking part of LPCA's suggestion, maybe we could replace the current "Related Projects" block with a community generated block (wiki-like) with two sections:

  • Similar Modules
  • Companion Modules

This new "Related Projects" block could default to a link with this text "This Information is editable, please add some." which would direct drupal.org users to an page with two autocomplete fields: "Similar Modules" and "Companion Modules". Once the data has been added by a user, it will replace the long default text with a small "Edit" link with the user generated data cleanly displayed.

EDIT: The new d.o apparently doesn't have a "Related Projects" block, so maybe a link in the resources would be the best option to display this data.

Much needed. Subscribing.

not sure i mentioned yet, but if each project stores this kind of information and it is sent inside the XML files when requested by drupal installations, you can do much more than Blocks in drupal.org

modules or drupal itself could use all of that information, plus external sites that dig into updates / modules at drupal.org

the best example of a module that could use this information is Upgrade Status module.
Update module in core could also benefit from this, as well the Module/Theme installer in core, and other related modules.

two interesting and related modules:
http://drupal.org/project/module_supports

This module shows how modules can be enhanced by or enhance other modules by using information provided in module .info files (implementation of #328932: Modules and partial dependencies - "Enhanced by" field in modules .info file).

The following are all the supported directives:
dependencies[] = modulename
recommends[] = modulename
suggests[] = modulename
enhances[] = modulename
breaks[] = modulename
conflicts[] = modulename
replaces[] = modulename

This information will most likely be used on the redesigned drupal.org, so start implementing this now in your own modules!

did this lead anywhere?
http://drupal.org/project/module_order

Module order provides a way for a module to specify whether it should be loaded before or after another module.

To use the module you simply add a "before" or "after" key to your .info file like so:

name = "My Awesome Module"
core = 6.x
before = less_awesome
after = pretty_awesome

The original idea for this module was described to me by David Strauss at DrupalCamp Austin

wondering what the future awaits :P

Glad I found this thread. I have similar thoughts all the time, and I love the way this discussion is going. Subscribing.

Issue summary:View changes
Status:Active» Closed (duplicate)

We are working on cleaning up Drupal.org-related issue queues. Many issues have been open for years with no resolution because there were no volunteers interested in taking on the task or staff time available to complete the work.

We are going through old issues and marking them as Closed (won't fix). If you feel your issue has been closed in error, please do comment on the issue and let us know. If we know something is critical, we may reconsider the closure of a feature request or bug report.

Thank you for your understanding while we work to clean up the Drupal.org queues.