[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-csc] Re: CSC call on 26 November
Anne, the meeting to talk about this was always set for Thu 7-9, no change there. Anne Hendry wrote: >> 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). > > > Oh dear, Thursday? What happened to Wednesday? > There's a ttsc meeting Thursday at 8am. > > (BTW, I'm beginning to really dislike 7am. It used to be > a fairly decent time of day: tea, muffins, and what not ... > So please excuse any apparent grumpiness. I (or you) will > get used to it!) > > -A > > 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. >> >> >> >> > > > > 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. > > -- Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM Web Technologies and Standards | Phone: +1 510 550 4616 x31442 Sun Microsystems Inc. | W3C AC Rep / OASIS BoD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]