Challenge Goal and Proposal for Drupal 7

Community Strategy

My challenge goal to the Drupal community is that we have our contributed modules ported within a month of the D7 release to show our support for and be able to take advantage of the new Drupal core. As most of us know, it has been 10 months since the release of Drupal 6.0 and a fair number of large modules have either not been ported to D6 or did so only recently.

The idea is that, when D7 goes to code freeze, module developers would similarly freeze the feature development of their D6 releases and focus on conversion to D7. This strategy will reflect well on the community's commitment to maintain a solid code base and reap the benefits of all the cool new features in each new core release.

Proposal

In order to facilitate the achievement of this goal, I propose the following:

  • Recast the 6.x to 7.x conversion roadmap documentation as the depository for developers to log the changes from D6 to D7
  • Create another 6.x to 7.x conversion roadmap (from the above depository) organized into separate pages by topic, and
  • Automate a great percentage of the changes in the 7.x release of Deadwood to be ready when D7 goes into code freeze

The Drupal community will benefit from the documentation change by:

  • Making it easier for module developers to find the core changes relevant to their module,
  • Clarifying for module developers the conversion routines to be applied by Deadwood,
  • Providing a more organized history of core changes by release, and
  • Helping everyone to understand the changes to core.

Similarly, the community will benefit from having Deadwood updated by the time D7 goes into code freeze by:

  • Making it easier for module developers to port their code by significantly reducing the time commitment involved
  • Increasing the time available to module developers to focus on new features for their D7 release
  • Increasing the likelihood that developers will port their modules on a timely basis with the D7 release

As part of this effort to update Deadwood, I would appreciate the assistance of developers to test its conversion routines, help correct any errors and suggest enhancements. I would like to remind everyone that Deadwood is not intended to perform all conversions but rather to do a great percentage of the mundane changes needed to port a module, thus leaving only a minimum number of changes requiring manual attention.

Role Model

In my opinion, the Firefox plug-in developers are excellent role models for us. They have new versions of their plug-ins ready in conjunction with new Firefox releases. (Is there anyone who doesn't appreciate this?) Let's have the Drupal community emulate this practice.

Comments

strategy

The idea is that, when D7 goes to code freeze, module developers would similarly freeze the feature development of their D6 releases and focus on conversion to D7.
I disagree. You can't tell to the developers what they should do, when they are doing it for free. If they need 10 months to make it a killer module, then be it.

I don't like automatic code changes, so I prefer the coder module. I do not know a Drupal developer who would say that upgrade from D5 to D6 is hard, so I do not really understand why making it easier would speed up the upgrade. The only problem for the most modules as I see it is, that someone have to do it..

They have new versions of their plug-ins ready in conjunction with new Firefox releases.
This is an easy lie..

But don't get me wrong, I appreciate the time you or anyone spend developing for Drupal.

“You can't tell to the

“You can't tell to the developers what they should do, when they are doing it for free.”

I think that it's very easy to get stuck with the idea that because Drupal is free and open source, people should be able to do whatever they want. Drupal 5 modules have taken a long time to convert to Drupal 6 and as a result, adoption of Drupal 6 has been slower than it could have been, which holds everyone up. While there's no way of forcing module contributors to port to Drupal 7, solid encouragement to do so more rapidly can only be a good thing.

Very insightful

I find this community strategy very profound and encouraging.

If this were to take off, I'm very sure that it would be a successful way of managing change towards the development and production of Drupal7-related functionality & improvement.

I bet that most of those who have heard this idea for the first time would raise an eyebrow or two, but in the end... it's all about showcasing the uniqueness of the Drupal community (in terms of building, creating, and working together for the software that we uber-love!)

Automation software is hard to build, in this case, something that could automate the dull and robotic tasks that we humans still tend to be obsessive-compulsive doing ourselves. With all the testing, coding, and debugging that there is yet to happen... it surely is a good idea to do this early for Drupal 7.

People might be thinking... "but it's too early for Drupal 7! Shouldn't it be release for like a year or two?". The answer is: No. In the world of software development, change can happen anytime. It's never too early, nor too late for a good change.

Jim, I loudly appreciate your ideas on this one. Way to go brother. Keep it coming.

Hmm, apparently I'm still suffering from my OpenSUSE 11.1 hangover.

Peace,

Marc Robinsone