I started talking about where we are headed in terms of governance in my previous thread but I am starting this thread so that we have a separate place for governance discussions.
The document that I would like to base this discussion on is TIP #0: Tcl Core Team Basic Rules which describes the governance used in the Tcl/Tk project. I also just found a Tcl Core Team Interview where the core team talks about how they wanted to encourage contribution whilst maintaining a high quality level of the code, the strengths of Tcl (not relevent here I know...) etc.
Here are a few of the key concepts in Tcl/Tk project that I think we should consider for OpenACS:
- Project - a feature change or a bug fix. Can also be an update to the project website (in our case openacs.org)
- Maintainer - someone who has taken primary responsibility for a piece of the code (in the case of OpenACS probably a package). The maintainer arranges (by delegation if necessary) for bugs to be fixed in his/her area and reviews modications of others to the code.
- Feature changes require approval by the core team. The proposer is responsible for the implementation. Before the code is committed the maintainer reviews it.
- Bug fixes do not require approval by the core team but must be reviewed by the maintainer.
Here are a couple of questions for discussion:
- How many members should be in the core team? It seems the Tcl core team has 15 members. It is pretty clear to me that the members of the .LRN TAB (Technical Adviosory Board) should be in the core team (Don Baccus, Jeff Davis, Lars Pind, and Dan Wickstrom). There are a number of people who have cvs commit rights who are probably candidates. There are certainly other active members in the community to consider as well. Note that in Tcl/Tk the core team members have commit rights on the whole tree and can admin the website.
- How often should the core team meet and how are decisions communicated to the community? I think the weekly IRC meetings of the TAB seem appropriate here. Maybe the OpenACS meeting could be right before the .LRN one as there will mostly be the same people in both meetings. I think that if the core team doesn't want to publish the chat log it must have the discipline to summarize the meeting and publish it in a public place.
- Where should projects (feature changes / bug fixes) be submitted? Probably in the Bug Tracker accompanied by any discussion necessary in the forums.
The Tcl/Tk document is very code centric and doesn't cover important topics such as road maps, visions, and marketing (areas where open source projects have traditionaly not been very strong). I'm not sure which of these should fall within the responsibilies of the core team and which should be taken care of by other groups in the OpenACS community. The .LRN project has three groups - the executive group that should do marketing/evangelizing, visions/road-map, a user group that should coordinate users needs, and a technical group (core team). I think that a user group for OpenACS would make a lot of sense and I think Caroline Meeks is interested in an initiative in that area as well.