Re: RIM 0.55 distribution

[Tim McGrath <tmcgrath@tedis.com.au>]

i do not think that the actions of the regrep team have broken the process.

the way i interpret the situation here is that the RegRep submitted a Spec to
QR on wednesday, have requested that this submission be withdrawn, and
submitted a Spec on Friday.  The team lead and editor have agreed with this new
submission (ie it has PT approval).

none of this discussion should be distracted by the fact the Nagwa (who is part
of the QR team) assisted in the revision.  It was not the QR team assisting (ie
not an iterative process).

i suggest the QR team review  RIM submission 0.55 and report to the executive
by Friday 26th January.

this keeps us all on track  for the April plenary and prevents wasted cycles.


Klaus-Dieter Naujok wrote:

> 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

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

begin:vcard 
n:McGrath;Tim
tel;pager:+61(0)299633829
tel;cell:+61 (0)438352228
tel;fax:+61(0)893352142
tel;work:+61(0)893352228
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:tmcgrath@tedis.com.au 
x-mozilla-cpt:;-23520
fn:tim mcgrath
end:vcard