Forum OpenACS Q&A: Response to Priorities, Roles, and the future of OpenACS

We have increasing number of people wishing to participate who come from different backgrounds and with different skillsets. We need a way to welcome these people into the project and provide them ways to make useful contributions

An idea that's crossed my mind is that perhaps we need a volunteer "volunteer coordinator". I'm used to this working model from my background as a board member of a largish (7,500 member) non-profit.

In that organization, the volunteer coordinator was the interface point for new faces that wanted to do volunteer work us. It was their responsibility to be on top of what volunteer jobs were available (like many volunteer organizations, we had formal job descriptions for volunteers as well as staff), what skills particular volunteers had, and to do a lot of the work associated with matching volunteers with jobs, including informal job interviews with potential volunteers.

That's *much* more formalism than we need. Someone mentioned the idea of gathering profile information as part of the registration process here, and I find that an interesting idea. I think it would be great to have an inventory of skills possessed by community members, along with a list of tasks that need doing. I think it would be great if someone would step forward and offer to take on this task.

For instance, if we were to draw up bylaws and all that, do we have any lawyers in the house, or would we have to hire one? Right now, we don't know. Wouldn't it be nice if we did?

More diverse topics not directly related to OpenACS development are coming up as we picke up more people, yet the site does not allow new topics to be added.. maybe we should revisit this.

Specific recommendations for improvements to this site should be forwarded directly to Talli Somekh at Musea, with a courtesy cc: to Ben.

We have larger numbers of developers who are updating or adding code features. We need to be able to review and absorb these code changes more efficiently. The original OpenACS project was hosted at SourceForge and allowed greater developer access than the current model. Should we revisit this? How to we test and QA and coordinate patches and updates as they come in?

Well ... commit access to the OpenACS 4.x project is easy to get, there are probably a couple of dozen folks who can commit to various bits of the tree today. Only a few can commit to every part of the tree. The reason for that is simply that we've got a lot of newcomers who are total strangers to the project. I accidently had the tree entirely open at one point in time, and one newcomer started "fixing" code for folks in packages they were working on without bothering to tell them, ask if they minded, etc (and they did, I got a couple of "hey, why's this guy mucking in my code behind my back?" letters).

Today, the crew consists mostly of folks who've been involved now for about three months, and I'd feel comfortable letting them commit freely. Then again no one's asking because folks appear to be comfortable just trying to get their own assigned packages ported.

As far as new projects go, when folks have asked, we've given them a cvs tree to play in. And, of course, if someone working on an OpenACS-based project prefers sourceforge they're certainly welcome to go there instead of here.

Our original vision was to be able to run ACS without spending a fortune on Oracle. I think it is time to revisit that.. like revisiting a business plan

This is an excellent point. I personally haven't quite figured out how to reconcile that original vision with our decision to support Oracle as well as Postgres. We were interested in multi-db support all along. The major reason that decision was made was that aD was abandoning their ACS Tcl user base and we didn't want that user base to be left without a community. That's great short-term justification but might not be enough to support a long-term vision.