Re: [ubl-csc] Re: Kavi meeting with the UBL chairs

[Anne Hendry <anne.hendry@sun.com>]

Jeffrey Lomas wrote:
> 
> Anne and Everyone,
> I've included my response inline.
> 
> Regards,
> Jeff
> 
> > 1.
> > http://www.oasis-open.org/apps/org/workgroup/ubl/ubl-lcsc/
> > click on the "QA Team Conference call".
> > Get "Resource not found".
> > This was recent email, so it was on my 'Group' member page
> > - it wasn't something I had to do a search on from the archives -
> > so I would have expected the link to work if it's showing up on
> > my member page under the 'recent email' list.
> 
> I have not have the same experience.  When I click on the link for ether
> conference call I get a page with call info on it.  I'll be keeping an eye
> out for this sort of behavior since it may suggest the presence of an
> intermittent problem.

Yes, I just tried this and it now works.

> > 2.
> > Click on 'Join' button at the bottom of
> > http://www.oasis-open.org/apps/org/workgroup/ubl/ubl-lcsc/members/upload.php
> > Takes you to the same 'Rerource not found" page.
> 
> Fixed.

Thanks!

> >> General
> >> -------
> >>
> >> 1.
> >> The problem begins with the fact that KAVI makes it difficult
> >> to disseminate the information on the daily activity of the
> >> TC to the general public.  We want our work to be open to
> >> the general public to view.  KAVI requires a password to
> >> view the contents of the group pages.  If we use those
> >> group pages as they were intended (as repositories for
> >> documents, calendar info, etc) then we make that information
> >> inaccessible to the public.  This is against the nature of
> >> the standards process. The standards process is an *open*
> >> process.  At least people certainly have been used to OASIS
> >> operating that way.  If we now require passwords in order
> >> for people to view the work of the TCs, that is a significant
> >> change in policy which I'm not sure will be very well received.
> >> I think this is the single most important problem with the current
> >> implementation.  Why do we need a password to get to TC information?
> >> Why is this information now restricted?  This is a serious
> >> collaboration inhibitor.  The driving factor appears to be
> >> revenue for OASIS, but this could backfire.
> 
> There are public views of TC information:
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
> 
> There are public views of SC information:
> http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-asc
> 
> Information submitted through the TC/SC member page is viewable from these
> pages assuming that the information is not marked as private.

Ah.  When you say 'marked as private', I assume you mean,
for instance, the check boxes listed when you submit a
document that say you can share this with x, y, z?
I think this, then, is a training issue - people are
still not sharing info.  It's discouraging that the
default setting is not to share.  I assume there is
a way to cusomize this, and I thought I saw a 'customize
this page' link somewhere in the interface, but I can't
find it anymore.  Can you point me to this?

When I look at the links you give above, it appears as though the
'default' list of available items is 'Membership', 'Mailing lists',
'Documents', 'Schedule'.  You say those URLs are public views
of the same info as the private pages, but I don't see that
this is the case for everything.  Is it possible to also make Action Items,
'Upcoming Events', etc also public?  It seems, actually, now that
I look at the public access area, the public access page for
documents is more useful than the private group access page
for same.

The issues that this raises are overall, though, is:
a) default is not to share, so every submission has to be
   manually changed.  Since the previous default was to
   share to all, why was this not the default in the new system?
b) the UI for submitting info (eg. docs) is very time consuming.
   it used to be that we could just send email - so much easier!
   Once the archives are working again we can still do this,
   but then we are bipassing the KAVi interface, which brings
   up the obvious question of it's usefullness, given the issues
   we're encountering.
c) the idea of submitting a document works in the cases where
   the document is long-lived, for instance, a mature version
   of a spec.  It is not so useful as an alternative means
   of communication in the situation where there is a lot of
   debate going on around the document, and the document is
   changing quickly, since it removes the document instance
   from the context of the surrounding debate.  However,
   this is how it is being used now since we don't have access
   to the archives.  The document submission would be redundant
   to the email archives.  It could be that some of these issues
   are the result of not having access to the archives, so perhaps
   when that is fixed it won't be as necessary to use this GUI.
d) I see that there is email capability in this system.  When
   using this email interface, is it transparent that the email
   is generated from KAVI?  How is it determined what tool it
   uses for email generation via that GUI?  What are the benefits
   to using the KAVI email capabilities?  It seems to me this
   just introduces a greater possibility of multiple threads,
   since people are used to using their own emailer for conversations.
   This creates a greater possibility of random threads that are
   then not integrated into the flow of a discussion ongoing
   through a different tool.  I realize this is a person's
   choice, but I'm just saying this makes it more likely to
   introduce discontinuity into a discussion.  Another training
   item.

