To release or not to release?

[GeorgLink]

Posted to mailing list:

• What does version mean for CHAOSS metrics?

  • What should people understand a version to be?
  • Does it mean a metric will not change? - Probably not, because the metrics definition is a living document.
  • Does it mean that we want implementors to focus on the released version, rather than the most current version? - Probably not, because implementors should implement the latest changes and we update the definition to reflect any challenges (which would not be documented and fixed in the released version).

• Issues with version:

  • people accidentally implement outdated version without realizing it
  • can cause a distance between our definitions and implementations
  • can cause confusion in users when metrics definitions change between versions (what version am I on and what does this mean?)
  • Software versions are becoming less important due to frequent updates, and our metrics should be reflecting this new reality.

• benefit of versions

  • Gives us a reason to release an announcement (public relations)

[germonprez]

@GeorgLink, thanks for the update on the weekly call. Sorry I couldn't be there.

It sounds like the angle is for 'no versioning' of the metrics. I think this is a clearer approach and think this is a good idea. We will need to make sure we effectively communicate that the metrics are an evolving target.

Thoughts on how we might handle the generation of reports in, for example, the D&I Workgroup? Particularly, a report would be based on a set of metrics, and software to accommodate those metrics. As metrics evolve, the associated software will have to evolve as well. Do we have to version the reports? Indicating the 'timestamp' of the metrics and software used.

[germonprez]

I suggest that we close this. As far as we're concerned, we have the hashes that mark the Categories (D&I, GMD, Risk, and Value) by date. To me this is very sufficient and quite clear.