Modules are grouped on the module administration page (admin/modules in Drupal 7) by Package. Sensible grouping can greatly enhance site builders' Drupal experience. (Package is defined, optionally, in our module's .info file.) As developers of contrib modules, we can come to this wiki page before choosing our package name to see what other thoughtful module developers have chosen for their package. [Note: the wiki page is now envisioned more for documentation than guidance for now.] Then, after we choose an existing package name or decide a new one must be created (or propose a new package, hoping to reach critical mass to break out of the "Other" ghetto), we record that here. Sprinkle the magic dust of collective intelligence and maybe we'll have an elegantly ordered list of modules on every user's Drupal 7 site.
Packages with no parenthetical comment are implicitly endorsed, so please flag questionable categories. Please keep all lists in alphabetical order.
Comments
Issue?
Is there an issue that goes with this to discuss changing the current best practices?
(source)
This has been an ongoing debate for a while and people have added "examples" to that page that violate the instructions because they disagree with them but, as far as I know, there has been no issue filed to get the guidelines changed. I'm -1 to the idea and prefer packages be used as they were originally intended and I know others are as well so this needs to be discussed.
Michelle
agree with both of you? :)
I think there's a place for both of these perspectives.
If we can get module developers to agree on the names (It's got to be both words: "Organic Groups" btw) then we will make sure that when a typical site is setup it will have 4 modules in each category.
"As a guideline, four or more modules that depend on each other (or all on a single module) "
I think that part of the guideline is a bit flawed. In my opinion, it's not so much about dependency but about the likelihood that they will be installed together. Dependency ensures they will be installed together, but we can make some good guesses about likelihood of co-installation.
SEO seems like an example where if someone is going to install 1 or 2 of the modules they are likely to install enough to make it worthwhile to put them in a group (perhaps called "Search Engine Optimization").
The other part of that guideline as I've heard it is "If you have less than 4 items then they are not a good group. If you have more than 12 then there are too many and they should be split into a group." The "Other" package clearly gets into the "more than 12" category far too often and we should see about cleaning it up.
knaddison blog | Morris Animal Foundation
.
I think maybe this argument comes about because people use the page differently. I never look for modules in a category. If module is big enough, I know it will have it's own group and go down alphabetically looking for the group. If it's a smaller module, I know it will be in "Other" so I skip down to that and scan that list which is also alphabetical. When someone decides their tiny little module belongs in some other category, it throws me off and I resort to ctrl-F. And that is a pain if there's a lot of depends on / required by parenthetical mentions.
Personally, I only want to see groups when there are a lot of submodules included in the same tarball so when I see some mysterious module I don't remember downloading I can clearly see it came with a larger package. Other than that, I'd like the whole list to be alphabetical so I can just whip down to the right letter and find it.
And I still think this discussion should be in an actual issue rather than hidden in a rather obscure group...
Michelle
About an issue, Which queue
About an issue, Which queue would we put it in? I'm not sure it would be more visible for the right people there than here. We can/should summarize discussion that happens here first into the issue.
I agree with your description of the problem here - we're defining a page for both the first times people find it (in which case separate groups are good) and advanced users (in which case one big list feels better). There are two or three contribs that change the layout of this page a bit, it might be worth investigating those.
knaddison blog | Morris Animal Foundation
.
Well, since it's about changing existing documentation, I guess webmaster's. Unless there's a more specific queue for the d.o handbooks?
I just think it's putting the cart before the horse to be deciding what to name the groups before there's any sort of decision on changing what is now documented as best practices.
Michelle
Module maintainers are naming packages already
Whether this page exists or not, module maintainers are already naming packages. I've only been looking at Drupal 7 and i guess i should be explicit that that's what i'm doing– i'm not suggesting any names, just pulling package names from modules that have been ported to Drupal 7 and from the suggestions on the documentation page (which were sorely out-of-date and somewhat contradictory with the documentation). I do feel that Administration and User Interface have established themselves as legitimate categories, like Development had, and authors of new modules should be able to see that.
This page gives us a chance to suggest one-shot module get back in the Other category, or to file an issue in the Organic groups queue (note that, per Drupal capitalization standards, that should be the module name) to stop using Group as a package name.
Feel free to change the wiki page's introductory text, but i think that the need to catalog what is being chosen (which could technically be automated) and for all of us to be able to provide feedback on it (which strongly suggest a wiki page) is pretty overwhelming.
Update – i just realized that this is not a wiki page, is it? If not, i messed that up.
Also Michelle i definitely understand your downloaded-together-only packages sentiment, but that's not policy either. Indeed, that one could probably literally be enforced by the packaging script?
benjamin, agaric
.
No, my preferred way isn't policy; it was just an example of a dissenting viewpoint. My point is that you are suggesting naming conventions that are against the current best practices as listed in the handbook. The fact that "other people are doing it" doesn't change that. Other people speed but that doesn't change the speed limit.
All I'm saying is that the rules should be decided first before spending a lot of energy coming up with naming for a practice that is currently discouraged.
And, no, this isn't a wiki.
Michelle
Moved to wiki page and noted current policy
The package list is now a wiki, and i noted the current policy (such as it is) and linked back to this discussion. If an issue is found or created, we should link to that.
Michelle, your points about the limits of control+F given dependencies is well made. (If Module filter searched on system name as well as public name and perhaps description – and it were put in core – i think my usability concerns would be best allayed that way.
Also, i now know, the category of what came in one download is created automatically as the project directive in .info files, but that information is not exposed to the user interface at all. Grouping by package, then by project, would be worth considering for Drupal 8– right now modules in the same project can give themselves different packages.
I do think package names should be used for sensible categorization of modules, developed in a collective process on something like that wiki page. (Personally, i further think all Commerce-related modules should be in one package, even if there are 97 of them, which is also against current policy; but as Greg pointed out, having four categories for Commerce and dumping everything else in an other category of hundreds is pretty hypocritical.) My original motivation was that the examples listed in the package section of the .info documentation page itself seemed contradictory to policy and where in any case out of date, and that as long as examples were to be given a more inviting, living document than a documentation page should be provided. However, i have tried to clarify that the wiki is descriptive, not prescriptive, and that current policy likely means your module is "Other" and should not define a package.
benjamin, agaric
added some suggestions to the
added some suggestions to the wiki
http://groups.drupal.org/node/97054
Luís Pedro Algarvio
Drupal and DevOps Developer, Evangelist & Trainer
lp.algarvio.org
Sorry, but Nonsense!
The topic needs to be resolved in Drupal core. I know there is at least one open issue against Drupal core for this, but can't find it right now. Might have been moved to Project or Drupalorg project.
http://drupal.org/node/542202 is pretty concise regarding the usage of package, although it seems to have been blurred by the addition of the second paragraph and the wiki page.
All of this was never intended with the "package" declaration in .info files. What we're currently seeing is an attempt to abuse a package system that was never designed for categorization.
Needless to say, that fails, big time.
Daniel F. Kudwien
netzstrategen