> Karl is the policy guru, so I'll let him speak to the details of your policy
> concerns.  Suffice it to say I am not aware of any changes in OASIS' policy
> for maintaining accessibility to TC information.

Item (a) above is a change in policy - the default view/access
is not open as it was before.  Also, the entire notion of having
a 'member area' that requires a password is a change in policy
(at least as far as I'm aware).  If you set the default password
to be *no* password, then you would have implemented what we had
before.  As it is now, *requiring* a password is a change in policy.
I suppose we could just announce our username/passwords to the alias,
though, and that would put it back to the same access.  But that
begs my original question: why not have left it at the open access
we originally had?  Why make private areas and content at all?
This should be an open process, I thought.

> >> 2.
> >> The inability to place documents in a static area of the web
> >> site is essential for maintaining continuity of information,
> >> particularly if that information only changes infrequently
> >> (eg. UBL Events Calendar).  There are currently 2 problems,
> >> one which is mentioned above in terms of not having public
> >> access to all information on the web site, but even if that is
> >> solved, the current document areas only show the last couple
> >> of documents or just the day's email messages.  How do I
> >> easily get yesterday's or the day before or the week before
> >> to find a document that hasn't changed since it was posted?
> >> It seems I would need to go back out and use the public lists,
> >> if it was in an email, but if it was not in email, we don't have
> >> the ability to easily retrieve it, that I can see.  We need a web
> >> site area where we can place and periodically update information
> >> that is not appropriate to send in email and requires more
> >> continuity/availability than an email message or document
> >> that quickly scrolls out of site.  This is one of the features
> >> that was provided by the OASIS server disk space and ftp access,
> >> and is still needed.
>
> Better and more consistent management of a document's lifecycle is an issue
> we are well aware of.  The KAVI system has serious flaws in this regard.  We
> are working on finding the right solution to this problem.
>

That's great to hear, although, still, the management of a document's
lifecycle is sometimes best within the context of the discussions that
were taking place around it's versioning.  In the previous system
we had everything (document/discussion) in one place (the email lists)
unless we chose to post things to the TC/SC web pages.  I see that the
KAVI TC/SC pages are a way to organize what we would have previously
put on the TC/SC web pages via ftp.  So now I'm beginning to see the
Kavi interface from a different point of view.  Perhaps we should
view is simply as a replacement for ftp, and make sure that everything
we post is totally public.  This would get us back to the same place
we were before KAVI (if we don't use any of the other features in the
private pages that are not able to be public), with the exception of
not having direct access to the layout of the web page, nor a place
to store info on the server disk.
 
> >> 3.
> >> We require a 'work area' that is semi-invisible and can be
> >> organized and reorganized without too much concern, but
> >> provides the ability to store/share documents.  Kavi
> >> imposes structure, but the structure is too flat and
> >> also too time-sensitive to provide this feature.
> >> The OASIS server was being used as such a disk repository,
> >> with ftp access giving the ability for manipulation
> >> (although limited) of files.  We had a many levels of
> >> directories to organize the content.  We lack this in
> >> Kavi - to my knowledge there is no way to build a heirarchy
> >> of information within the Kavi structure.  It's unclear
> >> to me why the ftp and disk access is being removed, and
> >> there is no viable alternative provided.  Two examples
> >> of the use we had for ftp to the OASIS site are:
> >>   a) the lcsc 'working area' where we had many documents
> >>      in various forms of finalization that could be
> >>      accessed easily by the chairs and editors and
> >>      provided a backing store that could be easily
> >>      manipulated; they were all accessible at once
> >>      in one place.  We no longer have that in Kavi.
> >>   b) I was storing our comments on disk on the OASIS server.
> >>      This was working very well, and helped to keep things
> >>      organized.  What does Kavi offer to replace this?
> >>      How can I get that functionality back?  I am now
> >>      storing this info on my system at home.  This is
> >>      not a good idea (no backups!)  I would like disk
> >>      space again.
> 
> You can create TC/SC member only directories in the Kavi doc repository.
> You can even create sub directories as you wish (assuming you have those
> privileges).  While I would agree that the Kavi doc repository will not work
> for long-term doc storage and access. It should work fine for temporary
> storage and dissemination of drafts and such.

