I'm officially headed to Drupalcon Szeged in August (thanks, Lullabot!), and so naturally submitted a few session proposals this weekend. :) Incidentally, if you haven't yet registered for Szeged, you really ought to do so soon -- the price goes up after June 30, and their website has a super smooth registration process.

So in addition to the "usual" Drupalchix BoF and Summer of Code showcase proposals, I also really want to try something new this year in support of spreading the testing love.

So I'm proposing.... Awesome Testing Party, a working session where coders from newbie to ninja gather in a room together and help each other to write tests for Drupal core.... and win prizes! :)

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?

Today, the Google Summer of Code 2008 accepted students were announced. 7,000+ applications to 175 mentoring organizations from nearly 4,000 students, of which 1,125 will be funded. Altogether, this means a $5.6+ million dollar investment in open source from our buddies at Google. Kick ass!

How did Drupal make out? We will be mentoring 21 Summer of Code projects from our 84 submissions. Drupal's mentor team did an outstanding job of weighing the pros and cons of each proposal, making difficult decisions, and ultimately choosing an exciting mix of projects and students:

Note: Please read the date of this post before sending me e-mails about it. Thanks. ;)

Since I got my start in the Drupal community in 2005, most have noticed that I've been a wee bit, erm. Obsessed. I try to help out in as many ways as possible, and often this means juggling about 50,000 different priorities at a given time, the last of which is always sleep.

Well, it was fun for the last 2.5 years, but enough is enough. While I will always have a soft spot in my heart for the Drupal community, my participation has often been at the expense of relationships with family and friends as well as my own personal health and well-being. :( So, it's time to say "goodbye, world" to the Drupal community and instead embark on a new chapter in my life...

In case word hasn't reached you yet for some reason, Summer of Code 2008 is a go, and this is the week for college/university students to submit applications to work on projects for their mentoring organization of choice over the summer. Our hope is of course that a whole bunch will choose Drupal, which is an awesome, knowledgeable, and fun community to be a part of, and very supportive of SoC students (I know, because I was one myself back in 2005! :D).

As part of my duties for the Drupal Association, I help to administer initiatives that help bring in new contributors, like Drupal's involvement in Google Summer of Code. A huge thanks to the admin team -- chx, cwgordon7, and dmitrig01 -- for their tremendous efforts in getting the program kick-started!

We're trying something new this year that we haven't done in years past: public community review of student ideas and proposals, prior to their submission as formal applications for Summer of Code. There are multiple reasons why we chose to "beta test" this approach, which I will detail after the break.

However, for those who want to help bring new contributors to the Drupal project, and have a hand in deciding what new awesome projects get funded over the summer with Google's multi-thousand dollar investment, please jump in and help review some student proposals! The absolute deadline for student applications is Monday, March 31, 2008 at 17:00 PDT, so it's imperative that students get their questions answered and their proposals reviewed and refined as soon as possible so they have ample time to get their applications in.

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?

In case you haven't already heard the buzz, Drupal 6 was released today, about one year after the release of Drupal 5! The announcement post goes into great detail about all the fantastic improvements, but I'd like to focus on a different angle: the hundreds of contributors who helped Drupal 6 come to be.

How many contributors were there?

How many people contributed to Drupal 6? It's very difficult to define. Depending on your calculation method, that number ranges from around 250 to more than 700. And the actual number is *much* higher than that, of course, when you factor in the entire iterative process of how an idea turns into an improvement in Drupal. Every contribution matters, from initially reporting bugs/features, to adding further clarifications, to thoroughly reviewing patches, to making minor tweaks that aren't large enough to warrant credit alongside the primary patch author(s).

But here's what we do know...

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. :)