[development] D7 contrib module development

[Marcel Partap]

> 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
> experiment
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 
modules?

> 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 
their patch?

> 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