International Federation of Digital Seismograph Networks

Framework for adoption of features within FDSN Working Groups

Version Montreal, July 2019

Preamble

  • The rational of the framework is to streamline and formalize the proposal and adoption of new features. Features can be formats, software, schemas, or even virtual networks.
  • This framework is intended to apply to any FDSN Working Groups considering adoption of features.
  • 2-stage process: 1) proposal phase followed by an 2) evaluation and adoption phase
  • Proposal phase focuses on seismologists evaluating the relevance of new feature. This is intended to clarify objectives and sets consensus requirements. Depending on the impact of the proposed features, outreach beyond FDSN may be required.
  • Evaluation and adoption phase focuses on technical implementation.
  • A suggested time period for each phase ranges from a minimum of 2 months to a maximum of 1 year for the discussion at each phase. The WG Chair declares before the start of a phase the time frames expected to be followed. The second phase need not directly follow the first, there may be an extended intermission between the 2 phases.
  • Proposal Review and Evaluation Review teams with at least 3 and at most 6 members from at least 2 geographic regions set up for each phase. At most 2 members per region (regions are North America, South and Central America, Europe, Africa, Asia, Australasia). Team members could change at the different phases. A review team nominates a single reporter as point of contact for the WG.
  • At the end of each phase, a vote to proceed with current plan (or on alternative plans) will be held over the WG mailing list.
  • Voting rules (consistent with current FDSN Terms of Reference):
    • 1 vote per FDSN member (i.e. each network or datacentre)
    • Votes are agreed with at least ⅔ majority. Quorum for any decision is 5 FDSN member votes.
  • This framework allows for different scenarios:
    • adoption of existing features already implemented, or
    • planned features to be developed
  • The entire process takes place within WG mailing list. Note: this can lead to feature adoption without review at biennial meeting.
  • If feature adoption is agreed in a WG and if a formal FDSN decision is required, the WG will propose the matter to the Steering Committee, either at a plenary of a meeting or via the Steering Committee mailing list.

Proposal Phase – Community consensus phase

Type A: making an existing feature an FDSN standard

The WG leads announce a potential feature that exists and should be considered for becoming an FDSN standard. A Proposal Review team is formed to report on feature and suggest suitability for FDSN. The WG decides whether to continue towards adoption. This can be a short phase.

Type B: proposing a new feature as an FDSN standard

The WG leads announce plan to develop a new feature. The WG votes on whether to pursue at FDSN level. If positive, a Proposal Review team is formed to develop specifications and then prototype feature. The Proposal Review team prepares a report for FDSN. The WG decides whether to continue towards adoption. This may be a longer phase, as it involves 2 phases of voting in addition to specification and feature development.

Evaluation and Adoption Phase – Technical completion phase

Report and possibly feature prototype is evaluated and the WG invites technical comments. the Evaluation Review team reviews comments and if the feature will be a candidate for FDSN adoption, recommendations will be made. Once these have been addressed, the WG votes on adoption.