Hi Bèr, I think you slightly misunderstood my suggestions. Basically my ideas was just the same as Károly. 1. well controlled set of modules, listed for download with Drupal. 2. 'wild' modules, that are listed elsewhere. I just feel that if you try to control /everything/ to much, it stifles creativity, and people loose interest. So the answer, control a set, and let the rest free. Like I said, the best of /both/ worlds. It is easy to criticise all the half-finished modules, however this is where the ideas get worked out, and they end up being the basis for what /is/ kept and made 'standard'. more comments in message below... Bèr Kessels wrote:
That diversity is nice. But ATM that diversiti leads to a large diversity of not-finshed and not-perfect modules. Why cant we have one good set, instead of four unfinished ones? Answer is easy: because after scratching your itch, you are done, and the module is "dumped" in contribs. But other will have other itches. I am suggesting we stop scratching, and invent a "jar of crême" (i.e implement a management system) that will solve the itches too. Because scratching might help for that moment against the itch, that itch itself wont be solved.
So: I dislike the model of diversity a lot. I know it is a common OSS problem. But without clear structures and management a lot of work is duplicated, even more work/time is wasted etc.
I think is possible to have /both/ the diversity /and/ 'one good set', why not?
- Being able to share 'special case' modules is a valuable dynamic of the Drupal community (even if they are not all compatible).
Yes true, but does that need to be on drupal.org? maybe, but in a sandbox or separate area, it should not be part of official downloads
What I meant by my suggestion /is/ to put them in a different place. So I agree.
Will special cases be maintained? most prolly No ,because the itch is scratched. How many special cases actually ever make it into maintained modules? Harddly any, nearly all the spacial cases are old, broken and must be removed after a new release. Its those nen-special case modules that survive.
This is normal, not a problem. They do help start the process of development towards a more general solution. Even if they do not last forever, they do solve an immediate problem for some people. When you have a deadline to develop a website, there is no time to develop such elegant general solutions. Sometimes a 'quick fix' is the right way.
What I think would be good would be the creation of two classes of modules: 1. 'Official' modules 2. 'Contrib' modules
Can be combined perfectly.
Not sure what you mean? I was trying to say that I think it's a good idea for them to be separate.
This would combine the best of both worlds - *Diversity*, and *Quality*
I think the core should stay 'lean and mean', then site admins (or 'distribution' providers) can customise the functionality of their site by selecting from trusted 'official' modules. Those who have particular special needs, can choose to develop their own modules, or make use of the shared 'Contrib' modules.
We should keep core out of this. This regards only contribs. Lets not aim too high. We will deal with core later, if ever.
I was not suggesting anything should be different with the core. I like the way the core is.
As I said before, I think bundles could be a good idea (if managed well), but I personally don't think it will solve the problem.
Other ideas to think about: - module rating system
-1. This will really not solve: * maintainability. * duplication of effort, APIs, code and features. * amoutn of modules contributed. It will *only* show what modules are more popular, /if/ it will show us anything at all. How often do you base your choise of a module on popularity. I never did, and never will. Based on quality, yes.
Just for the non-official contrib modules, not for the high quality integrated modules. You can't tell me that you do not use the ratings on sourceforge.net to help you find software.
- module popularity system
See above: -1, since It does not solve the issues we are discussing here.
As above, I think it's a good idea. But as you say, it's a separate thing to worry about.
- dependency/conflict management (package management style)
Yes, but that is aiming very high. I do not beleive this will get in soon, if ever at all.
I just gave the last 3 ideas as future ideas, to help with thinking differently about the approach.
Regards, Bèr
Regards, Ross