From an earlier discussion among the authors, editors, chairs and a few
other interested parties. (Someon, Ian I think, suggested that this
also be sent to the mailing list.)
Ian Cooper <ian@the-coopers.org> writes:
> A *huge* problem at the moment is that despite requests for "issues"
> to add to an issues list of things to be resolved, there have been
> *no* submissions. I'm an editor and have to take on some of the
> responsibility to come up with those issues (you'll note some of the
> editor notes in the current version) but I find it very disturbing
> that no-one else has identified any problems; there are a *lot*.
From the messages, it sounds like there are two types of "issues".
(1) internal consistency issues; e.g., the document set is basically
the right thing, but it is ambiguous or internally inconsistent on
some points. (2) incorrect design choices issues; e.g., the document
proposes a bad trade-off or doesn't address a potentially tricky
trade-off.
(1) internal consistency
Ian, I take it, was focused on the former. In my opinion, the draft
authors must take primary responsibility for these issues. These are
bugs of execution rather than places where additional input is
needed. Relying on others to correct our bugs waste their time, slows
down the process, and saps their energy and enthusiasm. Of course, we
won't be perfect, and once we have a draft we're happy with, we should
encourage and act on bug reports that come in. But we should not rely
on the list to do the work that is fundamentally the authors'
responsibility.
I'm as responsible as anyone this sloppiness; during the push to
get a draft out before the meeting deadline, I did not make a detailed
pass looking for these sorts issues.
Plan: As I understand it, Ian plans to make a thorough pass and Dan
has a list of other issues at this level that she will send him. After
that, I would suggest that the authors make a thorough pass with the
goal of presenting to the mailing list a "bug free/internally
consistent" draft.
We should do these things quickly.
(2) design choices
This is where active involvement from the mailing list will be crucial
and a high level of involvement essential. I think the current
document proposes a reasonable and achievable set of features. But, as
we design a protocol to meet these goals, it is entirely possible that
we will find that some of the features are more expensive or complex
than we had first estimated. We need to get as much input from
a wide range of people to identify such bad decisions or open
questions before we sink a lot of time writing a protocol that is more
complex than it should be.
A great example of this sort of discussion was Alex Rousskov's probing
on volume definition v. lookup time. There have been a pretty good
number of such discussions and decisions, and I think we have reached
closure on most of these discussions.
Then, if in the course of the detailed design, we bump into such an
issue that wasn't flagged, the requirements document provides
guidelines for making the appropriate trade-offs. And, if a particular
design is unable to meet a requirement, or if a requirement appears to
be more expensive than expected, that issues should be flagged for
intense discussion.
I think the relative lack of traffic reflects the fact that there has
been a good first few rounds of discussions about requirements, that
the RUP draft seems to make a reasonable stab at defining the starting
point requirements, and that everyone is expecting another few rounds
of intense discussions when hard trade-offs start to arise.
We need to get us much requirements-phase feedback as we can to avoid
as many ratholes as possible. But we should not let "finishing"
this discussion gate the closure of the RUP document or the beginning of
detailed design. Some of these issues are fundamentally tied to or
stem from particular implementation choices, so they are difficult to
discover in a "requirements gathering" phase that is (and should be)
more general than a particular design or protocol architecture. The
discussion of features v. complexity fundamentally cannot be
"finished" in the abstract -- we need to get our hands dirty and
propose specific trade-offs.
So, my sense is that we should dot our i's and cross our t's for the
current requirements document and then see if we can design a protocol
that lives up to it.
-mike
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:23:00 MST