This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
oss-health-metrics:minutes:2017-08-01-meeting [2017/08/07 20:44] GeorgLink [Other??] |
oss-health-metrics:minutes:2017-08-01-meeting [2017/09/10 00:02] (current) GeorgLink Page permanently moved |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Meeting Minutes 2017-08-01 ====== | ====== Meeting Minutes 2017-08-01 ====== | ||
- | ===== Governance Update ===== | ||
- | |||
- | * Governance document mostly done | ||
- | * Mozilla and Eclipse plan on joining CHAOSS | ||
- | * We are still trying to connect with Wikimedia | ||
- | * We are also talking to industry members | ||
- | * What is the process for declaring a metric official? | ||
- | * What process do we want to get input? | ||
- | * Currently, the four metrics are the ones we have heard the most | ||
- | * We do not have a formal process at this point | ||
- | * Do we want to have versioning? | ||
- | * No versioning would signal that metrics are constantly changing and differently understood in different contexts | ||
- | * Metrics are not software - does versioning make sense? | ||
- | * If there is a proposal to add a metric group, then we might have a discussion or process to add it | ||
- | * For reference implementations, they need to be able to work from a stable metrics version | ||
- | * We could establish a stable version for implementers and continue working on the metrics. Similar to stable and developer branches | ||
- | * The stable version that gets implemented will lead to feedback that informs the future development | ||
- | * It would be good to have a stable version of the metrics specification for implementation | ||
- | * How do we get consensus for establishing a stable metrics version? | ||
- | * That needs to be decided | ||
- | * Discussion will continue on the mailing list | ||
- | |||
- | ===== Open Source Summit NA Update on BoF session and additional break-out session ===== | ||
- | |||
- | * We have a BoF at the Open Source Summit North America | ||
- | * Monday, September 11 • 5:40pm - 6:20pm - http://sched.co/BCsP | ||
- | * Have another room for 2 hours the next day | ||
- | * Tuesday, September 12 • 2pm - 4pm | ||
- | * We will likely continue the conversation from the BoF | ||
- | * Open Source Summit Europe in Prague: We have a room for 4 hours | ||
- | * Tuesday, October 24 • 9am - 1pm | ||
- | * Possibly start with overview of CHAOSS and then break-out session? | ||
- | * Topics to be decided. | ||
- | * See Ray's email: https://lists.linuxfoundation.org/pipermail/oss-health-metrics/2017-August/000063.html | ||
- | |||
- | ===== Other?? ===== | ||
- | |||
- | * How did the current four metrics come to be? | ||
- | * **Project Diversity and Inclusion** is a metric that many people expressed an interest in. For example, if three large corporate members drop out of the community within one week, that is a strong signal. Mozilla expressed interest in lining this metric up with their Internet Health report (https://internethealthreport.org/). | ||
- | * **Project Growth - Maturity - Decline** answers whether our community or project growing. This question is asked by board members and many people. However, it is a loaded question because the context determines how metrics are understood and what metrics are used. | ||
- | * **Project Risk** is useful for mergers and acquisitions between projects and for companies. To what extent does a project have good hygiene? This question is important to the Core Infrastructure Initiative. How safe is a project to use or are there hidden risks? With regards to licensing, this metric aligns with the work of the SPDX group. | ||
- | * **Project Position with OSS Ecosystem** is important because projects may be used by many projects downstream. The libraries.io project can show where a project sits within the ecosystem. How is a project used and what does it use? | ||
- | * Each of these metrics is a composite of smaller activity metrics | ||
- | * The choice of current metrics are opportunistic and when other metrics are suggested, we can discuss and add them | ||
- | * Important: the metrics have to derive value or they will not be used | ||
- | * Value is in the eye of the user: the context matters | ||
- | * The ecosystem has different actors: developers may have different choices what looks as a better developer environment; a user of the ecosystem may be more interested in the popularity and that it is actively maintained. What is indicative of health is a factor of purpose and use scenario | ||
- | * We have to talk to different stakeholders, like the Symphony Foundation, to establish ground truth | ||
- | * https://metrics.symphony.foundation - Bitergia dashboard for Symphony Foundation | ||
- | * Many good production metrics | ||
- | * No consumption metrics - difficult to obtain - Philosophy: growth starts with consumption | ||
- | * How is the current list of activity metrics build? | ||
- | * Several strategies informed the list: | ||
- | * Research and conversations with practitioners | ||
- | * The list is incomplete and suggestions are welcome | ||
- | * A missing metric is: Effect of gender diversity: effect of seniority on teams | ||
- | * The activity metrics can be a long list of metrics 'for metrics sake' | ||
- | * Not all metrics have to be used in value-oriented metrics | ||
- | * We may list all possible metrics and keep track of why it is not used or how it could be misused | ||
- | |||
- | ===== Attenance ===== | ||
- | |||
- | * Christian Cmehil-Warn | ||
- | * Derek Howard | ||
- | * Georg Link | ||
- | * Josianne Marsan | ||
- | * Kate Stewart | ||
- | * Matt Germonprez | ||
- | * Peter Monks | ||
- | * Ray Paik | ||
- | * Sean Goggins | ||
- | * Tom Mens | ||
+ | Page permanently moved to | ||
+ | [[chaoss:metrics:minutes:2017-08-01-meeting|/chaoss/metrics/2017-08-01-meeting]] |