The member-only aspect is not the critical part (as you can see,
most of my comments reflect the belief that we've gone way overboard
in that area already).  The critical part is storage and access to
files on a server.  If you say we can create subdirs, then I withdraw
that comment in lieu of hearing from one of the chairs about their
experience with this functionality.  Would these areas then be
available to the public if we wished them to be?

Your comment on long-term storage bring up a question in my mind
as to what you consider to be short-term vs. long-term, and what
the OASIS responsibiity is for long-term storage of standards-related
information - as a historical artifact of the standardization process
(probably a discussion broader than this current discussion should
attempt to get into)?

> If you go to http://www.oasis-open.org/apps/org/workgroup/ubl/documents.php
> and click on "Add New Folder" you will be brought to a page that will lead
> you through the process of adding new folders and assigning their parent
> directory.
>
> You said, "to my knowledge there is no way to build a heirarchy of
> information within the Kavi structure."  My understanding was that OASIS
> provided training to the TC chairs.  Did you or someone else in your TC
> attend any of these training sessions?  There are also two other ways of
> getting help with using the Kavi Ap:

I don't see this link, so it may be that I don't have those privs,
in which case, I'll defer to the chairs.  Jon did state below that
he thinks quite a few of my comments in this section fall into his
court.  I didn't take the training - I may not have been in the TC then.
Training is definitely an issue - agreed.  However, that said, the
previous system didn't really require training, so that is a burden
on the user where it is unclear at this point that it is justified
by the benefits, but I'm assuming the benefits were also discussed
in the training, so I'll defer to those that did take the training.

Thanks for pointing out the ability to create the heirarchy, though.
I assume the depth is not restricted?  If this is the case, as it is
right now I have a whole slew of original comments email stored on
the OASIS server that I can't get to, so we've definitely lost access
to some important data in the process, which is a little disturbing.
We have a F2F coming up where that data would be very helpful.  If
I can create similar directories through this system, would it be
possible for you to package up thos dirs and send them to me so
I can re-enter (or, even better, can you just copy them (tar or
whatever) over to the KAVI area directly?  There are a lot of them
and re-creating them all through the GUI will take me hours, at best.

> 1.  Context-Based help:  Clicking on the "Help" button will bring up
> context-based help which may be the easiest way to finding the right answer
> in some circumstances.
> 
> 2.  Contacting webmaster@oasis-open.org:  Sending mail to
> webmaster@oasis-open.org gets you directly in touch with first tier tech
> support.
>
Yes, I've tried 'Help', and it's good for some questions, although
a lot to read through.  Not so good for other of these questions,
obviously.  I assumed webmaster was for web page related issues,
not so much for the app issues, but if you want us to send those
to webmaster, we can certainly do that.

> >> 4.
> >> Kavi places all email/docs/rep lists/etc from all subsc's
> >> in one list.  This is not practical - I need to be able to
> >> sort the mail and other info by SC and SubSC.  I just looked
> >> at the 'customization' page.  This is too much overhead.
> >> It was just fine to go to the mail list link and look at
> >> things 'by date' or  'by thread', or whatever, and be able
> >> to do a search otherwise.  Where are those features?
> 
> Can I assume that you are talking about the "My Groups" page? The short
> answer is the features you are looking for do not exist.  But I will add
> this item to the list of existing feature requests for the "My Groups" page.

Yes, sorry.  They are all intermingled.  Makes it hard to pick out
and follow any one thread.  Also, then, if you belong to several
TC/SCs, then the 10 that are listed may not even contain some of
the ones for an individual sc, since they may all add up to more
than 10.  So the usefulness of this is what I'm questioning.
Perhaps some other way to indicate there are new messages from
an individual tc (on the groups page).  Also, in general, having
to hit '10 more' over and over to get more is very slow and also
of questionable use.  The problem here, though, is that we don't
have access to the archives, otherwise we would not need to use
this.  So when the archives are accessible again, I think some
of these issues will become irrelevant.

> >> 5.
> >> I noticed that our minutes html document has a broken gif.
> >> How do we place html files in Kavi so that all their
> >> images, etc go along with them?
>
> Good question.  There isn't an easy way to drop html doc into the repository
> in such a way that they reference images in the repository.  Can you give me
> some example of images that you use in documents?
>
The OASIS Logo! :)

However, that wouldn't be the only one.  We have in the past
converted word or staroffice files, tables, etc, to html for
posting, for easier access.  This could at times contain gifs
or jpegs.  As a matter of fact, there is a comment that has
graphics and one of the versions is in html.

