RE: RIM 0.55 distribution

[Klaus-Dieter Naujok <knaujok@home.com>]

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