In one case (the dynamic chapter) we voted out a few sections, and in
another (the C++ chapter) we ended up postponing the second vote.
Several people have expressed amazement that the process could go so
far, only to be dealt a setback at the last minute. The purpose of
this note is to defend, and encourage, serious consideration at the
second vote.
I assert (and have heard others assert) that the MPI process does not
really allow consideration of global issues until the second vote. In
subcommittee straw votes, attempts to remove entire sections are often
met with "this is only a straw vote - let's give ourselves a chance to
explore this issue - we can always get rid of it later on". In other
cases, the proposal is being formed, and technical issues are being
hashed out, and it can be quite difficult to step back and look at the
global picture. Likewise, I assert that the first vote is pretty much
a technical vote. When people vote yes on a first vote, what I think
they are usually saying is that the technical details are
fine. Because there is another vote coming up, people haven't been
asking the question "do we really want this whole thing in the first
place" since they're not really forced to decide.
It is not until the second vote that you really have to ask yourself
the big question. The second vote means you're committed. It's also
not until the second vote that you have the complete picture. Even
for people who know all along that they would like to get rid of a
proposal, it might be difficult to make others realize the seriousness
of the error they are about to make if it is only a first vote.
What's the purpose of a second vote if there's no chance of reversing
previous decisions?
Finally...
In this and in other areas, I would like to try to vote according
to the following principle:
We should not add anything to MPI for which there is not
a compelling motivation and clear need.
As an outsider to the MPI-1 process, it was my perception and that of
many others that this principle was not invoked often enough. Whether
or not that perception is correct, I think it is a useful
principle. Adding things to MPI is sometimes a long process but there
is no inherent barrier. Removing things is effectively impossible. So
I would like to err on the side of not adding enough, rather than
adding too much, and if there is a serious deficiency, it can be fixed
later. At this point I am not concerned that MPI is lacking critical
functionality, or that the lack of certain functionality might doom
MPI, so we can afford to take a more relaxed and cautious approach.
Just an opinion.
Bill