I have my own views on most things, and the way I would design the container class is different from you. But it is impractical to write software by committee. The advantage is that you can do what you want. The disadvantage is that there are no guarantees that what you do will be adopted unrevised by the group as an ultimate framework component. I knew that when I wrote hddm. I propose the following general guidelines to make it easy for people to work within the group.
  1. People should be free to adopt a component of the sofware apparatus and develop it. The SWG should take care of approving adoptions and detecting and resolving collisions, but so far that has not been a problem.
  2. An adoptor should have a maximum liberty to make choices in the design, provided that it does not impose excessive revision work on prior existing code maintained by others.
  3. An adoptor's choices for his project will have implications for future projects, therefore he should have clear reasons for his interface choices that he can articulate and defend. These should be described in a software Technical Note and presented to the collaboration at a meeting. He does not have to convince everyone that his choices are optimal.
  4. The collaboration does not have to decide or agree with the detailed design or choices made, they simply must be informed and given the liberty to voice objections if they so please. The responsible party would be wise to listen to sound advice, but the final decision rests with the person taking responsibility for the component.
  5. An adoptor who wants to make changes to existing components needs to get the SWG to decide and agree with the proposed revisions, because they involve real work on the part of others.
Note that the designer who realizes that item 5 is costly in terms of time, sweat, and heart-rate will be drawn towards object-oriented techniques that keep such interdependences simple and flexible. These guidelines are very close to the ones followed for physical detector components. I think they fit the culture of our collaboration and will work in a context of limited manpower.