Re: [drupal-devel] Project management contribs: Bundles: grouped modules.
I like the idea of having a vetting team which puts together a list of recommended modules. This should be nothing more than a list. If they are stored separately or not is unimportant, the important aspect being that someone who was given the job looked at the work and endorsed it. This is not to say that modules not on the "A" list are bad, but they might take more work to install, or are less stable/tested, or are not as actively supported and developed. Most of us on this list would still download them, install them and make our own decisions. Less capable users would rightfully avoid them. I like the idea of bundles too, but only as a way of suggesting to users what works best. This should in no way be an enforced grouping and should only be an alternative way to select modules. Example: image.module and img_assist.module (4.5 versions). Both would be listed in the "A" list, and in a separate list, a bundle called "image bundle" would offer both together, as well as special instructions for getting them both up and running. This approach has several advantages. First, it takes the best parts of everybody's ideas (so far). Second, it requires very few changes to our current system. Third, we have nothing to lose. We don't lose the good modules that everyone likes, and we don't lose the wild ones which can be pretty bad and useless, but like mentioned already, play an important role in the community. In the end, it is a presentation and packaging problem. The two things which we would change to achive this are: 1) set up a vetting committee and guidelines (not too restrictive - shouldn't become a huge political thing) 2) extend our build process to offer bundle tarballs.
I agree about having a vetting mechanism. And I would add that I think you need a regression test mechanism. But picking up on the conversation of ratings: There is a discussion on another mailing list that I am on about the www.omidyar.net site and how they are using reputation points around charitable giving. Things like: http://www.omidyar.net/group/community-general/news/528 I wonder if you might not want to institute a reputation / point system for the vetting process. I have been installing a lot of drupal's lately. Some of the modules drop right in place. Some are flakey and take trouble to fix. I would be glad to vote on these modules. But you want the votes to carry some relative trust or context with them. So that you can identify the appropriate votes that are meaningful to you. Most popular, does not mean most useful. Nor most stable. "Robert Douglass" <rob@robshouse.net> writes: % I like the idea of having a vetting team which puts together a list of % recommended modules. This should be nothing more than a list. If they % are stored separately or not is unimportant, the important aspect being % that someone who was given the job looked at the work and endorsed it. % % This is not to say that modules not on the "A" list are bad, but they % might take more work to install, or are less stable/tested, or are not % as actively supported and developed. Most of us on this list would still % download them, install them and make our own decisions. Less capable % users would rightfully avoid them. % % I like the idea of bundles too, but only as a way of suggesting to users % what works best. This should in no way be an enforced grouping and % should only be an alternative way to select modules. % % Example: image.module and img_assist.module (4.5 versions). Both would % be listed in the "A" list, and in a separate list, a bundle called % "image bundle" would offer both together, as well as special % instructions for getting them both up and running. % % This approach has several advantages. First, it takes the best parts of % everybody's ideas (so far). Second, it requires very few changes to our % current system. Third, we have nothing to lose. We don't lose the good % modules that everyone likes, and we don't lose the wild ones which can % be pretty bad and useless, but like mentioned already, play an important % role in the community. In the end, it is a presentation and packaging % problem. % % The two things which we would change to achive this are: % 1) set up a vetting committee and guidelines (not too restrictive - % shouldn't become a huge political thing) % 2) extend our build process to offer bundle tarballs. % ----- John Sechrest . Helping people use . computers and the Internet . more effectively . . Internet: sechrest@peak.org . . http://www.peak.org/~sechrest
participants (2)
-
John Sechrest -
Robert Douglass