[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]