[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [legalxml-courtfiling] [Fwd: Proposed Procedures for Court Filing TCDeliverables - Input Incorporated.doc]
I am forwarding to all members of the Technical Committee Roger Winters' revised proposal for our internal operating procedures, incorporating the input he received by the comment cut off date. Please send any final comments to this list by Tuesday, September 3d. If no one objects, these procedures will be adopted effective September 3d. Thank you, Roger, for taking the initiative to get these procedures in place. -- John M. Greacen Greacen Associates, LLC. 18 Fairly Road Santa Fe, NM 87507 505-471-0203
--- Begin Message ---Title: 1
- From: "Winters, Roger" <Roger.Winters@METROKC.GOV>
- To: 'John Greacen' <john@greacen.net>
- Date: Mon, 19 Aug 2002 16:01:24 -0700
--- End Message ---
This version of the Legal XML TC's "Process for TC Specifications and Other Deliverables" contains the input I received by last Monday's deadline. John, you'll notice that I incorporated a section about the TC's relationship with JTC, Global, etc., as well as preserved the language that acknowledges there could be other external standards processes interested in reviewing/adopting the TC's work products, too. That's all in Section VI.
I guess the next step is to put this up for formal adoption by the TC on the List. I presume you, John, can call for a consensus and set a timeline to see whether there is anyone who can't live with these procedures?
>From Friday through Labor Day, I'm going to be away from the office, recuperating from minor surgery. I'm trying to pull together template materials for the TC during this week, but I can't be sure I'll finish that task before then. Anyhow, I'm giving it a try.
Please let me know if you have questions or if you're aware of any other input that should be included with this document. Thanks!
Roger
UPDATED PROPOSAL: August 19, 2002
(Reflecting comments received during open comment period through August 12, 2002)
Legal XML Court Filing Technical Committee (TC)
Process for TC Specifications and Other Deliverables
I. The Statement of Work
A. The Court Filing Technical Committee (TC) review process begins with a proposer (who may be one or more persons), or a proposer the TC designates, drafting a Statement of Work. This would be a paper, prepared using a standard TC template: to describe the specification or other deliverable[1] that will result from the proposed work, explain its general purposes, relate it to other work products of the TC, describe how it will be developed and by whom, and state when the proposer believes the work must be or could be completed.
B. The Draft Statement of Work must be sponsored by at least one TC member. The proposer will submit it to the TC Co-Chairs with a recommended period for comment and review by the TC. The Co-Chairs have the power to modify the proposed review period and they will announce the review deadline when declaring the Statement of Work to be out for TC review. The Co-Chairs would refer the draft for posting to a "topical Web page"[2] whose title would be that of the proposed specification or other deliverable (e.g., "Court Filing Certification," "Request for Proposals for Trusted Document Repository"), with its own URL within the Web site structure for the Court Filing TC. The TC Editor would not be expected to review this document in detail, except to verify the proposer used the appropriate template.
C. Contents of the Statement of Work would include:
1. A title appropriate to the subject matter of the specification or expected deliverable (with the title subject to modification by the Co-Chairs of the TC or the TC)
2. A description of the type of specification or deliverable (e.g., DTD, Schema, White Paper, RFP) that would be drafted if the Statement of Work is approved
3. A non-technical description of the subject matter and its significance to the work of the TC
4. A description of the relationship of the proposed work product to other products or activities of the TC (presented as a narrative and described in relation to any of the TC's charts/diagrams of its work products)
5. The names and relevant credentials of the proposed authors of the specification or other deliverable and a description of the roles they would play in doing the work, including designating who would have lead responsibility for the work
6. A description of skill sets/expertise needed to complement those of the authors (e.g., "needs technical expert to prepare the Schema," "no drafter is expert with SOAP and this may be needed")
7. Description of the proposed timeline to develop the work product, citing any factors or deadlines that might be driving the work (e.g., "Federal Administrative Office of the Courts would review this for adoption only if a 'Proposed Specification' is in place by August, 2003")
8. Version number assigned to the current draft of the Statement of Work, as required for proper version control and management.
D. The TC Co-chairs would announce and provide a link to the Draft Statement of Work for (Subject) to the TC membership, inviting their review for a specific period ending on a particular date. Input from the TC would be directed to a special List or provided otherwise, as described in the announcement. During this stage of the process, the draft is "owned" by the authors, who are responsible to take note of input provided through the TC's discussion lists, through written submittals, and otherwise. The Web master and Editor for the TC will be available as consultants and will ensure documents are well managed, with version control and so forth.
E. Input (from all sources) would be collected and reported to the TC members, no later than a set period of days after the close of the announced review period. The Co-Chairs would set the deadline for reporting what input was incorporated, what was not, the reasons, etc. The authors would have "ownership" at this stage and would:
1. Make a record of the input received or noted.
2. Make changes in the Statement of Work reflecting input the authors believe should be accepted.
3. Report the input not accepted and incorporated in the Statement of Work, with brief explanations for each item.
4. Complete the final draft of the Statement of Work and submit it to the Co-Chairs.
F. The final draft of the Statement of Work would be reviewed by the Co-Chairs and the TC Editor, based on completion and resolution of all of the above. It would be posted for TC final review and concurrence. This document would not be subject to a required period of public review and comment, nor would it have to be reviewed at a Face-to-Face meeting of the TC. TC approval would indicate only that it believes the subject is worth applying resources to draft the actual specification or other deliverable. Though public comment and a Face-to-Face meeting review are not required, they could be done for any given Statement of Work.
G. The TC Co-Chairs would notify the TC about the final discussion period to be observed and would schedule the TC's vote. A vote to accept the Statement of Work would, in effect, constitute the TC's consent that resources should be used, as described in the Statement of Work, to develop the specification or deliverable.
H. A Statement of Work that has been accepted by the TC would be prepared by the TC Editor for final posting on the Web page by the Web master. The posted Statement of Work would include technical editing, not substantive changes, that might be needed to ensure it conforms to the TC's requirements for its official documents, including version control requirements. The review process would be described in a document history statement.
II. The Requirements Document
A. The authors of the Statement of Work, or a designated drafting committee, would prepare the Draft Requirements Document, using a TC template. This template would include a means of uniquely identifying each requirement for purposes of traceability in subsequent stages - such as review of deliverables or certification. It should also include a section on compliance levels, describing how partial as well as full compliance would be determined. This document would, when ready, be posted to the same "topical Web page." That Web page would remain the place for collecting all documents, versions, links, and so forth relevant to the topic (e.g., "Court Filing Certification," "RFP for Trusted Document Repository").
B. The authors of the Draft Requirements Document would submit it to the TC Co-Chairs with a recommended period for comment and review by the TC. The Co-Chairs have the power to modify the proposed review period and they will announce the review deadline when announcing the Requirements Document is out for TC review.
C. Ordinarily, a review would be done at the next (presumably, quarterly) "Face-to-Face" meeting. "Emergency" work products might bypass the Face-to-Face meeting review. ("Emergency" would need definition or TC-approved justification.)
D. The Ombudsman to the Public Comment List of the TC would report the posting and location of the Draft Requirements Document, indicating the deadline for comments. The Ombudsman would also help non-members of the TC to locate the TC's or subcommittee's archive, so they could read and follow the discussions on this issue. A link to or instructions for finding the appropriate archived messages should be provided on the topical Web page.
E. Input from the TC would be directed to a special List or provided in a different manner, to be described in the announcement. Input from the public and other sources would be directed to the authors. During this stage of the process, the draft is "owned" by the authors, who are responsible to take note of input provided through the TC's discussion lists, through written submittals, and otherwise. The Web master and Editor for the TC will be available as consultants and will ensure documents are well managed, with version control, and so forth.
F. Input (from all sources) would be collected and reported to the TC members, within a set period after the close of the announced review period. The Co-Chairs would set the deadline for reporting on what input was incorporated, what was not, etc. The authors would still have "ownership" at this stage and would:
1. Make a record of the input received or noted.
2. Make changes in the Requirements Document reflecting input the proposer(s) believe should be included.
3. Report the input not accepted and incorporated in the Requirements Document, with brief explanations for each such item.
4. Complete their final draft of the Requirements Document and submit that to the Co-Chairs.
G. The final draft of the Requirements Document would be reviewed by the TC Co-Chairs and the TC Editor, based on completion and resolution of all of the above. It would be posted for final TC review and concurrence. A notice to all TC members would be issued, a final discussion period observed, and a vote taken. Adoption of the Requirements Document would show that the TC desires that specifications (or other deliverables) be written to fulfill those requirements.
H. A final version of the Requirements Document that approved by the TC would be prepared by the TC Editor for posting on the Web page by the Web master. The Requirements Document would be subject to technical editing, not substantive changes, to ensure it conforms to the TC's requirements for its official documents, including version control requirements. The review process would be described in a document history statement.
III. The Candidate Specification or Other Deliverable
A. Prepared by the authors or drafting committee, using a specified TC template (as provided by the TC Editor), the Candidate Specification or Other Deliverable would be posted to the same "topical Web page" used for the Statement of Work and the Requirements Document.
B. The Candidate... document would be submitted to the Co-Chairs of the TC with a recommended period for comment and review. The Co-Chairs would determine the deadline for comment and review and announce that to the TC List when the document is posted to the Web page and ready for TC review and discussion.
C. Any Candidate Specification or Other Deliverable would require review by at least one (presumably, quarterly) Face-to-Face meeting of the TC. The TC should adopt procedures for presenting such deliverables, discussing them, and resolving issues at those meetings, including allowing for member participation by phone. Face-to-Face recommendations, if any, would be reported to the List for ratification or other disposition by the whole TC.
D. The Ombudsman to the Public Comment list would report the posting and location of the Candidate Specification or Other Deliverable, indicating the deadline for comments. The Ombudsman would also help non-members of the TC to locate the TC's archive, so they could read and follow the TC's discussions. A link to or instructions for finding the appropriate archived messages should be available on the topical Web page.
E. Input from the TC would be directed to a special List or provided as otherwise described in the announcement. Input from the public and other sources would be directed to the authors. During this stage of the process, the draft is "owned" by the authors, who are responsible to take note of input provided through the TC's discussion lists, through written submittals, and otherwise. The Web master and Editor for the TC will be available as consultants and will ensure documents are well managed, with version control, and so forth.
F. Input (from all sources) would be collected and reported to the TC members, within a set period after the close of the announced review period. The Co-Chairs would set the deadline for reporting on what input was incorporated, what was not, etc. The authors would have "ownership" at this stage and would:
1. Make a record of the input received or noted.
2. Make changes in the Candidate Specification or Other Deliverable reflecting input the authors believe should be included.
3. Report the input not accepted and incorporated in the Candidate Specification or Other Deliverable, with brief explanations for each such item.
4. Complete their final draft of the Candidate Specification or Other Deliverable and submit that to the Co-Chairs.
G. The final Candidate Specification or Other Deliverable would be reviewed by the TC Co-Chairs and the TC Editor, based on completion and resolution of all of the above. It would be posted for final TC review and concurrence. A notice to all TC members would be issued, a final discussion period observed, and a vote taken.
H. If ratified by the TC members, the Candidate Specification or Other Deliverable officially becomes and is thereafter called a Proposed Specification or Other Deliverable of the Court Filing Technical Committee.
I. A final version of the Proposed Specification or Other Deliverable would be prepared by the TC Editor for posting on the Web page by the Web master. The Proposed Specification or Other Deliverable would be subject to technical editing, not substantive changes, to ensure it conforms to the TC's requirements for its official documents, including version control requirements. The review process would be described in a document history statement. The document would also be prepared for entry into the TC's Trusted Repository.
IV. The Proposed Specification or Other Deliverable
A. A Proposed Specification or Other Deliverable would be something that the TC believes could and should be implemented, by TC or other OASIS members. The final document would include a statement to that effect, indicating specific criteria and procedures for testing and evaluation that the TC will require before it would consider moving the specification or other deliverable to "recommended" status. The criteria and procedures would include any review of deliverables, certification requirements, or compliance level criteria that were included in the Requirements Document (see section II.A, page 4).
B. Since applications could be written based on the Proposed Specification or Other Deliverable, the document (e.g., DTD, Schema) must be posted to a stable, reliable, permanent Court Filing TC-Legal XML Trusted Repository. This Repository is to provide a stable, perpetual reference for the adopted deliverables of the TC, observing numbering, titling, and other rules designed to provide unambiguous references to which other sites, applications, etc., might point at any time in the future.
C. Once "frozen" by being posted at the Trusted Repository, the specification or deliverable would be announced to the world with its official and perpetual URL in the Repository.
D. Upon completion of the "operability tests" and any other prescribed steps, which would be described in the Proposed Specification or Other Deliverable, a proposal would be brought to the TC that it be adopted officially as a Recommended Specification or Other Deliverable.
E. Once approved, an adopted Recommended Specification or Other Deliverable, as appropriate, could be submitted to OASIS for its formal specification review and approval process.
V. Final Posting of a Recommended Specification or Other Deliverable
A. Each Recommended specification or other deliverable that has been adopted officially by the Court Filing TC must be posted to a stable, reliable, permanent Court Filing TC-Legal XML Trusted Repository. This Repository is to provide a stable, perpetual reference for the adopted deliverables of the TC, observing numbering, titling, and other rules designed to provide unambiguous references to which other sites, applications, etc., might point at any time in the future.
B. Once "frozen" by being posted at the Trusted Repository, the specification or deliverable would be announced to the world with its official and perpetual URL in the Repository.
C. All approved deliverables of the TC would be subject to whatever updating, revising, versioning, or other modifications that were specified for or found to be appropriate for them, based on the requirements, timing, and process steps described in their respective documents.
D. Once posted to the Trusted Repository, no deliverable shall be withdrawn from it, nor shall it be modified in any way, except pursuant to an action by the TC to revoke the deliverable and remove it from the Trusted Repository.
Otherwise, even a minor revision would require the posting of an incremented version number or other distinguishing indicator for that deliverable.EvenE. Posted URLs must be maintained in the Trusted Repository indefinitely. It is possible that specifications and other deliverables would include information providing for use of mirror sites and other reflections from the official Repository, if needed, to serve in supporting implementations. However, the official version for all such deliverables shall always be the version in the Trusted Repository.
F. Updates and revisions to specifications or other deliverables shall be maintained in the same Trusted Repository as their predecessors, with a clear and unambiguous revision history to be included in all updated and subsequent specifications or other deliverables
VI. Use of TC Recommended Specifications or Other Deliverables by Non-TC Entities
A. In addition to the OASIS approval process, the Electronic Court Filing Technical Committee will provide its proposed and recommended specifications to the National Consortium for State Court Automation Standards ("the National Consortium"), a subcommittee of the Joint Technology Committee (JTC) of the Conference of State Court Administrators (COSCA) and National Association for Court Management (NACM). The National Consortium will further vet the Technical Committee's recommendations through a "Joint Standards Development (JSD) Team" composed of representatives of state and local courts and private sector service providers who are interested in and knowledgeable about electronic court filing. The Joint Technology Committee acts upon the Technical Committee's proposals based upon the JSD team's recommendation to adopt a specification as a "proposed standard" for experimental implementation. After a "proposed standard" successfully completes tests, including interoperability tests when appropriate, defined in the specification, the Technical Committee transmits the specification to the Joint Technology Committee for adoption as a "recommended standard." When the Joint Technology Committee approves that recommendation, it is sent to the Boards of Directors of the two parent bodies, COSCA and NACM, for formal adoption on behalf of all state courts. The members of the Conference of Chief Justices then take whatever actions are required to implement the standards in their jurisdictions. COSCA and NACM may also submit the specifications for recognition by the Global Justice Information Network Advisory Committee of the United States Department of Justice ("Global").
A.B. Processing any of the TC's specifications or other deliverables through other national or state courts, court administration organizations and associations, judicial branch processes and structures, government bureaucracies, industry associations, and so forth shall be formally independent of the TC's internal review and approval process.
B.C.Apart from the procedures described in section VI.A, page 9, review by non-OASIS, non-Legal XML, non-TC groups would come in as part of the public comment and review activities provided for in the TC procedures, or it might take place after the final approved version of a Proposed or Recommended Specification or Other Deliverable has been issued.Ordinarily
C.D. The TC intends to facilitate the review and seek the endorsement of its specifications and other deliverables from other entities, as is appropriate for each of them. When the TC is aware of concerns, considerations, and deadlines important to those outside entities, it will do what it can to organize its process to be responsive to those matters.
D.E. Materials relevant to the work of the Court Filing TC that are produced outside its structure and processescould be incorporated into the TC's body of interrelated materials. To accomplish this, the TC would move such items through its own processes for review and adoption. As determined by the Co-Chairs, with the concurrence of the TC, process steps ordinarily observed might be shortened or treated as de facto completed, depending on the particulars of what is being reviewed.(e.g., "Functional Standards for E-Filing" developed by court administration organizations)VII. Rules and Procedures for TC Specifications and Other Deliverables
A. All TC rules and procedures shall be formally adopted by the TC and, like specifications and other deliverables, shall be maintained on the Trusted Repository, using version numbering, version control, document management, and providing for ongoing retention. This is because the rules are part of the context from which the specifications and other deliverables arose; therefore, they might need to be referenced at any time in the context of interpreting or using the specifications or other deliverables.
B. Specifications and other deliverables of the Court Filing TC in development previous to or at the time of the formation of the TC within OASIS, shall be "grand-fathered" in at appropriate points in the sequence of procedures adopted by the TC. The Co-Chairs, working with appropriate subcommittees, the Editor, Web Master, and Secretary of the TC, shall present specific recommendations on how to designate and process each of those specifications and other deliverables, that is, those which are in effect "in the pipeline" of the TC's review and approval process. Once assigned to appropriate stages in the review and approval process, those specifications and deliverables would be processed further according to these rules and procedures. As an example, it is noted that "Court Filing 1.1" has been adopted, prior to the TC's OASIS affiliation, by Legal XML's Court Filing Work Group, as a Proposed Specification for Court Filing. It could now be considered to have been processed through all review stages preceding the section headed "IV. The Proposed Specification or Other Deliverable," above, page 7. Further TC action on "Court Filing 1.1" would continue from that point.
C. A committee, consisting of the Editor, Web Master, Chair of the Trusted Repository Subcommittee, and the Secretary of the TC, with additional members that may be named by the TC or its Co-Chairs, shall be responsible for managing the TC's official documents, including maintaining clear records of their versions, titles, numbering systems, and so forth.
-Prepared and updated, based on input received through August 12, 2002, by Roger Winters, Editor, OASIS-LegalXML-Court Filing Technical Committee
RLW:CFTC:pc
[1] The term "specification or other deliverable" is used to mean any work item processed by the Court Filing Technical Committee (TC) from conception through the stages of review, resulting in official approval or other disposition by vote of the TC. Most of what the TC will process will be "specifications" (or, "standards"); however, other types of work products (other deliverables) might be handled this way. Examples are Requests for Proposals (RFP), official TC policies and procedures, formal White Papers, or other official materials of the TC.
[2] The Web Master is responsible for all TC Web pages, including topical sites of this sort; once a page is opened for a given topic, it serves as the location for all related work products, at least until completion of the review and approval process.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC