Conference call summary: Jan 28th 2009

Earlier today we had a conference call with a few consulting firms and individuals who integrate and deploy CiviCRM for clients. There were approximately 15 folks in the room. The agenda and quite a few comments are documented on this wiki page. We were fortunate enough to receive a very reasonably priced ReadyTalk license from TechSoup. We used ReadyTalk as a phone conferencing system this time, but we plan to make good use of this license by holding regularly scheduled webinars and product demos. The call was designed mainly to give the core team a better understanding of some of the issues faced when deploying CiviCRM. It was more of a "listening to what folks had to say" call, rather than trying to resolve any specific issues. Dave Greenberg did an excellent job facilitating the call. Some of the points made during the call include:

• Concerns about the "release early / release often" approach vs longer periods between releases with more fully flushed out functionality
• Support for prior versions of Drupal (D5) and Joomla (J1.0). Security fixes for prior CiviCRM releases (especially when CMS requirements change). Also support for older versions of PHP (5.1) since that is the default install on CentOS and upgrading is not trivial.
• Addition of new components (CiviCase in 2.2, CiviAuction in 2.3) vs solidifying the existing component set (flushing out CiviEvent, CiviMember, Relationships, Householding etc).
• Better Reporting tools.
• Better CHANGELOG.txt documentation for releases.
• Providing a public sandbox and tarballs BEFORE the code freeze so folks can take a look at what's present and highlight any missing features that significantly decrease the usefulness of the product.
• Developer issues: Notifying the community when we branch in SVN for a release, and document database changes.
• Better discussion and notification of feature freeze / spec freeze timelines.
• Providing patch files instead of complete package downloads to make minor upgrades easier.
• Making it easier to suppress fields that an given organization does not use.
• Making the UI cleaner and tighter.
• Focusing on one component per release, rather than spreading the love across all components.
• Insight into how features and fixes are selected for inclusion in a release.
• The need to improve communications between folks in the consultant / integrator / developer community.
• Mechanism(s) to pool financial resources in order to fund a particular feature or enhancement.

Overall we got quite a bit from the conference call. We will make this a regular feature and have a call every couple of months, timing it before a spec freeze / code freeze etc, which will remind folks to ensure they have their favorite things in the release. We'll discuss this internally and blog about action items and things to do from our end. We did not get a chance to cover: "How can the consulting community help us". This will be on the agenda for next time :) lobo