Re: [docbook-tc] Draft Kavi message

[Michael Smith <smith@xml-doc.org>]

A couple of comments:

* Need for process review

  I'm wondering whether it'd be appropriate to suggest that OASIS review
  the process they went through for making the decision to deploy the
  Kavi system to begin with.

  What I mean is, if, instead of deploying it site-wide the way they did,
  they had instead done some kind of limited trial with it, it seems like
  all of these issues would have been exposed, and they would have then
  needed to fix them before going ahead with deploying it site-wide (or
  maybe not gone ahead with it all -- some of these issues seem like
  fundamental shortcomings in the Kavi design that aren't easily fixed).

  Perhaps they did actually do some kind of trial. But if they did, I
  don't think it could have been very thorough -- because if it had
  been, it sure seems like these issues would have been noticed.

* E-mail problems

  Although the problems with the e-mail system aren't directly related
  to Kavi, but I think the root cause is related.

  What I mean is, they made some kind of change to the mailing-list
  system that has broken its handling of MIME-encoded messages. As far
  as I can see, they made that change without ever giving anyone any
  kind of heads-up about it.

  The fact that they broke it to begin with makes me seriously question
  the competence of whomever it is that's managing the mailing-list
  system. And the fact that it has remained broken weeks after it was
  brought to their attention makes it seem that they have a problem with
  lack of accountability, and brings into question just how seriously
  they're committed to responding to the needs of their users.

Ideally, I think they should have some formal, documented processes in
place for making sure that decisions about the Web site and mailing-
list system don't get approved unless they've made an effort to give every
TC an opportunity to review and comment (or maybe even vote) on them.

  --Mike

Norman Walsh <ndw@nwalsh.com> writes:

> At the last meeting, I took an action to draft our committee response
> to OASIS about the state of Kavi. Here it is. (Bob, please make sure
> we have an item on the agenda for discussing this.)
> 
> The DocBook Technical Committee would like to express its continued
> frustration with the document management part of the Kavi system
> implemented at OASIS. We find the system to be technically inadequate
> at best and flatly broken at worst. Beyond the technical issues, we
> are concerned that it is an awkward, difficult to use system and
> consequently we fear that it may be driving users away from OASIS.
> This is not only bad for our committee, it is bad for the consortium
> as a whole.
> 
> It is our unanimous opinion that the Kavi system as currently
> implemented has critical flaws, and that it is imperative that they be
> corrected. We are aware that some of these issues have been brought to
> your attention before by individuals, but we would like to reiterate
> them here as part of our committee position.
> 
> We draw your attention to the following technical issues.
> 
> 1. The document repository is simply broken. Although chairs and
>    secretaries can organize documents into a hierarchy, this hierarchy
>    is not exposed to the general public. This frustrates any attempt
>    that the committee might make to organize the documents for the
>    public.
> 
> 2. The Kavi system forces documents to have automatically generated
>    URIs that are meaningless and difficult to remember. Even if we
>    were able to accept the URIs generated, it is impossible to predict
>    the URI that will be assigned to a document when it is placed in
>    the repository. This makes it impossible for the committee to
>    decide offline, for example at a face-to-face meeting, where and
>    how documents will be published.
> 
> 3. Another consequence of the fact that URIs are generated by the
>    system rather than assigned by the committee with responsibility
>    for the material is that it is impossible to publish specifications
>    that contain internal cross references. An HTML version of a
>    specification, for example, cannot contain a link to the PDF
>    version.
> 
> 4. This also makes it impossible to publish a web of documents. A
>    large document could not be broken into chapters, for example, with
>    navigational links between the chapters.
> 
> 5. It follows further that the DocBook Committee *cannot* publish the
>    DocBook DTD on the OASIS site. DocBook is a modular DTD and the
>    URIs of the modules must be predictable. In fact, as a general
>    rule, it would seem that no Technical Committee can publish any
>    schema, stylesheet, or other work product of any reasonable
>    complexity on the OASIS site other than as a zip package or
>    something similar for the user to download and install locally.
> 
> 6. The OASIS email system is unable to deal with properly formatted
>    MIME messages. It simply discards their contents and forwards a blank
>    message to the list. This is causing considerable frustration and wasted
>    effort. We observe also that several individuals have approached the
>    committee to express frustration with the mailing list software.
>    This situation is inhibiting communications within OASIS TCs thereby
>    slowing down work by its members.
> 
> 7. The design of the OASIS web server is insufficient for the needs of
>    the DocBook Technical Committee. Before the migration to Kavi, the
>    DocBook TC maintained an area of web space on the server containing
>    almost 4,000 individual pages. No member of the public can be
>    expected to navigate a web space of that size without some
>    navigation system for the pages that are in the space, but the Kavi
>    design offers no mechanism for such an information architecture.
> 
> 8. It is also simply impractical to maintain a system of that size
>    through a system that uses web forms as its user interface
>    paradigm.
> 
> In addition to solving these technical issues, we feel that OASIS
> should give serious consideration to the overall design of the site.
> 
> We are concerned that the current design frustrates users ability to
> quickly and conveniently find the information that they need. (Try,
> for example, to find XML Catalogs Committee Specification or the
> minutes of the second UBL meeting)
> 
> This frustration, we fear, will make them less likely to return to the
> OASIS site thereby deprecating the organizations important role in the
> industry. Several TC members have already noticed this effect on
> themselves or others in their organizations.
> 
> We recognize that technical committees have many different needs. Kavi
> provides facilities for electronic balloting, membership maintenance,
> and meeting scheduling that are valuable. But it is demonstrably
> inadequate in some very key ways: in the presentation of committee
> work products, in the publication of schemas and other ancillary
> materials, in the design and organization of technical committee web
> sites, and in its inability to provide reasonable looking public URIs.
> 
> We close with the simple observation that these issues, both the
> technical and non-technical, are driving committees to establish
> entirely independent web sites in order to better serve their user
> communities. It would seem clear that OASIS must re-prioritize some
> staff duties and ensure that immediate, dramatic action is taken if it
> wishes to reverse this trend.
> 
> Signed,
> 
> The DocBook Technical Committee
> 
> <list of committee members>
> 
>                                         Be seeing you,
>                                           norm