[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-csc] Re: CSC call on 26 November
Hi Mark, I agree that the CSC is not the correct place for technical coordination. It's hard to achieve technical coordination consistently, and I agree that having liaisons between SCs would help in this area. In the NDR case, however, there was a liaison. Oftentimes, though, the liaison had nothing to report because nothing had come out of the ndr team meetings - either the meetings were underattended, or what was taken back from lcsc to ndrsc for review didn't get addressed, so the issues kept getting pushed back. So, going back to the purpose of having CSC as a coordinating body, this is exactly what was needed at the time the liaison effort was not working for NDR. We needed a higher-level body to hear and help resolve the coordination issue, which was mainly a schedule/timing/response issue, allowing LCSC and NDRSC to resolve their technical issues through the mechanism they already had in place (or providing suggestions on other temporary mechanisms). Regarding the QA Teams, although they did highlight technical issues, those were sent back to the individual SCs for resolution. Also, I thought the QA teams were set mostly to handle final review and release delivery - wasn't the LCSC QA team originally a Packaging team? - but didn't function during the early part of the development period. Another difficulty of the QA teams is that they suffered exactly the same problem as the parent SCs. There was an NDR QA Team and an LCSC QA Team. The same issues related above applied to these two teams. With Lisa's help we attempted to make them into one team towards the end of .70, but the attendance was mainly still LCSC. If we expand the QA Team role I'm concerned this would create more of an overlap that would create more of a management/coordination headache. There does seem to be the need for an overall technical assessment team, though, which would be an obvious responsibility of a QA (single) team. Perhaps the mechanism for this can be an item for the CSC to consider in its new role? Going back to the NDR/LCSC coordination, what has happened is water under the bridge. What I'm grappling with now is 1.b) below, which, along with better communication from ALL SCs, not just NDR, I believe will prevent similar disconnects. The reason I support creating a CSC that has a coordination function is that for a little while, at least, I think we'll need both (clarification of responsibilities and coordination of tactical issues related to carrying our those responsibilities). This is very much for me not NDR-specific. There is some overlap that needs to be acknowldeged and coordinated, and other general coordination/communication that needs to occur, between ISC, CLSC, LSC, and TTSC (and, of course, LCSC and NDRSC) if we are to have a meaningful, complete, usable release by February (only 3 months!). Because there is some overlap in charter, there is a large potential for duplication, which equates to wasted effort and confusion, neither of which we can afford. Much of this is not technical, it's procedural - who does what and by when. Jon's master schedule coming out of London, and Tim's 1.0 Beta schedule, are good examples of coordination tools. LCSC has been shouldering much of the recent coordination burden, and it's certainly not required by their charter. We justly need a single overarching forum to resolvie issues - one that has the authority to 'impose solutions' when issues arise that are taking us off track, and the rigor of weekly touchpoints to ensure we are staying on track. Overall, I'm in agreement with most of your points. -Anne CRAWFORD, Mark wrote: >Sorry for the silence on this folks. > >1) Need for Coordination: > > I do agree with Tim that we need a coordination mechanism. I guess my assumption all along has been that the QA team - with membership consisting of both groups - would be that mechanism to ensure that the Schema from LC conformed with the NDR rules. That clearly did not work for a variety of reasons. I think one of the problems has been that the schema developer has not been part of NDR, and given the poor job I did in sharing the NDR decisions, he was left to implement as best he could. My concern is that any attempt to make CSC the coordination mechanism does not have the right people involved - at least for this particular issue. It would seem to me that in reality what is needed is a) better communication from NDR, b) an agreement on what are the responsibilities of each of the subcommittees (despite the charters I believe we have allowed a certain amount of overlap to be created and this has caused the disconnects we saw in San Francisco) and c) a more effective QA effort - with active technical participation from NDR sufficiently in advance of any final review/approval cycle so that discrepancies can be identified and corrected. > >2) Role of CSC: > >My understanding of the CSC has been that its purpose was to provide a place where the UBL leadership could discuss cross-cutting issues and reach resolution as well as function as a coordination mechanism for the overall UBL effort. I am not sure that given its membership that it would be the right forum to address coordination issues of a technical nature. > >3) Technical Coordination: > >I think that technical coordination is better left to direct, pro-active efforts on the part of the technical subcommittees. Our problem in the past has been that the subcommittees have not been proactive. I think that given the SF issues we uncovered, everyone realizes what is needed. My proposal would be for the individual subcommittees to formally designate a technical person to act as liaison. That person would be responsible for attending all of the other subcommittee teleconferences for the purpose of sharing decisions made in their parent subcommittee as well as identifying any issues related to decisions the liaised subcommittee is making. I think we may also want to formalize the QA process as an entity separate from the existing subcommittees. The model for this would be the technical assessment subcommittee in X12 and EDIFACT. > >4) Schema Generation > >We may also want to revisit who should be creating the schema. Since the schema is supposed to be a simple auto generation based on the NDR rules, perhaps we should make them the NDR responsibility? The model would be what we are doing in CEFACT where the library is created by TBG and the schema are created by ATG. > >Mark > > > > > >>-----Original Message----- >>From: Anne Hendry [mailto:anne.hendry@sun.com] >>Sent: Monday, December 01, 2003 2:15 AM >>To: Eduardo Gutentag; Jon.Bosak@sun.com >>Cc: ubl-csc@lists.oasis-open.org >>Subject: Re: [ubl-csc] Re: CSC call on 26 November >> >> >>Thanks, Jon, for taking up this issue. 7-9 Wednesday 4 Dec >>works for me. >>I think we'll see the benefit almost immediately from a focus >>in this SC >>on coordination and communidation. >> >>Speaking about the change in CSC charer, though, I'm a bit perplexed. >>My original belief that the CSC was the right place for coordination >>and communication, not for administration, came from two inputs. >>First, the fact that there is already an 'Adnimistration' sc. >>I assumed the ASC was the right place for administration. >>Second, although I looked for a charter for the CSC on the OASIS site, >>but didn't find one, I did go back to the first mail message >>you sent to the CSC list, which states: >> >> >> >>>Welcome to the ubl-csc mailing list. The CSC was created by the >>>UBL TC 2002.01.25 in the following resolution: >>> >>> That a Chairs SC shall be created to promote communication >>> between the UBL subcommittees; that its membership shall >>> consist of the chairs of each of the UBL subcommittees plus the >>> chair and vice chair of the UBL TC; and that its chair shall be >>> the vice chair of the UBL TC. >>> >>> >>> >>Which is exactly what we need! >>Did the CSC charter change from this January 2002 post? >>If the CSC has been for administration, then what was/is the ASC for? >> >>Thanks, >>Anne >> >>Eduardo Gutentag wrote: >> >> >> >>>7-9am Pacific on Dec 4 '03 is ok for me, unfortunately ;) >>> >>>Jon.Bosak@Sun.COM wrote: >>> >>> >>> >>>>| the first thing we should do is acknowledge that we have not yet >>>>| realigned the two groups - just bought time to do so. the >>>>| situation with the work on code lists is a case in point. >>>>| Obviously, this is a management issue - it has nothing to do with >>>>| who is right or wrong, good or bad technology, personal >>>> >>>> >>abilities, >> >> >>>>| willingness of participation, etc. It is better management that >>>>| is needed. >>>> >>>>I am in complete agreement with this. >>>> >>>>| In the past we have relied upon overlapping membership >>>> >>>> >>and nominal >> >> >>>>| liaison members to ensure we keep our work items aligned. I do >>>>| not think this has been successful. What is more, we now have 4 >>>>| new subcommittees to add into the equation. >>>> >>>>Yup. >>>>| It may be that for the next 3 months the chairs group has to >>>>| become more proactive in its co-ordination activities. for >>>>| example, seeking progress and activity reports and initiating >>>>| tasks when things are not happening. That is, perhaps we need a >>>>| project management team and the chairs SC would appear to be the >>>>| easiest way to do this. >>>> >>>>I can see two alternatives here. >>>> >>>> 1. I can become much more active in project managing this >>>> effort at the detail level. >>>> >>>> 2. We can turn the CSC into a project management committee. >>>> >>>>It's an open question whether I could successfully execute >>>>alternative 1 if I were free to do so. I like to believe that I >>>>could if I were able to focus on this, but the fact is that I've >>>>gotten pretty good at the role of spokesman and talking head, and >>>>I've already mapped out a schedule for the next six months based >>>>on the assumption that I will be spending 100 percent of my time >>>>promoting UBL, not project-managing it. For example, I'm already >>>>committed to a two-week promotional swing through Germany, Spain, >>>>and Portugal (based around an invited keynote in Munich) that will >>>>basically put me offline for most of January. So alternative 1 is >>>>moot, and that leaves us with some kind of collective solution as >>>>the best approach to solving this. >>>> >>>>I agree with Tim that the CSC is the obvious group to take this >>>>on. Add up all the SC chairs, co-chairs, and secretaries, and you >>>>basically have the people who are most deeply committed to this >>>>effort. I am comfortable with the idea that this group could act >>>>as a steering committee. The fact that Mark chairs the CSC >>>>actually fits pretty well with the thought that I will be out >>>>hustling UBL adoption while the rest of you focus on project >>>>integration heading into the final release in March. >>>> >>>>On the other hand, Eduardo is exactly right when he says: >>>> >>>>| We'd have to change both the goal and the attitude of CSC to >>>>| attain what you and Tim obviously think is needed, or we would >>>>| have to put some other mechanism in place. But whatever is done >>>>| would have to be done explicitly, not just having an existing >>>>| mechanism silently assume a different role. >>>> >>>>This means that there will have to be a formal decision to adopt a >>>>different role for the CSC. My hunch, however, is that no sizable >>>>proportion of voting members of the TC will disagree that we need >>>>better management, so I think the task here is simply to be clear >>>>about the new role and how it's going to work. Here are what >>>>appear to me to be the basic features of the new regime: >>>> >>>> - Weekly 1-2 hour meetings of the CSC. >>>> >>>> - Specific authorization to act in a coordinative role (in other >>>> words, authorization to resolve disputes from above and to >>>> impose solutions upon the subcommittees when necessary). >>>> >>>> - Specific authorization to appoint short-term ad hoc cross-SC >>>> teams to ferret out disconnects and work up proposals for their >>>> resolution. >>>> >>>> - Appointment of a couple of CSC members or observers as keepers >>>> of the issues and AI lists. >>>> >>>>This list is probably not complete, but I think that these are the >>>>basics. >>>> >>>>The first item (meeting regularly) is the one that we don't need >>>>additional authorization to implement, so I suggest that we start >>>>there and devote the first meeting to mapping out the new role for >>>>the CSC that we need to propose to the TC. We can start with the >>>>list above as points for further discussion and elaboration. >>>> >>>>The earliest slot that I can attend for a kickoff discussion is 7-9 >>>>a.m. California time Thursday 4 December. Since several of the >>>>CSC members will be in Philadelphia the following week, it's >>>>probably then or not until the week of 15 December. >>>> >>>>Jon >>>> >>>> >>>> >>>> >>>> >>>>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/l >> >> >eave_workgroup.php. > > >>> >>> > > > >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. > > >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]