The nice thing about the subscribe commenting system was that the project maintainers could see how many users were interested in the issue; granted, the "follow" button was a major improvement for the focus of the issue. Adding a count of the number of users following any particular issue (perhaps next to the button) could help the maintainers reprioritize their approach to the issue queue, especially in regard to feature ...more »
In the same way in our Drupal Installation we can see what modules are required for a specific module and what module use a specific module. Could be good idea put couple blocks in a project page to show how modules are tied, because can provide to site builder an idea how strong are modules and how get examples about how to integrate this module in a custom implementation. For instance in services module/project page, ...more »
We can follow issues on individual project pages, but I'd love to be able to follow project releases/builds. I.e. it would be easier to have a list of projects that I was following rather than having to look through a myriad of project pages that I'm interested in.
I would like to propose a way to flag projects and issues as favorites, so I easily could find pages of interest when building next site. Also, filtering on those, so I can either show all my favorites, or none when I look for new modules to mark as favorites
The coder module carefully checks whether a contributed module conforms to the Drupal code comment standards. However, Drupal.org is not doing anything with the code documentation. Perhaps automatically generated API docs can be generated for modules with a sufficient level of conforming documentation, much like PEAR does for its projects.
Because projects are also nodes, they feature a "Posted by" line at the top of the page. Especially for old projects, where the original maintainer may have stepped down, this line adds no information to the page.