OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-csc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]