Today was the second (and, unfortunately, last) day of the SF CiviCamp.

The day started with Rob Thorne’s presentation on using CiviCRM 1.x contacts as CCK fields and his work on CiviNode. Given that in the meantime all of CiviCRM, CCK and Views released version 2s, the outcome of the discussion was that it’s best to rewrite this code from scratch.

That led to a discussion about the stability, coverage and the general uses of CiviCRM APIs. The consensus was that the main users of the CiviCRM APIs are third-party developers, and it would be most useful if there was a way for them to write custom APIs covering their most popular use-cases. This, in turn, led to whether our internal classes (CRM_*) are stable enough to be a viable API by themselves; we’ve always considered them ‘private code’ and as so never strived to stabilise the various functions’ signatures, outcome – or even their existence between releases.

Another topic raised during the morning session was the documentation of the API. As quite a lot of developers are supporting older versions of CiviCRM, we need to ensure the API documentation is versioned (and that older versions of the docs are easily available). We also discussed the priority of API bugs, and the need to fix more of them in the stable releases.

The following discussion on CiviCRM component development resulted in Matt Chapman volunteering to manage a CiviCRM component forge, where non-core CiviCRM developers and deployers can share their code. In most cases, the current reality results in development of CMS-specific

The discussion also touched some engineering ideas about CiviCRM’s codebase improvements, like better object-orientation of the code and the introduction of exceptions.

During the second part of the day small teams of developers formed to discuss and work on selected topics. These covered, among others, the discussion on what needs to be done in the core to initiate more widespread component development, and which parts of CiviCRM need to be pluggable for the componentisation to take flight. We also discussed the multi-lingual features of CiviCRM 2.1.

The third part of the day, again held in subgroups, touched various topics, including getting CiviCRM test coverage back into shape and the possibility of (particularly – API) test contributions from the community. Other topics included discussions on possible uses of the household concept, CiviMember-to-Drupal-roles synchronisation and hooking into the Drupal Views module to use it for CiviCRM-related data. One group worked on prototyping an RSVP workflow for CiviEvent – where invitees can respond ‘Yes’, ‘No’ or ‘Maybe’.

One of the more useful (and spectacular) outcomes of this day was the commitment of Mark Burdett and Matt Chapman to lead a community project of backporting CiviCRM 2.1 to Drupal 5.