Re: CSC call on 26 November

[jon.bosak@sun.com]

[Anne:]

| Speaking about the change in CSC charer, though, I'm a bit
| perplexed.  My original belief that the CSC was the right place
| for coordination and communication, not for administration, came
| from two inputs.

That's right -- it's for coordination and communication, not for
administration.  So if we want to use it as a decision-making body
(i.e., one that can enforce its decisions), we will have to go
back to the TC for authorization to do that.  Quite rightly, too.

[Mark:]

| My concern is that any attempt to make CSC the coordination
| mechanism does not have the right people involved - at least for
| this particular issue.

Hence my suggestion that we hand off specific issues to specific
small volunteer teams for predigestion.  But I agree that this is
a critical weakness of the steering committee approach.

| It would seem to me that in reality what is needed is a) better
| communication from NDR, b) an agreement on what are the
| responsibilities of each of the subcommittees (despite the
| charters I believe we have allowed a certain amount of overlap to
| be created and this has caused the disconnects we saw in San
| Francisco) and c) a more effective QA effort - with active
| technical participation from NDR sufficiently in advance of any
| final review/approval cycle so that discrepancies can be
| identified and corrected.

I don't think it's possible any more to say that NDRSC is strictly
responsible for the design rules and that LCSC is strictly
responsible for the content.  This was OK in the beginning,
because each SC knew so little about the area of responsibility of
the other that everyone was pretty much content to let the experts
in the other area make decisions in that area.  But people know
too much now to be happy with that; the LC people have opinions
about the way the design rules play out, and the NDR people have
opinions about the way the data is being modeled.  We've reached
the stage where a lot of these decisions ideally ought to be going
to the TC as a whole so that everyone buys into them.  (This is
the reality of what we've been calling "joint SC meetings.")

| I think that technical coordination is better left to direct,
| pro-active efforts on the part of the technical subcommittees.
| Our problem in the past has been that the subcommittees have not
| been proactive.  I think that given the SF issues we uncovered,
| everyone realizes what is needed.  My proposal would be for the
| individual subcommittees to formally designate a technical person
| to act as liaison.  That person would be responsible for attending
| all of the other subcommittee teleconferences for the purpose of
| sharing decisions made in their parent subcommittee as well as
| identifying any issues related to decisions the liaised
| subcommittee is making.  I think we may also want to formalize the
| QA process as an entity separate from the existing subcommittees.
| The model for this would be the technical assessment subcommittee
| in X12 and EDIFACT.

I believe that Anne's reply (which I won't quote here) nicely sums
up the drawbacks to this approach.  I am very well aware of the
essential and indeed heroic role that the ebXML QA team played in
seeing that project to a successful conclusion, but its efforts
were born of desperation and do not in my opinion represent a
model for how this kind of work should be conducted.  And I'm not
impressed by what little I've seen of the technical assessment SCs
in X12 and EDIFACT (though admittedly I don't have a lot of
experience on which to base this).

| Ah, I see what you are talking about now.  Not a body to resolve
| the technical issues, rather a body to identify that the
| coordination of the technical issues was not being properly
| addressed.

I sense that we are coming to an agreement on this as a minimum.

| I really believe there is a need for the QA team, and agree that
| CSC is the proper place to discuss the relative merits of it.  I
| was inferring from previous posts that folks were proposing the
| CSC resolve differences.

That *is* what I was proposing.  I still think that it's one of
the workable solutions, though it's apparent that none of us like
it.

| I fully support increased coordination of schedules and the like
| but I would be very hesitant to give CSC the "authority to 'impose
| solutions'" related to technical issues. For example, in the
| disconnect between LC and NDR over the beta schema, that would
| mean that CSC would have to choose between the natural product of
| NDR (the design rules), or the solution implemented by LCSC (one
| persons preference for schema design).  Such autocracy is exactly
| the model that is broken in CEFACT - Autocratic decisions by the
| executive based on personal preferences rather than on the
| technical work of the subordinate groups.

I agree that we don't want this.  The problem we've got is that
each *SC* sees the other SC as autocratic because the members of
each SC know too much not to have an opinion about the conclusions
of the other but don't participate enough (due to time
limitations) to completely understand their reasoning and buy into
it.  In my view, this is the core of the problem, and like most of
our problems, it's just another consequence of resource
constraints.

[Anne, in a later reply to Mark:]

| >But it is the technical disconnect that has caused the real issue
| >here.
| 
| Not sure I agree here.  If NDR and LC were one team (which is a
| procedural issue) I think the technical issues would have been
| resolved earlier.

Exactly.

| Even if they had begun separately bug merged
| part-way, I still think the same.  That's a drastic thought, but
| it's mainly a matter from my viewpoint of there not being enough
| time to have proper communication around the issues.  It could
| also have been resolved if enough members of each team had enough
| time to attend both meetings, or some other communication
| mechanism had been enforced.  I'm not discounting that there are
| tehcnical issues.  Just noting that, given we are all intelligent,
| capable people, I thnk they could be resolved with the application
| of some communication-enhancing procedures and decision
| guidelines.

I think this very accurately sums up the problem, but I can't buy
"better communication" as the entire solution.  We do indeed have
"intelligent, capable people" -- the problem is that they're too
darned intelligent and capable (and opinionated) to be satisfied
with letting other people make basic decisions without them.

[Tim:]

| from what i am hearing on this thread i think we are near
| agreement along the lines of:
| 
| * CSC has the role (already) of ensuring co-ordination across SCs
|   - no change of charter is required
| * CSC does not have the right (or skills) to impose any solutions
|   - just to facilitate them being achieved.
| * We have not been doing this very well
| * You cannot step into the same river twice (but you can try)

I agree with all of the above.

| * There are some issues currently on the table that we should be
|   aware of and monitoring.  the ones noted in this thread so far
|   have been:
| 
|  - code lists
|  - schema generation
|  - publishing of NDR rules
|  - QA of deliverables

To which I would add:

 - Final CCTS alignment

 - Formal contribution of our semantics to TBG17 (we're already
   late with this compared to some other groups)

 - Detailed consideration of RosettaNet NDR input (yes, I heard
   that this got some discussion today while I was out preaching
   UBL to Adobe, but we have a liaison issue here as well)

 - Maintenance of thoroughly detailed diffs between beta and FCS
   as input to the localization SCs and beta implementors (without
   this, the localization SCs will run completely off the rails)

Here are my conclusions at this point in the dialogue.

 - Turning the CSC into a steering committee can probably be made
   to work, but we all hate the idea.

 - Better communication will certainly help, but I'm not convinced
   it's enough.

 - CSC issue tracking and weekly meetings should help enormously,
   and I'm willing to see whether this is sufficient to solve the
   problem if people want to give it a shot before trying
   alternatives.  But we will have to be really clear on who's
   signed up to do what.

 - If issue tracking and better communication don't solve the
   problem, then in my opinion the best thing to do is to combine
   NDR and LC for the last leg of the journey to 1.0 FCS by
   holding joint concalls between now and the meeting in
   Washington.  We've demonstrated the efficacy of this approach
   quite a few times now, both in person and on the phone, and it
   appears to me to be the simplest solution known to work.

Let's continue this discussion in the call Thursday (7-9
a.m. California time, the usual UBL bridge, whoever gets there
first starts the call).

Jon