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