November 2nd 2006 (General Web Applications Focus - OpenACS)
Here is a list of topics people have expressed an interest in discussing at the LRN/OpenACS Fall Conference 2006
- Future of OpenACS platform
- XOTcl's role in OpenACS
- More focused platform/products to give you a head start (dotLRN, dotCommunity)
- What is the potential of a kernel rewrite?
- Timeline for a lickable openacs.org
- Building an easy and complete installer
- Supporting theming (better CSS/HTML local customizations)
- Supporting accessibility requirements
- Package Inheritance, better re-usability of code without forking
- OpenACS Best Practices
- Automated Testing: How and Why (Dave Bauer)
- Package Design
For those interested in participating in the 'what is the potential of a kernel rewrite?' discussion, here is a set of questions to think about. They are aimed at establishing the general point of view of those taking part in the discussion; ie. you don't need to answer them now or post a long article justifying your perspective. Simply knowing your answers and being able to compare them directly to other people in the discussion will help us get something useful out of it. You may also find it useful to consider these questions first from an optimistic perspective and separately with your own assessment of what is realistic (as people will have wildly different opinions of what is practical which may in turn hide the fact that people agree in principle).
First some questions to establish the context of your thinking:
What state is OpenACS in now?
- Almost there or needs a lot of work?
- In need of radical, non-backwards compatible improvements or more conservative, backwards comparable improvements?
- In need of cross package architectural improvements or localized incremental improvements?
- In need of documentation/idealogical changes or practical code changes?
Would you like to see all effort focused on incremental improvement? radical change? both in parallel (if so how should it be organized)?
What is OpenACS?
- A toolkit (ie. complete components which can be brought together with glue code to make a complete system)?
- A template (ie. a system with blanks that need to be filled in to complete it)?
- A complete system (ie. only required configuration to get a finished system)?
- A content management system (ie. mainly for publishing)?
- A community / social networking system (ie. focused on delivering functionality to groups of non-admin users and enhancing the relationships between them)?
- A collection of highly interactive apps (ie. a forum, survey tool, etc and some navigation to get between them)?
If your not sure what it is now, what do you think it should be?
Should OpenACS require local customization or be entirely configurable?
Second some high level questions to establish your priorities:
What are your aims for an improved OpenACS?
- Easier exchange of code between developers? (ie consistent context)
- More people using OpenACS in total?
- Improve QA in releases?
How should the OpenACS architecture be decided?
- By TIPs (if so how will the work be funded)?
- By anyone how has the resources to write the supporting code (if so how will long term consistency be achieved)?
Thirdly some low level questions to get the basics of your practical proposals:
What do you like about OpenACS now?
What are the biggest problems with OpenACS now?
What is your OpenACS wishlist?
What are your OpenACS implementation plans in practice?