eekim.com > OHS > SRI Meetings (May-Oct 2000) > Minutes

Minutes: June 15, 2000    (01)

4-6pm, SRI Engineering Building, EK255
By Su-Ling C. Yee <yeemailbox@yahoo.com>    (02)

Present    (03)


1) Action items decided:    (014)

2) News:    (021)

3) Lee has installed WIKI at Bootstrap.org. The URL (which Lee also posted on eGroups) is http://bootstrap.org:8080/OHS. WIKI is on a separate port. Users can put up pure text; WIKI will format it using html. Anybody can edit these Web pages. It's a way for us to put everything together, and organize our thoughts and ideas. It's primarily a tool for us to use right now, a convenience. However, it can be used as a way to experiment with collaboration models. It has an infinite undo facility. Lee is the manager of the site. A login mechanism can be set up.    (025)

One drawback is that WIKI has no attributions. So we must work on the basis of social contract, and users must abide by ground rules. For example, all users should set up a homepage and use that as the mechanism for attribution. Each page should be owned by somebody, who is responsible for the actual text there. Everyone else can add comments, but should not change original text. One way of doing version control is to copy the original to a new document, add a suffix to the document's title, and link it to the original. WIKI is anarchical. Everyone who wants to participate must look at the ground rules, and should suggest changes if so inclined. Eugene encourages all to visit WIKI and look at the ground rules.    (026)

We discussed of the format for the glossary (already on WIKI), ground rules, and procedures for editing it. Whoever signs the glossary should be responsible. Bill Bearden is going through it right now. Everything is in one directory of pages. Have name anchor in OHS, so can refer to glossary: so can do Glossary#OHS to take user there.    (027)

Rod asks many questions. Lee, Eugene and Eric emphasize that it's just a tool for us to experiment with right now. It's an online collaborative tool and we should collaborate online. WIKI can serve as prototype for any kind of methodology. We can use it to experiment with use cases. Nice to expose anchors. Use purple numbers. CSS style sheet exists. Can define visualization style. Infinitely cross-linkable. Rod proposes that Eric should be the only one who makes changes to the requirements.    (028)

4) Joe showed the photos he took of Doug doing the Augment demo last week. Joe explained his idea on how we should do the video demo. He says we need to do a planned production of it. (See Action items.) John suggests we get hold of the Augment manuals and tutorial documents, and study them, mine them for our requirements.    (029)

5) Eugene suggests an approach to our meetings: announcements at the beginning, and for the purpose of focus, items not directly related to OHS development should be taken offline. All in agreement.    (030)

6) Eric's talk on Java One postponed for next week because running short of time.    (031)

7) Eugene reports that Mozilla enthused about OHS project. One of their main engineers spent last few weeks reading Doug's papers on his own time. Collaboration potential is very good . A Gnutella presentation can also be scheduled for one of our meetings.    (032)

8) Eugene raises the issue of the dichotomy between the online and offline communities. We need to be as inclusive as possible. Minutes are important to keep everyone in sync. Misconception that this is a Stanford project and that we are not committed to Open Source. We don't have a good tool for people in remote locations to participate. They should be able to participate in creating the agenda.    (033)

Gil points out that people like him in remote locations perceive these meetings to be closed. (We agree we need to confirm with Doug the openess of these meetings -- see Action items.) Gil points out there's also the problem of time differences, but that it should be possible for people not local to contribute to the agenda and participate in some meaningful way.    (034)

Eugene mentions the possibility of audio conferencing. (NB. Currently it is possible to teleconference in.) Eugene said that we should make itclear to all list subscribers that they're welcome to stop by when in the area. Most Open Source projects don't happen face-to-face. Most work is done online. So this issue is important in future, when we have code base, requirements, etc. Once we reach the point of design implementation, we will shift to being online.    (035)

Currently, this is the way the agenda is set: Eugene (meeting facilitator appointed by Doug) solicits agenda items, this is posted on his web site. Eugene talks to Doug and asks him what he wants discussed in the meeting. Rod and John request Eugene post a reminder calling for agenda items and including the URL to the current agenda every week. Eugene agrees.    (036)

9) Eugene talks about our bootstrapping strategy. We should be doing bottom up things while top down stuff is being discussed. By developing basic XML schemes for content we're currently generating -- minutes, agendas, glossary, use cases/requirements -- we can generate HTML automatically and build in the features Doug wants such as the purple numbers. This will helps us focus, and refine our thoughts about building DKR. This also gives us content that can be sucked into the system when it is ready. Develop basic XML schemas for current docs. Find existing DTDs; Howard has found a Minutes DTD. Once we commit to a license, we will put any of our own created schema into Open Source under the group license.    (037)

Eugene recommended that everyone study XPointer, XLink, and XInclude. All of these are linked from Joe's glossary in WIKI. Lee recommended the following books: Neil Bradley, The XML Companion, 2nd Edition and Martin Fowler, UML Distilled, 2nd edition. John points out John Bosak would be a good person to ask questions about XML.    (038)

10) Requirements and Use Cases. Most of the group has done UML, some have done requirement ellicitation. Eugene said that the purpose of Use Cases is to describe from very high level black box point of view. Eric said, we should keep a good separation between design tangents and goals. Gil points out the different ways of doing Use Cases, particularly "Essential Use Cases" -- Constantine, Essential Modeling. What is the user's goal, design a different system with that in mind.. There are development methodologies such as Catellisis (sp?). Do mindmap and concept map of Mind map, i.e. concept map domain, get to shared understanding, share with users, then use case diagrams.    (039)

Eugene goes over one a Use Case, saying we should keep methodology and formalisms in the back of our mind rather than get bogged down by them. Eugene presented an XML DTD he created for Use Cases. Lee said that ArgoUML uses XMI, a DTD for UML that also supports Use Cases.    (040)

11) Gil demos Knoware. It is a collaborative concept mapping tool of server and client written in Java 1.1. He is currently working on a version that requires Java 1.2. Server is not open source right now, but there is a project underway to make it open source. Goal is to get shared meanings. Most other mind mapping/concept mapping tools are desktop tools and not real collaboration tools. Idea is that it is an informal modeling tool. There are two public spaces (Gil will send the URLs to the list), however these are not very structured. Putting Doug's docs that are on the Bootstrap site into this system will take Gil only a 1/2 hour. A cool tool, check it out.    (041)