Governance model

[flotang-gtt]

Please add your suggestions or ideas about a formalized governance model suggestion.

[bocklund]

Copying some old notes from our 2021 MGF OneDrive doc below. This was an early concept, nothing is non-negotiable.

The governing body (e.g. MGF) should organize a committee that has interests representing different parts of the community. The committee is responsible for publishing the standard and voting on and publishing revisions to the standard based on community RFCs, as well as releasing new standards according to some cadence. New models and extensions to the standard to be developed by the community, then incorporated into the standard through an RFC process. The committee should judge an RFC based on • ensuring that the additions are mature enough to be used by the community (maybe there's some CNCF-style staged evaluation period?) • ensuring that the additions adhere to the existing style standards, are complete and generalizable w.r.t. how the community uses databases for multi-component calculations (i.e. that they fit in the scope of the format) • new models or parameters need to have reference implementations, a reference publication (?), and accompanying documentation Expected challenges • Adoption by software tools - need a strong pitch on the value-add. • Exposing to database and software consumers whether the model used in a database is compatible with the software they are using. Also, the mathematical expression compatibility, like non-integer exponents in TC. • Are there models where the same parameter has different meaning and using parameters? Maybe like IHJ and Xiong magnetic models. Or different ways to parameterize a UNIQUAC model. • Designing a format flexible enough to describe the Calphad models of the future. In particular, to not paint ourselves into a corner where every model has to be CEF-like (either a direct CEF or expressible as a CEF model)

[richardotis]

I recommend a vendor-oriented approach where you have Calphad package developers and key stakeholders like GTT and QuesTek form a consensus and jointly maintain a specification/schema via standing committee. NIST in the US is very good at facilitating these kinds of discussions, if two criteria are met: (a) all the key parties already agree to participate in the activity; (b) there is already a draft specification that is 80%+ agreed to.

Importantly, I think you will already need to achieve a degree of adoption before you attempt to standardize anything. The timing is really important as if you try too early, your committee won't maintain momentum to complete the task, but if you wait too late you will lose control of the file format and you will start to see diverging dialects of the same format.