Separate D.O. into "Marketing/Brochure" and "Project/Collab" sites and Dogfood them with Drupal Major/Minor versions

Events happening in the community are now at Drupal community events on www.drupal.org.

What's your idea?

*.Drupal.org be split into the "marketing sites" (drupal planet, main landing pages, association pages, etc) and the "Project Infrastructure" sites (projects, groups, etc) and have the marketing sites line up with the major versions (say 9.0.0) and the infrastructure sites line up with a significant minor version (say 9.2.0).

What are the benefits?

This would send a pretty strong message that as soon as a major version comes out it is ready for a top notch marketing site, and set us up for a big contrib push before the next significant minor version.

Also:

  • Stop the upgrades from being so big
  • Switches the upgrade from one huge upgrade, into a small/medium size one and a large one
  • If we use Commons for g.d.o it gives time for it's contrib requirements to get upgraded while still having the benefits of dog fooding
  • General Benefits of Dogfooding: Dogfooding our drupal.org Infrastructure (@tsvenson)
  • Reduces dual updating: There's been some updates to the marketing side of Drupal.org during the year+ upgrade that must have been done in both D6 and D7
  • The Drupal.org upgrade effort could be used to provide examples for how to upgrade modules
  • would hopefully act as kickstart/boost to contrib space for each new version
  • make sure the Drupal Associations gets the most value out of the resources put into the upgrade

What are the risks?

  • It would be dependant on some version of [policy, no patch] Decide if and how to implement semantic versioning for Drupal 8.x happening (and that's been open since September 23, 2009 at 5:59pm with no resolution)
  • There's a risk the dogfooding may delay releases
  • Separating it out might not be clean and easy i.e. project* is all on the main drupal.org site which is where the main marketing material is
  • May need to do some backwards compatibility work between the two versions of the sites (for Bakery etc.).

How can we measure the impact of this idea? (metrics)

Effort spent on upgrades. Time between version release and upgrade.

Who directly benefits from / will use this improvement? (target audiences)

Would benefit:

  • Core Commiters: people are dogfooding their work increasing test coverage
  • DA members: the DA's investment in the upgrade would be pushing the Drupal and the contrib space forward (currently the upgrade seems like an effort to stay minimally upto date
  • Anyone trying to sell the latest version of Drupal as the version to use
  • Are additional resources available for discovery/implementation? (volunteer effort, financial backing, etc.)

    None identified yet.

    Comments

    PS Sorry this is late

    dustin@pi's picture

    My apologies I'm submitting this idea late ... I was on vacation!

    Drupal.org 2014 roadmap brainstorming

    Group organizers

    Group categories

    Difficulty to implement

    Group notifications

    This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

    Hot content this week