Implementation and criteria to differentiate user-focused distributions or products from other distributions

We generally do not link to stuff that is not on d.o.

I am also not sure that distributions are generally easier to grok than a plain Drupal core.

I say -1. Install profiles is what those projects technically "are". We wouldn't add another project type called "plugin" that's somehow different from a module, and I don't think that we should do that here.

Instead, can we have some way to flag an install profile as either a product or a utility distribution? Product = OA, OpenPublic, etc. Utility= commerce kickstart, media_dev, etc.

I think that would be the way to go here.

But aren't all install profiles really a sort of distribution? Why not instead rename "install profiles" to just "distributions"? That would probably need to be done both on d.o and in core APIs. Which probably alsp makes this a little bit bigger task. But still.

I could imagine that people installing a CMS are more familiar with the concept of "distributions" than "install profiles", not? I'm thinking about the whole Linux thing and other web platforms starting to adopt it too (http://symfony.com/doc/current/book/installation.html).

Edit: I realised that I didn't read the OP carefully enough, where webchick already neglects my thinking here. Sorry for that :P But still, my opinion still stands.

Note that there's support in Project* for project-type-specific taxonomy vocabularies. See #371957: Add customized per project type related vocabularies for where that was added and #852342: Configure extra fields for theme projects as the primary motivating use-case for it (side note: that still needs someone to drive it home).

If the real problem here is distinguishing between "polished" end-user-friendly distros and other stuff, we could easily have a vocab to capture the distinction, put that in the solr index, etc.

This is actually something I've thought about quite a bit over the past year or so.

While I the "I've used Drupal for a million years and I know where to find stuff when I need it/keep up with stuff in the community to know enough about the different distros/install profiles" part of me totally agree that projects not on d.o shouldn't be linked (though there are some notable exceptions), the community advocate in me feels the opposite. I really don't think it's a bad idea to move in a direction that would make finding distros easier for people that are new to Drupal.

If anyone was in Eaton's talk at DrupalconChicago about Snowman (formerly Tsunami), this conversation probably seems a little familiar. By including these projects on d.o, it makes them easier to find if the user is specifically looking to use a Drupal-based solution for whatever their need is. This may keep some of the "Drupal is too hard/it's too hard to put together what I need/the learning curve is steep" users from leaving in frustration where a distro may exist for what they're looking for.

Obviously the decision for whether or not a specific project ends up on d.o is completely up to the dev(s), but I think that those that have created something that maybe fits a smaller use case than, say, Open Atrium, has a chance to be found. So really, it is helping both the user and the dev(s).

This only brings up questions of where the issue queue lives (OA, for instance, has theirs on their own site, not on d.o), which, without consistency, can also be confusing to users.

To your last point - that I can understand. Just wondering if the convenience and user experience of being able to find solutions in one place outweighs the additional burden it'd put on d.o.

-1. Installation profiles and distributions are one and the same thing they do not differ neither technically nor by intent (at least for those hosted on drupal.org).

The actual problem we have is that we don't track usage of distributions well. As a consequence, the order on the Installation profiles page is not meaningful at all.

How could we improve that?

I see the necessity to say "this is web application you can use *right away* with turnkey installation, that you can further extend/change (because it's Drupal!)" ( == distros). I'd be wary of adding in adjectives like "polished" to apply to all distros.

IIUC we're just talking about having a site section on DO for them; not change any documentation, APIs nor anything else. If so, +1.

However, I hope this won't mean we also have to think of modules that are "too basic" vs. those that aren't.

So... some [rather obvious] tasks to figure out:
* What the IA would be to have a distro section. Perhaps there would even need to be categories inside that section.
* What the process would be to evaluate and have something qualify as a distro. (what the rules are, who gets to do it, how often, etc.) Perhaps a similar process to sandbox=>project reviews?

We've got a similar discussion going over here [#3552890]. Bottom line: people are confused with the current setup.

We want people to use distributions, we need to better explain what they are and why they are useful.

Having two separate project types as webchick suggests doesn't seem like a big deal to me, but a content type + view would work great as well. It means we can treat them differently, targeted to their intended audience. I helped a gentlemen in #drupal-cod that had no prior experience of Drupal. He wanted to make a conference site, but had questions about how to use Views, permissions, etc.

Here is yet another example of people finding the content/organization on d.o. lacking so they've made their own solution: http://drupaldistrowatch.com

So, if we went with a content type, some ideas based on the recent discussions about the new marketplace and showcase content types:

