OK, this may drive this thead out on a tangent, but here goes...
Talli (PBC, s-o ZtA, b-o HtR),
You touch some important points, especially the part about the community sometimes having a closed feel. Both you and I have personally met many of the core people, so I suspect you agree that in reality the people behind are anything but closed to outsiders.
IMHO the problem is simply, that A) many of the core people know each other very well from the aD days, and B) they are often very, very busy as well. So I wonder if many of them simply have less of a need for making noises as compared to, say, a project, which historically grew out of a personal code project on the web. And when they do communicate, it is often in private. I'm a "recent addition" to the community :), and indirectly I can see that currently at times decisions are made, which are often only mentioned in passing in public at a later date, if at all.
Some ideas:
***) Have a weekly, or bi-weekly, "OpenACS Happenings for Week X-Y" thread on the dev forum. Here everybody are encouraged to tell what they are currently working on, decisions made (whether personal, or by, say, the OCT), and future plans. This would be easier to make and maintain than an official newsletter or the like. My guess is that even very brief entries by many of the core persons would show a flurry of activity, which often isn't apparent by reading the, at times, very quiet forums.
***) Have 'commit levels' and a document describing them. By this I mean some agreed upon policy of what people with commit priviledges but different levels of experience are allowed to do to the tree without asking anyone else (would perhaps help on the bug/patches issue). Eg. I am a newbie, so I am only allowed to change things in HEAD, that doesn't touch security issues or change the state of the DB. But I would be encouraged to fix, say, trivial noquote bugs where I find them, in cooperation with the package maintainer.
The OCT members are at the top, and then there might be two other levels, one in between newbie committers and the OCT, and those people without commit priviledges.
This way people 'down on the floor' would perhaps feel more free to work together closing the simpler bugs while sparing the core members. It might take twenty times as long for me to fix a DB select as one of the core members, but it would be educational, and I would get more of a feel of doing something constructive. It is a curious but well known psychological fact that you tie people more strongly to you by getting them to do favours for you, not the other way around!
***) We already have some pages on openacs.org aimed at the newcomer. After rereading them I cannot help feeling we might want to roll several of them into one, longer 'Getting Involded' document. Sort of a 'Welcome to the community, here is how it works and the pieces fit together' piece. Especially important would be a suggested list of reading (in order) and how to get started from scratch/proceed from here. Ie. this document should have a status of being wrapped in virtual neon saying 'README.1st'!
Also strongly emphasize the importance of the IRC channel, especially for newcomers, as this is a very good way of getting the feel of the other active people there. Yes, the IRC channel is mentioned twice on the front page already, but... ;)
The current documents seems to suggest that people, who try out OpenACS already have a fixed goal in mind, ie. they already know they want to build a website using the toolkit. The interested hobbyist who just stopped by may not have any such thing in mind.
***) Have mentors/IRC anchor people, who have publicly stated they don't mind be borthered by newbies. I am aware that in principle this is probably true for most of the long time community members, yet often I myself am reluctant to raise one of the core on, say, IRC over what may or may not be a trivial issue. Allow same mentors to step down from the position, temporarily or permanently, as time restrictions dictate.
Frank.