Standards Development Process
This page describes the process by which the Ed-Fi Alliance develops data exchange standards.
Contents
Request-for-Comment Process
The first formal stage in the lifecycle of an Ed-Fi standard is the Request-for-Comment (RFC) process. This section describes the process for generating and approving an RFC document, which contains a proposed set of changes or additions to Ed-Fi standards.
Other community material — such as use case documents or project artifacts from field work — may precede an RFC and provide evidence of need or support for specific designs proposed in the RFC.
Worth noting is that many new standards and major revisions may go through multiple RFC drafts. This allows the technical product and accompanying documentation to be refined as opportunities for improvement are identified by community comment, evidence in the field, and technical review. Typically, the issuance of an updated draft makes obsolete the previous version.
RFC documents are published on Ed-Fi RFC Home, which solicits comment from the Ed-Fi community and the general public.
Workflow
Figure 1. The flow of ideas for an RFC document (click to expand)
Stage Details
The following table describes the sequential RFC stages.
| Stage | Actor | Details |
|---|---|---|
| 1 | Work Group or Alliance Staff | Ideas for a new standard or changes to existing standards are proposed as a draft by Work Groups (1a) or Alliance staff (1c). The detailed draft RFC documents are asserted by Work Group chairs or by Alliance staff. In addition, members of the Ed-Fi community may register working drafts (1b) with a Ed-Fi work group. Working drafts describe proposed solutions and may be at a low level of maturity. However, they must contain required information for such documents and represent actual field work. Working drafts can be removed by the work group chairs if they are deemed to not be within scope of the work group. In addition, if there is no applicable work group for a proposal, working drafts can be registered with the TAG. |
| 2 | Technology Advisory Group | Technology Advisory Group (TAG) reviews the draft RFC. Commentary from the review is aggregated onto the draft RFC. |
| 3 | Governance Advisory Team | Governance Advisory Team (GAT) reviews the draft RFC and TAG commentary and provides a recommendation. |
| 4 | Executive Committee | The Executive Committee reviews the draft RFC and approves or declines it. If declined, it goes back to the GAT, who can work with the Work Group or Alliance staff on changes. |
| 5 | Ed-Fi Community | If approved, the draft is promoted to RFC status and published for commentary by the community. At this point, early adopters are expected to implement the changes and gather. |
There are a few elements included on this diagram that reflect the overall operations of the Ed-Fi community.
- The Ed-Fi open source solution is a context for ongoing field experimentation. While the Alliance encourages the use of the governance process for growing our standards, the Ed-Fi community values action and experimentation even more. While discussions provide great context for weighing options, the "real world" is the ultimate arbiter of what works and what does not. Instead of leading with discussion, in many cases it is better to lead with doing, and then feeding the lessons learned back into community discussion.
- Ed-Fi's Core Principles are sum of documents describing principles of Ed-Fi standards development, the most important of which is About - Data Standards. The expectation is that standards follow norms established in this and related documents. These are tools for use by the various actors in evaluating and commenting on proposed changes to Ed-Fi standards
Unified Data Model Versioning
The Ed-Fi Unified Data Model (UDM) includes an appended letter to signal that it includes RFC material (e.g. v3.3a). The letter will iterate if new RFCs are added, or if an RFC is replaced with a newer, sequential version letter (e.g. v3.3b).
When an RFC is approved as a standard, a new version of the UDM is released by dropping the appended letter (e.g. v3.3). When this happens, it is likely a new development version is produced with the version incremented and the version letter reset (e.g. v3.4a).
Standards Approval Process
The second formal stage in the lifecycle of an Ed-Fi standard is the transition from an RFC to a standard. This section describes how a RFC becomes a standard.
In this stage, proposed changes or additions have gone through some validation via field work, and that work provides the principal evidence for and basis of approval as a standard. To be considered, the proposed standard must adhere to the Core Principles referenced above.
Workflow
Figure 2. The process by which an RFC becomes a standard (click to expand)
Stage Details
The following table describes the sequential standard approval stages.
| Stage | Actors | Details |
|---|---|---|
| 6 | Work Group or Alliance Staff | The Work Group (via the chairs) or Alliance Staff can propose that an existing RFC be promoted to a standard. Approval as a standard requires evidence of field implementation from at least 2 separate implementations in production usage, which will accompany the RFC. |
| 7 | Technology Advisory Group | Technology Advisory Group (TAG) reviews the RFC. The TAG should consider issues such as if the field evidence suggests that the structures captured in the RFC are ready to be promoted into a standard. Commentary from the review is aggregated onto the RFC. |
| 8 | Governance Advisory Team | Governance Advisory Team (TAG) review the RFC and TAG commentary and provides a recommendation. |
| 9 | Executive Committee | The Executive Committee reviews the RFC and approves or declines its promotion. If declined, it goes back to the GAT, who can work with the work group or Alliance staff on changes. |
| 10 | Ed-Fi Community and World | If approved, the RFC is promoted to a standard. This standard is usable by the Ed-Fi community or any others. Changes to this standard will come through future RFCs. |