Absolutely right, Henry. There are positives and negatives
to the feature. The main negative, in my mind, is that when
I go back to a reorganized discussions, the structure and
relationships of things will be different than when I left.
I'm not sure how well that works, from a human factors
standpoint. (Maybe it's overlooked, or maybe it causes
enormous confusion. Don't know.)
Mostly, though, I think we are talking about timing of the
revisions. When the part is released, or the software goes
FCS, it is time to "freeze" the dialog, so it remains an
unchanged historical record.
A copy can be made for the next version, if that is
appropriate. (Software -- probably. Airplane -- maybe not.)
But, up until the discussion is actually frozen and a decision
is made, it should be malleable, so as to reflect the best
possible thinking and exposition of ideas.
You are, however, totally right to call for the equivalent of
"policy controls" that allow malleability to be turned on and
off.
Henry van Eyken wrote:
>
> Indeed. Eric's thoughts are very useful, but not always applicable. I
> am much in
> accord with the examples given, but one may come up with other
> examples as well.
>
> An engineer advocating a widget for an aircraft's steering mechanism
> does not have
> the right to remove or alter the relevant documentation from a DKR
> after that
> widget has been put into use. Investigators looking into an airplane
> crash should
> have the full record available.
>
> And it is has been frowned on that Nixon erased parts of the White
> House tapes.
>
> Degree of an author's responsibility is a factor.
>
> And then there are authors and readers who are more interested in
> Napoleon's love
> life than his prowess in politics and war.
>
> I agree very much with Eric as far as his specifics go, but I doubt
> the reasoning
> ought be made into a rule without regard for circumstance.
> Nevertheless, following
> Rod, the post does belong in a DKR keeper's policy manual along with a
> note that
> editorial discretion is the better part of valor.
>
> Henry
>
> Rod Welch wrote:
>
> > Eric,
> >
> > Good reasoning that belongs in the DKR keeper pile, similar to your
> planning on
> > 000212.....
> >
> > http://www.welchco.com/sd/08/00101/02/00/02/12/193428.HTM#L332415
> >
> > Rod
> >
> > Eric Armstrong wrote:
> > >
> > > In the discussion I had with Lee last week, a couple
> > > of thoughts came out that I would like to post to a
> > > wider audience. (As usual, I'm thinking in email. I'll
> > > post as an HTML page later.)
> > >
> > > The core is this: The concept of an eternal and unchanging
> > > archive of exactly what was expressed, when, and by whom,
> > > is highly overrated, in my opinion. In my opinion, we think
> > > that way because we are only used to two options: full
> > > history, and no history. Of the two, we prefer having a
> > > history.
> > >
> > > Let's consider that we have a collaborative email-ish
> > > discussion going on, most likely based on an IBIS-style
> > > investigation of issues, and that we have our dream data
> > > engine (Nodal, in all liklihood) powering it.
> > >
> > > Now, lets consider a few cases.
> > >
> > > CASE #1: Wrong audience.
> > > I post a message to the group that was intended for an
> > > individual. Or I accidentally post to the wrong group.
> > > As the author of the message, I have a perfect right to
> > > press the "retract" button, as it were, and remvoe the
> > > noise from the wires.
> > >
> > > CASE #2: Wrong assertion.
> > > I post a message that says, "A is true", and someone
> > > replies, "no it's not", with canonical proof that I
> > > am wrong. Well darn it all, I want to remove that
> > > hare-brained, addle-pated, wrong-headed, idiotic claim,
> > > so I don't look a fool for all eternity. And as its
> > > author, I have a right to do that!
> > >
> > > Now maybe I just have to file the "desire to delete",
> > > and when the person responding takes away their
> > > contradiction, then the whole thing can disappear.
> > >
> > > Or maybe I can at least edit the thing to say that
> > > "you'd think, on the surface, that A is true, but as
> > > Ralph so alerty points out, ..." Or words to that
> > > effect. Details to be decided. But you get the idea.
> > >
> > > CASE #3: Civil Discourse.
> > > Here, tempers flare. I say, "you rat-brained son of a
> > > skunk". He/she says, "you pig-eating, flaming goose
> > > neck", and we're off to the wars. After a while,
> > > everyone calms down. I edit my message to read, "I'm
> > > not sure you're right about that". He/she edits their
> > > message to read "I have to disagree". Later on, reading
> > > the archive, the information content is the same. It is
> > > only the emotions that have been extracted.
> > >
> > > The bottom line here is that the overall readability and
> > > usability of the archive is improved as a result of the
> > > editing. At the moment, an archive is a huge field of
> > > wheat, with needles strewn about. You search the field
> > > looking for needles, and of course you spend a lot more
> > > time "hopeless separating the chaff from the chaff".
> > >
> > > Message threads begins to organize the wheat into haystacks.
> > > But as we all know, often a message that belongs in a
> > > thread is posted outside of it. The ability to edit the
> > > archive makes it possible to put it where it belongs,
> > > which reduces the number of haystacks and makes them a
> > > more accurate reflection of the dialog.
> > >
> > > Similarly, removing material helps to reduce the size of
> > > the haystack. Both reorganization and removal help you
> > > narrow your search and make it more effective.
> > >
> > > The alternative -- the unedited archive -- is a mass of
> > > detail that no one ever sees. If you can link to it --
> > > but you can't find anything in it, and you don't even
> > > want to start looking, then the archive loses much of its
> > > potential value.
> > >
> > > The archive, should, over time, become a "narrative
> > > history" of the discussion. What options did we consider,
> > > which ones did we reject and why. What did we learn. What
> > > did we end up with, and why.
> > >
> > > Like any narrative -- a story told in a novel or over a
> > > campfire -- it benefits from revision and editing. Rough
> > > drafts are simply not all that much use, except to the
> > > historian.
> > >
> > > That leads to the first of two arguments in favor of fixed
> > > archives -- the value of maintaining a complete history.
> > > The second argument is over the possibility of broken links.
> > >
> > > COUNTER ARGUMENT #1: History
> > > For the process-gurus, a history is invaluable. How did
> > > we get here? How did that group *actually* arrive at
> > > those conclusions. For such folks, the fixed archive, IN
> > > COMBINATION WITH THE EDITED VERSION, is invaluable.
> > >
> > > Tracing the evolution of the archive lets them see when
> > > tempers flared, how things were retracted, the deals that
> > > were made. "I'll remove my comment if you'll remove yours",
> > > etc. Then, when the whole ball of wax disappears, the
> > > process folks can dissect the social processes that made it
> > > happen.
> > >
> > > That kind of archeaology can certainly be valuable. And
> > > it makes it worth considering retaining the original
> > > archive via versioning, as the edited archive is constructed.
> > > But it is important to remember that for everyone *except*
> > > the process historian, it is the readable version of the
> > > archive that is most valuable -- it contains the distilled
> > > collection of "knowledge nuggets", with the minimum of
> > > excess material.
> > >
> > > There is a space consideration, though. Since the archiving
> > > and versioning consumes additional space, resource constraints
> > > may play a role in the deciding whether or not to retain
> > > the unedited archive.
> > >
> > > Then, too, when I accidentally post a note that was intended
> > > for my girlfriend, I unequivocally reserve the right to
> > > remove it, I care not what!
> > >
> > > Note:
> > > This kind of case happened just the other day.
> > > At home, I have the alias "sun" for my work address. At
> > > work, I have (HAD) the alias "sunstatus" for the folks who
> > > stay abreast of what I'm working on. I was creating an alpha
> > > test-list for my learn-by-ear, see-how-its-played tune teaching
> > > program, and mailing it back and forth between the two accounts
> > > as I thought of additional people to put on the list. At work,
> > > I typed "sun" without thinking, and autocompletion expanded it
> > > to "sunStatus" and mailed it to the gang of folks I do projects
> > > for. Not good! In such cases, "retract" is really necessary.)
> > >
> > > COUNTER ARGUMENT #1: Broken links
> > > The second counter argument concerns broken links. That is
> > > of course a serious technical consideration. What if I have
> > > a pointer to a node, and that node has disappeared? Given a
> > > data engine like Nodal, I believe that the issue is largely
> > > moot.
> > >
> > > First, note that Nodal specifies that the default linking is
> > > to the latest version of a node. So when a node is replaced
> > > by an edited version, no broken link results.
> > >
> > > Second, since the back link facility keeps track of who is
> > > has pointers to the node, the engine knows when the node can
> > > be retired, or when it needs to be kept around.
> > >
> > > Implementation note:
> > > The node would be marked as deleted. If no links exist to
> > > the node, it would be targeted as a *candidate* for
> > > removal. But there could still be external links who have
> > > not "synced" with the system recently. The "ok to eradicate"
> > > process would have to work like this:
> > > a) For each node, maintain a list of folks to whom
> > > he node is potentially visible.
> > > b) Maintain a master list of delete candidates.
> > > c) As each person syncs up, check the master list. For
> > > any node on it they haven't referenced, remove them
> > > from the potentiallyVisibleTo list.
> > > d) When the potentiallyVisibleTo list is empty, the node
> > > can be garbage collected.
> > >
> > > Summary
> > > -------
> > > The value of an archive, like the value of a novel, depends on
> > > its *readability*. Editable archives allow for discussions
> > > that, over time, reflect the best possible reasoning and
> > > explication of issues. Whether or not an unedited version is
> > > retained underneath, it is the edited version which should be
> > > the topmost, publically visible layer.
> > >
> > > Community email addresses:
> > > Post message: unrev-II@onelist.com
> > > Subscribe: unrev-II-subscribe@onelist.com
> > > Unsubscribe: unrev-II-unsubscribe@onelist.com
> > > List owner: unrev-II-owner@onelist.com
> > >
> > > Shortcut URL to this page:
> > > http://www.onelist.com/community/unrev-II
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
> >
> >
> > Community email addresses:
> > Post message: unrev-II@onelist.com
> > Subscribe: unrev-II-subscribe@onelist.com
> > Unsubscribe: unrev-II-unsubscribe@onelist.com
> > List owner: unrev-II-owner@onelist.com
> >
> > Shortcut URL to this page:
> > http://www.onelist.com/community/unrev-II
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-II-subscribe@onelist.com
> Unsubscribe: unrev-II-unsubscribe@onelist.com
> List owner: unrev-II-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/unrev-II
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Small business owners...
Tell us what you think!
http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/IHFolB/TM
---------------------------------------------------------------------~->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2b29 : Fri Aug 03 2001 - 16:23:34 PDT