At 04:58 PM 12/11/2001 -0600, Mike Dahlin wrote:
> > This email really belongs on the list rather than in private email.
>
>Ian, I quote you below; if you (or anyone else) doesn't object, tomorrow I
>will send the message below to the mailing list to help continue the
>discussion there. In the mean time, those who have been involved in this
>private email discussion so far should feel free to read and comment by
>reply-all (or, as far as I am concerned, feel free to reply to the list.)
>
>-mike
Hi, Mike, I agree with everything you said below. We got good coverage on
RUP requirements, it's time to move on to design, and flush out more
issues/discussions as we go. The chairs should be more active driving the
process forward. - Dan
>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" draft. We should
>do these things quickly. Ian, what deadline are you shooting for the
>reorganized draft? (FYI: my schedule during the coming weeks:
>traveling (intermittent e-mail) December 21 through 28; traveling (no
>e-mail) January 11th through 20th. Other than that, I will attempt to
>provide quick turnaround with the next draft.)
>
>
>
>(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