[drupal-devel] CivicSpace development moving to Drupal

[neil at civicspacelabs.org]

A couple things have become obvious to those of us working at
CivicSpace:

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
  one.
- 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
  Drupal.

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
  well?

- To properly release the configure [1] 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 [2] 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 [3] 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 [4] 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 [5] 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 [6] 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
  faster.


Notes

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
http://civicspacelabs.org/home/blog/71)


-Neil Drumm
 Lead developer, CivicSpaceLabs.org