Quoting Steven Peck <speck@blkmtn.org>:
What? This is set to help end user experience. One end users needs are not another's. Too many discrete groupings only serve to confuse and dilute the usefulness of the feature. In any given install there are very very few groupings of modules that will work and play well together in such a grouping.
I agree with this. I also think that unless the maintainer of a module package hasn't been given the value of the package string then the package string value should not be specified. But the documentation doesn't support this.
Dismissing the community experience and the very long discussions we've had planning this as 'merely dev type opinions' is not a correct thing to say. We have had serious participation form coders, UI folks, end users non-coders, support types, etc.
I am not "Dismissing the community experience" I am a fresh newborn Drupal convert reading your documentation and discussions for the first time. I am providing feedback so that the "community experience" can be improved. I am bringing this matter to light (again for some) because in reviewing the provided documention and submitting .info files to maintainers I did it wrong. As well, other more experienced to Drupal, have it wrong. I am trying to get the confusion resolved and the documentation modified to reflect what the value truly should be. I didn't say 'merely dev type opinions' I said 'the dev types that know what it is supposed to represent'. Reading the documentation didn't enlighten me as to what its true purpose was. Reading the documentation and looking at it functioning in the UI gave me my clues. I am both an end user and a dev type.
http://lists.drupal.org/pipermail/development/2006-November/021080.html
Yes, I have read your technical explanation before. It is the end user experience I am trying to benefit. I agree that a module in a package, package grouping, category or what ever it is needs to move to Other if there is only one in the grouping installed in the users environment. I disagree that if I have more than one Taxonomy module package installed that the menu should display both of those in the Other package grouping rather than the Taxonomy package grouping.
Earnie
There are a lot of levels of use here that were hammered out in the initial discussions. This is a step. We as a community need to see what develops out of the initial setup. Now is not the time to leap off the bridge we just built. Just because something leverages the taxonomy system does not mean it cooperates, plays well with or bears anything but a passing relationship to any other taxonomy based module. It just means it needs taxonomy from core turned on. Is this taxonomy module a menu? A section module? A breadcrumb module? A theme module? A forum access module?
<quote>If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here.</quote> Hmm... It uses Taxonomy ... Hmm... That must be the package string value I should use for my package.
Each change in how things interoperate brings us knowledge and experience. So far we have a consistent policy.
It may be an understood among those who have discussed it consistent policy but that policy hasn't been portrayed well in the documentation. Perhaps because the documentation like the policy is a work in progress and only recently has the policy been cast as consistent.
Let's see what we learn from this in the 5.0 release and apply that to the 6.0 release. I suspect that we will learn that this was pretty close to what we do for 6.0 but we'll see as 5.0 will bring us a whole new realm of people, backgrounds and experiences.
I agree. There are enough modules in CVS with info files that you can get a feel for the fact that people are confused about the package value. The affect is rather ugly. There is currently no control. My opinion for 5.x, formulated as we have had this discussion, is that if the package value doesn't fit a known list it should always be listed in Other. Earnie