[META] Improve installation profile listing on Drupal.org

These look like solid improvements to me. Do we have the data for most active and most installed? I think OA is installed on 10,000+ sites but when sorting distros by most installed it doesn't show up due to limitations of usage stats. commons_release is on 1,000+ sites but also doesn't show in the top of the main list. Basically I guess these stats won't be accurate until we solve the "package profiles from d.o" portion.

On the search issue, my guess is that solr just needs to be re-indexed. Did you tag them on d.o or w-d.r.d.o? I think search on scratch sites is based on a read only access to the live solr.

Also, great work here!

There is a way to track usage for 6.x: http://drupal.org/project/usage/hyperlocalnews - if the distribution put its feature/support modules inside the profile then it reports usage in a way that works.

I don't think it's worth tracking downloads - too easy to fake.

Three comments:

1. Distro "landing page" needed. The page you land at after you click "Download a Drupal Distribution" should not be purely text / information. It's a great place to do a really great marketing job; and since we're wanting people who want solutions (vs. code) to come here, we should aspire to an effective marketing landing page. E.g. a) a rotating banner with 4-6 distributions featured (see below), b) Karen's "education" about distributions, c) maybe a subnav or faceted search that navigates / searches distros only, and (only) d) then some views with listings, etc.)
2. +1 on Featured distributions. As is mentioned in Karen's PDF, I really like the notion of a Featured Distro. It can resolve the "cold start" problem that distribution builders face: How to go from being the new kid to being widely deployed. A distribution might live on the "new" list only for a short while; and it's not going to get onto the "most downloaded / in-use" list until some point in the future a while. So after a flurry of notoriety on the New list, it falls off the radar, into no-mans-land, and fail to reach critical mass. Being in a banner location for a while gives people (/companies) who have invested a ton of work into their distro a chance to reach critical mass. And there won't be so many distros that we couldn't create some rules around how a distro get into the banner (maybe even get so bold as to sell that space...), and how long a distro is there, etc.

   For the record, I think "Featured distributions" ought to be in the short list of links that's marked as "New" in Angie's mockups above.

3. Module counting.Let me propose a way to count modules. (You may, or may not like it.) With Commons, we struggled with how / where to list it on d.o. We initially thought /project/commons, but because we include CKeditor with the distro, we can't build it on d.o, so we couldn't really post the full download there. We added it to the install-profiles listing, but this wasn't an obvious place to get long-term visibility.

   Simultaneously, we also struggled with how to do update notifications, since there are version dependencies (e.g. the latest version of any given module might not be one that works with Commons).

   To resolve both problems, we created the commons_update module. It's mostly a no-op module itself, but it accomplishes the normal module usage reporting back (assuming phoning home is enabled for the site), and we can also use it to trigger update notifications (by overriding what Commons looks for in updates, and ONLY looking for the commons_update module, burying all the rest).

   So one way to get normal reporting is to require distros that want counted to contain an equivalent distro_update module.

In the documentation, there is Additional distribution documentation, with a list consisting for the most part in the most popular Drupal distributions (with categories: generic, academic, business, community, conservation, event, government, hosting, intranet, magazine, media, nonprofit, performance, social, video, etc.).

However, this list is currently done by hand. And most distributions are downloadable from external sites only, as mentioned by webchick on comment #10. Wonderful that all this is probably near solution.

Great to see progress continuing here, and this is definitely a needed improvement.

Some thoughts here (and the team at FunnyMonkey just spent a chunk of time reading over this issue and talking about internally).

From comment 10: "one of the major pieces of work—one which should be done by the end of the year—is the ability to add external libraries such as CKEditor to distributions"

This is AWESOME! This was one of the blockers that prevented us from hosting VoiceBox (and would be a barrier to our upcoming D7 distributions) on d.o.

In light of the original mockups, I'd say that 4 shifts are needed here:

1. Homepage adjustments - as laid out in the original mockups, distributions need to be introduced from the outset;
2. A "Distributions" landing page - as noted in comment 9 this page is an opportunity to describe the problems that distributions solve, and how they are fairly unique to Drupal. The audience for this page is non-technical/new-ish to Drupal, and the content should be light on text, with ample opportunities to dive deeper into more information as needed;
3. Distributions list page - a list of all distributions; filtering here should be similar to what we have for modules and themes to keep the user experience consistent
4. Individual distribution project pages, which provide an overview of the distribution, etc.

WRT Featured distributions, the criteria here needs to be managed in such a way that it keeps the playing field level. Selling access to the space seems to run counter to the notion of a space that celebrates the work done by shops/people in building the distribution. If we sell access to this, it dilutes the value of it for end users, as it becomes just another spot for another type of ad. Possibly, there could be a process to determine a set of criteria that merits an install profile to be featured, and all distributions that meet that criteria could cycle through the space.

RE counting installs, this seems like a case where we need to decide on a standard method, and then document how to implement that method. Backporting this for D6 does not seem like time well spent; if there is strong disagreement on this I'd be glad to go into more detail. But in any case, any mechanism for counting installs should be an opt-in, and should be separate from the update status functionality, as we need to respect the rights of site owners not to report information about their install.

Awesome!! My 2cents.

* Agree with @bonobo, let's include distributions on the homepage. I'm thinking just add them to the Current activities list... although perhaps the Featured site could also feature some of the nicer distributions.
* On Download & Extend, move Distributions tab just after Core.
* On Get Started, I think the button text should be Find a distribution (or something more representative of what their next step is) ... however sounds like this page needs quite a bit of design... is it right or sane that the 'find a distribution' be the same as an introduction to distributions? I think we can make it work.

The attached screenshot shows one way of featuring distributions on the home page. It does this by reducing the amount of text in the left column, and by reclaiming some space that is currently unused.

This also assumes, of course, that we have a good landing page about distributions that we can link to :)

you can see this in action at http://webchick-drupal.redesign.devdrupal.org/ (user/pass: drupal/drupal)

I've followed some of the successive distribution links, and it looks great (simple user-friendly organization, tabs, etc.). Good work.

Don't know if this belongs here, but on webchick's demo site there would also have to be an additional facet (under 'or filter by…') for distributions on the search result pages.

See also #955928: Split apart "Forums & Issues" in search filters. According to Damien's #17 there on completely rebuilding the index, perhaps it would be better to do both Solr facet changes at the same time.

Updating issue summary.

I wonder, how do users understand the difference between installation profiles and distributions? I am not sold, that we can solve this by adding a handbook page. Can we think of moving installation profiles under distributions, as a subtab orso?

I dont think we should rush adding this to the homepage. Yes, its important. But lets first get this page settled in the website, meassure its use and then consider adding it to the homepage.

Also adding it to the get started page is fine, but now we have two buttons with similair visual importance. That is wrong, it should be either a clearly visisble link with some spacing, or a different kind of styling.

I wonder, how do users understand the difference between installation profiles and distributions?

In most cases:

Distributions -> "Drupal out-of-the-box", "Drupal made easy", "Drupal ready to use". Or, frequently, full-featured Drupal sites, almost ready to use by end users as complete solutions for specialized use cases, with little intervention from site buiders. They are really different from plain Drupal core, including almost always many contributed modules and configurations.

Installation profiles (in their packaged form, or kickstarters) -> Time-saving tools for developers and site builders. Their packages are moderate variations from Drupal core, and usually include few or no contributed modules.

Naturally, there are a few different cases such as generic distributions like Acquia Drupal, or a performance distribution like Pressflow. They are not so ready for end users and need more work from site builders, but are not installation profiles, and are considered special types of Drupal distributions just for site builders.

However, "Drupal out-of-the-box" applies to most distributions. Something like this can be for example in the landing page for distributions, to make it easier to understand by new users.

