Responding to Peter's original request for comments:
I think the TIP#0 document is pretty close to something OpenACS can work with. We will have to better define how the optional packages fit into this process. Possibly with a limited openacs core, a set of official optional packages, and a third set of contributed packages that have not been reviewed by the core team, but which are avaiable for download.
One question I have, is if a package is not part of the core openacs, such as forums, survey, wimpy-point, etc, who would approve new features? Would the package maintainer do this, or would the core team also be involved. This is probably the biggest difference between OpenACS and Tcl. In TIP#0 they mention that the core team only works on the Tcl core, which is clearly defined. Because all the packages etc are distributed from openacs.org, and there is a desire to offer a full-featured download of openacs with optional packages, I think we definitely should consider the process for optional packages that will be distributed with a full openacs release also.
The core team should probably decide for themselves how often they need to meet to coordinate the project. Maybe at least once a month, but hopefully more often.
The tcl core team has a mailing list where they conduct their dicussions. From reading the TIP it looks like only the core team can post, but the archives are public. I think this is a good idea for OpenACS also.
Peter asks, where should features/bugs be submitted. We should use the bugtracker, possibly making changes that reflect the processes of new feature approval more closely.
