Click-click! "Agree." "Next." "Next." "Next." "Finish."
/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).
participants (1)
-
Max Bell