See also the handbook section Distributions vs Installation Profiles, and the issue #1349778: Create a page that explains what the heck distributions are.

@juan_g I know that we, in this queue know the differentiation. But outside this queue I am very unsure.

I mean, we can make it easier to understand by new users with short easy titles like "Drupal out-of-the box", etc., adding the rest of details in the explanatory text.

Or maybe subtitles:

Installation profiles

Time-savers for site development

Distributions

Specialized Drupal sites out-of-the-box

Or shorter:

Installation profiles

Save development time

Distributions

Drupal out-of-the-box

(Just some possible ideas).

RE:

I wonder, how do users understand the difference between installation profiles and distributions? I am not sold, that we can solve this by adding a handbook page. Can we think of moving installation profiles under distributions, as a subtab

I don't think users understand the difference here, at all. There is no *single* fix for this; it requires a multifaceted approach, and a handbook page (and possibly a subtab) are two ways to help make the distinction clearer.

The confusion is made worse because "install profile" can mean two different things, and getting some clarity on this is covered in #1353610: Improve documentation to clarify the different meanings of "Install profile"

Forget about "distributions" and "installation profiles". The separation is invalid.

Whoever is trying to distinguish installation profiles from distributions is merely adding a layer of complexity that factually does not exist and will not exist.

Forget about "distributions" and "installation profiles". The wording can't get any nerdier.

Whoever is going to read whichever of both is going to run away screaming.

Forget about "distributions" and "installation profiles". They are missing the point.

Users are not interested in technical crap like that. Users are interested in useful products.

"Products" that solve actual "use-cases."

The design mockups here are unfortunately missing the entire point. It's not about providing additional suspicious things you could try as well. It's about replacing THE Drupal download with something useful.

It's not about making Drupal and drupal.org more complex and confusing. It's about the exact opposite: making it easier and more straightforward to get yourself a Drupal; a product that actually does something and solves your use-case.

Drupal core is the worst of all possible choices. It always was and definitely will remain to be.

We have to provide viable choices, so you, as a user, can choose your Drupal, exactly like that.

--
Sorry for this stupidly blunt comment, but we're walking in an entirely wrong direction here.

@sun: I think we are all essentially going in the same direction, only often gradually while for example you usually prefer quicker action.

So, are you proposing to call everything "products" and just feature the most popular/downloaded?

IMO, that seems indeed one of the different possibilities, at least for landing pages for end-users, who don't need technical details. People are working now to make possible that all distributions can be downloaded from drupal.org. Right now, most distributions are downloadable from external sites only, so there aren't any usage/download statistics.

Therefore, the current steps of issues like this are about giving more prominence to ready-to-use products especially useful for end-users, as complete solutions for specific use cases (called distributions), because they are now hidden among development tools for site builders, not very different from plain core (that is, packaged installation profiles). Hence, the need for a differentiation, at least until usage statistics are available, when the most useful products for end-users will go in a natural way to the top of the list.

Sometimes the differences are subtle for developers, since all these products technically work in the same way. So, explanations are difficult, but the differences are clear for users when they look at those products in action.

In any case, hopefully distributions on drupal.org, with usage statistics, will be available in a near future, and your proposal of a landing page for end-users with the most downloaded Drupal products will be then possible.

As someone who maintains my own drupal sites, has experimented with Commons, and has never touched core or the internals of a module, I wonder if this distinction is at all helpful:

- Drupal packaged with modules for particular use-cases, but without any unusual interactions among the modules and with other modules a developer might load

- A more tightly bundled set of modules that involve significantly more complexity when integrating with other modules a developer might add, perhaps because of extreme customization in the distribution

When evaluating Commons, it seemed like adding an additional module could potentially have unexpected effects and, potentially, break everything. There were frequently discussions about whether a given module might work or not.

I don't know if this is particular to Commons or reflects a misunderstanding, but I would very much want to know whether a "package" (whatever it is called) is designed to be easily extended or if how locked into various interdependencies I might be.

Ultimately, whatever you end up with, it would be great to be able to update these "packages" with drush.

Hope this makes sense.

+100 to everything techsoldaten wrote.

I agree that popularity isn't what potential users from various target audiences care about as the primary sort. We can have that be the default sort when you see a listing of distros from a specific category, but first is to find the right category. That said, if we have a full /download/distributions landing page, I wouldn't mind if *one* of the blocks on there was a list of top distros across all categories, something like we have already at /download for modules.

I love your initial list of target audience/use-case terms to classify distros. I copied that into the issue summary and added a few of my own suggestions:
- Development (drupalorg_testing needs a home, too)
- Promotion (e.g. band sites, portfolios, brochure sites, etc)

Case studies like you propose are in the works here:
#948062: Build Drupal Case Studies
I encourage you (and other interested parties) to continue that part of the discussion over there.

Cheers,
-Derek

Suggestion:

Drupal Distributions

Ready-to-use, tailored products for your news, e-commerce, intranet or community site. Learn more...

webchick wrote:

add a Flag (or similar) to the project creation/edit form so when Installation Profile Distribution is selected, the maintainer has the option of flagging it as a _____

It could be a form with radio buttons to select one of two options. For example:

How would you describe this distribution?
(*) A quick-start tool for developers and site builders
( ) A full-featured product for site builders and end users

The first would be the default option.

+1 to #39. That looks great. I don't think we need flag here, since we don't necessarily want everyone flagging the projects. Let's just make it a field on project nodes. In D6, that means a project-type-specific taxonomy vocab. We can form alter the UI to be as juan_g describes. In D7, it could just be a field on the install profile/distribution project node type (bundle).

#39 looks great.

BTW we already have a Sector vocabulary on d.o, which has some of the terms proposed. It's being used by the organization listing in marketplace, and will be used by the case studies as they get built out. We might consider reusing it for the distribution listing. So I've created another issue for this #1360660: Should we use the Sector vocab for classifying distributions? What additions do we need?.

Whether or not we use the Sector vocabulary to cover distributions as described in #1360660: Should we use the Sector vocab for classifying distributions? What additions do we need? is a separate issue from the toggle proposed in #39.

+1 to the suggestion in #39 - it's simple, and provides a good starting point for adding clarity for the end user.

In fact, especially in the Linux world, full-featured is often used to differentiate between user-focused and minimal distributions.

Well, then there seems to be some consensus, at least as a starting point, on the short descriptions in #39 for the maintainer side, and a modified version for the user side in RTBC #1357806: Decide a name for user-focused distributions/products

A full-featured product for site builders and end users

Please tell me:

How many features are required to make up a "full-featured" product?

» Read on in #1205640-54: Implementation and criteria to differentiate user-focused distributions or products from other distributions

A quick-start tool for developers and site builders

So the root cause of this false dichotomy and pointless discussion is that we have a handful of profiles that happen to target a developer audience?

we're doing baby steps here. Let's deal with the situation we have now

I'd love to do baby steps, but you're not. If you would, then you'd:

1. Stop discussing a difference between installation profiles and "distributions" where no difference is.
2. Stop inventing an entirely new project type and project listing. Use and improve the existing listing instead.
3. Stop designing custom one-off flags and properties. Use damn tags to classify projects into Use-cases and Target audiences.

Stop designing custom one-off flags and properties. Use damn tags to classify projects into Use-cases and Target audiences.

@sun: This is what you also say in another post, from a related issue:

The thing is called "taxonomy" and it allows to categorize projects into use-cases and target audiences.

I think there is some misunderstanding. We agree with you about this in most of the details -apart from the tag or field (no flag) implementation-, and indeed this is what is essentialy being done.

