Forum OpenACS Q&A: Response to Sizzle vs. Steak

In addition to "skins," what about a selection of basic "pre-packaged services" such as:

1) an OpenACS install with 1 bboard, 1 calendar, & 1 news module OR

2) an OpenACS install with 2 bboards and 1 news module, etc.

This is how most of my OpenACS installations work, as most of my clients want a minimum of services to start with; and having a script help me setup the basic configuration for a fully working system would be great.

At present, I have a set of ultra-mini-HowTos that remind me of the steps I must take to properly setup a basic set of OpenACS services. This way I can focus my time on customizing the UI instead of re-remembering how to create categories for a bboard.

Question on the "config scripts" used to build a specific OpenACS system:

I assume BITS, the "Open Bug Tracker(TM)" script will walk me through (using a series of web pages) the decisions that need to be made to properly setup OpenACS as a bug tracking system, such that when I am done with the installation I have a fully operational bug tracking system (with all the properly configured parameter/, home.tcl and admin/???.tcl pages), OR are you planning to have a more "recipie" style system that lists the steps that need to be done?

I am thinking of Windows here, in that after the basic install, I get a few "configuration" screens that allow me to setup my services; i.e. timezone.

Whats more, I am thinking that the Installation/Configuration scripts will result in the basic home.tcl, and admin/???.tcl files that offer _only_ the choices that I have selected to install.

I have already started to build a set of "configuration" scripts (.tcl) pages that walk me through the post-installation process, to help my associate admins more quickly build an OpenACS installation with basic services activated. But my requirements for a basic OpenACS system are likely different from those of others.

Can we agree on 2-3 basic configurations (plus any specific "skins" such as the OpenBugTracker), for the out-of-the-box crowd, so the configuration pages I help build can be more focused?

Can we also agree on the page layout and/or structure of these pages so that I what I build will conform with what other people build?

Perhaps we do not limit the number of OpenACS configuration solutions, but we build a library of solutions from which the user can choose; each with their own description, sample screen shots, documentation (where appropriate), and script files that are used to make the appropriate changes. If we could start with one OpenACS Configuration Model and a guideline that helps future config builders... hmmm I like this, but I think we need to define some basic structure and standards before I go nuts building config solutions. Any thoughts? -nate