Earlier today, I asked the fine folks from the Chicago Technology Cooperative what the status is of GMap and Location in terms of a Drupal 6 port. I expected at best a brief reply, probably followed by a "buzz off." ;)

Instead, Brandon Bergren and Rebecca White decided to join #drupal-dojo and spoke at length about the current status of the modules, what's needed to get them stable, and what the roadmap to Drupal 6 is. And, most importantly, they also went into details about how we can help (coders and non-coders alike! :)).

A summary of the talk (as well as the full IRC log) are posted at groups.drupal.org at The State of Geospatial in Drupal. The general plan is to get stable releases of the 5.x modules out first, then do straight ports to Drupal 6, followed by new development.

Want to help speed things along? Here's a list of the places to jump in if getting these modules stable is an itch for you, too.

Earlier tonight, Jimmy Berry posted a plea for the Drupal community to clean up their messes in terms of testing. Since Jimmy did a whole bunch of the heavy lifting involved in getting the SimpleTest framework ready to commit to core, a major milestone in Drupal's development, we'd do well to listen to his words and his frustrations when he sees all of his hard work falling apart due to neglect.

SimpleTest has only been in core for a month now, and already we've managed to break more than half the tests. This is a big problem. :\

In order for our community to embrace testing, we're required to bring several hundred people who've never written a test before in their lives (and might not even have heard of automated testing until heard some Drupal people talking about it) up to speed on what testing is, why it's a good thing, and how to do it.

But every time there's a bug in the testing framework, and every time an existing core test fails to run, this serves to completely destroy developers' confidence. If we're lucky, these people will go work on other things for a little while, and then check back periodically to see if things have been sorted things out yet. If we're unlucky, they start to develop animosity and resentment about the very idea of testing, and then start to distance themselves from doing development and encourage others to as well. Either way, the end result is stalling development on D7, and fewer people to spread the work around of writing further tests.

So how can someone concerned about the state of D7 development help?

Still stuck... er, I mean... visiting ;) Boston after Drupalcon, thanks to a lovely winter storm in Canada that refuses to go away. Karen Stevenson was nice enough to put me up in her hotel room for a night, so I wanted to pay her back by making this important issue my "itch of the week": we need to figure out a data model in order to move CCK fields in core efforts forward. See Karen's Field Structure thread for more details.

Currently, regular old single-value fields (like "first name") are easy. Just cram 'em in the content type table. But when you start moving into more advanced areas like shared fields (such as a "picture" field that's attached to both "book" and "video game" content types), or multiple-value fields (such as a group of checkboxes for "interests"), those currently get split off into their own tables in order to normalize things. Moving fields to and from multiple value and shared has always been a harrowing process, involving table structure manipulation and data migration. However, with the abstraction brought on by the new Schema API in core, this suddenly became a lot tougher.

A couple of options have been proposed, which include a de-normalized schema per content type (leading to a bunch of NULL values for multivalue fields and data duplication for shared fields), and a "each field in its own table" approach, which involves many (sometimes MANY many) joins, which can kill performance on a large site.

So, calling all database schema experts, SQL gurus, performance nuts, etc. We need your help. We need to make sure we're not missing any obvious options that would make this work more slickly, and we also need some help benchmarking to determine what the best option is going to ultimately be. Please head over to http://groups.drupal.org/node/9297 and post your thoughts!

This week's itch is another usability itch: adding example text to all textfields in core. There's work there in process to do stuff like emulate the Yahoo! registration form, where a faded-out example value is placed in initially, and disappears when the box gets focus:

On browsers that lack JS support, the example text will just be displayed next to the box.

How does this work?

I noted in my Drupal 7.x Personal Battleplan that I was going to focus on Usability and QA stuff this go around. So I've started a new segment called "itch of the week" to keep track of the efforts I'm working on to that effect. It'll be interesting (well... to me and probably no one else :P) to see if I can keep up with these weekly or not. ;)

Anyway. The first itch goes to.... permission descriptions!

This is a patch that was originally written by kkaefer way back in fall of 2005. It came back on my radar when I was observing Marci working with Drupal on her blog and struggling to figure out what the various options meant. It further came back on my radar when I heard a support request come in from a client about why their editor could see private site content intended only for administrators. Permissions are sometimes poorly named (I've come across some doozies in contrib :P) or have other implications that are not immediately obvious, such as roles with "administer nodes" permission bypassing any access control on content. This patch attempts to make these more obvious to folks.

Anyway, if this sounds like something that's interesting to you, please help review the patch, and we'll see if we can get it into Drupal 7.x. :)