PIDX

PIDX Approval Process
Draft Specification

Summary

This is a specification of an approval process for formal PIDX deliverables such as API Recommended Practices and Endorsements. There are basically four steps in the life cycle of a specification going through this process: 1)Proposal; 2)Draft Specification; 3)Candidate Specification; and 4)Approved Specification. At each step this process attempts to provide a framework for balancing the often conflicting requirements of generating an effective solution and getting the work done in an efficient and timely manner.

Background

This process was developed specifically to use for the development and approval of XML technical specifications under the auspices of the PIDX XML Task Group, as described in the proposal . We realized early on, however, that the process might be generally useful for other PIDX deliverables, and we have tried to define it in general enough terms so that it may be used for a variety of purposes. It is beyond the scope of this group to define in exactly what circumstances PIDX might use this process, but we believe it may be applicable to a wide variety of formal PIDX deliverables.

The details of this process are not intended to break a lot of new ground. They are primarily based on processes already being used in PIDX and previously documented in the context of standards developed in collaboration with X12. The primary addition to current practice is to define checkpoints at which various products should be published on the PIDX web site for review by members or the public.

The objectives of this process related to ensuring an effective and efficient solution are:

  1. Ensure that the problem statement is clear and that the scope and relevance of the work is understood.
  2. Generate a technically sound and effective solution
  3. Provide mechanisms for developing agreement from a wide cross section of the industry on the solution.
  4. Provide a well understood process that can be implemented efficiently.

Specification

Numbers and letters shown in brackets (e.g. [2a]) in the following outline refer to the attached flow chart of this process. Note that the publication steps distinguish between using the PIDX members' web site and the PIDX public web site.

  1. Proposal
    1. [1]A PIDX member company or User Group develops a proposal and submits to the PIDX Executive Committee. This proposal should contain the information documented in the attached PIDX Proposal Template (formats: 1) HTML [.htm] with CSS Style Sheet [.css], 2) MS Word Document [.doc], 3) RTF Text Format [.rtf]). PIDX personnel are willing to work with the author of the proposal to understand what is needed here.
    2. [A]The PIDX Executive Committee does an initial screening of the proposal to weed out the clearly inappropriate. If a proposal is rejected the Executive Committee responds [2a] giving the reason for not accepting the proposal and the process stops here.
    3. [2]The proposal is published on the members' web site.
    4. [3]The PIDX Executive Committee sends the proposal to all PIDX member companies for comment .
    5. [4]The PIDX Director reviews responses from member companies, prepares a summary and makes a recommendation to the Executive Committee.
    6. [B]The Executive Committee decides whether to approve the proposal, based on member comments and participatioin and any other factors which seem appropriate. If not approved, a response [2a] is sent to the proposer and the process stops. Note that through this point information about the proposal has only been made available to member companies.
  2. Draft Specification
    1. [5]The PIDX GC or Standards Chair assigns the proposal to a PIDX user group.
    2. [6]The proposal s published on the public PIDX web site.
    3. [7]The PIDX user group develops a draft specification. Note that defining a process for this step is beyond the scope of this specification. In particular, many user groups may want to form subteams and an internal approval process, and there may be PIDX processes or "best practices" involved with these or other aspects of the user group activities.
  3. Candidate Specification
    1. [8]The draft specification is published on the members' web site at least 2 weeks prior to the Standards Subcommittee meeting in the next step.
    2. [C]The PIDX Standards Subcommittee reviews the draft specification, either approving the specification to "candidate" status or returning it [9a] to the user group from further work. Again, defining the process which the Standards Subcommittee uses to conduct this review and approval is beyond the scope of this specification, but we may note that this process often involves the creation of technical subteams.
  4. Approved Specification
    1. [9]The candidate specification is published on the public web site at least 2 weeks prior to balloting in the next step. If this is the second time through the balloting process because there are outstanding objections (see below), care will be taken to provide a full explanation of what the objections are and the responses of the user group and/or Executive Committee to these objections.
    2. [10]THe PIDX Director issues ballots to the PIDX general committee. PIDX members have 30 days to return these ballots. Members are requested to explain negative ballots with specific reasons for the objection and, if possible, alternatives.
    3. [11]The PIDX Director reviews the ballots and routes negative ballots with specific reasons and/or alternatives to the user group for response. The user group makes an effort to respond to these objections and, if possible, to gain acceptance from the objecting member company. Although not desirable, in some cases it may not be possible to gain acceptance from all members, and in these cases there will be a second pass through the balloting process. On the second ballot a simple majority of ballots cast are sufficient for approval.
    4. [13a]The approved specification is forwarded to the API for publication.


© 1995-2002, American Petroleum Institute
Updated: March 12, 2002