[development] D7 contrib module development

[Marcel Partap]

> Change requires to take some action.
That's what me taking the initiative was all about ;)


>>> Bad habit of module authors.  Slap them, but create a patch to
>>> remove what has been duplicated afterwards.
>> Yeah like i even have multiple days each day - sorry i simply can
>> not fix stuff beyond the needs of my NGO site. If the development
>> process allows module authors to have bad habits - well maybe its
>> not tightly regulated enough.
> We have several handbook pages that outline coding standards and
> best practices.  You can simply put it this way: Developers who do
>  not adhere to them do not want that anyone contributes to their
> modules. To be realistic, we can't regulate more than regulating
> that any code in CVS is licensed under GPL.
Yes we can. We can set up a clearly defined landing path for code
submissions.

>>> Removing the duplication requires that those module maintainers
>>> (finally) come to that conclusion.
>> That seems far less realistic than setting up a strict
>> regulatory bottleneck for every line of official core/contrib D7
>> code. Take a look at how extremely discerning the benevolent
>> dictator of the Wine project - Alexandre Julliard - handles the
>> many code submissions from wine-patches - and at the resulting
>> quality. There's a reason he skips committing 30% of patches.
> ...which prevents innovation.  At least one of my modules would not
> exist today if it would not have gone through 1 year of quality
> assurance and testing, becoming one of the most popular Drupal
> modules in the end.
Does not. A lot of stuff has been tried already for D6 - for D7
everyone and his dog should have made the experiences from which we
can benefit, especially about which design decisions cause maintenance
problems later one.
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.

>>> Core developers are already buried with core development. Take
>>> a look at issue queues of "sub-core" modules like Views and
>>> you'll understand that each project needs its own code-guards.
>> That very well i know. Maybe we can all improve the process and
>> optimize the obligatory set of tools?
> The issue is not the tools, but the brains and time of
> contributors.  Each and every module needs people who "love" a
> module and can spare a fair amount of dedicated time to think about
> and work on a project.
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.

>>> Machines can not (yet) replace the complex thoughts and
>>> decisions of a human.  If a patch passes some (human-created)
>>> tests, that only means a) it passed an expected behavior (which
>>> still can be wrong or outdated) and b) it passed coding-style
>>> tests (if there were some) - but there still has to be a
>>> gate-keeper who tells you about logic errors and the future
>> of Drupal. Of course not - but if the automated tests pass, AND
>> 10 registered Drupal developers okay the patch by voting RTBC -
>> for sure a commit bot can take the decision to just do it? My
>> guess: swarm intelligence + sophisticated tools outperform
>> stressed individual core developers.
> 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.

To clarify here's how it could work:
- erection of drupal-patches mailing list for all code to pass through
- coupling that mailing list with a revised patch tracking system
   - patch submissions to the ML create a patch issue
   - comments to the posting get also attached to the issue
   - in turn, patch issues file through the web interface are echoed
     on the ML, just as comments to it
   (similar how to what the mailman/mailhandler modules.. i hereby
    step up for a clean reimplementation of this functionality)
- inserting a voting system into the patch issue tracker
   - two choices: 'ready to be committed' or 'veto'
   - core developers' votes get higher weight, can clear 1/2 veto votes
- having the patch issue tracker DISPLAY the code by default
   additionally to providing it as attachment
- setting up rules and regulation (proposal)
   - developers get awarded D7 svn rights by either landing more
     than 1K of code or 10 commits in core, or by being promoted
   - all code *has* to be either committed by these developers or
     has to get 10 RTBC votes with no vetoes
   - all code going in has to at least break no tests AND
   - all code is automatically tested for adherence to coding standard
   - patches can -and should- be improved by all who care until 10 RTBC
   - code contributors are recorded in each modules changelog / AUTHORS
- several frameworks have to be put in place for D7:
   - messaging / change notification
   - polls / web forms / questionaires / quiz
   - translation (l10n server integration, finally!)
   - caching
   - media integration
   - probably e-commerce/payment
   => brainstorming in the corresponding groups needs to start

Of course implementing this would require messing with the ways of 
some drupal developers, and it will definitly slow down the rate of 
contrib code increase. However, in the end, you get what you pay for!

To explicitly say it again: all this is only viable because of the 
experience gained from D6 unregulated contrib development creativity. 
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..

Webchick, Dries, core devs: pleace voice opinion NOW ;)
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