RE: [ubl-csc] Co-ordination of SCs... was: CSC call on 26 November

["Sue Probert" <sue.probert@dial.pipex.com>]

Sounds a very good idea to me.

Sue

-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: 01 December 2003 22:22
To: anne.hendry@sun.com
Cc: CRAWFORD, Mark; ubl-csc@lists.oasis-open.org
Subject: [ubl-csc] Co-ordination of SCs... was: CSC call on 26 November


Quoting Anne Hendry <anne.hendry@sun.com>:

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

i propose we set up these (and others that will inevitably arise) as action
items for CSC and then make sure we get a status report on each call.

Can we make a decision on this on Dec 4th?

>
> CRAWFORD, Mark wrote:
>
> >Rather interesting as NDR was constantly making decisions on rules.
Clearly
> there was a disconnect if those rules were not being conveyed. As for
issues
> coming back from LCSC, I really don't recall many - other than containers.
>
> >
> >
> Those may have been the meetings you weren't able to attend.  There was
> the need to clarify the rules, and there were issues that required
> specifc NDR members' responses when they were busy with other priorites,
> although some of this is inevitable where you have only a single expert
> in one area.  So we shouldn't dwell on those things past.
>
> >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.
> >
> >
> Yes!
>
> >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.
From
> your current post I think my inference was incorrect.
> >
> Yes, from my perspective I see the CSC in a non-technical, coordination
> role (see my original response to Tim's posting).
>
> >I am still concerned that there is a disconnect between what is coming
out
> of NDR and what is being realized in LC.
> >
> That may be the case, but if it's technical, I see the CSC as only
> responsible for the coordination of communication on the disconnect (if
> communication is an issue), not as the provider of the solution to the
> technical problem/disconnect.  I guess I don't really know what you
> consider the disconnect to be.  So without going into it further here,
> I'd suggest you and Tim get together and clarifiy the aspects of this
> disconnect/problem from each of your viewpoints, separating the
> technical from the procedura/coordination.communication issues.  Then I
> can see the CSC suggesting steps to fix the procedural aspects you find,
> if there are any.  You're on your own for the technical side! ;)  Not
> really, but then if you have a body that can handle the procedural
> aspects, that frees you up to focus on the technical aspects between the
> two teams.  Maybe a couple of joint meetings will do?  But the people
> have to be there.  How to get quorum so issues aren't constantly
revisited?
> Maybe the CSC can help there too (load balancing).
>
> >I think what we need to do is have a better definition of what exactly
would
> be entailed by the coordination function.
> >
> >
> Yes.
>
> >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.  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.
>
> >Ah, but there is the rub. 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.
> >
> Ah, here you're assuming the 'imposed solutions' (this phrase btw came
> from Jon's email) would be technical.  Not so in my mind.  For me this
> would refer to communication/procedural solutions, such as agreeing on
> priorities, or helping identify the root of the disconnect/problem.  The
> one 'imposing' solution I can see is deadlines.  Monitoring that the
> required deliverable will indeed be delivered on time.  But this is a
> simple matter of setting milestones and 'imposing' adherence to them so
> that interim deliverables allow everyone to keep moving.
>
> >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 understand your concern here.  Yes, we have to avoid that.
>
> Now, having said all that, it is the case that this solution assumes the
> SCs can come to some agreement on technical issues.  As I said, we're
> all intelligent, capable people, so to me it's a given that our
> decisions are based on their value to the overall UBL TC and it's goals,
> and that the primary goal from my viewpoint is to release a
> specification that is as complete and usable as possible within the
> given timeframe we have to execute it.  [ Perhaps others have different
> goals?  If so, the alignment of this would be also a CSC matter. ]  So,
> as such, if there's a concern of the ramification to the overall product
> of a technical question and a solution has not been reached in a timely
> fashion after all procedural CSC recommendations have been applied, I do
> see the CSC as playing the role of final arbiter.  But the SCs have
> total control over this.  They can come to agreement far before the CSC
> is engaged.  Also, this is no different than what we have currently.  I
> think Jon has the current role of intervening in never-ending circular
> technical debates.  Now we're just broadening the forum for, in those
> hopefully very, very, seldom cases where the SCs cannot reach agreement
> on something that is at the heart a technical debate.  So broadening
> that final arbiter role to me is a positive thing.  As stated, though,
> hopefully the SCs will realize the value of coming to agreement far
> before anything reaches this state.  :)
>
> -A
>
>
> 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.
>




-----------------------------------------------------------------
Sent through Reynolds Technology IMP http://www.reynolds.net.au/
Configurable spam and virus free email. Anywhere, anytime.


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.