The formation of a working group requires a charter which is primarily negotiated between a prospective working group chair and the sponsoring Governance Committee Chair, although final approval is made by the Technical Governance Committee, A charter is a contract between a working group and the openIDL to perform a set of tasks. A charter:

Lists relevant administrative information for the working group;
Specifies the direction or objectives of the working group and describes the approach that will be taken to achieve the goals; and
Enumerates a set of milestones together with time frames for their completion.

When the prospective Chair(s) of the working group and the sponsoring governance committee chair are satisfied with the charter form and content, it becomes the basis for forming a working group. Note that a governance committee MAY require holding an exploratory Birds of a Feather (BOF) meeting, as described to gage the level of support for a working group before submitting the charter to the Technical Governance Committee for approval.

Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group. The charter is an agreement between the openIDL and the working group which is committing to meet explicit milestones and delivering specific "products" and in return is then provided organization, meeting and technical planning support.

Specifically, each charter consists of the following sections:

Working Group Name

A working group name should be reasonably descriptive or identifiable.

Chair(s)

The working group may have one or more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) shall be included. Generally, a working group is limited to two chairs.

Governance Committee

The name of the openIDL Governance Committee with which the working group is affiliated and the name and electronic mail address of the associated governance committee liaison. The sponsoring Governance Committee provides meeting support and coordinates technical resources for the working group.

Mailing List

An openIDL working group MUST have a general Internet mailing list. Most of the work of a working group will be conducted on the mailing list. The working group Charter MUST include:

The address to which a participant sends a subscription request and the procedures to follow when subscribing,
The address to which a participant sends submissions and special procedures, if any, and
The location of the mailing list and documents archive. A message archive MUST be maintained in a public place which can be accessed via the web.

Description of Working Group

The focus and intent of the group should be described in an executive summary. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph can be used as an overview of the working group's effort.

To facilitate evaluation of the intended work and to provide on-going guidance to the working group, the charter must describe the problem being solved and should discuss objectives and expected impact with respect to:

Architecture
Data Requirements
Operations
Security
Network management
Scaling
Transition (where applicable)

Goals and Milestones

Purpose: The purpose of the Flood Working Group is to develop robust insurance industry solutions for insurers, brokers and reinsurers to evaluate and responsibly respond to U.S. flood risk in a secure/trusted way that will be acceptable within a regulated insurance marketplace.

Vision: Have OpenIDL be a leader in creating a functional private flood market. This is achieved through creating a data reservoir that is a combination of FEMA and private market exposure and claims data, creating standards for data formats, facilitate exchanges of data between insurers, intermediaries, reinsurers, and catastrophe modelers, and plug into the regulatory environment for quick review and approval of flood rating programs.

Benefit for Modelers: Establishing a workflow of flood data that can pass from insurers to modelers, reinsurers, intermediaries, and regulators removes many barriers to entry for companies eager to write flood risk while reducing the cost of ownership. By having modelers plug into the blockchain with uniform standards around flood data capture, the following benefits emerge:

· Exposure data prep is reduced to a pre-formulated query based on existing data in the blockchain

· Modeler output can be queried from the block chain to be used in reinsurance submissions

· Modeler output can be easily queried for regulatory reporting

The working group charter MUST establish a timetable for specific work items. While this may be renegotiated over time, the list of milestones and dates facilitates the Area Director's tracking of working group progress and status, and it is indispensable to potential participants identifying the critical moments for input. Milestones shall consist of many deliverables that can be qualified as showing specific achievement; e.g., "Internet-Draft finished" is fine, but "discuss via email" is not. It is helpful to specify milestones for every 3-6 months, so that progress can be gauged easily. This milestone list is expected to be updated periodically (see section 5).

Charter Review & Approval

Proposed working groups often comprise technically strong participants who are not familiar with the openIDL and the agile development processes. This can, unfortunately, lead to good working group consensus about a flawed design. To support and facilitate working group efforts, a governance committee chair may assign a consultant from among experienced openIDL members and participants.

Once a sponsoring governance committee chair has approved the working group charter, the charter is submitted for review by the openIDL Technical Governance Committee. The openIDL Technical Governance Committee can approve charters through electronic mail consensus.

Working Group Process

Scope Refinement and Planning

Working group members refine the technical design, project scope and deliverables by defining features, acceptance criteria and releases.

Discovery

Technical research and design refinement

Working Code

Proof of Concept, Prototypes and Test Applications

Documentation

Data Requirements
- FEMA/NFIP - NFIP Transformation - 2.0 (scheduled/deferred to October, 2021)
Smart Contracts
Operational Requirements
Network Impact and Financial Support Recommendations
Security Requirements, Authentication and Access Control

Code Source Control

Intellectual property documentation
Source control review, approval and acceptance into operations

openIDL Working Group Support

Meeting planning
Meeting notes and reference library
Email archiving
Document archive

The Floo

Browser not supported