[development] D7 contrib module development

[Marcel Partap]

...
> 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.
You're right, haven't noticed him although he probably also processed
my application.. KUDOS Andy for bearing with the community ;)

> 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. :(
Yeah being in the jury just never pay off.

> Thank you, Andy!  You are one of the most important people for
> Drupal. Without you, Drupal contrib would certainly be a pain.
Wow i didn't realize it could be far worse..
Now on to the more profane stuff.

>> 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.
Well admittedly starting the discussion is only a first small part.
For much of the work i can not be of help simply because i have other
obligations, but i volunteered for reimplementing a mailman/drupal
integration module and would contribute as much as possible.

> 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.
Well of course it does, but a) the structural sanity benefit might be
worth it and b) the license doesn't prohibit code reuse ;)

> 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.
No. It does require the community at large to do the work of
discussing, drafting and finalizing the structural design of these new
frameworks - module maintainers are not required, but of course their
experience would be of tremendous use.

> This has been done before.
Fine. So uhm let's do.

> - 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.
Shame on those module maintainers! But still, all is not lost. Let us
try making it suceed and mirroring the process, without leaving
current module maintainers out of the equation.
By the way, a policy change like described would put more pressure on
those maintainers - if they want to have at least some of their code
run on D7 - they better be cooperative!

>> 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.
Ok now that's a valid point. Maybe it can be possible for people to
take responsibility without having exclusive access rights to a module?

> Yet another example: If there was some bad, not carefully reviewed
>  code committed to Views module, then 72,799 sites could go down.
So as that has not yet happened it seems responsible developers exist
in the drupal community.. hurray! ;)

> 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's the scenario where the veto vote i proposed comes into play ;)

> 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.
Well if it work better, that'd be great. However not all individuals
live up to these standards, which is why i think maybe the drupal dev
collective at large can better fulfill this role!

> 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.
My proposal was to shift the responsibility from individual persons to
a community process, to minimize possible negative influence of those.
The process should promote and support taking responsibility by
anyone, and hinder the opposite.


> 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.
True, _but_ individuals who do not want to follow the common shared
values may be excluded from using the community to publish their code.
That will teach them ;)

> 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.
Yes and no. It restricts freedom, true. But why does experimental code
need to be committed to the central repository, and how does enforcing
an open development process hinder evolution?


-- 
  "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