Date: Wed, 20 Dec 2000 11:04:29 -0800
From: | Garold L. Johnson |
dynalt@dynalt.com> Reply-To: unrev-II@egroups.com |
To: | UnRev II eGroup |
unrev-II@egroups.com |
Subject: | OHS/DKR problem revisited |
I would like to try to capture what I think Paul and I have covered so far.
These problems are socio-technical in nature. Most of them are more social than technical.
Solutions to these problems will be socio-technical. Solutions will be developed and implemented by groups of individuals collaborating in their solution. Therefore, tools which facilitate collaboration will facilitate the solution of many of these problems.
We need to distinguish the investigation of the nature of the problems and the attempt to solve the problems. From a KM development perspective, the nature of the effort to solve the problem drives requirements. Some investigation will be required in order to prototype, but it would be better if we could tackle problems that we know we can solve so that we can tell when our tools are helping. If we fail to solve a major social problem with our evolving tool, is it the tools or the problem?
We need to reach agreement on what the tools should do.
We need to use the tools to determine that they really contribute to problem solution.
We need to iterate the solution and the requirements as necessary until the tools become useful for larger problems.
All of this would be a lot easier if we already had the sort of system that we wish to build! It sure sounds like bootstrapping to me!
We need to be able to represent addressable atoms of information. The kinds of information, the nature of the representation, and the operations that can be performed on them is part of the problem investigation.
Since all input from the system will be by individuals, a successful tools will be usable by a single individual for managing the information with which he is directly involved. Start of scalability is 1 person.
The next step beyond the individual is communication with other individuals. This is essentially publishing at varying levels of formality.
Beyond publishing is accepting feedback.
Beyond feedback is collaboration.
Studies show that people resist formalisms in capturing information even if they use such conventions by observations.
http://www.csdl.tamu.edu/~shipman/formality-paper/harmful.html
Given this, we need ways to capture information as it arises, and connect it in various ways later.
The tools need to allow us to capture and organization generated information.
"You can't start from where you aren't, you have to start from where you are."
What tools do we have that we can start to use for discussing the development of the KM tools.
The source for several varieties of Wiki is available so that the tool can be extended in various ways
There is a substantial community of experience in the use of Wiki that we can draw upon.
All information is available in straight text allowing relatively easy analysis and post-processing.
SourceForge provides all kinds of tools for managing an open source project.
Issue tracking systems that are web based
Requirements tools
Nearly any existing tools to support collaboration among software developers.
General collaboration spaces such as Groove, BCSW, etc.
Others?
...sounds good, but I haven't been able to get it installed.
That should be enough to get a discussion started! (g)
Thanks,
Sincerely,
Garold (Gary) L. Johnson