[development] Click-click! "Agree." "Next." "Next." "Next." "Finish."

[Max Bell]

/delurk

Hello, Everybody!

I wanted to chime in on the subject of Drupal distribution profiles, ask a
couple of questions, pimp my Drupal group relating to same
(http://groups.drupal.org/drupal-distributions-strategic-cooperative) and
solicit feedback on the lot.

But first...

YAY 5.0! YAY 5.0! YAY 5.0! I am SO ready for this beta! (and with THAT out
of my system)...

I really DON'T want to subject anyone to "lets just create a new web site
and put all our information there" -- what I am hoping to do is be able to
hand aggregate what information is available and put it in a central
location (the group I created) myself. While I think it may be a worthwhile
thing for those considering or actively developing a distribution profile to
devote some part of that development time into focusing on the subject and
collaborating with developers working on unrelated distributions, I am
cognizant of how little it would take for such an effort to become extra
work, rather than a means of saving work, so hopefully I can condense and
consolidate the process a bit.

My interest in this subject specifically stems from the time I spent posing
as DeanSpace support and a couple of brief exchanges I had with Drumm on the
subject at the time. In essence, having spent a short period installing
DeanSpace for folks while chatting with them on AOL instant messenger, I
discovered that the period of time consumed by the installation was an
important and valuable opportunity to shape the user's experience with the
product. Besides explaining how the installation worked as I put it
together, I was also able to tell the user what other users were doing with
the software and ask questions about what they hoped to do with it
themselves, then show them (roughly) where to find the relevant
administration functions and help them begin roughing out the vision they
saw in their mind's eye. I don't really want to belabor the idea of
installation as teaching experience, though, so much as explain that I'll be
evangelizing the idea a little. Imagine, if you will, a series of Drupal
distributions so comprehensive and coordinated that a novice web
designer/site administrator could, having completed one installation, turn
around and create a completely unrelated site based on a different
distribution profile, using the skills and understanding developed during
the first installation. An army of mini-Drupal distributions, branded and
coordinated with the core distribution, marching across the face of the
earth in a united front with the common goal of Drupal world domination,
illuminating and facilitating the creation of unique and feature rich web
sites tailored to specific markets while fostering user confidence and a
general skill set that increases the pool of Drupal gurus available to
assist new users and reducing the level of overall support required...
(Shutting up, now)

Back in the real-world, though, Dries really nailed it with his "we need to
pre-herd the cats this will attract" post.

Just a quick tour of the Drupal sphere will show that people are already
talking about the "distribution profile" as labor-saving utility idea at
least to a modest degree, and I can understand why they would. Consider the
site designer who'd like a set of custom profiles to facilitate prototyping
and deployment for new clients, or the hosting provider who'd like to
automate client set up and offer a set of basic installation types, or the
developer who just wants to knock-out a headless sandbox installation to
save typing, prepopulate the database and set up utility modules. Clearly,
none of these examples involve creating distributions developed for
consumption by the general public and probably won't be intended to stand up
over the long haul. But I would like to suggest that this utility be
acknowledged and embraced with the caveat that it be clearly distinguished
from distributions that will be made available for people to download and,
potentially, generate support requests.

That said, focus rightly belongs on distributions that potentially may
occupy a directory next to "default" at some point. To that end, I wonder if
it doesn't make sense to view the task of maintaining such distributions
through the filter of "my distribution is still Drupal" -- in other words,
to view developing distributions kind of like people view creating themes --
separate the presentation from the code. Core and contrib modules already
have their own documentation, support and upgrade mechanisms in place and it
makes sense to make use of them as much as possible. Keeping this
distinction in mind also provides the added bonus of keeping focus where it
belongs, with Drupal. While this will always be secondary to focusing on the
requirements and functionality necessary to the market the distribution is
developed for, "what's good for Drupal and, by implication, the collective
sum of other distributions" should still trail a close second in a perfect
world.

Which brings me to note that thus far, installation profile development is
still in it's infancy, the documentation written thus far is sparse and
seemingly dated, and there isn't much in the API docs about the hooks
involved. Thus I hope someone can take a moment and answer a couple of
questions:

1) I number this mailing list, the support forums on drupal.org and it's
sister site, groups, as potential sources where I might find folks talking
about developing distribution profiles; I stay off of IRC because I can see
myself doing nothing but keeping tabs on Drupal development full time, and I
have to play with the software occasionally. Besides general RSS aggregation
of syndicated nodes that might address the subject, though, is there
anywhere else I should be looking that anyone can think of?

2) How closely are module installations and distributions related? I may
answer this question in part, myself, since as soon as I finish this mail I
am going to knock out a sandbox and create one using the documentation in
the handbook. I just can't help but notice that the documentation references
hooks I am not seeing in the API docs and so on.

3) Can anyone recommend any general-purpose reading for this subject
(links?)? Again, I will do some digging on my own, but from experience (I
generally create custom Windows installations before I reinstall and am
learning how to accomplish this same end with Ubuntu, but I don't really see
anything like a "best practices" list coming to mind between them).

Finally, +1 to feeds/mailing lists enabled by default with the core
distribution (and any other). I tend to suspect that prominently displaying
a list of help resources at the end of the installation and then reinforcing
this by making the same list readily accessible as part of the initial
configuration may be a good idea. Having a feed or mailing list option
enabled by default to channel support and the like to the correct
destination would be even better, IMHO. So long as I'm rambling, one of my
fondest wishes has always been for something like a meta-taxonomy for core
feed categories (support, development, etc.) -- thus creating a kind of
networked discussion area that would be automatically available/optional for
newly created sites.

I'll shut up, now, and close by pimping my "group for talking about Drupal
distribution profile development groups" again
(http://groups.drupal.org/drupal-distributions-strategic-cooperative).