[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-csc] Re: CSC call on 26 November
before we get too excited about this, i just read the LCSC miniutes and nothing about RosettaNet NDR there. it does appear in the LSC minutes (quite rightly as the RosettaNet liaison was asking). perhaps you are right after all eduardo, if we had fewer separate meetings we wouldn't get confused by the acronyms for the minutes! Eduardo Gutentag wrote: > So the LCSC had a meeting today at which the RosettaNet *NDR* > input was considered? Well, it would seem to me that this is > precisely why the only solution that has any chance of doing > anything good for all of us is the simplest and the one mentioned > at the very end of the message, viz. joint meetings throughout. > It'll be problematic to coordinate, but just making sure that > those are the only meetings (that is, eliminating the NDR meetings, > and eliminating the LCSC meetings, and having only TC meetings) > will go a long way. > > Of course we'll have to talk about this, but the more I think > about it the more convinced I become that any other solution is > just a hack... > > Jon.Bosak@Sun.COM wrote: > >> [Anne:] >> >> | 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. >> >> That's right -- it's for coordination and communication, not for >> administration. So if we want to use it as a decision-making body >> (i.e., one that can enforce its decisions), we will have to go >> back to the TC for authorization to do that. Quite rightly, too. >> >> [Mark:] >> >> | 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. >> >> Hence my suggestion that we hand off specific issues to specific >> small volunteer teams for predigestion. But I agree that this is >> a critical weakness of the steering committee approach. >> >> | 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. >> >> I don't think it's possible any more to say that NDRSC is strictly >> responsible for the design rules and that LCSC is strictly >> responsible for the content. This was OK in the beginning, >> because each SC knew so little about the area of responsibility of >> the other that everyone was pretty much content to let the experts >> in the other area make decisions in that area. But people know >> too much now to be happy with that; the LC people have opinions >> about the way the design rules play out, and the NDR people have >> opinions about the way the data is being modeled. We've reached >> the stage where a lot of these decisions ideally ought to be going >> to the TC as a whole so that everyone buys into them. (This is >> the reality of what we've been calling "joint SC meetings.") >> >> | 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. >> >> I believe that Anne's reply (which I won't quote here) nicely sums >> up the drawbacks to this approach. I am very well aware of the >> essential and indeed heroic role that the ebXML QA team played in >> seeing that project to a successful conclusion, but its efforts >> were born of desperation and do not in my opinion represent a >> model for how this kind of work should be conducted. And I'm not >> impressed by what little I've seen of the technical assessment SCs >> in X12 and EDIFACT (though admittedly I don't have a lot of >> experience on which to base this). >> >> | 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. >> >> I sense that we are coming to an agreement on this as a minimum. >> >> | 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. >> >> That *is* what I was proposing. I still think that it's one of >> the workable solutions, though it's apparent that none of us like >> it. >> >> | 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. 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 agree that we don't want this. The problem we've got is that >> each *SC* sees the other SC as autocratic because the members of >> each SC know too much not to have an opinion about the conclusions >> of the other but don't participate enough (due to time >> limitations) to completely understand their reasoning and buy into >> it. In my view, this is the core of the problem, and like most of >> our problems, it's just another consequence of resource >> constraints. >> >> [Anne, in a later reply to Mark:] >> >> | >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. >> >> Exactly. >> >> | 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. >> >> I think this very accurately sums up the problem, but I can't buy >> "better communication" as the entire solution. We do indeed have >> "intelligent, capable people" -- the problem is that they're too >> darned intelligent and capable (and opinionated) to be satisfied >> with letting other people make basic decisions without them. >> >> [Tim:] >> >> | 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) >> >> I agree with all of the above. >> >> | * 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 >> >> To which I would add: >> >> - Final CCTS alignment >> >> - Formal contribution of our semantics to TBG17 (we're already >> late with this compared to some other groups) >> >> - Detailed consideration of RosettaNet NDR input (yes, I heard >> that this got some discussion today while I was out preaching >> UBL to Adobe, but we have a liaison issue here as well) >> >> - Maintenance of thoroughly detailed diffs between beta and FCS >> as input to the localization SCs and beta implementors (without >> this, the localization SCs will run completely off the rails) >> >> Here are my conclusions at this point in the dialogue. >> >> - Turning the CSC into a steering committee can probably be made >> to work, but we all hate the idea. >> >> - Better communication will certainly help, but I'm not convinced >> it's enough. >> >> - CSC issue tracking and weekly meetings should help enormously, >> and I'm willing to see whether this is sufficient to solve the >> problem if people want to give it a shot before trying >> alternatives. But we will have to be really clear on who's >> signed up to do what. >> >> - If issue tracking and better communication don't solve the >> problem, then in my opinion the best thing to do is to combine >> NDR and LC for the last leg of the journey to 1.0 FCS by >> holding joint concalls between now and the meeting in >> Washington. We've demonstrated the efficacy of this approach >> quite a few times now, both in person and on the phone, and it >> appears to me to be the simplest solution known to work. >> >> Let's continue this discussion in the call Thursday (7-9 >> a.m. California time, the usual UBL bridge, whoever gets there >> first starts the call). >> >> 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/leave_workgroup.php. >> >> > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]