[meta] Make standard install profile into a "Community in a Box"

Create some sort of wizard/buttons that one can select and choose the profile (get list from d.o), download the profile & install. That way we can ship with anything... this is of course pending on #395480: Plugin Manager in Core: Part 4 (installation profiles). All the complexity's aside, asking the user is the best way to go if we don't go the download route. Ship with like 5 simple default profiles (instructions on how to get more complex), first one being minimal.

Is there any way to get the php memory limit? That way the admin knows what he has to work with and the requirements for each part in the wizard.

Hm Boris this does not stir the masses as it seems. Weird. So is momentum on this issue somewhere else?
Every minor text change gets 85 comments.

OK.
What can I do to help pushing this?
I edited the wiki in one point: I think Article should continue being promoted, as this is Drupal's basic blog functionality which is not bad IMHO. If we remove it Blog must be presented in a different way. Because if nothing gets promoted by default, uhm...

As to Photos: due to Quicksketch's endavour I think we will have Imagefield, Imagecache and filefield/imageapi in core.
How about creating a bit of random fun for the "photo" content type? I think of the following: Making a main image floated left (and if we find a way, add an ability to make it float right by choice) with a sensible margin (5 15 5 15 has proven to be a good practical value for me). This would need two imagecache presets. Should talk to Quicksketch about the chances of his plans about this, but it might give him further motivation.

And what about the wizard? I guess it must be coded, right?

As a daring thought it might be to pursue the thought of an "advanced" install profile that uses quite a bit of contrib - a bit like Acquia Drupal. The almost given fact that we will have Plugin Manager in Core makes Room for that vision. I know chances are not too big to get this in, but if we start now, maybe 10% are there. Great victories have been archieved with smaller chances. This could be a _true_ community in a box then.

Who else is on this track?

I'm really interested in this -- if we get some ideas then maybe I can get prototyping; I've done profiles before but this sounds really neat.

Bump. Four weeks left to decide on which modules to enable/disable in the default install profile. Everybody interested, review http://groups.drupal.org/node/21013, it still is the most concrete proposal we have.

This issue seems rather unfocused, as well as outmoded due to installation profile changes.

This does seem a bit unfocused at the moment, but I don't see how it's outdated at all. We certainly want a great initial experience for people installing Drupal. And there's plenty of time left to make changes to the standard install profile (even though we are well past code freeze, changes there don't really affect anything else...)

Let's leave it up to the people who have been most active in this issue whether it makes to leave it open as a meta-issue (hopefully with some links to spinoff issues for implementing specific things?) or to close it after all.

Some time ago, I wrote an extensive proposal regarding a better install profile: My vision of usabilty for Drupal

To sum it up:

