Jerry,
Let me address the issue of documentation first, then I'll go on to the other points.
When I wrote the initial documentation in linuxdoc (later moved to DocBook) I did it because I wanted a way to export to various formats easily, and because it's easy to index and link things together.
The source for the documentation is available. You can just grab it and modify it, then send a patch. A wiki would be cool, but since mostly it's only me managing the 3.2.x documentation, _I_ don't have the time to wander through a documentation wiki looking for changes and then auditing it for quality. It just wouldn't happen.
Now, for writing _new_ documentation rapidly, then we may have a use for wiki there. For creating a new project, I don't know how a wiki would help, really.
0. I'd have to agree that content is hard to move (which hopefully will be improved once we start using CMS and the content repository), and you've being doing a great job of discussing the search possibilities in another thread.
Do you want to start a "OpenACS Search" Project? If so what do you need? How can we help? Tell us in plain terms. We'll continue to do our best to support the efforts of community members, to the best of our abilities and available resources.
1. This could be well addressed by creating a demo.openacs.org and improving the documentation, no? I haven't created a demo.openacs.org site because I don't have the time currently. I'd love to see it happen though.
2. The combination of file-storage, Wimpy and bboards has given some great results without the need for a wiki. Anyone can know who's doing what by looking at the OpenACS 4.x status page, which is constantly updated. Another option is that we could use the Groups functionality of 3.2.x to have separate projects with their own calendars and news items. We could have a "projects" page that would list the several projects. Would that be enough?
3. Goes back to the open source model. When a need comes a long and someone takes the lead and implements it, then a community gathers around it. We can't pass a decrete saying "YOU! Implement this" because nobody is working for anyone here (mostly). What you (and others) are doing with the XML-RPC thing is excellent! Keep it up. I got involved in this project 2 years ago because I wanted to run the ACS on my sites using PG. I got that. I didn't write documentation because I wanted to run ACS on my sites. I did it because it was a way to contribute back to the community, that has helped me stratch my itches.
4. The best way to discuss this (and all of your points here) would be (I'm sorry to say) in their own threads. Balooning everything into one huge thread won't cut it.
Regarding committees and bylaws and all that, I'd like to see other open source projects that do that and are successful.
Instead of "committees", I'd like to see projects (a 'documentation project', a 'PR project', etc.) Instead of a charter, I'd like to see leadership. Instead of formalities, I'd like to see commitment and fostering of new ideas.
Do you want to start an OpenACS-related project? Tell us what you want, and what would you like to do (in a new thread). Do you need a xmlrpc.openacs.org (just an example) domain? Do you need CVS? Do you need a new bboard?
