[development] D7 contrib module development

[Marcel Partap]

> There lies the fallacy. I don't believe there is any 'one best
> solution' for most given problems, especially in Drupal.
No, but what is possible is to come up with an algorithm that leads to
a statistically significant improvement on the sustainability and
correctness of decisions.

> Which is better: a simple solution that gives a few features out
> of the box, or a highly configurable, extensible solution that
> requires multiple configurations before it can be used?
Well you asked for it: better is an extensible framework which does
what 80% of the users want in the minimum/default configuration, and
can be expanded to all other use cases by activating extra modules 
(just like cck, i18n, views, xmlsitemap..).
To have different code for simple and complex use cases is what i
consider to be the worst case.

> It depends on the site being built and on the site builder. In the
> realm of email subscription modules, for example, the needs of an
> internal documentation site versus a public news publishing site
> are very different.
So a notification framework clearly needs a lot of clever thinking to
come up with a structural design that scales from small and simple to
huge and complex. That's why brainstorming on it has to start soon ;)

> Likewise, Site builders who are coders are going to be drawn to the
> module that describes itself this way:
>
> "This is a complete Subscriptions/Notifications Framework aiming at
> extendability and escalability. It allows any number of plug-ins
> defining new event types or subscription types or a different user
> interface."
>
> Site builders who are afraid of PHP will drawn to:
>
> "This module allows users to subscribe to periodic emails which
> include all new or revised content and/or comments much like the
> daily news letters sent by some websites"
>
> or, if they already know the drupal lingo and need more power,
> maybe:
>
> "This module enables users to subscribe to be notified of changes
> to nodes or taxonomies, such as new comments in specific forums, or
> additions to some category of blog."
So the solution would be two frameworks:
"Hi, i am the messaging framework and responsible for handling all
communication. You can enable different sub modules for mail, sms,
jabber, twitter, smoke signaling according to your needs." and
"This module is for handling change notifications of nodes, fields and
comments. By itself it does not expose any UI."
plus the correspondent modules building on that:
"regular notifications UI - user interface to enable intervalled
updates for all types of subscriptions"
"change notifications UI - notify users when an Drupal object changes"
"advanced subscription settings UI - provide UI for more precise
control of content subscriptions"
(something along these lines, i'm sure many people more experienced
with this stuff than me can do better)

> Duplicated modules aren't necessarily competing modules.
Disagree.
> I think it's good to have different modules focused on meeting the
> needs of different audiences.
Yes, but the clever way is to make them share code. Just like all the
.DLL and .so files on your computer, which are frameworks that
provide a broad variety of special functions for applications to use
a selected lot of them.

> One size does not fit all.
No, but reimplementing basic functionality multiple times in
incompatible ways is not exactly the clever approach either.

> It was suggested that some duplicated modules exist solely to feed
>  developer ego. That's not the most flattering way to put it, but
> I have noticed that being the maintainer of a module does lead to
> business inquiries; I'm not keen to give up the publicity.
Well the mission of drupal should definitly not to feed module
maintainers, but to strive continuously to be the best open source CMS
in existence. So this really shouldn't be influencing the decision.
Furthermore, my proposal did state that each module collects the
credits of its contributor, and i am sure we can find ways to give
hard working coders some publicity. Ever read the KDE commit digests?
They have some nice statistics at the top (people with most
commits/bug fixes/buzz)...


> One possible solution to this would be to have project pages list
> all the committers for a project, and not just the one owner. This
> would increase the value of collaboration and decrease the
> hesitation for developers to let a module die in favor or a new,
> truly better solution.
Not invasive enough. In my opinion, bold steps will result in better
results here. Trying to _promote_ a certain way of doing things or
specific values does not seem to work well enough.

Still voting for 'let the swarm maintain the modules', 'improve
code-centric tools and communication' and 'tightly enforce quality
standards for the official D7 contrib repository' here.
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