Is it possible to start with what problem we are trying to solve? This isn't a one man community, neither you or anyone else should shoulder the entire burden. It's a noble motivation, but we really have to play to our collective strengths. This is even more necessary now. Apparently we have one person inside AOL who gets paid for some time on AOLserver. Everyone else is a volunteer. It makes no difference if someone has perfect knowledge of the perfect application, collectively we all know how everything works right now. Any change requires an effort by each community member to catch up.
Decisions like this are difficult. They are the equivalent as switching from one database to another, or one accounting system to another. Everyone is impacted, not just the time sink for the expert who can make the switch. As a community of volunteers, we can't expect that anyone who is here donating time, hardware and expertise today will be here next week. This is a reality. We can't put all our eggs in one basket. This isn't even a corporate model where we can take a risky gamble. There are many users who rely on stability, expect stability, and AOLserver offers that...not because of a lazy community but because AOLserver has benefitted from years of expert development. When we look at everything which could be done to perfect AOLserver, or fill it out, what do we usually hear? Massive bug reports? No! Lack of documentation? Yes. This is an easy criticism because everyone accepts the premise that an API needs good documentation. However, here is the problem: we have a community of very advanced users. When I was looking at the ns_pools documentation, there was a comment to read the C code. Actually, I can't disagree with this, I believe code is documentation. And we are fortunate that AOLserver C code is very easy to read. Note that the code itself doesn't have much documentation as comments, but if I can figure it out, it must be pretty well written. Version 4.5 made many internal changes. >From what I have seen, these changes simplify the code and make it easier to understand, but I think all of the motivations and goals have not been written down. This is a more serious lack of documentation. With no idea what the goals were, it is hard to judge if things are finished or what is possible or not. In addition, version 4.5 has introduced other modules like ns_proxy. The bottom line is we have a lot of new code, almost like a birthday present, but we need some instructions on how to use it. We don't really need a screwdriver or body shop, we need an owners guide or maintenance book. Although it is easy to try to jump in and start documenting stuff, there is so little current documentation that there might be an opportunity to rethink how to do this. tom jackson On Friday 31 August 2007 16:21, Dossy Shiobara wrote: > On 2007.08.31, Tom Jackson <[EMAIL PROTECTED]> wrote: > > Why is this speaking out against Trac? Why isn't this speaking up for > > AOLserver, Tcl, OpenACS, and everyone in the community who supports > > and uses these high quality products? > > I, personally, am in no position right now to volunteer and/or donate an > AOLserver/OpenACS installation--and have no ability to make anyone else > do so. Therefore, I'm not going to waste my limited time pursuing that > line of thought. > > If someone would step forward and volunteer to set it up and maintain it > and/or donate the resources and funding required to operate it, that > would be fantastic. > > > Anyway, I seem to remember my email being a little longer than a > > single line. > > Sorry, I try to follow good netiquette and trim quoted text. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