About the categories by use case, a taxonomy vocabulary is being discussed for example at #1360660: Should we use the Sector vocab for classifying distributions? What additions do we need? Webchick (see her current proposal, comment #34) and also others have mentioned several times that a categorization is one of the main tasks, as you also say.

And about the classification by target users, the almost consensus for now is a naming that is also frequently used in the Linux world, where "full-featured Linux distributions" are user-focused, and clearly different from small or minimal distributions.

It was already suggested to classify by specific target like developers, builders, users... However, the proposal that has seemed enough for now is just the following to let users more easily find user-focused distributions:

• Full-featured distributions -> all-inclusive products for site builders and end users
• Other distributions -> quick-start tools for developers and site builders

Another posibility, closer to what you say, would be to just add two target user tags, for site builders and end users, to the user-focused distributions. That's indeed something to consider.

Stop discussing a difference between installation profiles and "distributions" where no difference is.
Stop inventing an entirely new project type and project listing. Use and improve the existing listing instead.

That's stopped already, since ten days ago. See, this is another misunderstanding on this difficult topic, and you are replying to the old proposal.

Sun, you are one of the most hard-working core developers, but please read webchick's current proposal (comment #34, December 1), which is different. All distributions will be in the same listing with the same project type. All the previously called "installation profiles" (the packages) will be called "distributions". Naturally, some of them, the user-focused distros, will be filtered/promoted to the landing pages for users as "full-featured", like it's being done for Linux distros. So, the existing listing is being used and improved as you say.

How many features are required to make up a "full-featured" product?

Yes, that's a difficulty we all have about this. And the fact is that the other possible option, a target-user taxonomy tag, would have exactly the same difficulty.

As you suggest, there are indeed a few doubtful, middle point distributions. However, in the current situation of Drupal distributions, we find that the great majority of them have been either fully or little developed, and are easily in one of the two groups. But yes, it's true that this is a non-strict target-user classification just for practical purposes (that is, for landing pages for users).

So, what's the difference?:

Full-featured distributions, full distros, or products, are complete solutions for specialized use cases, ready or almost ready to use as they are, maybe with a little help from site builders. They probably have features that can be enabled or disabled, however all features are built already. No Lego work needed. Examples are:

Aegir, Commons, Conference Organizing, Donor Rally, eRecruiter, Managing News, NodeStream, Open Atrium, Open Enterprise, Open Outreach, OpenPublic, OpenPublish, OpenScholar, VoiceBox, Watershed Now...

Other distributions are tools, sometimes intended for developers, or for testing, or more frequently to be used as a quick-start for the site building process. There are many types of distributions not intended as a product for users but -with exceptions such as Drupal.org Testing, etc.- in most cases they are not very different from plain core, and just a small part of the Lego and configuration work is done. Examples are:

Acquia Drupal, Build Kit, Cocomore Drupal, Commerce Kickstart, Drupal.org Testing, Feeds Test Site, Localized Drupal, Media Development Profile, Multilingual Drupal, Pressflow...

And why this differentiation? Because, for example, users can easily find the most essential contributed modules (Views, etc.) in lists sorted, by default, by most installed. And, on the other hand, it's very difficult for them to find the first group of examples, the full-featured distributions -that is, the products for users-, on drupal.org.

When installation or download stats will be available for distributions, things will be indeed very different, and probably that differentiation by target users won't be as needed as it is now.

That's why. And I really think we all agree on the essential, and the differences of opinion are about details of the implementation: names, categorizations, tags/fields, and so on.

So, let's discuss any alternative plan -apart from doing nothing to improve the service to users, naturally-. What are the alternatives?:

• Target user tags (user, builder, developer...) instead of a field (full-featured)?

