Forum OpenACS Q&A: Response to What is a WIKI
I think you're being a bit disingenuous, or maybe I just haven't made myself clear.
I'm not asking for a new webmaster, I've suggested, in this other thread, https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=00025b, that we put together a steering committee to determine a bit of direction, a bit of policy, and a bit of organization.
I believe your new poll sets up a strawman to be defeated. We're not asking for a new webmaster. We all appreciate and are grateful for yours, Don's, Roberto's, and everyone's efforts. I would have preferred a poll that asks the question: would you like to see a steering committee formed? Why do I think a steering committee is needed? Because I cannot create a poll at this site /admin/poll, and I don't like strawmen arguments.
I never said I wanted an insecure Wiki. I said my preferences would be that given the alternatives, I would prefer to implement a wiki today, and migrate it/improve it later, and deal with the security risks today, with the tradeoff that we might get 0wn3d on occasion and as we learned.
By the way the first page of a google search for wiki and exploits reveals none known that lets the h4x0r 0wn a box, just the justified concern for letting arbitrary html into any wiki page and how that might effect users. So if there was any chance that a wiki might be implemented somewhere, I would suggest ensuring that there are filters in place, much as the ACS has filters too, to ensure that arbitrary and naughty html doesn't make it in.
I never said I didn't want to be there when the box gets hacked. I said that realistically the box is 3000 miles away from where I am, and that I won't be there when the box gets hacked. And I acknowleged upfront that that distance might make it too easy for me have the preference that I do.
I don't think that makes me irresponsible. I'd prefer to think it shows vision, confidence, and trust in the community.
I would like this community to be open to experimentation. Sometimes experiments go awry. Sometimes they don't. And sometimes we learn best through our failures. How will we know? How will we know if modules are scalable? This is probably one of the largest OpenACS sites, and my preference would be that it's okay for this site to occasionally be down, and even get restored, because I am confident that that's the best way to make it a showcase for open source, openACS philosophies and technologies. It would be one of the best showcases for an OpenForce, Furfly, Civilution, Digital-People, ybos, Museas, etc. to show.
I would like to see this be a learning community. Usually three steps forward and occasionally one step back. It would be a statement: we're open, we're honest, we share, we learn, and we're confident in our solutions. Experimentation. Boldness. Leadership. OpenACS.
I would like to see the OpenACS embrace web best practices that create well engineered solutions, to the greatest extent possible, regardless of underlying technology. I think we can learn something from our competition. And I think that by doing so, we can best our competition, coopt our competition, partner with our competitors, and leverage our competition. Okay hands now: which OpenACS companies out there are purposefully not exploring any of Java, Python, Zope, W2K, or C#? Who amongst us doesn't belong to a mailing list powered by Mailman?
If folks want W2K OpenACS, cool beans. If someone builds .NET hooks into OpenACS, okay. If someone suggests that we explore what a wiki might do, or that we turn general comments on /doc, I'd like to see that given a chance too.
Isn't it silly, isn't it bizarre, isn't it frustrating that postgresql.org has no db backed discussion groups? We think that those pg developers are sitting in the dark, using their mailing lists, and not turning to the light of the ACS. They're not interested in experimentation or outside technologies. How would you ever convince them otherwise?
Ben, let me apologize. I don't feel picked on, but I'm pretty sure you do, and for that, let me apologize once more.