How should committees be composed?

The question sought to define the composition of committees in simple terms -- who should be represented, i.e., technologists, producers, consumers, government representatives, etc. Steve Oksala brought several important points to bear.

1. The people who populate the committees will take on a variety of different positions as the need arises. Beyond profession, company, and nation, they will at times take a public good perspective, trade association perspective, or standards association perspective. All of these perspectives may be necessary at one point in time.
2. It is assumed that the people in a standards committee should be technically competent. Whether an individual represents a corporate, public, or professional perspective is less important than that they do it competently, consciously, and with disclosure. Regarding the last criteria, the point is that not only should the participant know what perspective they are taking, but they should be clear with their colleagues about the perspective.
3. While technical participation and perspective should dominate the development process, the approval process should be broader and at the international level, the national perspective should dominate.

The question of committee composition really has two parts. The first is to suggest that it may be appropriate to compose different committees for different functions, and then to ask for each of these committees, who should be encouraged to participate. It is possible to identify at least four parts of the process:

1. The process of deciding to develop a standard (see next section)
2. The process of developing of a standard
3. The process of ``approving'' the standard at the committee level
4. The process of ``approving'' the standard at a national or international level

. . . [I]t is common that the people doing the technical work don't get a real vote at the end. . . . [I]n the approval process everyone should have the opportunity to comment at the very end of the process - the ``go/no go'' point - and that the development groups should be required to reasonably address these comments. Not to accept them, and not to provide a detailed technical defense of the choices, but to at least ensure that an open process exists and that there is a generally accepted standard.