The rest seems to be already in the current proposal (#34):

• Unified distribution listing
• Unified project type
• Taxonomy for use cases
• ...

Added list of taxonomy terms for classifying distros via techsoldaten in #36, plus two of my own (development and promotion).

"full-featured Linux distributions" are user-focused, and clearly different from small or minimal distributions

But you do realize that you had to search the net to understand what "full-featured distribution" actually tries to say?

Do you really believe that this terminology means anything to users?

For whom, again, do we want to improve the experience? Geeks?

you are replying to the old proposal.

We have issue summaries. :( Please use them. I've updated it now.

All the previously called "installation profiles" (the packages) will be called "distributions".

I do not see an agreement on that.

And why this differentiation? Because, for example, users can easily find the most essential contributed modules (Views, etc.) in lists sorted, by default, by most installed. And, on the other hand, it's very difficult for them to find the first group of examples, the full-featured distributions -that is, the products for users-, on drupal.org.

Again:

that is, the products for users

KISS, make that button on the front page link to http://drupal.org/project/installation%2Bprofiles?audience=beginner - case closed.

Do you really believe that this terminology means anything to users?
For whom, again, do we want to improve the experience? Geeks?

Some people liked the name "products" (more clear), and other people "distributions" (more open-source). So, a middle point consensus for now has been "distributions" in the name, and "products" in possible descriptions/taglines, like this: Full-featured distributions -> All-inclusive products, complete solutions for specialized use cases (from #1357806: Decide a name for user-focused distributions/products).

KISS, make that button on the front page link to http://drupal.org/project/installation%2Bprofiles?audience=beginner - case closed.

So, basically, now we have two possible good implementations to choose from:

• A field for products for users, or full distros, or similar.
• Or taxonomy tags for the different target users.

Any of them seem perfectly valid solutions. They could be sandbox-tested to see whether there is any advantage for users in any of the two possibilities...

(BTW, the authors data for the issue summary revisions are wrong -I didn't edit it-, and seem affected by the bug #1217286: Posting a comment changes too many issue node revision properties).

Well, let's hope usage stats are available for distros soon; that would solve automagically these distribution issues... ;)

We should try to choose the best available solution, so let's discuss a bit the "only target-user tags" possibility. Not sure if this idea, while also good, would really simplify this issue; maybe yes, maybe not.

Reviewing the long lists of current distributions (at least 168 + 8 with or without project page at drupal.org), the list of possible selections for them in the project form for maintainers is:

1. Just developers
2. Developers and site builders
3. Just site builders
4. Site builders and end users
5. Just end users

There are indeed a few distributions only for developers, etc. However, it's clear that most of the current distributions would need two tags:

• Developers and site builders (for the quick-start tools)
• Site builders and end users (for the full-featured products)

So, if target-user tags are used, there should be an indication that two tags are often needed. For example, probably part of the distribution maintainers would not select "end users" for a full distro or product, given that site builder assistance can be advisable.

And also needed, some description of what a distribution for end users should be: all-inclusive, no Lego work, etc.

The same difficulty about "at what point a distro is full-featured?" appears here with "at what point a distro is for end-users?"

Just my thoughts. Naturaly, other possibility is that I'm wrong and just the following is enough:

Target users

• Developers
• Site builders
• End users

The point is to have an agreement to start with something, this (target-user tags) or the previous consensus (field for full-featured products). It's possible that any of the two implementations, while not perfect, could work for now, and later be improved.

Our target audience here, in order of priority, should start with least technical (ie, end users), and go to most technical, because the least technical users will most likely be:

* the most unfamiliar with Drupal;
* most in need of precise terms to help clarify exactly what they are looking at;
* most unsure of the substantive difference between the different options they will encounter (core, install profile, distribution, product, contrib modules, etc)

Site builders and developers will, in most cases, be more technical, with more familiarity with Drupal, more familiarity with how open source projects are structured, etc. The problems we're trying to address here are more tied to how we can get end users up to speed and familiar with solutions that will address their use cases more effectively.

Or: we are trying to make it so more people can have a great first experience using Drupal. Site builders and developers have generally had their first experience, and they have stuck around for more, which indicates that they have some deeper level of understanding of how the install profile thing works.

Which is all a long way of saying:

+1 to a simple taxonomy of:

* End users
* Site builders
* Developers

Then, we can use existing tags to categorize these things further.

In the case that we use short descriptions in the project form to facilitate an accurate distro tagging by maintainers, then two possibilities to choose from are the following.

The previous consensus (radio buttons, two options):

How would you describe this distribution?
(*) A quick-start tool for developers and site builders
( ) A full-featured product for site builders and end users

(The first would be the default option).

The purpose of this simple possibility is just to make full distros or products more easily available in landing pages for users.

And the other possibility, those short descriptions adapted to sun's proposal of target-user tags (checkboxes, three options):

How would you describe this distribution?
Please select one or two options:
[ ] A testing sandbox for developers
[x] A quick-start tool for site builders
[x] A full-featured product for end users

(The default would be empty; this form would select taxonomy tags for developers and/or builders and/or users).

For example, in this second possible project form, most full distro or product maintainers should select both site builders and end users, because a single target-user option is not accurate for most of the current distributions.

In the user interface, the resulting tags for this example could appear like this:

Target users: site builders. end users

Those distros including at least the "end users" tag could still be called -in the UI- full-featured distributions, full distros, and/or products. And the rest of tag combinations just other distributions for now (from the current consensus in #1357806: Decide a name for user-focused distributions/products).

Or perhaps, instead of just other distributions, two additional distro groups for developers and site builders. That is, calling development distributions, dev distros, or sandboxes to those containing only the "developers" tag. And site building distributions, building distros, or tools to the rest of tag combinations (all of these logically with the "site builders" tag). Of course if we don't just use, to simplify, full distros (or distros for users) and other distros.

So, which one of the two possibilities would be better to use? A simple field for two options (previous consensus), or more complete taxonomy tags for three options (sun's proposal)?

I just did a bit of editing on the documentation page at http://drupal.org/node/1089736/

juan_g has added a lot of improvements and useful information to that page, but there also seems to be a bit of definitional fuzziness. For example, he has added a table under the heading "Full-featured and Other Distributions" that categorizes "the different types of Drupal installations" as: "Drupal core," "Full-featured distributions," "Other distributions" and "SaaS platforms." It feels a little funny to think of Drupal core and SaaS platforms as "distributions." There are also some other types of "pre-configured versions of Drupal" that don't seem to fit in any of those categories:

• There are a number of significant efforts to release pre-configured versions of Drupal in which the method of distribution consists of a tarball including all of the code plus a mysqldump. Instead of running install.php, developers are instructed to import the mysqldump as way of getting set up. This is how the Federal IT Dashboard was released, for example, and just recently data.gov was released this way also.
• CiviCRM and Ubercart both seem to be examples of Drupal+ that could be considered distributions, even though they don't come with installation profiles. Webenabled offers a pre-configured version of CiviCRM.

@juan_g: Multiple taxonomy terms can be combined when filtering a list.

To achieve what we want, projects can be tagged with one or more terms of target audiences,

• Developers
• Site builders
• End users

This means if your project applies to more than one target audience, which can very well be the case, then you simply select the appropriate ones. That said, "end-user" rather is a skill level, not a target audience.

We can tag projects with multiple terms on multiple axes. The axes may be

1. Skill level
2. Target audience
3. Use-case

Given a classification of projects on these axes, we can freely decide what we want to show to newcomers by filtering the project list accordingly. (Therefore, the definition of concise terms is of high importance, but I guess that's for a separate issue.)

Thus, we can decide that people who're entering the install profile list from the drupal.org front page; i.e., those that click this button here:

...we can decide that those people will see the project list filtered by skill level "end-user" (or "beginner") by default; hence, only showing projects that have been built and prepared for this kind of user:

http://drupal.org/project/installation+profiles?skill=end-user

The user is able to adjust that decision and change the filter. Projects that are not tagged do not appear in the filtered list.

Furthermore, it's trivial to add a link to this list for a different skill level/audience in other places. E.g., people landing on the site building guide are likely more interested in

http://drupal.org/project/installation+profiles?audience=site-builders

Lastly, we also need to be careful about terminology. For example, the Drupal community commonly uses the term "end-users" to refer to "people who are visiting the site." I.e., in a sense, the "user" is the one who installs, builds, and manages a Drupal site; the "end-user" is the one who is the "user's user", or one more time in different words, "the user who uses the user's site."

But as mentioned above, concise and clear terms are very important, and it's going to be a challenge on its own to define a solid list. If there is an issue for this already, we should add it to the summary. Otherwise, let's create one.

We can tag projects with multiple terms on multiple axes. The axes may be

1. Skill level
2. Target audience
3. Use-case

@sun: Yes, we could do that, but maybe we are adding unneeded complexity. It's true that use case is a must, and as well target users. Although the simple original consensus with two combined target-user options seems to me enough for the current task (landing pages for users), your proposal with three/multiple target-user options can be also interesting for dev distros, etc.

However, I have my doubts about skill level, which is ok for docs and support, but maybe less practical to tag distributions. For example, the maintainers of Acquia Commons, OpenPublish, etc., will be probably happy to tag their distros as suitable for target users such as site builders and end-users, given that they can be installed and configured even by end-users with some assistance from site builders. And also will happily tag their corresponding use cases (social, magazine, etc.). But, on the other hand, perhaps they will be hesitant about tagging their extensive distributions with the skill level of "for beginners".

In any case, more than finding a theoretically perfect solution, I think the important point is to reach again any practical consensus like we had before, any middle point that can work for the task. At least, until we have usage stats for distros. ;)

It's just an opinion, and probably I'm writing too much, because remarkable members of the community like you, webchick, dww, and others, are those with the weight needed to reach a consensus about these distribution issues.

Drupal core and SaaS platforms as "distributions."

@Sheldon Rampton: I've just clarified that incomplete subsection title, thanks. Anyway the table had already the correct title and description. That is, a comparison of different types of Drupal installations, including types of distributions but not only them. Core and SaaS are the other well-known types of installations, not distributions, to compare differences and similarities, with examples, etc.

And thanks for the other suggestions (Federal IT Dashboard, etc.). I've added also CiviCRM to another handbook page on distributions. I didn't before because some people don't consider it a distribution -core not included-; however, after we add core is -for practical purposes- a distro.

@sun: About the terminology details you mention on end-users, etc., I think all of us are referring to "developers" as those who code the Drupal system, "site builders" as those who put together the parts of the system, and "end-users" as those who operate the system every day, administering content and site users, etc.

That is, we are referring of course to end-users of Drupal, not of the sites. I don't think there is confusion here; no one will think that managing distributions is a task for site visitors. But naturally the word "users" can be used instead, if people prefer it.

We shouldn't think about this like we are coding a comprehensive API system. In my opinion, more than the implementation details if they are clear enough, the really important point is to have some simple agreement or at least majority so that this distribution work can go ahead to better serve Drupal users.

On the other hand, as old Albert said, "everything should be made as simple as possible, but not simpler". Yes, because sometimes reality is not as simple as we think. You know, the thing is to find the good middle point.

@juan_g: I mentioned the Federal IT Dashboard and CiviCRM in part because I think it is important to consider cases where there is some kind of Drupal "distro/installation/product" that doesn't include an installation profile. An installation profile is a technique for sharing a particular preconfigured Drupal solution, but it isn't the only technique available for doing so. Discussions of Drupal distros thus far have tended to assume that distros are a subset of installation profiles, but that's not always the case. This may have implications for how to best create a useful listing of distros. Should the goal be to "improve the installation profile listing" as the title of this ticket suggests, or should it be to "provide a useful list of available distros"? If the goal is the latter, and we want to include cases such as the Federal IT Dashboard, simply tagging projects of type "installation profile" may not suffice.

The focus is on installation profile projects maintained and hosted on drupal.org.

These other distributions and forks that happen to contain Drupal are what people actually understand as distributions; a software that contains Drupal is developed, maintained, hosted, and distributed by a third-party vendor, not the Drupal project nor the Drupal community, and only god knows how many hacks and changes they contain. They lack behind in releases, especially security releases, and the Drupal community is not able to support them in any way, because system and design parameters are entirely unknown. It is good and beneficial to outline on a handbook page that these profiles/projects/products are not officially endorsed by the Drupal community (you have to consult the respective vendor to learn whether and how well they are supported). But aside from that, they do not matter in this effort of better promoting installation profiles on drupal.org.

@Sheldon Rampton, @sun: Currently, the community is actively working to remove the obstacles (with white listing of third party libraries, etc.) that don't yet allow complex distributions to be downloaded from drupal.org. Distro maintainers usually say they also want to be on drupal.org, not only on external sites. See:

• Drupal.org distribution blockers
• Community Initiatives: Distribution Packaging

Also, please see the current webchick's proposal (#34). From the comments in these issues, the community seems to be agreeing on this proposal. For example, all install profiles (the packages) will be named "distributions"; install profile will be just a technical name for the install code:

a) Rename Installation profiles to Distributions on D.o. That gets rid of the confusing "two separate meanings for install profiles" problem, as well as the "Distributions are a bundle of stuff too! Why are they different than install profiles?!" problem. Install profiles then become "a bundle of code in the /profiles/ directory", and Distributions become "a package of one or more install profiles + their required modules/themes/libraries from Drupal.org".

(...)

And, in addition to the complete distribution listing, the subset of distributions for users (also called full-featured distributions, full distros, or products) will be more directly promoted on landing pages for users.

These are some of the main goals of all these related issues.

the community seems to be agreeing on this proposal. For example, all install profiles (the packages) will be named "distributions"

Again, there is no agreement on this yet. Major concerns were raised, not only by me but for example also by @Bojhan, who's one of Drupal's Usability team leads. The last screenshot (#52) purposively used a different terminology that's more oriented towards end-users. This requires more discussion over in #1357806: Decide a name for user-focused distributions/products

But as already noted and clarified many times, the exact naming is less important; it's just a string that may be changed later on. Until then, we can continue to work on the structural and organizational changes.

The issue summary already contains an action plan. The next logical step is to actively discuss and work on the project classification terms and vocabularies. Figuring those out will vastly help in the remaining decisions we have to make.

I already asked in #52 whether we have an issue for that already - is there one? If not, create one?

Regarding adding some simple taxonomy labels: Attempting to qualify various projects via taxonomy is perhaps a useful approach, but do the proposed tags help? What does "skill level" mean? Skill in what? Systems administration? PHP? Where to find the double-secret buried Drupal configuration settings? Skill level required for installation? Skill needed for site maintenance? Skill needed for additional customization?

For example, Open Atrium is pretty darned simple now to install and bumble through configuration, but you'd better want what OA gives you out of the box because customization requires not just Drupal expertise but real comfort with Features and perhaps some "hotsauce" knowledge. So what skill level rating should OA get?

I wish I had an easy answer, but this takes some serious thought and ideally some user testing.

But as already noted and clarified many times, the exact naming is less important; it's just a string that may be changed later on. Until then, we can continue to work on the structural and organizational changes.

@sun: On the general structure, there seems to be consensus now. Before, there were concerns (dww, Bojhan...) about the old proposal of separate project types for "distributions" and "install profiles".

Now, after the proposal was modified on Dec. 1, all (for example you, webchick, dww, etc.) seem to agree on the current structure with an unified project type for distros, apart from implementation details about possible names (install profiles, distributions, products...), about fields or tags to filter user-focused distros, etc.

The next logical step is to actively discuss and work on the project classification terms and vocabularies. Figuring those out will vastly help in the remaining decisions we have to make.

I already asked in #52 whether we have an issue for that already - is there one? If not, create one?

About the taxonomy possibilities, dww already explained that there is support for project-type-specific taxonomy vocabularies. As said, an issue is open on taxonomy for use cases, but I don't know about other related issues yet.

For documentation pages, we have the following.

Level:

• - None -
• Beginner
• Intermediate
• Advanced

Select the skill level of the page.

Audience:

• - None -
• Developers and coders
• Documentation contributors
• Site administrators
• Site users
• Themers

Intended reader type.

It's clear that this should be different for distributions. No need for skill level I think. For example, you proposed to consider more specific terminology about end-users or users. A possibility would be for example site administrators or admins.

Target users:

• Developers
• Site builders
• Site administrators

Or with short descriptions like in comment #50.

Thinking a bit more on the possible tag I've mentioned, site administrators, I'm wondering what new Drupal users would say:

- Did you try that Portfolio thing with Drupal for your personal site?
- Hell no, it was tagged for "site administrators". That must be some device for rocket scientists...
- But you have a site, you are a site administrator.
- Really? I just wanted to use Drupal.

Well, better we keep it simple and just say users or end-users of Drupal.

@juan_g: If you say "users or end-users," won't that create confusion with "anyone who visits the website"?

How about the term "site builders" or "website builders"? That might sound less formidable than "site administrators."

@Sheldon Rampton: Please see comment #54 about those details.

It's clear that this should be different for distributions. No need for skill level I think. For example, you proposed to consider more specific terminology about end-users or users. A possibility would be for example site administrators or admins.

Target users:

Developers
Site builders
Site administrators

I don't think this is "clear" at all. (It's not all that clear for documentation, either, but that's a different issue.) The very same people are going to be looking at building a site a la carte, with core plus various modules, vs. going with a distribution.

I thought the whole idea of clarifying the Profiles/Distributions "stuff" (i.e., all of it) is so that more people are aware of their options and what they may be able to accomplish with such. Well these people are asking themselves the same questions as people considering going a la carte, because they are the same people: folks who are looking to create a website/webapp for their own project.

The proposed breakdown of "users" doesn't help, imho. I don't understand how a distribution could be for Developers but not site builders, or site administrators but not developers. Where would Open Atrium fall? On the one had, you could say "Site administrators" might very well muddle through installing and setting up an OA site. On the other hand, you could say that it will take "Developers" -- and quite expert developers at that -- to customize OA beyond what it's already built to do.

We really need a taxonomy that is more meaningful, to address what these distributions are to the people seeking solutions for their own projects. A taxonomy focused on their questions, not on our assumptions of how to categorize them. For example, a taxonomy that describes ease/difficulty of installation, customization, maintenance, theming, etc.

We really need a taxonomy that is more meaningful, to address what these distributions are to the people seeking solutions for their own projects. A taxonomy focused on their questions, not on our assumptions of how to categorize them. For example, a taxonomy that describes ease/difficulty of installation, customization, maintenance, theming, etc.

@laura s: That could be useful. It would be good for an issue on classification terms and vocabularies that sun has suggested to open (#58).

In any case, apart from that, it's not necessary to spend years in the distribution issues designing a perfect system. We can start with anything simple that works for the users (especially, with a classification by use cases: publishing, social, nonprofit, etc.), and then gradually add improvements as needed by them.

sun wrote:

The next logical step is to actively discuss and work on the project classification terms and vocabularies. Figuring those out will vastly help in the remaining decisions we have to make.

I already asked in #52 whether we have an issue for that already - is there one? If not, create one?

For the project classification possibilities proposed by sun, there have been several suggestions from laura s and others, such as: customizability, extendability, upgradability, ease of installation, ease of maintenance, compatible themes, compatible modules, command line or UI, security...

They could be implemented as taxonomy vocabularies with terms like "high, medium, low", etc. Or for now like questions to reply in the distribution documentation, or in feedback by users (reviews/comments) proposed by techsoldaten (#36).

At this moment, issues for the distribution classifications more discussed, and therefore apparently with the most priority are:

• Classification by use cases (academic, business, government, media, nonprofit, personal, publishing, social, etc.):
  An issue was already open, #1360660: Should we use the Sector vocab for classifying distributions? What additions do we need?
• Classification by primary use (quick-start tool, full-featured product) and corresponding target users (developers, site builders, end users):
  A new issue has just been opened with the different proposals, #1372386: Classification by target users in project forms for distribution maintainers

Updated summary.

Updated issue summary, according to webchick's current proposal (#34), and other suggestions from the community (sun, dww, techsoldaten, lisarex, laura s, etc.). That's my first edit on this issue; others are from webchick, dww, sun... The dates and authors listed for the revisions of the issue summary are unreliable and misattributed to comment posts (bug #1217286: Posting a comment changes too many issue node revision properties).

Updated issue summary, according to webchick's current proposal (#34), and other suggestions from the community.

Alternative naming suggestion (installation profiles) from sun's #56.

Minor edit for clarity.

@webchick: I don't know if you've read my
comment #42 in Decide a name for user-focused distributions/products, but I think it has some relevance to your current proposal. I think this discussion about installation profiles/distributions/helping new Drupal users is going around in circles because people keeping treating those three concepts and the related terminology as interchangeably when in fact those are three different things, three different concepts. By using the same terminology interchangeably to refer to different things, we've created a kind of "who's on first" conversation that isn't quite as funny as the Abbot and Costello routine. I think renaming "installation profiles" to "distributions" as you've proposed merely perpetuates the "confusing double-meaning of the 'installation profiles' term" rather than eliminates it.

I don't much care whether my exact proposed terminology is adopted, but I think clear definitional distinctions are going to be necessary in order to truly improve or clarify anything. The three separate concepts we're dealing with are: (1) "the .profile files in the /profiles directory" (which I'm referring to here as "installation profiles"), (2) the "collection of code" that includes a version of Drupal core + possibly additional modules, themes, profiles and libraries (which I'm referring to here as "distributions"), and (3) the "polished," easy-to-get-started-with versions of Drupal that we want to "help new Drupal users to discover" (which I'm referring to here as "products").

Renaming "installation profiles" to "distributions" doesn't help anyone understand those distinctions, and it won't help new Drupal users. When they go to the installation profilesdistributions page, they'll still be dealing with a listing of projects that range from OpenPublish to places where someone has "barfed out a .info file with all the cool modules I use on my sites and have it showing up next to Open Atrium or Portfolio as a viable alternative to Drupal core" (to use your words from the beginning of this issue). Only some of those project pages will include a link that lets people download the full "distribution" (as I'm using the term). Some will have a link to an external website where people have to go to download the full distribution (for example: OpenPublic). It will still be the wild wild west, where anyone can start a saloon and you have no idea which ones are safe to walk into.

If we get in the habit of clearly distinguishing between "installation profiles" (the .profile files), "distributions" (the full "collection of code"), and "products," I think it becomes easier to identify some ways to improve things.

1. Add a "distribution" field to the "installation profile" content type with a URL that people should use to download the full distribution. This will ensure that there is a standard place in the layout of project pages where people can go to download a full distribution compatible with that installation profile. It will also establish a clear distinction between installation profiles that have distributions and installation profiles that do not have distributions.
2. Possibly add some other fields along the lines that Karen Borchert suggested in her proposed "merit-based criteria" for distributions. I think the contents of those fields can be used to unambiguously and automatically determine whether something is "polished" enough to be classified as a "project." (If those fields are all filled in, it's a "product." If they're blank, it's just an "installation profile" or maybe an "installation profile with a distribution.")
3. Other than that, leave the "installation profile" section of Drupal.org pretty much as is, but generate a separate, shorter listing of just the projects that meet all of the criteria needed to be a "product."
4. Improve the documentation pages on Drupal.org so that they clearly explain these distinctions, which currently is not the case. (For example, the documentation page on Installation profiles and distributions states that "even downloads labeled as Installation Profiles are really Distributions, thanks to the packaging script which bundles the installation profiles up as full distributions." This is not actually true.
5. Announce and highlight the "products" listing on the d.o. homepage.
6. Profit!

OK, I guess I was a bit confused. Your previous post referred to comment #39, not #34, so I didn't read #34 before posting my comments earlier today. (This has been a long and winding thread, and me gets lost sometimes.)

It sounds then like your proposal is reasonably close to what I'm thinking, but I do have a couple of caveats:

(1) Using a flag to distinguish between "distributions" and "products/full-featured distributions" seems still like too simple a system to properly distinguish and inform users. It still gives you no way to clearly distinguish between "installation profiles" and "distributions."

(2) The language suggested for the two flags seems to me to allow for more ambiguity and confusion than you're imagining. Suppose, for example, that someone has the aspiration to build "a full-featured product for site builders and end users," but they've only just begun writing the code for it, so it is in a very unusable, alpha state. They might nevertheless check the flag which includes it along with Open Atrium and Open Publish, etc.

I therefore still prefer the ideas I floated above:

• Add a field for entering the URL where people can download the distribution, if there is one, which has been packaged to work with the installation profile.
• Add some other fields to provide a structured way of requesting information that can make it possible to determine whether an installation profile belongs to something that meets the criteria suggested by Karen Borchert.

Having said that, I think your proposal is better than not trying anything at all. If other people don't agree with my suggestions, I'd support going ahead with your proposal.

+1 to what webchick has in place. It's a great start, simple, and allows for growth/expansion/change over time.

RE:

Suppose, for example, that someone has the aspiration to build "a full-featured product for site builders and end users," but they've only just begun writing the code for it, so it is in a very unusable, alpha state. They might nevertheless check the flag which includes it along with Open Atrium and Open Publish, etc.

This is a documentation issue. People seem to have one of two choices:

1. Tag it as "full featured" and create a dev branch, and mark on the project description that the distro is under active development.

2. Tag it as a developer-focused tool until it's fully baked - then, update the project to indicate the "full featured" status, and cut a point release.

Either of these are viable options, but the larger point here is that we're not going to come up with a technical solution that addresses all of the various ways people interpret what distributions are. What we can do, however, is create a structure that is a little more clear, and improves on what we have now. We will continue to make incremental improvements.

The use of distributions is just going to increase. They're useful, and they're not going away, and our understanding of them will likely shift as their usage becomes more mainstream. We need to improve what we have now, in a way that allows for additional adjustments over time.

webchick's proposal charts that course very well.

Perhaps I'm mistaken, but it seems to me that whatever we call these bundles, a particular bundle of Drupal, modules, and possibly "elbow grease" could range along a continuum from:

- most other modules should play nicely with this bundle

to

- everything is tightly coupled by design and expect other modules and individual updates to break something. Waiting for official updates of the bundle is highly recommended

Is this an accurate assumption and is it, or should it be, captured in some way?

@jsibley, I think there is some kind of continuum on which distributions could be ranked with respect to being "tightly coupled" vs. "loosely coupled," but measuring that is somewhat subjective, and there are lots of other ways that distributions could and should be ranked. For example: quality of documentation; stability; quality of UX. There is therefore a lot of room to debate which of these attributes should be "captured in some way" and how to capture them. I think this is why webchick is simply trying to implement a flag at this point, which I understand.

Regarding Gerhard's position on adding links, I hadn't considered that point. I can see how that makes it impossible to add the link I suggested, although right now I'd say Gerhard's rule is rather porous in practice. There are plenty of module and theme project pages where they have put in links to the project maintainer's website. For example, the Corporate Clean theme inclues a link in the project description to the sponsor's website and Flickr page for seeing a live demo, screen shots, documentation, and for contacting the sponsor. When it comes to installation profiles specifically, the OpenPublic project includes a link to Phase II's website for obtaining "a full Drupal install." The download directly on the d.o. project page for OpenOutreach project just gives you the bare-bones installation profile without even its contrib module dependencies, and links to the OpenOutreach.org for obtaining the full distro. I could go on and on with examples like this. I don't think the current state of things is really stopping people from linking to their outside websites. All it does is ensure that the links are not in a consistent location on project pages, which makes it a little harder to find them.

Anyway, none of this is an argument against going forward with webchick's current proposal as stated in comment #34, which I agree is an improvement. My one remaining concern is that renaming "installation profiles" as "distributions" seems to contribute further to the confusion between those two concepts rather than eliminating confusion. If the "installation profiles" section on d.o. is renamed as "distributions," users who go to the ngpprofile project page will be expecting to find a distribution there, when in fact all they get is a makefile, shell script and .profile file. I would therefore personally prefer to see the other aspects of webchick's proposal adopted while retaining the current name for installation profiles. That's just my opinion, FWIW.

For example, the documentation page on Installation profiles and distributions states that "even downloads labeled as Installation Profiles are really Distributions, thanks to the packaging script which bundles the installation profiles up as full distributions." This is not actually true.

@Sheldon Rampton: Thanks for this detail. On that handbook page, I've just added a small clarification using "many of the downloads" instead of "downloads" in that phrase about install profiles packaged as distributons (with core, etc.), since part of them are not using this packaging option. For example, especially old install profiles, and also project pages of current distributions downloadable from external sites, of course until there is whitelisting of third party libraries on drupal.org.

Related info:

• Fully packaged Drupal distributions now deployed on drupal.org (2009-12-01)
• Packaging a profile on drupal.org
• Community Initiatives: Distribution Packaging

If the "installation profiles" section on d.o. is renamed as "distributions," users who go to the ngpprofile project page will be expecting to find a distribution there, when in fact all they get is a makefile, shell script and .profile file.

Yes, that can be a problem with that part of the install profiles. However, surely maintainers are not going to tag those as full-featured. It would be unreasonable to expect end users to run command-line drush make, etc. to build distributions from install profiles. Therefore, they won't go in the more promoted listing of full-featured distributions or products for users, but in the extended, complete distro list for developers and site builders.

Although those install profiles are easily distinguishable from packaged distributions (just some KB for profiles, vs one or several MB for distro downloads), maybe also in this case notes on the project pages could be useful.

@ juan_g: wrote:

Yes, that can be a problem with that part of the install profiles. However, surely maintainers are not going to tag those as full-featured.

Correct. However, webchick's proposal in comment #34 will tag it as a "distribution," and the ngpprofile project is not a distribution.

Webchick is proposing that we rename "installation profiles" as "distributions," and then that we have a flag which distinguishes between "full-featured" and not-full-featured distributions. That would be fine if there were only two concepts in play, but not when there are three, as is the case here: "installation profile," "distributions," and "products/full-featured distributions."

@webchick, I fully support going forward with your proposal in its current form and tweaking it later as needed. Please don't construe my caveats as an argument against going forward.

These suggestions are really positive for Drupal. We should have a landing page for Distributions that explains "what Drupal does" with Distro examples in various verticals. It is so impressive yet hidden from the general public. It is important to note those without a Linux background don't understand distros, it is not as widely understood in the mainstream business world..... those that will expand Drupal's reach. We have the Distro Summit on January 25th and this will all be great to discuss.

webchick wrote:

Same as the list at /projects/modules defaults to showing only Full projects, not sandboxes, to try and push the most useful stuff to the front. You can still get to the non-full-featured distros (and sandbox modules), but you have to dig a little more, and that's fine for people who know what they're looking for.

Possible filter options for drupal.org visitors, to workaround the naming problem mentioned by Sheldon Rampton (that is, the current mix of KB install profile and MB distribution downloads), could be something simple for now like:

• Full-featured distributions
• All distributions and installation profiles

Later, a more detailed list could be added. Probably there are some simple ways to detect which install profiles are using or not drupal.org's distro packaging system, at least by size (MB vs KB). In this case, the filter list could be for example:

• Full-featured distributions
• Other distributions
• Installation profiles
• All distributions and installation profiles

Note: the drupal.org database knows exactly what releases are "fully packaged distros" vs. "just the install profile". For the fully packaged distros, we provide a table on the release nodes showing what stuff got packaged up with the install profile to create that distro release. Since this info already lives in the d.o DB (look at the {project_package_*} tables in the DB if you want the gory details), it'd be relatively easy to stuff it into solr (via project_solr) and add filters to the download pages accordingly.

Cheers,
-Derek

I've tried sampling a number of projects currently listed under installation profiles and am seeing a variety of results when I download the tarball.

1. Some, like the ngpprofile project page, are just a bare-bones .profile file with maybe a makefile.
2. Some give me a tarball of all of the modules, etc. that would go inside /profiles/myprofile.
3. Some give me a tarball of an entire version of Drupal core, plus the /profiles stuff.

Personally I would define a "Drupal distribution" as #3 above. I would call #1 an "installation profile" and maybe call #2 a "profile package." I think it is even possible to envision scenarios in which the same installation profile might be part of more that one different distribution, as well as scenarios in which a Drupal distribution might contain more than one installation profile. (For example, suppose someone decides to create a distribution that consists of Drupal+CiviCRM + OpenPublish.)

The idea would be to have both the "full-featured" tag or field (decided by each distro maintainer) and the automatic "fully packaged" status (which dww has mentioned). That is, full-featured for end users, and fully packaged with Drupal core and dependencies:

Notes:

About the n/a, if a maintainer of an install profile not fully packaged with core, etc., selects the "full-featured" tag by mistake, this tag would not be applicable to that project, which would still be considered an install profile.

For example, an special case is CiviCRM, often considered a full-featured distribution for nonprofits (downloadable from a external site), even when it does not include Drupal core because it can work with either Drupal or Joomla. Given that drupal.org is going to be more distro-friendly soon, let's hope a Drupal version of CiviCRM can also be downloaded from here, and fully packaged with core so that it can be considered the full-featured distro it is in practice.

Re: #83: Yeah, I wasn't claiming the "fully-packaged" bit is essential for helping end users find what they're looking for, or that it's particularly relevant to the question of "full-featured"/"polished", etc. I was just answering juan_g in #81: "Probably there are some simple ways to detect which install profiles are using or not drupal.org's distro packaging system...". I'm not advocating we must do this. I'm just explaining how to implement it if we decide it's a good idea. ;)

Re: #84: Yeah, those are the 3 kinds of packaging drupal.org does for install profiles. See these two pages juan_g linked above:

• Fully packaged Drupal distributions now deployed on drupal.org (2009-12-01)
• Packaging a profile on drupal.org

I don't want to hijack this ticket away from its intended purpose, which is improving listings of installation profiles, but this whole discussion has gotten me thinking a bit about some design aspects of installation profiles. For example, there may be a case for separating the "installation" from the "profile" part. An installation profile is designed to run once and only once upon site installation, but then some of the "profile" part (such as module dependencies) becomes an immutable constraint upon site configuration that cannot be changed after installation. Rather than start that discussion here, should I create a separate ticket? Is there someplace else where that kind of conversation could happen?

@webchick: I'm a bit confused. When you say you "don't want to go down the road of making 'installation profiles' the name for anything other than the bundle of code at /profiles/xxxx," you saying you're now not planning to rename "installation profiles" to "distributions" as stated in comment #34?

Also, by "the bundle of code at /profiles/xxx" are you referring just to the the bare-bones .profile file, .info file and makefile needed minimally to define an installation profile, or are you referring to that code plus all of the contributed/hacked modules, themes, libraries etc. that go inside /profiles/xxxx"? Just want to make sure I understand.

@webchick: However, I think some of Sheldon's confusion in #84 and beyond is that not every install profile project on d.o is providing a drush .make file and getting turned into a distribution (to use the currently agreed-upon terminology). So, what happens when you land on a tab called "Distributions" with a listing of projects, find one that looks promising, download a release, but all you get is the install profile? Do we care? I think that's the concern with this rename. Unless we also add a filter like I was talking about in #82... But then what do you call the filter? And/or do we leave somewhere where you can find the install profiles that aren't distibutions?

What a mess. Sometimes I really hate Drupal. ;)

@dww, @webchick: Yes, that possibility of partially keeping the "installation profile" name in some cases -mentioned by Sheldon and me- is just a complementary idea for the rather collateral damage ;) or secondary question: What we do with those downloads that are not fully using drupal.org packaging possibilities and only contain a .profile file, maybe a .make file and little more, and not core and dependencies? Are they also distributions?

Naturally, we are not referring to the full-featured distributions on external sites now, that will be downloadable from drupal.org soon. We are talking about a part of the installation profile downloads on drupal.org not packaged with core as distributions. An additional example: Spaces 3 demo.

Anyhow, since they are not intended for end users and hopefully won't be tagged as "full-featured", it's not so much important whether they are called "installation profiles" or they go mixed for now in "other distributions" for developers and site builders, since they can build a distribution or site with those small downloads and drush make, etc.

As webchick has suggested, the important point in this current issue is to deploy something as a needed start for the full-featured distros for users. And they are not affected by those other downloads, that can be taken care of later.

Of course, unless there is any simple workaround that solves it for now without delaying the main work here.

@webchick: In some cases, yes, they mention the current drupal.org restrictions. In other cases they do not mention them (for example OpenAcaDept, etc.) but I've just looked at some .make files that indeed include references to external libraries. Some others not, but they are old installation profiles (such as Drupal Hebrew Installation Profile, for Drupal 5, with just .profile and no .make file).

It has been a quick file review, and of course I'm not really sure about all the 172 install profiles, but possibly you are right and a greater number will be fully packaged soon, when restrictions are reduced. Maybe we can wait to see what happens, if you don't think it's a good idea to use a "installation profiles" classification for those cases.

Or possibly it would be nice to at least warn the users with a note in the Downloads sections of those project pages such as "This is not a fully packaged distribution, and requires you to build it", or something similar, because it is not clearly said in many cases. This could be done automatically with dww's filter.

So, we can do it now, or wait and see after the whitelisting for external dependencies.

So, we can do it now, or wait and see after the whitelisting for external dependencies.

This sounds like a good approach. Once we start tagging distributions, we can use this (along with the text-based project descriptions) to further refine the info that is given to (and targeted at) less technical end users.

Splitting off part of #95 into a related but separate issue: #1393528: Automate a visual indicator on fully-packaged distribution project pages

About comments #5 to #9 on this issue, I've just opened the new issue #1421972: Usage statistics for distributions.

Some assistance on technical details would be wonderful. For example, on how usage statistics are working now for Commons, a D6 distribution, without need for an .info file or an already removed distro-specific module (since two weeks ago).

The issue in the previous comment (#98), just fixed with the new handbook page Usage statistics for distributions.

That is, distributions have usage statistics available, and the docs now explain how, thanks to dww.

Just did a quick review of the updated dev site.

+1

FWIW, the reworked dev site solves the issues flagged at #1469148: Clean up links for install profiles at /download

Overall I think the changes are fine, but I question the language used on the homepage and getting started.

/home

Distributions package and configure themes and modules for feature-rich web sites. Current distributions include online communities, media, e-commerce, and more!

This feels like a text that I would do some form of A/B testing to see what entices users to try out distributions. I'd probably reword it to something like:

Distributions are a collection of pre-configured themes and modules for feature-rich web sites giving you a head start on building your site. Build your own online communities, media portal, online store, and more!

/start

Drupal distributions are pre-packaged collections of modules and themes, designed for specific types of sites.

Again its rather bland, but then again so is the current core text:

Drupal core is a collection of files that you download to get started with Drupal.

My suggestion would be to care less about the files and more about the opportunities Drupal gives users.

Drupal core contains the essential building blocks providing you a flexible foundation to get started with Drupal.

[Download Drupal]

Drupal distributions provide community made installations allowing you to quickly setup a fully featured Drupal site.
[Find a distributions]

I also don't think the link on "distributions" should point to /documentation/build/distributions in its current form at least, I was expecting it to take me to a list of currently available distributions.

Code wise there are a few cases of double quotes being used where singles would do, and the indentation of the HTML code seems inconsistent (single space vs double space). Not sure how important coding standards are to the drupalorg module.

Regarding the language, I'd also suggest a prominent link to a (yet to exist?) documentation page describing pros and cons of distributions. This is important especially for newbies who may not understand the complexities of going with a distribution, especially if Features are involved to any great degree. Otherwise I fear we get backlash from people in angst over delayed security updates, inflexibility of changes to defaults, incompatibility of otherwise popular modules, [fill in potential complaints here].

Years ago newbies had the CivicSpace option. At first it seemed just dandy and wonderful, but then they felt trapped when wanting to grow beyond that paradigm. You see a lot of issues people encounter dealing with Open Atrium, too. (Not to pick on OA, but it's a distribution I'm quite familiar with.)

In general, Distributions may seem easy, but imho they're a choice best opted for by experts, not novices. I feel it's worth voicing some caveats as we drive new users to the Distributions page.

I have that tab open, ready to add a child page that will at least be a stub, hopefully a draft. Always welcoming improvement.

Just added the following update to the handbook page Usage statistics for distributions:

Download statistics

Update: In addition to the usage stats, and since April 6, 2012, download count has been deployed on project pages, including distributions. The default sort order is still by usage.

This is really useful for distributions, at least until more distros do the necessary steps to enable usage stats for them. As an example among many, from the NodeStream project page today:

Reported installs: 1 site currently reports using this installation profile. View usage statistics.
Downloads: 3,773

Didn't realize how much of Drupal.org was hard-coded in a custom module. Is this some stuff we could replace with a few menu blocks?

+1 on @webchick's revisions from 109.

Committed, with manually applying the drupalorg_crosssite parts, and a couple small code style changes.

• http://drupalcode.org/project/drupalorg.git/commit/210a838
• http://drupalcode.org/project/drupalorg.git/commit/753c8e5
• http://drupalcode.org/project/drupalorg.git/commit/8e2fe21
• http://drupalcode.org/project/drupalorg.git/commit/a28960f

This is on http://staging.devdrupal.org/ for any last minute review. Looks okay for my spot checks.

For why this is hard-coded - sometimes code is better than configuration because we can review and deploy it like we are doing here. Like any Drupal site, we have to find the right balance for where to keep things. Changing it is a separate issue.

WOO HOO!

Deployed

Deployed

So, it's now live on:
http://drupal.org/
http://drupal.org/download
http://drupal.org/project/distributions
...