1. OMG Issue

ABPSC — Need clear policy regarding review of an RFP by the AB

  • Key: ABPSC-50
  • Status: open  
  • Source: Jackrabbit Consulting ( Charlotte Wales)
  • Summary:

    Section 4.1 of the Hitchhiker's Guide, V7.8 includes this:

    A typical Task Force voting scenario is as follows:
    1. The Task Force meets at least once to discuss the RFP prior to any Architecture Board (AB) review. By policy, a RFP cannot be issued at the same meeting that it is first discussed.
    2. A spokesperson(s) presents the RFP to the AB at its first meeting day (by convention, Monday afternoon) for initial review.
    3. The AB may or may not request minor revisions.
    4. The RFP working group makes necessary changes (if required).
    5. AB and subsequent Task Force changes (if any) are reviewed and the vote to recommend issuance occurs in a Task Force meeting prior to the AB’s second meeting day (by convention, Thursday afternoon).
    6. The (modified) RFP is presented to the AB at its Thursday meeting with a request to vote its recommendation for issuance.

    I think item 1 needs to be added to the P&P to ensure it's not just a de facto policy – which, unless it's in the P&P – is all it is. I don't know where (Section 4.2.1?) or even how to state it in proper P&P form (in small text under item 1 in Section 4.2.1? or is that not normative?). As TF chair I've been enforcing this "policy" for years and it's not an unreasonable policy at all – even if it's only de facto. It ensures that we never have a situation in which an RFP (posted by the 4 wk deadline) is reviewed by the AB and the purported issuing TF is completely unaware of its existence or content.

    Need to also make it clear that an RFP may not be voted for issuance by the AB without first being recommended for issuance by the issuing TF via a formal vote. Unless it's stated elsewhere in the P&P, this statement in the P&P as it stands now is too weak:

    1. An RFP is usually drafted by the Task Force responsible for that
    technology area, and passed to the TF's parent TC for issuance.

    Btw "usually drafted"?? Why "usually"? Is this to cover the case where a SIG prepares an RFP and brings it to a TF to issue? Suggest adding something in small text to explain what is implied by "usually".

  • Reported: ABPSC 3.3 — Wed, 2 Nov 2022 19:07 GMT
  • Updated: Wed, 2 Nov 2022 19:07 GMT