Forum .LRN Q&A: Re: Announcement: .LRN Spring Meeting in Heidelberg (2004)

With our conference fast approaching, I'm wondering if we might discuss a little more what we might do for the bug bash/boot camp on Sunday-Wednesday.  Personally, I've got two projects I'd like to work on:

1) TO move the ".lrn gardens" project the next step, as outlined by Nima in the last entry there (https://openacs.org/forums/message-view?message_id=167160):

---------excerpt from Nima's post -------------------------
2.1 First step
A dummy page is created using existing material to define a consistent style that can cover about 80% of what is described above without a single change required inside the packages.
The materials include:
    * default-master template for the layout elements we have
    * forms.css and lists.css for the builders we have
    * default-master.css for the standard elements required for the site
The resulting dummy page will include most of what is required in the site and serve as test case for
    * consistency of look & feel for all styles
    * consistency for all style classes defined for the site
At this stage we will have a proof of concept which can be discussed broadly in the community.
------------end of excerpt from Nima's post --------------------

2) To improve the organization and documentation for newbie hackers like myself and those that will follow us who want to customize the dotlrn interface.  At present, I navigate to (1) "site-wide administration," (2)"Developer's Admin", and to customize the front page I am delivered to (3)"Using templates in OpenACS", and failing to comprehend that (I am "differently abled"), I click (4)"Learn More: OpenACS Documentation", then (5)"Learning OpenACS", choose the simplest of the choices, (6)"Help Configuring an OpenACS Site", and then find some otherwise VERY friendly and helpful advice on the things I want to do but written for people with more programming experience and patience than me.  Please don't get me wrong, this is good stuff for probably 99% of the programmers implementing dotlrn over the past year, but my concern is for the next year, including non-programmers like myself and my three professor clients who have been happy using dotlrn 1.0, who signed up to use 2.0, and who want to customize it next week -- but will wait three weeks more because I've asked them to and because showing them how to fiddle with the wonderful translator/messages feature will keep them busy until then.    I want them to click at step 1) and find a tutorial that will help them put up their class logo, install and start using the photo album and lars blogger, and move things around -- in ways we will discover as soon as we make it easy for them do so so.

My business plan, and the one I think might help our cause, includes getting such "early adaptors" hooked, help them "own" the technology by helping them make it their own, and more generally, developing implementations that include a research component that might lead the way to needs assessments / interaction designs based on a finely-grained analysis of uses by those who are using it.  I want them to be able to redesign their pages like they organize their desktops and notebooks.  Dotlrn does this already to a wondeful degree, and its success in doing so invites more flexibility yet!

Hence, I want to rewrite the otherwise excellent "edit-this-page" and subsite building documentation for my early adapters so I/they can better grasp the learning/interface problem, and having done so, be better positioned and eager to argue for and eventually hire "real programmers" -- like those who write the first generation dotlrn documentation -- to build the next generation functionality.

My hunch is that when Joel, or any of the other wonderful openacs wizards I've had the pleasure of getting to know, walks me through the "How Do I" (https://openacs.org/doc/openacs-HEAD/how-do-I.html) documents, I'll "get it" quickly, in a few hours have a decent grasp and enough to find my way, and from there might be able to figure out how to rewrite the documentation for mere mortals.

That is, I'm trying to figure out what would interest me AND what might contribute to the community at the same time.  Here are two suggestions: I'm hoping some people will sign up for both AND will come up with others I might sign on to help with, too.  What do you all say?

Two possible foci for the bug bash:

1) Now that we've reduced the Priority 1 and Priority 2 bug lists down to the nitty-gritty things that can't generally be fixed in a bash, we can start on the Priority 3 bugs and the non-core bugs.

2) Documentation for tclwebtest-based tests is almost complete - we could start writing tclwebtest tests for the core modules.

I'm with Joel.  Let's make the functionality we have extremely solid.

I'd add performance testing.