[meta] Panopoly 2.x for Drupal 8 battle plan

This issue is to discuss a couple policy questions about Panopoly 2.x for Drupal 8, and also to plan out the goals and objectives to get us to the first 2.0 stable release!

@populist and @dsnopek discussed this and came up with the following proposal! However, this is open for discussion and change.

What will be included in Panopoly 2.0?

We decided that we won't aim for 100% feature parity with 1.0 in order to release 2.0 (but eventual feature parity in later releases will definitely be a goal!), instead the key feature to have working in the in-place page editing, which means:

1. Panels IPE: Being able to click "Customize this page" and "Change layout" and open the IPE like in Drupal 7
2. Creating new blocks in the IPE: In Drupal 7, this was done by Fieldable Panels Panes. In Drupal 8, custom blocks are already fieldable entities - we just need to be able to create new instances of them from the IPE!
3. Panelizer: To take over rendering of nodes, provide defaults for the content type and make per-node customizations
4. Radix Layouts: Our library of layouts, which is actually already ported to Drupal 8! See Radix Layouts 8.x-3.0-rc1.
5. Panopoly Widgets: Excluding all the widgets that depend on external dependencies which don't have Drupal 8 ports yet (like the Map and Table widget)
6. Migrations for the stuff that exists - Some migration classes for moving a site from Panopoly 1.x to Panopoly 2.x. However, since there won't be 100% feature parity immediately, this will only be for the stuff that exists. If you're migrating a site, you'll need to wait until everything you need exists in Drupal 8! See: #2736629: Implement basics of panopoly_migrate for migrating from Panopoly 1.x to 2.x
7. Panopoly Demo: We can't release a Panopoly 2.0 that doesn't have demo data! See: #2732417: Port Panopoly Demo to Drupal 8!

Of course, we'll port some of the basics that exist in core, like the image styles in Panopoly Images, content types in Panopoly Pages, maybe a default WYSIWYG configuration in Panopoly WYSIWYG, etc.

But anything beyond the bullet points above is optional, and can wait until after 2.0. Patches are always welcome! :-)

As the Drupal 8 eco-system comes together, we'll continue adding more missing features after 2.0 (in 2.1, 2.2, etc), and will eventually reach 100% feature parity with Panopoly 1.x.

We believe that this approach will allow us to provide a Drupal 8 version quickly, so that contributors can start using it and improving it, while allowing us to maintain the level of stability and security that you have come to expect from Panopoly.

What will -alphaX, -betaX and -rcX mean?

2.0-alphaX

The -alpha cycle will be about experimenting and laying the groundwork for Panopoly 2.0!

These versions are meant for contributors who want to help make Panopoly 2.0 a reality, and shouldn't be used on production websites.

The -alpha releases will be missing features and there won't be an -alpha to -alpha upgrade path.

2.0-betaX

We'll switch to -beta when we have all the features mentioned above that we're targeting for Panopoly 2.0 (see the list above), and we're ready to start providing -beta to -beta upgrades.

These versions are meant for early adopters who are OK with bugs, and don't need to migrate from Panopoly 1.x.

At this point, you could start using it for new Drupal 8 sites!

2.0-rcX

When we have the bugs to an acceptable level and migration classes for upgrading from Panopoly 1.x (if you don't need any of the missing features), we'll start making -rc releases.

These versions are meant for regular site builders and developers to try out Panopoly, not just early adopters, so we can iron out any critical problems before the 2.0 release.

Once we're reasonable happy that we have a stable -rc release, we'll release 2.0 (which will hopefully be nearly identical to the last -rc).

Specific changes/goals for the 2.0 release

The first Panopoly release was made in March of 2012. At the time, it was really the first "base distribution" ever made! A lot of decisions were made without knowing exactly what the consequences would be.

However, in the 3 years since then, we've learned a TON from the experience of users and contributors using Panopoly to do some amazing things, many of which would never have occurred to us in the beginning. :-)

Based on that experience, we'd like to pursue the following specific changes/goal for Panopoly 2.0:

1. Eliminate "concentrations of code" in Panopoly, and move them out into contrib. During Panopoly 1.x, we've spent a disproportionately large amount of time maintaining the few concentrations of code in Panopoly. We'd prefer to move those out into to contrib to be maintained by a wider community, and limit Panopoly's code to pulling in, configuring and integrating contrib modules. Specifically, here are some examples:
   1. Panopoly Magic: The primary job of Panopoly Magic is to provide live previews of Panels widgets. In Drupal 8, Panels widgets are blocks, and this functionality could be useful even on a site without Panels! Rather than porting Panopoly Magic to Drupal 8, we'd like to implement this "block preview" functionality within CTools in Drupal 8.
   2. Spotlight widget: The Spotlight widget was intended to be the "simplest slider that could possibly" work, with the idea that if you wanted a real slider, you'd use something from contrib. However, a lot more people used it than expected, and we spent a considerable amount of time fixing bugs in it. Rather than porting it to Panopoly 2.0 as part of Panopoly Widgets, we'd like to have an external app (ex. maybe panopoly_slider?) that uses contrib modules to build a real slider. Ideally, this would be maintained primarily by the community, rather than the core Panopoly developers.
   3. Content Item widget: The "Content Item" widget is a clever Views widget that provides better usability than the CTools "Existing content" widget. It was simple to create using Views, but it turned out that there were a number of subtle edge cases that meant we had to implement several Views hooks for it to work correctly. Looking back, it would have been easier to implement in custom code OR to improve the usability of the "Existing content" widget from CTools. Rather than porting this, it'd be great to just make the CTools widget usable from the beginning!
2. Put media support in a new Panopoly Media module: In Panopoly 1.x, we have media support in Panopoly Widgets. Media ended up seeping into several other places making for some weird dependencies, but it'd be hard to move without breaking the upgrade promises we made for Panopoly 1.x. For Panopoly 2.x, let's put media in a new Panopoly Media module!
3. Break Panopoly Widgets into more modules: A common complaint in Panopoly 1.x, is that some users don't want all the widgets included in Panopoly Widgets. While it's possible to disable any individual widget, you're stuck with any modules that widget might depend on which led to several users forking Panopoly Widgets. In Panopoly 2.x, the main panopoly_widgets module will only contain those widgets which have no additional dependencies - if an additional dependency is necessary, it will go in a seperate module. For example, this means that the "Map" widget, which depends on simple_gmap would be in a panopoly_widgets_map module by itself. (The media widgets will move to the Panopoly Media module.)
4. Break panopoly_search into panopoly_search_solr and panopoly_search_db: For the same reasons as with Panopoly widgets, many people have been unhappy that Panopoly 1.x always includes support for both DB and SOLR search, but their site may only use one or the other. In Panopoly 2.x, let's split these into two sub-modules of the main panopoly_search module!
5. Drop respondjs: No more IE8 support in Drupal 8! :-)
6. Include some tours to help site managers get started: Drupal 8 includes the new "tour" module which allows providing interactive walk-throughs, however, Drupal 8 doesn't really provide any tours itself. To help demystify both Drupal and Panels, let's create some really great ones for Panopoly 2.x!

TODO

1. Open Panopoly issues for each of the features in "What will be included in Panopoly 2.0" above and make this issue their parent issue
2. Open issues in all the contrib projects for what needs to be implemented their to make that happen, and link to those issues from the relevant Panopoly issue
3. Start implementing!