* project owners could create the node where it goes into a community review process
* we can use existing drupal.org vocabularies to categorize the distros
* this means we need a lot more human reviewers

I don't know if webchick's solution is the way to go, but I think something should be done to address the core problem she's raised. I think there are actually several problems with installation profiles as currently defined.

(1) The word "profiles" already has a separate, common meaning in Drupal, namely, "user profiles." This isn't a huge problem, but it's suboptimal. For example, it makes it harder to search drupal.org for discussion threads that bear on problems involving installation profiles.

(2) More fundamentally, there are some vexing unresolved issues related to versioning and maintenance of the contrib modules that go into a Drupal distro/installation profile. For example, drush does not currently recognize modules that are located inside the /profiles directory, which means that running drush pm-update on a module that is part of an installation profile actually downloads a second copy of that module and puts it into sites/all/modules. I've also had some nasty experiences with messed-up .git handling of contrib code inside the /profiles directory.

(3) There is another problem I've encountered that I think might affect the way we want to think about profiles. I've had several situations where clients have wanted to migrate their existing Drupal site (which was built without using an installation profile) onto an existing installation profile such as OpenPublic or OpenPublish. They want to do this in the hope that the profile will serve as a sort of design standard, and making their sites compliant with that standard will make future site upgrades easier. However, installation profiles are designed to only run upon installation of a site. There is no way to enable their functionality later without some significant hacking. I've done this a couple of times and have some notes I could post describing the process. It involves running a MySQL query to set a value in the variables table, plus creating a custom module adapted from the installation profile's .install file and other code. After dealing with this a couple of times, I think that either (a) core Drupal should provide some kind of system for enabling installation profiles to run after the original site installation; or (b) it would be better to turn some installation profiles into features based on the features module rather than use installation profiles in their current form.

I thought I'd elaborate a bit more on the issues I've had with versioning and maintenance of the contrib modules that go into Drupal profiles, because I think they illustrate the point that janusman made about the tension between regarding a Drupal distribution as "polished" vs. saying it is a "web application you can use *right away* with turnkey installation, that you can further extend/change (because it's Drupal!)."

I think there are actually three different ideas here, each of which is in some conflict with the other: (1) "polished"; (2) "turnkey installation"; and (3) "you can further extend and change them."

Drupal installation profiles typically stuff their contrib modules into a subdirectory inside /profiles, e.g., /profiles/openpublic/modules/contrib/views. This seems necessary because it enables them to specify a different release version than the current release and also lets installation profiles apply their own patches to contrib modules. It also makes it possible to set up Drupal multisites with a single codebase that is capable of running multiple installation profiles, even when the profiles have different versions of the same contrib module. To give a specific example, the current release of OpenPublic uses a patched version of the nodeblock module. If I wanted to use the same codebase to also run a non-OpenPublic website which uses the non-patched version of that same module, I could do so by creating a separate installation profile for the other site. In short, it gives me a codebase that offers "turnkey installation" of not just one Drupal distribution, but several coexisting in a single codebase.

Once I start wanting to extend/change a distro, however, this setup creates problems. In fact, I've run into problems before I even make any changes, as soon as I try to add the code for an installation profile to my own private git repository. The problems happen because a few of the contrib modules in the OpenPublic distro contain their own separate .git directory. Git seems to deal with this by treating the affected modules as git submodules, but it doesn't actually create the .gitmodules file or the .git/config information needed to properly track git submodules. The result is that git clones of my repository merely contain an empty directory for each of the affected Drupal modules. Git then refuses to let me add files to those empty directories, and it gives fatal errors when I try to delete them. (After some Googling, I found a solution to this dilemma here.) I'm tempted to regard this as a bug in the OpenPublic distro, but I experienced similar issues when I tried to create my own git repo for a site that I started using the makefile for Drupal.org testing, so I think this may be an issue in general with the way installation profiles work in Drupal. There are hackish solutions to this problem, but they certainly don't make it a "polished" experience when I use installation profiles.

I'm also not sure what to do with regard to updates of contrib modules that are part of a Drupal distro. The current release of OpenPublic uses older versions of key Drupal modules, including views, panels, ctools, date and calendar. If I want to update to the latest versions of views, panels, etc., should I put those versions in /profiles/openpublic/modules/contrib, or should I put them in /sites/all/modules/contrib? I've gone back and forth about this and haven't been able to decide. I don't know if this is even an issue worth reporting, but it seems to point to a place where the paradigm for maintaining projects in Drupal.org is breaking down a bit with the advent of features and installation profiles. The main paradigm for projects is that they each have their own code, which site builders download into a specified directory inside their Drupal codebase. With installation profiles, projects are more like "recipes for how to assemble code from multiple other projects," combined with a relatively small amount of original code specific to each profile.

