Re: [ubl-csc] Re: CSC call on 26 November

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

> 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).

Oh dear, Thursday?  What happened to Wednesday?
There's a ttsc meeting Thursday at 8am.

(BTW, I'm beginning to really dislike 7am.   It used to be
a fairly decent time of day: tea, muffins, and what not ...
So please excuse any apparent grumpiness.  I (or you) will
get used to it!)

-A

jon.bosak@sun.com wrote:

>[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
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-csc/members/leave_workgroup.php.
>
>  
>