[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-csc] Co-ordination of SCs... was: CSC call on 26 November
Hi, Yes, this makes sense to me, although to ensure that we don't tread into the area that Mark has noted to be a dangerous area for an executive group to tread, I think the issues list should more clearly state the coordination, communication, procedural or whatever (non-technical) issue that needs monitoring/addressing by CSC, rather than the whole subject itself. This will ensure that the scope of the CSC discussion doesn't stray into the purview of the other SCs, if you know what I mean. It would be helpful to have all 4 of the items listed here to be clarified in this way, so the discussion doesn't begin open-ended. The CSC needs help focusing as much as other SCs do (maybe even more so). So people that have the issues could pose them as specific actionable requests. For 'code lists' for example, I'm not exactly sure of the details, but I recall there being last week some question of division of responsibility between code list mechanism and code list fullfillment/population/identification. If that's the issue, then the item on the CSC agenda would be, rather than just 'code lists': + code list ownership (mechanism, population/identification) needs clarification Then for 'QA of deliverables' it could be: + need owner for 'review of schemas to ensure they conform to ndr rules' (It was Mark's assumpmtion that it was QA, but LC thought it was NDR, which is why we kept sending NDR notification of the schema deliveries asking them for review. Then they handed it off to their QA team, so within NDR it may have been their QA team, but within LCSC it was not the QA team since the LCSC QA team had all kinds of other things to review and validate and package. Now there's a disconnect. So that basic question still needs to be answered - whose responsibility is this one item? I think if we deal with this first then the next questions would probably be along the lines of how much do we have that needs QA'ing and how many QA teams or members do we need? But this may be the most contentious and the others may be able to be handled wihtin the SCs without CSC intervention once this one has been addressed.) So this way we do as much clarification/scoping as possible of the problem before sending to CSC so CSC doesn't end up expanding the scope of the issue. Can someone do the same for 'publishing of NDR rules' and 'schema generation'? -A Tim McGrath wrote: >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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]