I don't think that this is an 'or' question.
Different aspects of an archival record are needed for different pruposes.
Much of this will come out when we attempt to get a more comprehensive set
of actors and use cases.
A 'nearly accurate' historical archive is valuable for historical research.
I say 'nearly accurate' to allow for the editing or deleting of silly
mistakes or embarrasing errors.
In order for collaboration to be most effective, we need to provide stable
points in the duscussion.
One of these is a summary of the various positions and ideas that have been
proposed in a given 'thread'. This just organizes the results of what is
otherwise a rambling record.
The next is the point at which decisions have finally been made and agreed
upon, possibly with dissenting views.
These stable points are necessary for collaboration in order to be able to
find and organize the set of agreements that the collaboration has produced.
Having to reconstruct them from scratch every time is energy consuming and
error prone.
At some point in the collaboration on a sizeable project, we need to
document the results in a form that others can follow for understanding the
final product. It shouldn't be necessary to wade through all of the history,
but the salient parts of the history should be available.
This is exactly what happens in the evolution of scientific or mathematical
theory. Learning calculas, for example, would be a major undertaking if all
that was available was the journals of Newton and Leibniz (if I have the
names right).
David Parnas wrote an excellent paper called "A Rational Design Process: How
and Why to Fake It", in which he says that no real project ever got built
from the top down, but that we can and should construct a paper trail that
represents how a true top down approach could have brought about the results
that actually occurred.
I think of IBIS in this way. Studies have shown the resistance that many
people have to classifying their comments as they make them. A refactoring
that creates and IBIS style discussion from a less structured discussion
could be ectremely valuable.
Neil Larson build a networkd based hierarchical, hyperlinked collaboration
system. His experience was that the system required an knowledge worker to
organize areas of high activity to provide a hypertext system that could be
navigated at any time.
The Extreme Programming Wiki found that elements needed to be refactored
when they got too disorganized. Since refactoring is one of their main
principles because they found the same necessity in code, we can either say
they wer biased toward refactoring or that their experience that it was
necessary in code is a good reason to consider that it will be necessary in
other forms of task oriented expression.
Thanks,
Garold (Gary) L. Johnson
DYNAMIC Alternatives
----- Original Message -----
From: "Henry van Eyken" <vaneyken@sympatico.ca>
To: <unrev-II@yahoogroups.com>
Sent: Friday, August 03, 2001 4:51 PM
Subject: Re: [unrev-II] Maleable Archives
> Eric.
>
> I think we are converging. I also think that the last word on this topic
> hasn't been said yet. I am inclined to the view that we need different
kinds
> of records. For example, a proper historical record that allows for future
> investigations into what happened. And a competently edited record to
remove
> "dandruff." And another form of competently edited record, a digest. Of
> digests we may have have them couched in the language of experts, and in
the
> common vernacular. Writers of school texts may digest them further and put
> the material in a language most suited for young people. And aside from
all
> of the above, an author should be able to withdraw accidental items such
as
> the ones you first commented on: those embarrassing mistakes. Besides all
> this, we shall have the encyclopedic DKRs (such as reported on at
> http://www.bootstrap.org/archive/archive_firstoff_1.html#E ) in which
facts
> found to be erroneous are corrected to the best of competent human ability
.
>
> I believe that if we get that e-journal, "Engelbart in Context" really off
> the ground we shall gain plenty of experience in this area.
>
> Henry
>
> P.S. We used the word "archive" in the above url for it is still a static
> affair. Doug and I are hoping to see it eventually turn into a DKR worthy
of
> its name with continual proper updating in situ.
>
>
>
> Eric Armstrong wrote:
>
> > 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.
> >
> >
> > 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 http://docs.yahoo.com/info/terms/
>
>
>
------------------------ 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 10 2001 - 18:11:29 PDT