At Drupalcon Chicago, I organized a 'core conversation' about the Snowman (nee Tsunami) project and many of us (including Leisa, Dmitri, Bojhan, Yoroy, and others) met up for a BoF the next day. A couple of really valuable insights emerged and we believe that it's solidified our path forward.
- We shouldn't use a code-name that just killed a ton of people. See this post and for info about the new name..
- The original use case for the profile is a good one: a group of people collaborating on a project or participating in a single group, telling the world about their shared goal or activity, and inviting others to participate. We need to put together more concrete examples of this, but it's a very good match for what Drupal has always been good at and it gets us out of the 'Build a blog with some extras' rut.
- The user persona we're targeting is not an experienced Drupal site builder. It's someone who's a member of the group described above who is knowledgeable enough to install a piece of web software, but would probably hit Drupal's "learning wall" trying to build out all the functionality needed by the group. As Leisa put it, it's a step in the "dance of value exchange." They download and install Drupal, investing their time and attention. We want to give them something that is immediately useful and interesting for what they need to do with their web site, not just a set of tools useful for building their web site.. They can dig in deeper and customize it, but we want them to hit the ground running.
- Snowman will not attempt to hide Drupal's Drupaly-ness. It's a preconfigured Drupal site that gets people with the above use case to the 60% point, where they can understand what the site is and how it works, see that it is useful for their specific needs, and begin working with it.
- Anything created by the Snowman installation profile should be be configuration that can be torn apart by a motivated user with Core's own site building tools. This means no custom hook_menu tricks or sneaky theme hacks stuck in the .profile. If we must customize something and it can't be done via configuration, we file a bug against core and try to fix it.
- Really useful functionality for the use case that simply can't be implemented in core can be handled in two ways: propose low-impact core patches for Drupal 8 that add the capabilities, and/or treat the gaps as an "on ramp" to exploration of the contributed modules directory, engagement with the Drupal community, and development of site building skills. Examples of 'simple' stuff would be letting admins choose how many nodes appear on the front page. Examples of 'complicated' stuff would be adding mailing lists. Debate about what lies in between will follow, but shouldn't be our primary focus.
- The Snowman profile can serve as an 'R&D' lab for interesting core patches, generating ideas from real world use cases and pain points. It can also serve as an example of how Drupal's tools can be used for site builders learning the tricks of the trade. And finally, it can serve as a 'canary in the coal mine' of core development. If the choices made in Drupal core development make Snowman harder to implement, it can serve as a warning that we'll be making it harder for non-core profiles and distros. However, these are all happy side benefits. Our primary goal with Snowman is nailing the target use case and giving the target user persona something something that is genuinely useful.
- The profile is absolutely NOT targeted at experienced site builders or developers who want a base to start working from. Unless they genuinely want Snowman's specific functionality, and want to expand on it in particular, they should start with the Minimal profile and follow their own plans.
- Because the Snowman project will focus on relatively small sites (compared to, say, whitehouse.gov), it should be possible to provide sample content out of the box. We want to err on the side of Wordpress, which provides an example blog post, an 'about' page, and a sample comment. The Joomla! installer offers two options: no sample content, and too much, making it difficult to get one's bearings or difficult to remove the dummy data depending on the option chosen. Some good ideas to start with for us would be proper user roles for the use case, an example non-administrator user, and one or two easily editable nodes of each content type that guide the new site owner, rather than making the site look "full."
- The Snowman project, for the time being, can be built in contrib against Drupal 7 core. As Drupal 8 is branched and new patches and features become available, we can follow the changes and decide whether new features would be useful for Snowman's users.
Everyone who attended the group is welcome to post anything that I missed, or clarify anything I've misunderstood! Later today I'll be posting our "next steps" plan, where we can all dive in and start working!