Snausages

Now, in this particular case, I've been accused of "not reading" the plain and obvious and that I simply should have done my homework.  The point in question is the interpretation of the following from the process documents:

5.6.2 Actions
The SDE (Specification Document Editor) shall create the appropriate documents based on the content of one or more RFCs. Under ideal circumstances the formulation of the Specification would be a mechanical process but it is expected that the SDE will uncover inconsistencies or other issues in the RFC(s) which require clarification by the appropriate EG. In this case the SDE shall liaise with the appropriate EGs directly to resolve the issue. The SDE shall have at least one and preferably several review cycles with the appropriate EGs to ensure accuracy prior to completion of the Specification.

Certainly, this is something that I completely understood.  It is unfathomable to me that the SDE wouldn't uncover inconsistencies and have to come back for "clarification by the appropriate EG".  However, this is not - imho - what actually happened.  What happened was that the SDE came back with the recommendation that we fundamentally change the specification.  This is not "clarification", in the way I understand the term "clarification".  Clearly (to coin a phrase), clarification means to make more clear.  It does not mean to "change the specification in fundamental ways" because there are time issues which force us to make difficult decisions.

A specification, particularly the final RFC, represents a compromise amongst many competing business interests.  If you want to change that compromise, you're invariably going to work against at least one of those interests and thus destroy the compromise.  That is not the process of clarification.  Now, perhaps I have completely misunderstood the use of the word "clarification" in section 5.6.2, but then that just shows that the process itself needs - ahem - clarification.

Further, one of the deep issues with the process as practiced, has been the underlying assumption that the only vote we would get would be on the entire specification, not just the particular specification under question.  This was not just my confusion, but seemed to be a shared understanding by many - on both sides of the issue.  Certainly, the way it was repeatedly represented to me in my queries was that the only chance we would have for another vote would be on the full specification which contained the array of individual specifications.  After much investigation did it turn out that this was not a correct interpretation, but the odd thing was that it was somehow considered to be the "nuclear option" - that is, actually taking a vote on the SDE's rewriting of the specification was considered to be in poor form and something that would cause deep divisions.

Now, of course, I could be confused about this as well.  Certainly, at this point, I'm wondering what all the fuss would be about if, in fact, that a vote following the SDE rewrite of an individual specification was actually spelled out and understood as part of the process - certainly that wouldn't seem to be a "nuclear option", nor would it seem that standard operating procedure should be a source of divisions within the group.  So, color me confused yet again.

In any event, I think it is still necessary to understand exactly what the SDE's limits on "clarification" are.  If "clarification" means making fundamental changes to the specification, then I don't think it should be all that controversial to have a good discussion and another vote on the "clarification".  It's a fundamental change to the compromise and we should be required to see if the compromise still holds.

But then, I'm just a process guy.  What else would I think?