Being able to store web pages I think is an important feature.
I wouldn't want to limit that to text-only web pages.
I think this is a general drawback of using a database-based
system rather than a file system -based system.  It's not
KAVI, but the fact that KAVI has a database back-end, I assume.

> >> 6.
> >> There seems to be information missing.  For instance,
> >> the membership list of the ebXML IIC contains only 2 people.
> >> Perhaps this is because only two of the people on the
> >> alias have formal OASIS membership.  However, if that
> >> is the reason there are only two people listed, this
> >> is a brutal way to transition people who are volunteering
> >> their time on these efforts.
> 
> TC rosters are managed by TC Chairs.  You will have to consult with Jacques
> Durand or Jeffery Eck with regard to ebxml-iic roster issues.
> 
> >> 7.
> >> People are still not getting email.  Please check to
> >> see if robert.shanbaum@gerbercoburn.com is on the UBL TC
> >> and UBL LSC lists, and if not,let me know what needs to be
> >> done to add him.  It's not reasonable to take the membership
> >> of such a large organization and expect everyone to drop
> >> what they are doing to fix these problems.  This should
> >> have been scoped out before-hand and all requirements
> >> communicated.  The original email aliases were available
> >> and could have been mapped against the OASIS membership
> >> list *before* the rollout. Then a staged roll-out would
> >> have been appropriate so people (chairs) could have been
> >> walked through the changes.  It's still not too late to do this,
> >> since there are still many changes to be made to the system,
> >> and still email list discrepancies.  This should be done in
> >> one operation now for all the tcs.  [I suspect that this issue
> >> belongs to me almost entirely -- Jon]
> 
> I do not see him on the roster.  Assuming that he is a member of OASIS, he
> will need to join this TC.  Until he has done this, there isn't much for Jon
> to do.

I'm not sure which roster you're saying he is not on: the OASIS roster
(I assume there is such a thing) or the UBL TC roster?  If you can tell
me if he is a member of OASIS, and he is, then we can fix the problem
without bothering him again.  Otherwise, I'll ask him to join.

> >> 8.
> >> Search is not scoped in a way as to be useful.  I can search
> >> all groups or one group, but not the groups I belong to.
> >> Some of the things on my home page relate to my groups
> >> (documents, mail, etc) and some relate to all of OASIS
> >> (company members, search, etc).  I don't see any capability
> >> to search for individual items (documents, etc). or to
> >> limit the scope to a set of dates.  Perhaps I don't see
> >> this and it's there somewhere.
> 
> noted
> 
> >> 9.
> >> Communication of the benefits would be helpful here.
> >> I don't recall seeing any notification on the OASIS
> >> site that there would be a transition and for the
> >> general public, who may have come to visit over the
> >> past month, to understand what is happening and why.
> >> There's nothing there now to ease the uncertainty
> >> of people who are going to the site and finding
> >> everything changed and a lot broken.
> 
> I think there have been announcements to both the chairs list and the
> members list.

I think the broken-ness, combined with the ramp-up,
is overwhelming the perceived benefits.
 
> >> 10.
> >> The one feature I've found slightly useful is the calendar,
> >> but I think I could get a calendar for less headache.
> 
> 
> >> Specific link problems
> >> ----------------------
> >>
> >> 1.
> >> If I follow a link to http://oasis-open.org/committees/ubl/lsc/,
> >> then click on a link from that page to another (old-style) link
> >> within OASIS (eg. http://oasis-open.org/committees/ubl/) I am
> >> redirected to
> >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
> >> and can no longer use the 'Back' button to get to the page(s)
> >> I came from ('Back' simply puts me in a continuous a redirect
> >> 'loop' over and over back to
> >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl.
> 
> There was a need to maintain link persistence between the old site and the
> new.  The only way to do that was to create redirects.
> 
> >> 2.
> >> I have a lot of bookmarks (and I'm sure I'm not the only one)
> >> to the tc pages.  These are some where I get errors:
> >>
> >> a.
> >>    http://oasis-open.org/committees/archives/ubl-lcsc/
> >>    http://oasis-open.org/committees/ubl/msc/200204/ Not Found
> This is an apache config issue I am trying to work around.

How's it going?  What other instances/situation might the issue apply to?

I think this brings up something I may have commented on later.
At this point, given the time that these issues have been outstanding,
and the unavailability of information that has been present, both
to the TC members and the general public, I'd like to request:

a) a notice be put in a prominent area on the OASIS top level page
   stating that OASIS is undergoing a change in tools which may cause
   the inability to access some information (some examples may be
   helpful), but that you are working on the issues and ask people
   to be patient and reassure them that the system will at some
   point in the future be back in order.

b) regular updates to the membership on the status of the conversion
   (this may be going out to the chairs, but there's no reason to
   put them in the middle of this, is there?)  Everyone deserves
   this information and the chairs should not need ot be stuck
   in the middle with an additional workload like this.
   (This is just my view.)
 
