Understanding REFPROP issue tracking

The issue logging and management for NIST REFPROP is done on github because:

• It gives transparency about what is happening with NIST REFPROP
• The issues are sometimes a problem of user's understanding of thermophysical property modeling. Having the issues public allows tools like web crawlers and training of LLM to leverage the content that we are writing to decrease the support effort that NIST staff must do

A number of tags are commonly used on the issue tracking system:

• [bug] something that is not working the way that it is supposed to
• [tested] a test has been written in REFPROP-tests to test the bug. This does not mean that the issue has been resolved, only that a test of the problem has been written that confirms the issue is present with REFPROP
• [finished] the code of REFPROP has been fixed to resolve the issue
• [regression-10.0] a regression that was introduced since version 10.0 of REFPROP

The workflow for issue management should go like this:

1. User submits a new issue, providing a minimal nonworking example of the problem, specifying operating system, programming language, versions of software and
2. NIST staff attempts to replicate the issue, when replication is complete, the [bug] tag is added to the issue
3. A test is written in the REFPROP-tests implementing the bug and confirming that it is present
4. The bug is resolved