[development] D7 contrib module development

[Daniel F. Kudwien]

> So in my opinion the concern you voice is valid even for D6, 
> it would have stiffled innovation to regulate code committs. 
> But for D7, i believe the goal should shift from having a 
> huge quantity of modules to expandable frameworks for areas 
> like notifications, polls/web forms/questionaires, payment 
> that provide coherent and flexible APIs to obliterate 
> fuplicate attempts of providing the same functionality.
> If it takes a lot of time to migrate certain modules from D6 
> to D7, and just as much time to implement a totally new 
> module for D7 which merges functionality, code and vision of 
> several modules, i (as a student of engineering, specializing 
> in construction and development) *very very very* strongly 
> would support the later choice. It might be difficult and 
> require changes, but in the long run it will be worth it.

That's a nice vision you have there.  But it sounds like you only want to
talk about it.  Merging and rewriting most of those duplicated modules from
scratch (e.g. Notifications/Subscriptions, eCommerce/Ubercart, etc) requires
a lot of development time - much more than simply porting them to yet
another Drupal core version.  To have any effect in the end, it also
requires that all module maintainers agree on the "roadmap", which means
that they will let their own, duplicated modules die in favor of the new,
centralized module.

This has been done before.  Two examples:

- Content profile module is the successor of Bio, Node profile, and Usernode
modules, created after months of discussions between all maintainers,
developers, and contributors of the previous modules.  Given that Fields
(CCK) are in D7 core now, this decision and joined effort for 6.x will
ensure that there is a unique upgrade path to 7.x all developers can work
on.

- Wysiwyg API module is the successor of all client-side editor integration
modules, because someone analyzed the anatomy of all previously existing
modules and thought about a better, generic way to do it with Drupal.
Almost none of the other maintainers and developers ever contributed to this
vision, which is the reason for why the few developers of this project are
completely buried with work, and Drupal users are (even more) confused about
which module to choose/install.  Because of that, we won't have better
Wysiwyg support in Drupal 7 core.


> Yes and no. Each piece of code needs to be written by someone 
> who needs the functionality AND is passionate about it, ACK. 
> But that should not inherently make him the person to solely 
> be responsible for the code. Instead, every code contribution 
> should be subject of a community process in which everyone 
> caring about it reviews and contributes, without defining 
> single individuals as maintainer of a module (though 
> recording the credits for each individual submission).
...
> > Improvement and innovation requires in-depth knowledge about 
> > something.
> True. How does a more swarm-like approach to code committal 
> hinder that? That'd just channel the flow more tightly.

People most often forget that maintaining a project is primarily about
responsibility, once it is in the wild.  Yet another example: If there was
some bad, not carefully reviewed code committed to Views module, then 72,799
sites could go down.

I have seen issues where 10 or more contributors reviewed and gave their
thumbs up, but luckily there was this responsible maintainer who told them
that the entire approach is wrong, followed by the proper way to do it.
That is the primary job of maintainers (gate-keepers) and the reason for why
it is both excellent and required to have separate, specialized knowledge
and vision per project.


> > We have this system already.  It is called "co-maintainers".
> 
> Well it doesn't systemicly solve the problem, as it really 
> just expands the number of stressed individual developers who 
> have responsibility instead of tackling the root cause that 
> makes all this even possible: no enforcement of coding 
> standards, no wider review of changes before committal, no 
> opportunity for improvements to be made before committal, 
> single individuals responsible for decisions.

If a project or maintainer does not adhere to Drupal's coding standards and
best practices, there are most likely no co-maintainers.  The reason is
simple: Without adhering to them, other developers and contributors have
very hard times to fix, improve, and advance on what's there.

Your proposal really boils down to the question whether a project maintainer
is open to improvements by the Drupal community and thereby takes the
required, additional steps to ensure that the community is able to
contribute.  It's about following a certain paradigm - or not.  No automated
process or AI will be able to change the paradigms of humans who do not want
to follow a certain paradigm.


> But looking at how *quality* is at the top of the D7 agenda, 
> it might be a wise idea to apply more pruning and gardening 
> tactics in general also to the modules to _not_ end up in an 
> impenetrable jungle thicket like the D6 contrib area. And 
> swarm intelligence is just the right buzzword to do it..

We can measure quality in contrib (and there are plans to do so), but
putting regulations onto contrib hinders innovation, evolution,
contributions, and lastly freedom.

That said, I was wrong in that our CVS licensing policy is the only
constraint.  Fresh Drupal developers who want to create a new project on
drupal.org must pass an initial code review quality assurance.

Because 99.9999% of all Drupalers are not really aware of that, I want to
take the chance to publicly say THANK YOU to Andy Kirkham (AjK), who does an
awesome job on carefully reviewing a bloat of CVS applications - mostly
alone.  We get several new CVS applications *each day*.  Although there are
a few other community members who are eligible to process CVS applications,
he is the one who takes this on with the required responsibility,
discipline, and motivation.

That's an ungrateful job, because many applicants complain about the slow
review process and in parallel, his hard and time-consuming work is not
recognized throughout the community. :(

Thank you, Andy!  You are one of the most important people for Drupal.
Without you, Drupal contrib would certainly be a pain.

sun