[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: RIM 0.55 distribution
On Fri, 19 Jan 2001 12:27:52 -0600, Nieman, Scott wrote: >Finally, for the future, I am authorizing Farrukh to make revisions to the >document that are ONLY editorial in nature and submit revisions to QRT on >behalf of the team . "Editorial in nature" is an assumption that changes >only provide clarification to QRT concerns. Any substantive changes will >require VOTE by the registry team. I am assuming that the StC will not >object this the process (please let me know asap if this is an issue). Scott, I understand what you are trying to achieve, however, we have a very lean (simple) process in place that we must follow. I am not aware that there is currently a so to say "interactive" process between QRT and the project team that has submitted a specification to revise on the fly the specification under review. Therefore I don't understand your suggestion for Farrukh to be allowed to submit editorial changes to QRT. I should point out that QRT has approved the TA specification but at the same time had many comments to be addressed as part of the next review. However, the QRT comments against the RIM were more than of editorial nature that could be to be taken care of in the next editing session and therefore they rejected the request to go out for public review. The process is very simple, a PT approves by vote (min 67%) its draft to go for the first public review. It is submitted to QRT for quality review. If QRT recommends that the specification can go out for review, it is made public including any comments from QRT. At the end of the review cycle the PT reviews the public and QRT comments in order to create its next revision. After approval by the PT it goes out for the second cycle using the same process with QRT. At the end of the second review the PT takes again the public comments and QRT comments to prepare the final specification. This version will be made available to the ebXML community 2 weeks before a ebXML meeting in order to approve it during the closing plenary. Should QRT reject the specification, and the Executive does not overrule the QRT, than the PT will have to address the issues by either revising the document or countering the QRT comments. If the PT revises the document PT approval is required to present it back to QRT. Should the PT disagree with QRT it must present it counter arguments to QRT. In the case that QRT disagrees, the Executive will review the issue(s) and make a recommendation to the StC which will take a decision at the earliest time via a conference call. Should the QRT agree with the counter arguments the document as submitted will go out for review. In the case that QRT rejects the specification and the executive disagrees with the rejection, there are two possible actions. If the Executive feels that the reasons are not of technical substance it can take the decision to go out for public review. If the Executive feels that the technical issues raised are not a show stopper or are not valid it will asked the StC to take the decision to allow the specification to go out for review or not. In closing, the main reason for having the PT submit the request to QRT via the StC was to make sure that all PT lead and the Executive were aware of the fact that a specification was entering the review process. Scott, I hope I clarified the process and reasons for it. I have no intentions to put road blocks up, the opposite is true, I want to make sure that we follow our simple process so that no one can claim we short circuiting it, which would mean in the end more work by back tracking. Have a great weekend, looking forward to reading you specifications as they go out for review. Regards, Klaus -- Klaus-Dieter Naujok ebXML & TMWG Chair Netfish Technologies, Santa Clara, CA, Chief Technology Officer
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC