On 16 Mar 2005, at 02:49, neil@civicspacelabs.org wrote:
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.
Great news, Neil.
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?
I'm OK with that. Feel free to organize that, to announce it on drupal.org, etc. Is there anything you need to make this happen (eg. installing an event module on drupal.org)?
- 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.
I suggest you reserve the name crm.module. It shouldn't be too difficult to rename your existing contact module.
- 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.
This is of interest for the CCK and the profile modules. We can probably start working on that using the profile module and the contact module as a use-case. Some more thoughts: 1. The availability of the drupal.org infrastructure - and the CVS repositories in particular - will become increasingly important. Ditto for approving and managing CVS accounts. It might make sense to move the contributions repository to a dedicated machine. Like that, system administrators can be recruited to help administer CVS. Because the way CVS integrates into drupal.org, this might be a bit of a challenge. Anyway, food for thought. 2. We can create a 'Distribution vocabulary' and bind it to project issues. It lets you filter, track and syndicate CivicSpace related issues. It makes sense to invest in the project module a bit (e.g. and to look into Nedjo's project module patch). -- Dries Buytaert :: http://www.buytaert.net/