I just re-read webchick's original comments that started this issue and think maybe I've wandered into a tangent. She is proposing creating a separate category of "distributions" that would be defined as "polished" products where "a lot of the rough edges are smoothed over, and lots of care is given to user experience."

I think the problem that she's point to is that right now there is no guarantee that the rough edges will be smoothed over for users who use a Drupal distribution. I've tried a number of the leading Drupal distros, including OpenAtrium, OpenScholar, OpenPublish, OpenPublic and Drupal Commons. Each of these distros clearly aspires to being a polished product, but OpenPublish is the only distro that in my experience actually came close to achieving that. They all deliver a lot of prebuilt functionality, but the "polished" part really isn't there yet.

I think part of the point here is that Drupal would benefit greatly from providing a polished experience to people so that they can get started doing useful things with Drupal without having to know a lot. In order to deliver that sort of polished experience, however, we would need something more than simply a new project type on Drupal.org. We would need some kind of review and certification process to ensure that projects can only get added to the "distribution" content type after they meet a high standard for usability. If we're going to have a content type that promises polished, it needs to deliver polished.

webchick: Hm, yes, but then how exactly do you define the difference between "a product that happens to be based on Drupal" vs. "Drupal with some stuff turned on out of the box"? A number of Drupal installation profiles, such as Hyperlocal News or the Drupal ERP Profile, might be considered products even though they don't have many users and are not being very actively maintained. Is the aspiration to be a product sufficient to place it in the category of "distro" instead of "application profile"?

This same ambiguity does not exist with respect to the distinction between modules and themes. We always know that a module belongs in the "modules" section, and a theme belongs in the "themes" section.

@Sheldon, we could put the "distro" vs "profile" through a public vetting process in a issue, much like we do with other things in the Drupal community, like whether to add a feed to Planet. When we separate them out, we can just start with a propsed list of which should be in which. As we go, we will form some guidelines as to what a typical distribution might have.... like documentation, etc.

I guess if we had kind of basic policy defining the difference between a distro and a profile along the lines that webchick suggests, that should do it. Would "separate branding" mean that a distro has to have its own website outside of drupal.org?

Another useful heuristic for judging whether something is a profile or a distribution might be, "Does a site such as webenabled make it available in a form that you can just spin up? If so, it's a distro."

I'm loathe to introduce another "approval" process around this, personally. I'd rather just treat it like we treat mis-filed modules and simply go in after the fact and clean it up if we get bug reports

Yeah. If someone disagrees with categorization they can file an issue.

I agree that an additional content type could be useful, but for now let's just create the additional term and go with that. People can modify their project page to include the meta-data that would be in a new content type and that solves a lot of the problem. After a while we'll see how this goes and have more ideas of whether we need a content type and what fields to include.

I am not sure that the hosting concerns have been adequately addressed.

Ie: If we waive the requirement for distributions to be hosted on d.o (in case that is intended, I may be wrong), on which grounds can we keep that requirement for modules and themes?

I think the main thing that keeps modules on d.o right now is not a policy but the tools, visibility, and peer pressure. There are a handful of other issues about hosting distributions/profiles on d.o and afaict this issue is primarily about creating a special home to promote distributions on d.o. They already have homes here, but we should make that home *nicer* :)

I think each distribution should be able to choose whether to use d.o for hosting their code or some other place. Personally, I try my hardest to package things on d.o where I can, but for COD we eventually had to move elsewhere as we needed external packaging and parts of drush make that are not allowed on d.o.

@webchick: I don't care that much where the development happens, I consider the "end product" to be more important.

@greggles: I don't think that we could peer-pressure anybody who is the project head for one of the top 5 modules into anything. If they'd decide to host elsewhere (for selfish or other reasons) we would need to decide to delete their project part or allow them to link to an external site as OA does. Since I want to keep all Drupal related code on d.o I don't want to allow such a precedent.

Killes, the precedent was set long ago. peer pressure is one part and probably not even the biggest part.

http://drupal.org/node/12014 has no repository
http://drupal.org/node/14410 has no repository

Then there are 1,123 projects with zero commits:

select from_unixtime(created), n.nid, vpp.repo_id, vco.repo_id from node n inner join versioncontrol_project_projects vpp on vpp.nid = n.nid left join versioncontrol_operations vco on vpp.repo_id = vco.repo_id where n.type = 'project_project' and vco.repo_id is null order by created desc;

