[drupal-devel] CivicSpace development moving to Drupal
neil at civicspacelabs.org
neil at civicspacelabs.org
Wed Mar 16 01:51:28 UTC 2005
A couple things have become obvious to those of us working at
1. We shouldn't be maintaining a development community.
2. We have been trying to maintain a development community.
That means people who want to help out with CivicSpace will have to get
on Drupal.org sooner or later. That is okay, every serious CivicSpace
developer has done that anyway.
This should be relatively straightforward:
- All modules which are not in contrib should be in contrib.
- All modules which don't have an associated project will have to get
- Our issue tracker becomes a search over the issue tracker for the
modules we include in CivicSpace.
- Anyone who wants a sandbox or something else will have to go to
These things are being integrated into our development cycle soon. The
overall status of our development (including moving to 4.6), can be
found at http://civicspacelabs.org/home/developers/roadmap.
There are a few things I could use some advice about:
- Bug fix fridays in the Drupal community. The simple explanation is
that Zack and I come up with a list of bugs to fix every Thursday,
tell the CivicSpace developers mailing list about them, and bug
assignments are made at a set time in an IRC room Which IRC room
should be used, #drupal-bugfixday? Anyone else want to do this as
- To properly release the configure  module it will need about 2/3 of
the code pushed into individual modules using a new hook. We should
have a debate about this going into Drupal core at some point. It
could easily live as a contrib module, but I think we need to take a
step back and think about how module installation works.
- The contact  module. It has a naming collision, a replacement
coming in some number of monthsi (CiviCRM), and hasn't had any
non-bugfix updates since Drupal 4.4. This code isn't up to Drupal
standards and shouldn't need to be updated, assuming CiviCRM works.
- The contact module uses the forms  module. IMO, the forms module
needs to be replaced with a core API based upon the admin-configurable
forms in flexinode and profile modules. Contact uses an old version of
forms module before some API changes; I like the changess, but haven't
had the time to rewrite and retest contact module.
- Survey  is forked because it has to work with the forms module we
are using. And we haven't really gotten a good idea of how we expect
people will want to use survey in the context of a CivicSpace site.
- Our node_import  module is heavily forked. Things will get worse
before they get better with the coming of CCK. This is something we
can get working on 4.6, but we don't haven't been dedicating much
resources to this module.
- Install.php  is a heavily branded and Postgres incompatible moving
target. Who is interested in helping get this into Drupal? I know
people who want to make Drupal easier to install are out there.
- We want to know when 4.6.0 final will be released. Yeah, I know, it is
ready when it is ready and review issues and test it to make it go
1. Configure is a wizard to walk through the basic configurations needed
to get a site running.
2. Contact keeps data from user registrations, mailing list sign ups,
and data entry in a central location.
3. Forms provides an API for modules to maintain admin-configured forms.
4. Survey creates simple surveys for data collection.
5. Node_import imports CSV files as nodes.
6. Install.php loads table definitions into an SQL database and writes
conf.php (yes, it is 4.5.x code right now).
(This email will be cross posted to my blog at
Lead developer, CivicSpaceLabs.org
More information about the drupal-devel