[development] D7 contrib module development
mpartap at gmx.net
Mon Mar 9 16:52:02 UTC 2009
> It is not a negative to have unmaintained modules and such, given that
> others are thriving.
Well what if unmaintained/bad modules are sucking the time of users
and developers and annoying them for no good reason? Not negative?
> How could it be integrated with other modules, what could be
> factored out into 'frameworks' (/library modules) ?
> It happens naturally.
Very well. But there's a reason bioengineering is the latest hype: it
is a lot FASTER and more DIRECTED than the evolutionary process.
> What I am saying it happens naturally as people realize that they are
> evolving their pet project into an API/Framework over time.
At our university we are taught: the more brainwork you invest early
on in the development process, the less headache you'll have to cope with.
>> Sure. But what is the prior goal of the Drupal project? To create a
>> healthy vibrant community? Or to create the best open source CMS
>> CODE out there (best accomplished through a healthy vibrant community)?
> The vibrant community leads to the best open source CMS code.
No, not by itself. It needs some structural algorithm to have things
develop into that direction.
> You miss the fact that this is an ecosystem, and you have all kind of
> relationships: symbiosis, parasitism, commensalism, ..etc.
If they interfere with the creation of top-most quality code - they
should be prevented from doing that. If people can make money offering
drupal services to customers: fine. Should the development process of
an open source project try to facilitate that? I don't think so.
> You can't dictate what happens in contrib without stifling the
> innovation that this ecosystem has.
Who's talking about dictating.. Everyone can code freely. But for code
to enter the official repository, quality checks should apply. That
doesn't stop innovation, does it? Look at the few commits to the
cck/views branches for example. Why is that kind of responsible code
committing not scalable to all other modules as well?
> We can nudge people to work together but we can't force them to.
Well not many people who score goals by hand have made successfull
career in football. How comes? Might it be that whoever doesn't
respect the rules will not be allowed to play?
>> I want to have *all* the functionality spread over slightly
>> different modules with the same purpose, combined into one flexible
>> solution. And i am quite sure i am not the only one.
> You are advocating the "one true way".
Am not. What i am advocating is a process that makes problems that
occured in the past less likely to happen.
> But without letting people
Why is not letting experimental code into the repository stopping
people from trying stuff out? Please explain that to me, i simply
don't get that.
> that one true way could be the one with less features, with
> a non-committed maintainer, could be buggy, ...etc. You don't know until
> you put it out there and let the ecosystem decide.
> Who will decide the one true way? Committee? Hierarchy?
No - the swarm, that is us. We all work together on finding the best
way to lay the foundation for the respective functionality. Aren't we
already doing that with core? Is it impossible to apply to non-core
> What we can do is let things evolve for a while and then naturally a
> winner or two will emerge from the fray.
So please tell me, what is the winning change notification framework?
Notifications, Subscriptions, Comment Notify, Notify, ...?
Which is the best module to create sophisticated web questionnaires?
Is it webforms? Advanced Poll? Decisions?
Do you really want to have the same situation with D7? Not terribly
user-friendly, is it?
> As disconcerting this is to
> some, it is a sure way to have a proven solution for the problem space.
Is not. It might be sufficient, but it surely isn't the optimum.
> No. I am saying is that without seeing people contribute for some time
> you don't know before hand if they will turn to be a drive-by
> contributor of a so-so project, or the author of the next big hit.
Why is applying quality checks before applying code to the official
repository making it harder for people to code, experiment, innovate?
How does having each submission routinely reviewed by the community
stop anyone to contribute?
> All that cannot be seen just from the first contribution adherence to
> coding standards.
Whos talking about judging people by their first code? But what is a
good reason for the first contribution of someone starting to learn
drupal to be included in the official repository? Wouldn't it be much
more helpful to receive comments and tips in the discussion thread for
> Fair point, standards will arise across CMS's too
Didn't even touch _that_ topic.
> But within Drupal, I don't see we are the point where we have a central
> body .
Well i didn't propose a central committee, but for the whole community
to pick up quality checking and maintain the modules as a huge diverse
team. Sounds implausible? Well who's stopping us from trying.
> Later maybe? Perhaps. But not now. When you see a majority of the
> community cry for that, then it is time to re-evaluate.
At the time people are crying it usually is a bit late.
> rgds marcel.
"Obstacles are those frightful things you see when you take
your eyes off your goal." -- Henry Ford (1863-1947)
Change the world! Vote: http://hfopi.org/vote-future
More information about the development