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

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

Hmmm, ok, I recall now.  Sorry - my calendar meetings all reached
their end periods at the end of November, so my calendar for Dec.
looked quite empty!

I have to qualify my 'aye' then, because I can do 7-8 but not 7-9
(and neither can anyone else because ttsc has a meeting from 8-10)
unless we use a different #.  Very sorry about that.  We are beginning
to need either a master calendar or an additional  number anyway.
This was somethign I was going to raise to the regular old CSC.
Don't know where this falls with the 'new and iimproved' CSC.

-A

Q: Do we still have the usual CSC call on Wednesday as well,

Eduardo Gutentag wrote:

> Anne, the meeting to talk about this was always set for Thu 7-9,
> no change there.
>
> Anne Hendry wrote:
>
>>> 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. 
>>>
>>>
>>>  
>>>
>>
>>
>>
>> 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. 
>>
>>
>