• "First sight" is what matter the most
• One-minute install file (example with another blogware). Basically a server-to-server install, although you still need to open up a FTP client—I imagine it would be easy to not even have to use a FTP client, but then major security issues would arise)
• Multi-language wizard, Mac OS X-style. Further improvement: topmost language is browser's language (requires some PHP)
• Instruction for installing languages (this part is OK, but there is a minor thing to add for Mac OS X users: Macuser are used to deletion, not merging and they should not have to know that their server is (most probably) a Linux box which merge, not delete
• "What do you want" wizard, a profile-choosing page. Read the original article for more about this, this is pretty long.
• Either remove any need for giving permissions or give unambiguous values ("give write permission" is ambiguous; set permission to 755 is not — well, on Unix servers at least)

Hope it helps pushing the subject a little further.

Hi Boris and thanks for the reply:

Ultimately, the default profile should be a meta profile leading to other profiles (on of them being present-day default profile). Am I clear?

To directly answer your question: the advantage of Drupal is also its weakness. How can you decide what default is with such a broad range of use? Will Drupal be used as a blog, as an e-commerce site, as a corportate site, a community site, a photo gallery? Do we have statistics about the main use of Drupal? Even if we do, do they matter with the anticipated larger adoption for Drupal? What all of the above scenario have in common?

It seems like your own goal is community-in-a box. This is all well and good, but I do not believe an install profile should make too much assumptions regarding what Drupal will be used for.

• what is community-in-a-box? If you just mean comments, it is pretty easy. If you mean more than this, less so. What are the similarities between an issue tracking software, a forum and a Facebook-like site, out of comments?
• what about all the other kind of Drupal uses? Photo galleries, most corporate websites… do not put emphasis on community
• An install profile shall stick to the lowest common denominator and with such a broad software as Drupal, this lowest commun denominator, for me, is : comments, multi-users, RSS and… choice. The first three are already in. The last one requires a major overhaul that cannot be done so close to the release date and should be pushed to Drupal 8 (which should be take less time than D7)

(I followed the links and most are heading the same direction (features.module, "wizard options"…)

To end with a (somewhat) positive note: I can see some room for improvement in multilangauge defult install, by bundling some languages and present the user an install screen with the right localisation (browser sniffing here). That could be done Firefox-way (maintaining one Drupal core per language) but even this would take time. If Drupal is to be released in June, this is doable, though.

Hope this helps :)

Update: I revamped, updated and simplified the whole thing on my blog: Metaprofile — proposal for an improved Drupal default profile.

So here is my noob 2 cents...

I have installed Drupal 3 times now(D6 - twice this week, D7 - tonight). I am ok with core configuration defaults.

The biggest issue is module installation and management. Take a look at jquery and steal a page from their book. We need a way to see a table of modules with checkboxes on the drupal website. Let us check the modules to build a tar bundle and download that for installation.

Especially since Drupal has modules that have their own modules and so on. I spend more time downloading modules and sub-modules and enabling them than any other task out there. I havent tried plugin-mgr only because its documentation page says its buggy and unreliable.

The module view still doesnt have a sort feature. And the permission screen probably doesnt either. These screens get so long its nearly impossible to find the latest installation. At this point in time my D6 app has so many modules that I just enable everything so i don't miss anything.

And maybe the modules can be sorted by install date or by color. green for today, yellow for yesterday.

I've started making the case for a more focused, task-tailored standard install profile in this blog post. It echoes a lot of what Boris has said about "community in a box" but hints at some more focused use cases to make the pre-configuration choices a little more directed.

Drupal's default installation profile should be treated as a genuine product. It should be unashamed to focus on the target audience that already benefits the most from it: small groups of collaborators who want to share their work with the world, and convince their audience to participate as well. This covers a broad mix of users -- open source software projects, online news teams, community organizers, and more. The tools that come with core are already well suited to this use case: multi-user blogging for the team, RSS feeds and aggregation for collection and distributing news, forums and polls for getting the audience involved, contact forms for soliciting direct feedback, and so on.

In the comments of that post, there's been pushback about "making a profile for site builders," versus "making a profile that builds a site." The more I consider it, the more I think talking about site-builder experience for the standard profile is missing the point. The standard profile can be is a way to ensure that the site-building tools that come as part of Drupal core are actually sufficient to built a useful, reasonably complex site.

Building it is like a unit test for core's meta-functionality: can a useful site like this be built? Can it be captured in an install profile without hard-coding everything into one-off modules or forcing everyone else to use the same structural choices? The working profile demonstrates a focused example of what a built-out core site can do, while the process of making and maintaining the profile itself helps us spot crippling issues in core's APIs and configuration management tools.

Boris, what do you think a useful next step for that would be? Gathering participants who are interested in ironing out that epic's boundaries? A handful of end-user-groups to talk to for input?

@Boris - A wiki for persona's and other planning sounds like a great start. Do you have an existing group in mind or should a group be started for this purpose?

There's a lot of common ground between "community in a box" and the Tsunami idea. Forums, a blog, an image gallery, content aggregation etc. are prototypical Drupal features. Example sites that utilize these features are online communities, magazines/blogs and business/non-profits that wants to extend their brochure style site with a number of community features. There's a lot of discussion to be had on the specifics but I do think that most will agree that most Drupal sites fit into this mould.

I don't profess to write solid personas but for the sake of having a starting point here's some examples to foster conversation:

Tom, Site builder
Tom works for a non-profit with limited resources. He tends to wear many hats, one of which includes creating the organization's website and managing its online presence. He installed Drupal on the recommendation of a friend. It is important to Tom that he can get going quickly with features such as blogging, news updates and an information request form. Over time Mark see's his organization wanting to expand its website, adding online community features and a way to donate online.

Suzy, Content editor, web admin
Suzy is the editor of "Ponies Daily", an online magazine built on Drupal. She logs in daily to create new content, moderate comments and forum discussions. She also tweets and want's to bring these tweets back into the site. From time to time Suzy change site settings such and administers user accounts. Suzy's magazine has guest bloggers who have permission to post blog posts and news but who can not edit other people's posts or change system configuration. While Suzy is a web native, she doesn't want to be bothered with HTML. She would like an easy way to format content and insert photos and YouTube videos into her blog posts. It is essential that these features are available to her guest bloggers.

It is important to Suzy that Drupal is easy to use but is still powerful enough to support an active community and a lightweight editorial workflow. She doesn't actively try to optimise her site for SEO but she does want her content to rank highly if it is relevant.

Martin, End user logging into community site
Martin loves Ponies and logs into "Ponies Daily". He wants a site that is quick to load and is user friendly. He has registered for an account so that he can participate in the forums. As one of the more active community members Martin is considering applying to be a forum moderator or a contributor to the blog. He also thinks Pony Daily should add a photo gallery feature where user's can upload and comment on photos of each-other's ponies.

Tarun, Web developer new to Drupal
Tarun works for a web agency and is working on his first Drupal project. He's heard that Drupal has a steep learning curve but in the end it is worth the trouble. Tarun downloaded Drupal for the first time and installed the standard profile (it was the recommended default). He's started to look at the source code and configuration to see how standard is built. Since he's looking at Drupal core Tarun assumes that the standard profile follows best practices within the Drupal community. He's now started to download additional modules to extend Drupal to meet his client's needs.

Jane, Experienced Drupal developer (anti-persona)
Jane works for a large development shop. She typically work with a team of 5 or more on websites for government agencies and major brands. Jane build sites based on wireframes created by the team's information architect and the recommendations of a user experience consultant. The team cares about small details; they don't want Drupal to make decisions for them. The development team starts from scratch with the expert profile or develops project specific installation profiles. The sites that Jane builds regularly have over a million visitors per a week and can experience spikes of traffic well beyond that. It is important to Jane that Drupal is as performant as possible and has solid, consistent APIs.

There's some great content at http://www.d7ux.org/who-is-d7ux-for. The sketches there are still very much valid.

I've also whipped up an initial FAQ on the 'Tsunami' concept and published it on g.d.o. Hopefully it will be a nice place to point people to avoid reiterating common questions. If anyone has objections to the stuff in there feel free to chat about it, but based on the existing discussions I think it's a solid start.

This thread seems to be dying. Reviving it!!

Housekeeping…

Title and priority change reflect the consensus on gdo/Tsunami-Snowman and blogs, IMHO. Continuing..
---

Eve, an event organizer
Eve hosts Drupal users group meetups in local cafes. She wants to work with Suzy, Tarun, Jane, and Martin to create content about each of the group's events. They download and install Drupal with the standard Group Management profile, and then they work together on their event content using the standard editor tools and publication workflows.

Also related:
* #144355: [ideas] Blogging profile
* #1777388: Support arbitrary workflow states
* #1809352: Write tour.module and add it to core
* #79582: Add example content to the experimental out-of-the-box demo install profile
* #1668292: Move simplified Profile module into core
* News article
* Photos
---

Another nice article, worth reading is sun's Pay It Forward, (snippet) which describes the stakeholders:

[s]mall groups collaborating on a project who ... want to communicate with each other and the world ... and our interest... to on-board new people into our local groups[,] [t]ransferring and sharing knowledge. Taking Drupal to the next level.

eaton's Stay Frosty, My Friends is also worth checking out.

And, Snowman (this) should not to be confused with Snowball, which is an initiative for making tools to help collaborating groups manage resources. It would also be helpful for groups, but isn't the 80% use case.

With Views now in core perhaps all is not lost for ☃ in D8. Date and Pathauto may even make it. Some of the biggest blockers for having Drupal do anything OOTB are being resolved. :)

With Views now in core perhaps all is not lost for ☃ in D8. Date and Pathauto may even make it. Some of the biggest blockers for having Drupal do anything OOTB are being resolved. :)

Indeed. Because of the rapid pace of change, my current intention is to wait until feature freeze and aim for a simple Snowman install profile to be released in contrib at the same time that D8 *ships*. If it's judged appropriate for inclusion in core, it would be a non-breaking additive change, and could be rolled into a point release for D8. That approach avoids making the D8 feature push any crazier, and ensures that less time will be spent building on APIs and framework features that will change before release.

@eaton: Please let me know when you want to start working on that + count on me. As you know, we have a 99% matching use-case. :)

I think this is something to be done later, maybe in 8.x-1.x

The spammer assigned this issue to themselves - unassigning :)

Wonder if this can be closed out. Sounds like it was meant to have a "show off" profile which is umami not sure what's to be done.

Following up if this can be closed, if no follow up in 3 months going to close out

This can be closed now that Drupal CMS and recipes exist. Also 'standard' is kinda going away/being merged with minimal in #3159848: Merge the minimal and standard install profiles into a starting point recipe

Since this spanned so many years just crediting every (but myself).