Enjoy contacting and deleting these nodes.

Both of your examples are unpublished exactly because they have no code. :)

The earlist example I found which has no code and should be unpublished is drupal.org/node/17729

And the fact that some projects slipped through the cracks doesn't prove anything.

Also, most of these nodes (I obviously didn't check all of them) seem to contain no code _at_ _all_ ie no code on drupal.org or anywhere else. That's not exactly the same situation as with distributions I hope...

created an issue at #1216964: Unpublish projects with no code on drupal.org. There are about 200 entries in the list I made that should be evaluated.

greggles wrote:

I think each distribution should be able to choose whether to use d.o for hosting their code or some other place. Personally, I try my hardest to package things on d.o where I can, but for COD we eventually had to move elsewhere as we needed external packaging and parts of drush make that are not allowed on d.o.

Not only for COD and Open Atrium. This seems also the general case for most Drupal distributions. I remember some mentioned technical problems related to libraries, etc., that make difficult hosting distribution code on drupal.org. Because of this, many of them have it on Github or their own external sites.

This is also explained in the Drupal.org docs on Installation profiles and distributions:

Note that most distributions include code (such as the jQuery library) that cannot be hosted on Drupal.org due to incompatible licensing, so downloads of these distributions are provided via 3rd party website.

On that page, see also the section on the difference between Distributions vs Installation Profiles.

The docs include also an, of course, not complete but useful list of Drupal distributions in Additional distribution documentation.

As an example of the mentioned situation, an interesting info from the project page of the NodeStream distribution:

Some functionality is missing in the packaging system on drupal.org to be fully compatible with how NodeStream (and most other distributions) are built. Work is being done to fix this, read more here: Install Profile Packaging.

Therefore, like many other distributions, and in addition to git, they have a downloadable package on their own external site.

In reference to webchick's idea, I think there is a very clear difference between a distribution like Open Atrium and something like drupalorg_testing. The question is how to distinguish between them.

I don't think there is a technical difference between the two in terms of what components go into making them. The difference isn't technical, it's social or situational. People expect, and have a right to expect, that Open Atrium is fairly polished and gets them pretty far down the road toward having a fully functional website for a specific purpose. People don't expect and shouldn't expect that from drupalorg_testing.

What about creating and prominently featuring a documentation page that lists all of the significant Drupal distros, with a brief summary description of each one and a link back to its project page on d.o.? The documentation page could be open to editing by all approved d.o. documentation editors, who could collectively curate the list wiki-style. Being listed on that page would constitute a form of quasi-certification as a "recognized production-ready" Drupal distro. There might be some debates of which distros belong on that list, but they could be worked out by the people who edit that page. As a safeguard against bias or self-serving edits, you could declare a rule which says that distro maintainers should not directly edit the description of their own distro. I think this approach might be more workable than creating a separate content type, because ultimately I think you need someone actively curating the list to ensure that only distros which meet some reasonable usability standard get included in the list. If you just define a new "distribution" content type but don't have the curation, then anyone with a bag of half-written code will be able to post it as a distro, and the problem that webchick is trying to address will happen all over again.

Sounds like duplication of work, to me. We have Views, why not use it? A very simple solution is to simply tag install profiles as distributions and create a view that lists them. Easy.

Of course, then we can have problems with people abusing the tag for random, unrelated things. So that's a problem.

I think a separate content type would be the best way to go, but I think it's going to be a lot of pain to make those nodes work correctly as project nodes + interoperability with the packaging system, etc.

We could introduce a sort of "review" process (as much as I hate to suggest that). Owners of Installation Profile nodes could go through a review process similar to what we have for sandbox->full project promotion. That is, you can create all the installation profiles you want, but in order to be listed as a *distribution*, somebody needs to look at it and make sure it's actually a *product* (for some definition of product - those criteria would need to be decided on in advance).

If we can wait until d.o runs D7 (I doubt it) then yeah, it'll be trivial to have different node types for the different kinds of projects.

Short of that, the type-specific taxonomy I describe in #6 is probably our best option.

But yeah, we have big problems with managing who uses the terms/flags/tagging whatever technology we use. I agree with Sheldon Rampton: the difference is purely subjective (requiring humans to get it right) not objective (that can be automated). To me, coming up with a good solution to this problem is the crux of the matter. The specific implementation details of how we mark project nodes as being "distros" vs. "profiles" are less interesting or important.

I think the sandbox is definitely a step in the right direction and therefore think it is worth doing. Even if it's not perfect or the final optimal solution, it's an improvement.

Upon reflection, I think the term "distribution" is itself a bit obscure to people who come to the website wanting to learn about Drupal for the first time. (And those are the people who benefit the most and are most likely to be impressed by the power and ease of setup that distros offer.) The concept of a "distribution" is loosely taken from the idea of Linux distros, and the concept itself makes total sense, but outside the world of Linux geeks, most people don't even know what a distro is.

I don't propose abandoning the term "distribution" altogether, but to really get people to grok the concept, maybe d.o. should have a landing page with some more marketing-savvy language that says something such as, "What kind of website do you need? Drupal offers a number of prepackaged setups, called "distributions," that can get you started with a web-based newsmagazine, a government website, a social network website, or an online store in an hour or less. Here are some of the most popular setups:..."

One note about future-proofing this: Once we *are* on D7, and there are actually separate node types for the different top-level project types, it's no longer going to be a click of a button to change from one project type to another. Obviously it'd be possible if absolutely necessary, but it's either going to require some custom code or something like http://drupal.org/sandbox/damz/1316746.

So, do you really want separate *project* types for distro vs. profile? I was thinking more like a taxonomy vocab on install profile projects that says if it's a distro or not. Maybe your distro use-case vocab just needs a "stupid old install profile" term?

Given that it's a really subjective thing to distinguish profile from distro, I'd rather not put a huge technical barrier between them.

-1. Install profiles is what those projects technically "are".

But aren't all install profiles really a sort of distribution? Why not instead rename "install profiles"

Installation profiles and distributions are one and the same thing they do not differ neither technically nor by intent (at least for those hosted on drupal.org).

...

Why do we try to fight the reality? And try to produce an artificial difference between "distributions" and "installation profiles", when there is none?

Why do we try to over-complicate things? Whatever you call whichever of both, they attempt to improve the initial experience after downloading Drupal.

Instead of making things more complex, let's reduce to the max. Keep it simple, please. It's about packaging, and packaging the appropriate things, and nothing else.

Whatever you package, you produce a more or less complete product. Product audiences can be expressed in tags, but that's it.

Or in other words: Who's going to review, test, try, and actually classify all of the existing profiles? Who's going to decide whether a profile is a distribution? And which distribution is not? And what, again, makes the actual difference?

No one is going to. And no one should. No one wants to have that differentiation in the first place.

@sun: How does drupalorg_testing "attempt to improve the initial experience after downloading Drupal"? How is it a "complete product"?

Webchick has argued (persuasively, in my view) that there is a clear difference between drupalorg_testing (a bag of code whose primary purpose is to enable testing) and a distro such as Open Atrium, which does in fact meet the criteria you mentioned. In reality there are only a relatively small number of distros that meet the quality standards of OpenAtrium or OpenPublish, after which there is a long list of distro-wannabes. There is nothing wrong with someone releasing an installation profile that lacks the completeness and usability of a true distro. Hopefully some of them will improve to the point that they become true distros. From the point of view of someone trying to use distros to build new websites easily, however, the long list of distro-wannabes makes it hard to find the ones that are truly worth installing.

It may be true, to use your phrase, that all installation profiles are a "more or less complete product," but there is in fact a difference between "more complete" and "less complete." Distros are the ones that are "more complete." That difference does matter to people.

Names that have been proposed in related issues:

• Drupal applications
• Drupal distributions
• Drupal editions
• Drupal packages
• Drupal products

Distribution or distro is one of the most accepted names, even when some say is a word of Linux geeks. Product is also really popular. Package seems a general word that can also include installation profiles. Edition has been proposed for possible official packages, such as Drupal Standard Edition; it's also a name used by the Symfony Standard Edition, etc. Application is used for example in the Drupal.org homepage, and has been proposed by a distribution developer as a less commercialist name than product; however the name Drupal app is now being used for other things.

So it seems to be between Drupal distributions, products, or maybe applications.

There's no technical difference between an installation profile and a distribution, but I think there should be some sort of distinction. Since we have flag module on Drupal.org now, can't we just stick a flag on the Installation Profile nodes that denotes whether or not it's a distribution (as opposed to a normal install profile?). The maintainers of drupalorg_testing, knowing that their profile is a development profile, would not check the checkbox, while Open Atrium, Open Publish, etc would.

Seems pretty simple to me.

To clarify, I'm -1 on anything that will create yet another moderation process. Leave the decision to the maintainers of the installation profiles. If somebody is using the flag improperly, we can address that, but I'd want it to be open from the start.

Oh and yes, hell no to a moderation process

And what exactly is #1349782: Create an initial list of distributions to populate listing page if it's not a moderation process?

There is nothing wrong with someone releasing an installation profile that lacks the completeness and usability of a true distro. Hopefully some of them will improve to the point that they become true distros.

The community is building Portfolio. It is supposed to become a viable product. But it is an installation profile. It is still Drupal. You install it like Drupal, you use it like Drupal, and you potentially build and extend your site like you would after getting Drupal.

So please tell me, at what exact point will you decide that it's no longer a profile but a distro?

And at what exact point will you decide that it's complete and usable?

Nonsense.

You could as well go ahead and apply the same idea and thinking to modules and themes. What you're essentially saying is that either the project maintainers or some artificially elevated morons decide to flag a certain project as

[»] This is actually useful.

Of course it makes lots of sense to create and maintain a project for something that isn't useful. And of course, absolutely none of the existing projects want to be in a list of useful projects.

distributions are polished "products" with Drupal under the hood [...] The target end-user for these distributions is often someone without any Drupal experience at all; a lot of the rough edges are smoothed over, and lots of care is given to user experience.

Installation profiles (which we do have a list of), on the other hand, are "Drupal with some other stuff bundled in and pre-configured for convenience."

Please tell me:

• How many rough edges exactly need to be smoothed over to count as distro?
• How much has the profile itself (vs. packaged projects) to care for user experience to count as distro?
• How much needs to be pre-configured in the profile to count as distro?

Answering these and further questions is pointless. But of course feel free to research and write an academic paper to defend your PhD.

It's a false dichotomy either way, which makes this discussion a total waste of time.

I think vigorous debate is a good thing, but I don't see how insulting language contributes to vigor in a debate. It's fine with me if sun disagrees with my point of view, but I don't think he adds any insight or value to this conversation when he sprinkles his comments with phrases such as "nonsense," "artificially inflated morons," etc.

I'm curious, moreover, to know why sun filled his broadside with questions and then declared that answering those very questions would be "pointless" pedantry ("an academic paper to defend your PhD"). For the record, I do not have a PhD and am not pursuing one. If sun feels that answering his own questions is pointless and stupid, then it must have been even more pointless and stupid for him to have posed those questions in the first place. Similarly, if he feels that this entire discussion is a "total waste of time," why is he adding to it?

As far as I can tell, the substance of our disagreement is that I believe it is possible and worthwhile to highlight installation profiles that are "polished," meaning that they are relatively easy to install and use even by people who don't know a lot about Drupal. sun evidently disagrees and moreover believes that people who think like I do are idiots. I guess he is entitled to his opinion. Have a nice day.

Nothing in my comment was directed to anyone specifically or personally.

the substance of our disagreement is that I believe it is possible and worthwhile to highlight installation profiles that are "polished," meaning that they are relatively easy to install and use even by people who don't know a lot about Drupal.

That's correct. What matters is the implied meaning in this statement:

Tag such profiles with "usability" and "beginner", filter the list accordingly by default (or not). Done.

Don't care for usability? Remove the tag in the filter. Profit.

That said, @juan_g was so friendly to point out that this entire proposal and issue is obsolete for some time already. Thus, closing this issue.

That said, @juan_g was so friendly to point out that this entire proposal and issue is obsolete for some time already. Thus, closing this issue.

To clarify, what was abandoned was the idea of a separate project type. So, according to webchick's proposal, all packaged install profiles will be distributions, with the same project type and the same basic distribution listing. However, what is still in the proposal is that an additional filtered list, with distributions intended for users, will be available in landing pages for users. That's it. The rest are details on different implementation possibilities.

webchick wrote:

we can keep this one focused on technical details

Since this covers more than the old option for a separate project type (discarded on December 1), opening again and updating the title according to webchick's current proposal and other suggestions from the community.

Shorter title.

More specific title, according to #1314124: [META] Improve installation profile listing on Drupal.org.

(Sorry for the two previous incomplete edits).

We are working on cleaning up Drupal.org-related issue queues. Many issues have been open for years with no resolution because there were no volunteers interested in taking on the task or staff time available to complete the work.
We are going through old issues and marking them as Closed (won't fix). If you feel your issue has been closed in error, please do comment on the issue and let us know. If we know something is critical, we may reconsider the closure of a feature request or bug report.
Thank you for your understanding while we work to clean up the Drupal.org queues.