We have made the CHAOSS community a vibrant place of activity that brings together diverse people from across the open source ecosystem who are interested in understanding, measuring, and analyzing open source community health. And we are now expanding our community in one more way
With CHAOSScast, the CHAOSS community is growing even further!
Dawn Foster – When Pivotal was recently acquired by VMware, I joined VMware’s Open Source Program Office to lead the open source community strategy efforts. As an active CHAOSS community member, one of the first things I did while I was building the strategy was to start gathering metrics so that I could better understand the health of our current open source projects while also understanding where we could improve.
When I talk to people who tried to install GrimoireLab, I get one consistent answer. It is difficult and our GrimoireLab tutorial is too complicated. I believe this status quo is hurting the adoption of GrimoireLab software and CHAOSS metrics. This blog post is about how to make it easier for anyone to start using GrimoireLab.
A contributed article on The New Stack details how the CHAOSS D&I Working Group got started and evolved. Georg Link and Sarah Conway take a close look at the working group’s history and capture insights that are only known to those who were part of the evolution. The article outline is:
Back in October, my colleague John Hawley and I reflected on our visit to last year’s U.S. CHAOSScon where we gave a talk on “The Pains and Tribulations of Finding Data.” At the end of that post, we mentioned learning more at the conference about Grimoire Lab’s Perceval tool for tracking data from multiple open source projects on a single dashboard. That opportunity helped me develop the work that was the subject of a talk I gave at the recent CHAOSScon Europe 2019.
Currently, GrimoireLab allows to produce analytics with data extracted from more than 30 tools related with contributing to Open Source development such as version control systems, issue trackers and forums. Despite the large set of metrics available in GrimoireLab, none of them relies on information extracted from source code, thus limiting the end-users to benefit of a wider spectrum of software development data.
The GMD Working Group is one of the CHAOSS working groups, tasked with defining useful metrics relevant for the analysis of software development projects from the point of view of
GMD (growth-maturity-decline). It also works in the areas of risk and value. For all of them, we’re intending to follow the same process to produce metrics, similar to what other CHAOSS working groups are doing. This post describes this process, that we have recently
completed for the first metric (many others should follow during the next weeks).
Community managers take a variety of perspectives, depending on where their communities are in the lifecycle of growth, maturity, and decline. This is an evolving report of what we are learning from community managers, some of whom we are working with on live experiments with a CHAOSS project prototyping software tool called Augur (http://www.github.com/CHAOSS/augur). At this point, we are paying particular focus to how community managers consume metrics and how the presentation of open source software health and sustainability metrics could make them more and in some cases less useful for doing their jobs.
Open communities lack a shared language to talk about metrics and share best practices. Metrics are aggregate information that summarise raw data into a single number, stripping away any context of data. Pedagogical metric displays are an idea for metrics that include an explanation and educates the user on how to interpret the metric. Metrics are inherently biased and can lead to discrimination. Many problems brought up during the MozFest session are worked on in the CHAOSS project.