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

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

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