> >>    http://oasis-open.org/committees/ubl/lsc/200204/industry.pdf Blank page
> This doc comes up for me

OK, me too now.

> >>
> >> b.
> >>    From a January email to lcsc from Tim:
> >>    http://lists.oasis-open.org/archives/ubl-lcsc/200301/msg00010.html
> >>    gets you to http://lists.oasis-open.org/css/top.css and 'Not Found'.
> >>    and then if I hit the 'Back' button after that I get 'Network Error:
> >>    connection refused', and can't go back.
> 
> That doesn't happen for me.  I get an email from Tim McGrath with the
> subject "Re: [ubl-lcsc] [QA Team] Feedback on Methodology Paper"

OK, this works for me too now.  This brings me to a comment
I made somewhere along the line here that I think the system degrades
either over time, or when it is triggered by some action.  I think
this warrants further investigation.

> >> c.
> >>    From http://lists.oasis-open.org/archives/ubl-lcsc/ click on the
> >>    200301 (January 2003) 'by date' link.  You get the same problem
> >>    as above:
> >>    gets you to http://lists.oasis-open.org/css/top.css and 'Not Found'.
> >>    and then if I hit the 'Back' button after that I get 'Network Error:
> >>    connection refused', and can't go back.
> I get the ubl-lsc archive listing.  Not the problem you describe.

Yes, works for me too now.

> >> d.
> >>    After this, no matter what link I click on that lists page I
> >>    get the same error.  I think it kills the server.  As a matter
> >>    of fact, at this point, if I go all the way back up to
> >>    http://lists.oasis-open.org/ and choose *any* of the tc lists,
> >>    then try to view any of the list by clicking on any of the 'by *'
> >>    links, I get the same error.  I do think if the server is not dead
> >>    now at least it is not answering requests.  Kavi appears brittle.
> 
> Hmm....

Same with above (ok now).  I do believe this is a sporadic issue.
Because there have been several times when I've tried one link
and many fail.  I know I'm not the only one either.  I did include
some email later in this series from a non-ubl participant having
trouble with the archvies, and another I saw this morning (although
that was from March 24th, so perhaps that is an issue that is fixed).

> >> So I've spent just a little over an hour now and have found these
> >> problems.  I only had to go through 10 of my old email messages to
> >> get this many issues.  I believe it should be up to OASIS to test
> >> this software and do a proper staging before rolling it out into
> >> a production system.  I wonder if any requirements-gathering was
> >> done, because the issue of public access to the TC work seems
> >> fundamental, and not to have been considered in the choice of
> >> how to roll out this software.  I think it's possible the
> >> software may be able to be configured to provide global
> >> access, but I haven't heard of this being tried out.
> >>
> >> It certainly needs more off-line testing.
> 
> I agree that there are still bugs to work out.  Some of them we hadn't
> noticed until we loaded the system with all of our TC's data and got folks
> using the system.  It would have been nice to get more input from chairs
> during pre-launch, but most didn't communicate any information with us until
> we went live.
>
Usually in rolling out new systems there is a mirror site where
everything is loaded and there is a pseudo cut-over.  This is
a big system.  I think it warrants that type of gradual roll-out
(could have cornered one TC into volunteering as a guinea pig,
tested it out that way with all their data before rolling out to all tcs) ...

> >> 2.
> >> Going through the private web pages, doing 'view all' on email for the lcsc,
> >> clicking on 'month' for 200303, gets:
> >> http://www.oasis-open.org/archives/ubl-lcsc/ubl-lcsc.200303.gz,
> >> and a 'not found'.  Are the archives supposed to be gzipped??
> 
> Yes, they are.  I am in the process of bringing this feature offline as one
> of many measure to block email addresses from being harvested by spammers
> (another topic altogether that we're not going to get into here).

Oh, dear.  Glad you're on top of that one!

Thanks for answering these questions/conerns.

-Anne