Thanks for the comments, John.
I understand that you need to force yourself
to be out of the loop a while. This stuff is
seductive. There's nothing I'd rather be working
on, so I spent yesterday putting the article
together instead of getting my work done! (I
can only afford so much of that. :_) (01)
A few short responses:
* Question-Asking Process
* Typo
* Refinements
* Evaluation Strategy
* Node Types
* Extensions (02)
Question-Asking Process
-----------------------
You are right about needing a process that helps
you to "ask the right question". That's the kind
of problem that facilitated IBIS excels at. (03)
The trick is carry on those discussions online,
reach an agreement, and then *bury* the dialog, with
a link to it so the reasons can be examined when
desired. (04)
That's one aspect of the problem that is glossed
over in the current version of the tutorial. (05)
Typo
----
Thanks for the catch:
>
> because the system doesn't __allow_ "illegal"
> states , even temporarily.
> (06)
Refinements
-----------
Thanks for the other ideas, as well. Would that we
had the system in operation, so we could capture
them in context as alternatives the ideas I've proposed! (07)
The most important thing for the design, though, is
that you've suggested some refinements and alternatives
that I would have a hard time capturing in the system,
as currently spec'd. (08)
It's part of the "reaching agreement" issue,
because your suggestions bring into question features
of the proposal. More accurately, they bring to
light questions that should have been asked in the
original version. (09)
It's the moral of the IBIS story: Any "answer" (statement)
is in reality an "alternative"--one of potentially many
possible answers to a question that was never asked.
IBIS makes sure that the question gets asked, as you
have done here. (010)
I've got to think about two things: (011)
a) How to integrate your suggestions into the
proposal, and (012)
b) How to modify the design so they have a
"natural home". (013)
Evaluation Strategy
-------------------
My initial reaction is that the kind of evaluation
strategy you suggest is something that should
operate outside the system--which would allow
other strategies to be plugged in and used. (014)
That's an off-the-cuff reaction, though. We
definitely need more discussion of the pros and
cons. (015)
Node Types
----------
A node should definitely be limited to a single
idea. It was the observation that a paragraph is
supposed to represent a single idea that led to
the concept of "NodeIDs", where each "node" is a
heading or paragraph in a purplized document. (016)
I like your outline of node types and some of the
additions you've made. They bring up the idea of
extensions (next). It's something I was thinking
about when writing the spec, but neglected to
mention. (017)
Extensions
----------
The DITA spec has done a nice job of defining an
extensible system. You can add tags, but only by
extending existing tags. So a tool that's built
to operate on the basic tags will also do something
reasonable with the extended versions--until and
unless you custom the tool to handle special tags
differently. (018)
That's a hell of an achievement, in my mind. They
use XML tags, but the tags represent objects, and
there is an inheritance hierarchy at work when the
tags are processed. I don't know exactly how they
achieved that goal, but it's a model for the way
the system needs to be designed. (019)
Thinking in terms of a the "challenge" type that
I plan to add tonight: (020)
* One /challenge/ for the system is the ability
to define a usable /core system/ that can be
extended for particular applications. (021)
--/Proof/ that it can be done is exhibited
by DITA--an information-typing architecture. (022)
John Sechrest wrote:
>
> Eric Armstrong <Eric.Armstrong@Sun.COM> writes:
>
> A very nice article. Thank you. It has helped me a lot.
>
> Here are some small comments.
>
> % REQ: Maintain a stable temperature that supports
> % life on earth.
>
>
> The process of choosing the question is vitally important.
> Sometimes questions are generated that have the prefered
> answer already embedded in them.
>
> The difficulty with this "right question" discussion
> is the same problem with many philosophical discussions.
> You end up meta discussing the question, and defining terms
> and never really ever getting to answering the question.
>
> But suppose that instead of the REQ above, we ask the question:
>
> REQ: How should Humans life on the earth?
>
> This becomes a deeply religious discussion quickly. And yet.
> The first question is directly related to this one. So at
> some level you have to ask:
>
> What is the process for asking the right question?
>
>
>
> % l) A drawback statement is /invalid/ if it is not
> % yet linked to a requirement--but it can still
> % be present in the system.
>
> % It seems small but this is another big deal. People
> % generally dislike structured authoring systems for
> % two reasons: (a) they're forced to choose a type
> % when they don't yet know how to categorize what they
> % want to say and (b) they're forced to do things in an
> % uncomfortable sequence because the system doesn't
> % "illegal" states (like a drawback without a requirement
> % to link to), even temporarily.
>
> this last sentence does not have a verb.... What is the verb?
>
> -> because the system doesn't _____ "illegal" states , even temporarily.
>
>
>
> % At this point, the mechanism for choosing among viable
> % alternatives is undecided. It could (and probably
> % should) operate completely outside of the design system.
> % Choices could be made by voting, by personal whim, or
> % by any other mechanism.
>
> I had an idea here. I have an alternative evaluation methodology
> which involves weighting and evaluating each of the nodes.
> If you do a weighted sum of all the nodes, then you basically
> are doing a decision tree evaluation.
>
> So allow each of the participants to
> a) Define the possible states of a node (1-5)
> - 1 Bad (what does it look like to do bad)
> - 2 poor
> - 3 OK
> - 4 good
> - 5 Great (what does it look like to do great)
>
> b) choose on a per person basis what state they thing this
> node is at
>
> c) Define the wieght about how important this node is to what they
> consider important.
>
> Then you can do (for each node ( node-list) {sum(state($node) *
>weight($node))})
> which then gives you an ordered list of proposals.
>
>
> % I'm not sure it matters. As
> % long as we're choosing from a collection of viable
> % alternatives, things will be heck of lot better than
> % they might otherwise have been.
>
> It does matter. It matters a lot. Because the minor drawbacks for some
> will be major drawbacks for others. And the choice need to not be
> made on whose baby is getting gored.
>
>
>
> ...
> % Maybe the only really important task left at this stage
> % of the process is to come up with a catchy name. We
> % could simply add a D: DIBS? IBIDS? BIDS? SPID?
> % Or maybe it could be named after a noted problem solver
> % or peacemaker. (Buckminster? Bucky? Wright Stuff?)
>
> % Any other ideas?
>
> Thank you. That was very helpful.
>
> I think that there are several places where things are needed.
> I am still tumbling down the tuple path that jack pushed me down
> some time ago. This is a representation issue, but I can see
> how to use it to drive a system like this.
>
> The nodes of discussion need to have limited size. As a way to keep
> the focus on one issue. The problem with many of the "discussion"
> processes is that they let each node support many different
> types of objects and to refer to many different issues/ideas/drawbacks
> all at once.
>
> Having "articles" written, which put forth material, should not be
> the core of the IBIS decision process. But should be base material
> that is referenced (linked to), but should not be the core of
> the IBIS nodes.
>
> Each node should have just one thing. An idea. which it then
> references other stuff from. If this is done tightly enough,
> then the node can have other attributes, like weight and score etc.
>
> There are many user interface issues around what you are talking about.
> And that would be a good thing to deal with as well. But I will put
> off that set of commentary except to say, that people should
> be able to indicate how they feel about the discussion. And that you should
> be able to put timelines into the system.
>
> You mentioned that you conflated time line and desirability. This is
> a problem. Urgency versus importance is a key problem that most people
> get caught on. You need to be able to represent both independently.
>
> I think this is a great outline. I think the next step is to find all the
> node types and all the things they depend on:
>
>
>
> Q: Question
> A: Alternative / Answer
> P: Pro
> C: Con
>
> REQ: Requirement
> IMP: Importance
> Level 1: Immediate Need -> Major Requirement
> Level 2: Important , but not so -> Minor Requirement
> Level 3: Nice, but not vital
> Level 4: Low level of importance
> Level 5: Not important at all
> URG: Urgency
> QUAL: Quality
> Weight:
>
> ISS: Issue
> PROP: Proposal
> State (complete, incomplete,sound,viable)
> (must have link to Requirements)
> (must have links to advantages)
> (must have links to drawbacks)
> A proposal is /incomplete/ if it has:
> * invalid drawbacks
> * invalid advantages
> * major unaddressed requirements
>
> (addresses, violates,fails to address ) a requirement.
>
>
>
> COMP: Component
> VERS: Component version
>
> DRAW: Drawback
> (must have link to requirement)
> State: (Valid, invalid)
> A drawback statement is /invalid/ if it is not
> yet linked to a requirement--but it can still
> be present in the system.
>
>
> ADV: Advantage
> (must have link to requirement)
>
> REASON: reasons/evidence
> State: (asserted, withdrawn, retracted)
> OBJECTION: Objection
> State: (asserted, withdrawn, retracted)
>
>
>
> Clarification
> Correction
> Restatement
> Question
> (The details still need to be worked out.)
>
>
>
> Tool features:
>
> * *Tagged* so that a proposal is distinguished from
> an objection, and so that a schema can enforce
> the structure.
>
> * *Threaded* so that people can respond within the
> context of a proposal, as when quoting an email
> --but without having to quote and re-re-quote
> material so that it winds up duplicated in every post
> in the thread. (Part of the reason for implementing
> purple numbers in the Yak email archive was to permit
> operations of that kind in the future, and to at least
> allow for granular linking in the meantime.)
>
> * *Attributed* so that the author of any particular
> statement can be identified. (Important, since only
> the author of a statement and the all-powerful
> /editor/ (sys op) can retract a statement.)
>
>
> * *Indenting*. The original text will have indentation.
> Responses from others need to be indented, as well.
> Some way to distinguish the two kinds of indentation
> is needed so that, when displayed or printed, the
> discussion reads like a well-structured dialogue,
> rather than a linear dialogue (as at Slashdot,
> for example).
>
> * *Highlighting*. Like an RSS aggregator, the tool
> used to watch and participate in the discussion
> must make it possible to highlight things you haven't
> yet read.
>
> * *Fast Access* It should also be possible to quickly
> jump to the next unread passage. It should also be
> possible to flag a passage, see an index of flags,
> jump to a passage from the index, and jump from flag
> to flag.
>
> * *Filtering*. Display a proposal without drawbacks,
> with only drawbacks, with or without objections, etc.
>
> * *Collecting and Partitioning*. It should be possible
> to work on multiple projects in the same workspace,
> putting them in folders and picking up where you left
> off when you revisit them. So you may collaborate on
> project A with X, Y, and Z but collaborate on
> project B with M, N, and O. You'll only work on one
> project at any one time, but you should be able to
> see all of your project folders in a single tree,
> switch between them rapidly, copy files between them,
> and possibly share authoring templates and other
> "personal" (non-collaborative) files between them.
>
>
> ----
>
> Any other ideas?
>
>
> Ok. I have to work on a proposal due tuesday, so I will have to leave
> this discussion. But In a week, I would be glad to take the next step.
>
>
>
>
>
>
> -----
> John Sechrest . Helping people use
> . computers and the Internet
> . more effectively
> .
> . Internet: sechrest@peak.org
> .
> . http://www.peak.org/~sechrest
> (023)
--
This message is archived at: (024)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43C07114.1060605@sun.com (025)
|