I think this is a bit of a tightrope-walking exercise. I'm in favor of transparency and open communication, but on the other hand am not a believer in "design by committee". I do believe in "divide and conquer". The problem with dividing tasks among smaller groups of folks is that there is often a tendency to forget to include wider groups of people in the discussion.
The model that I think works well is for interested folks to work together on a design and plan for improvements to a particular bit of the toolkit or a new package, and to actively seek community feedback *before implementation*.
If the group feels comfortable using our forum tools to communicate while working on a design, that's fine, but if not, I won't get bent out of shape as long as the toolkit community at large has the chance to make meaningful feedback at some point.
So I find nothing wrong with the fact that Neophytos and I (to pick one example) are privately discussing the fact that we'd like to move Service Contract descriptions to XML much like package .info files and away from SQL definitions that have to be written separately for Oracle and PostgreSQL. When things move further along, I'll certainly ask Neophytos to make a public proposal so folks can comment, suggest improvement etc.
Likewise I've talked some with other folks about possible improvements to permisisons, workflow and other packages and expect to float some ideas in public after I have some more time to muddle through my own thinking.
We could hold all of our discussions in public - there's been a public thread on redoing the context bar stuff and to use the template's "property" feature to move rendering of headers and the context bar to the site's master template (Carl Coryell-Martin's on the hook for this task as of last night, large quantities of beer will cause folks to foolishly volunteer, remember that!). In truth, though, that discussion's serves as an example as to why I don't get terribly hung up about folks discussing features and changes in private - only a very small number of folks participated in this public discussion.
But ... significant changes or new work should be floated in public before implementation whenever possible. In the case of dotLRN I'm not sure it was really practical to do so, as the work was large, and the product spec client-driven and not really subject to change (Sloan has a rather large existing user base who expect to find familiar UIs and functionality in dotLRN as they now have in SloanSpace).
