Not exactly minutes, but a summary of the discussion

General

• Classes being discussed should be marked with a version number, since everything is changing so fast.
• We need a better plan for separating the specific from the general discussion, and for generating an agreed on list of recommendations for each class.

Form

• Names for get/set methods
  • should be getXXX and setXXX, so it is clear what is being done (but see below)
• one class per file
  • In the case of CalDigi, it probably makes sense to have CalLogReadout be a nested class, since it's accessed through CalDigi anyway.  In that case, it can be renamed Readout, or LogReadout, since it will be accessed as CalDigi::LogReadout, and the Cal is explicit.
• code in headers (I forgot to include it in my CalDigi report. We never talked about it.)
  • The convention is that simple methods can be implemented in the headers. The usual definition of "simple" is "one-line," but a better one might be "no-logic."
           xxx() { return m_data;} 
    certainly satisfies both of these, but what about:
           xxx() {
                    char nRanges = (char)m_readout.size();
                    if (nRanges == 1)
                            return (range == ((m_readout[0])).getRange(face)) ? ((m_readout[0])).getAdc(face) : (short)-1;
                    else
                            return ((m_readout[(nRanges + range - ((m_readout[0])).getRange(face)) %nRanges])).getAdc(face);
            }
    It seems that there's enough going on here that it should be in an implementation file.
• Name of the container: List, Vector, Col
  • Col: the idea is that the client isn't supposed to know about the details of the container. Also, it allows the developer to change her mind about this without sowing hugh confusion.
• Using enums for storing masks, etc. in a class.
  • I stand corrected. Perfectly good way to do it.

Content

• Use of set methods vs. initializing in the constructor
  • Things should be set by the constructor or specific initialize/finalize methods, unless really necessary to do otherwise.
• init() vs. constructor for setting params
  • Is there some constraint imposed by ROOT?
• VolumeIdentifier in Digis (and elsewhere?) or more use of idents classes
  • This would increase uniformity. Probably not much other real advantage
  • If we do this, we should generate methods that extract the information we need from the volId
• special efforts to save space (We didn't come to any conclusion on this.)
  • Packing
  • short data types: short, char
• connection of Digis to MC (and vice-versa)
  • This should probably wait for a special class mapping the two-way relationship
• marking of noise hits
  • This is similar to the above, but not the same.  Noise will be added at the digitization stage, so if we don't put the info into the digis themselves, we need a class containing something like a list of pointers to noise-generated digis. This job seems easier than the one above. We should maybe do this first.