[Chaoss-software] [Meeting item] Future events where we plan to participate

Sean Goggins s at goggins.com
Thu Oct 19 21:19:16 UTC 2017


Daniel & Jesus:

Apologies for any twisting that was inconsistent with what you meant. I be more exact with quotes in the future. 

A few more comments inline. 


> On Oct 19, 2017, at 3:34 PM, D M German <dmg at turingmachine.org <mailto:dmg at turingmachine.org>> wrote:
> 
> Sean Goggins twisted the bytes to say:
> 
> Sean> Hi All, 
> Sean> I appreciate Jesus’s shaping of our groups discourse. And also Daniel’s observation that “chaoss” has nothing to
> Sean> show. And Jesus’s subsequent observation that we have 3 projects, including his and Daniel’s, in the CHAOSS GitHub Repo.
> 
> Sean> A few items from my point of view:
> Sean> 1. Making metrics visible and useful is more than loading software in a repo and continuing to invest. We need a
> Sean> conceptual roadmap articulated.
> Sean> 2. Before we do that I think we try a few things.  I like the metrics committees idea of putting together 3-7 “activity
> Sean> metrics” in the various implementations of CHAOSS.
> Sean> 3. Having a common place to discuss what different metrics mean and then operationalizing them in software against
> Sean> projects with different structures and social technologies will enable the advancement of metrics with greater
> Sean> potential. I think getting that conversation started is an accomplishment. Keeping it going and engaging developers in
> Sean> the work of software construction around those metrics is an additional challenge.
> 

This section is a super helpful and beautifully concise synopsis! Thank you! 

> i agree. I think there are three stages with respect to adopting a
> metric:
> 
> 1. A definition (so it can be computed)

What are your thoughts on how the definitions are presently expressed by the metrics committee. For example: 

https://github.com/chaoss/metrics/blob/master/activity-metrics/contribution-acceptance.md <https://github.com/chaoss/metrics/blob/master/activity-metrics/contribution-acceptance.md>

The definitions are expressed at the “activity metric” level for the most part right now.  This is the most granular metric building block in the conversations we have had to date. 


> 2. A rational of why it is useful (evidence?)

Presently the rationale’s are most clearly expressed (IMHO) in the rationales underlying each metric category, which is currently a “bucket” for metrics.  I suspect there will be intermediate aggregations of metrics in between “activity metrics” and “metric categories” in the near future. 

https://github.com/chaoss/metrics/blob/master/2_Growth-Maturity-Decline.md <https://github.com/chaoss/metrics/blob/master/2_Growth-Maturity-Decline.md>
> 3. An implementation of the computation of the metric.
>   - algorithm, and
>   - implementation

Some of the algorithm is expressed as SQL against GHTorrent in the “activity metrics” definitions. But these are basic “counting type” metrics. Once we start to try and distill a set of metrics down into something more easily digested, I think there will be more sophisticated algorithms. 

I think by algorithm you mean an abstract representation of implementation. In which case we do not precisely have that. I think SQL against a known data structure is probably at some uncomfortable place in between algorithm and implementation. It has the advantage of clarity and precision across software and metrics communities, which is probably how it came to be…. but we can ask for what we want in terms of expression I think. 

> 
> I want to highlight that one major challenge of the CHAOSS is that it
> confounds metrics with presentation of those metrics. Computing metrics
> is one thing, presenting them is another (usually way more expensive
> than the former). Jesus can probably elaborate on his experience doing
> so.

This is a great point!  How might we do this? Do you see both computing and presentation as part of the software committee’s charge (I do, but I am one person). 

> 
> My view is that we should precisely and clearly separate these two
> aspects (computation of the metric vs presentation of the results).
> 

I agree that we need to precisely and clearly separate them. One challenge will be getting feedback from the metrics committee on metrics that do not include a presentation component, or only a very rudimentary one. 

It seems that it may also be important to separate concrete data sources from the implementation of metrics in algorithms and implementations; that data mapping and reshaping are also separate activities. In this case, I think they are a related and vital consideration, but not central to our mission.  They are central to ultimate success, but generally I think a more local challenge. 

> 
> --
> Daniel M. German                  "Space is really empty"
>                                   Ed Stone. Science-team leader, Voyager.
> http://turingmachine.org/ <http://turingmachine.org/>
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxfoundation.org/mailman/private/chaoss-software/attachments/20171019/84f10542/attachment.html>


More information about the Chaoss-software mailing list