What's your idea?
To show the worls that Drupal 8 is the best there is, we should switch as soon as possible, preferably before Drupal 8 is released.
What are the benefits?
Show everybody that Drupal 8 is a good and flexible system. "Eat your own dog food"
What are the risks?
Probably lack of resources
How can we measure the impact of this idea? (metrics)
Who directly benefits from / will use this improvement? (target audiences)
The world, our community
Comments
I would very much like this,
I would very much like this, but it needs to be done absolutely right and especially for the right reasons.
See https://groups.drupal.org/node/313068#comment-955028 for some of the requirements and benefits this would mean.
--
/thomas
T: @tsvenson | S: tsvenson.com
Drupal.org used to run on
Drupal.org used to run on betas/release candidates of the latest core release until not all that long ago - either Drupal 6 or Drupal 7 broke that pattern but I don't remember which now.
Getting back to that means aiming to run on a Drupal 9 release candidate (it's already too late for 8.x), and planning for that could start now.
There's two obvious ways to get to Drupal.org on Drupal 9:
starting the upgrade to Drupal 8 immediately after the Drupal 7 upgrade is launched, so it's feasible to upgrade again when Drupal 9 gets to RC.
preparing for a migration from Drupal 7 to Drupal 9 and skipping 8.x altogether.
I would favour skipping 8.
I would favour skipping 8. Then we can use the extra time to make a complete architectural inventory of our infrastructure, features, tools, content, etc. Then use that to look into what we really need, what is missing and how it should be working. There are most likely some good candidates to move to their own server. For example docs.drupal.org.
A pause and reflection like that would most likely be a really good and timely thing. *.d.o has been "dragged along" and patched in all directions for many majors now. It needs a fresh start.
We could then also look into implementing features such as a proper OAuth solution and much needed improvements to user profiles. With our own OAuth server we can even allow third party sites to use it for login. Sites such as www.drupal8multilingual.org would greatly benefit from something like that for example.
Skipping 8 would also mean we give it time to settle. The changes it introduces have somewhat fragmented the community where some have concerned about what we will end up releasing. To be blunt, some fear it could be our Windows Vista.
I'm not taking it as far as that, but it will need a lot of time settling and require a much longer learning period for both developers and users wanting to build sites with it.
When we know more about that, then aiming for *.d.o on Drupal 9 early could be the thing to bring the community back together, create common goals and help us to both build a much better and modern home as well as our Windows 7 equivalent.
--
/thomas
T: @tsvenson | S: tsvenson.com
I'd be comfortable voting for
I'd be comfortable voting for this if the version were switched from 8 to 9. Given that Drupal.org has been in feature freeze for a year preparing to launch the D7 upgrade, I can't in good consciousness advocate for moving to D8 right now.
Upgrading statistics
@webchick
This is a little off-topic, but still relevant. Bryan Ruby (CMS Report) raised an interesting observation about Drupal adoption, and the release success of new majors, in this comment. Its about sites adopting and upgrading to Drupal majors.
It got me wondering. Do we have any statistics or other information about this? Particularly interesting is to know how many that opts to upgrade to new majors and when they do that.
If not, it would be a great thing for the DA to do. It could initially be done as a survey amongst Drupal shops. They should be able to shed quite a bit of light about this.
--
/thomas
T: @tsvenson | S: tsvenson.com
I would love to see
I would love to see *.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).
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.
(lot's of assumptions in this idea).
Me too :)
Please propose it as an idea. :)