Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
README.md
first-code-contributions.md
template.md

README.md

GMD Working group use cases

This directory is for describing use cases related to the use of GMD (growth-maturity-decline) metrics. The main aim of these use cases is to provide information on how people are using, or intending to use, GMD metrics.

The CHAOSS GMD working group has identified this kind of use cases as one of its key goals, so that we can define metrics that are useful in the real world.

What is a use case in this context?

A use case should show, in some specific aspect, one or more high level goals, that can be refined in questions, which could be answered with metrics.

If possible, the use case should identify some of the metrics that could lead to those answers, but that is not required in the first version of the use case (the CHAOSS community could later help to identify those metrics)

Who can propose a use case?

Anyone who can define high level goals that could be answered, even partially, with GMD metrics, can propose a use case. There is no requirement of being a regular contributor of the working group.

How can I propose a use case?

Open an issue in the repository for this GMD working group, with the title "Use case: XXX" (being XXX the name you want to give to the use case, usually related to the goal(s) it pursues).

In the description of the issue, write one or more high level goals of the use case (the kind of learnings or take aways that are pursued in the use case), and a list of the questions that could be relevant for reaching that goal.

If you are not familiar with GitHub issues, you can check the documentation about how to open a GitHub issue. If you find it could help, use an auxiliary document in Google Docs with the description of the use case, and link it from the isssue. In this case, a part of the comments could be in the form of comments in the Google Docs document.

How are use cases being discussed and eventually accepted?

Anyone can comment on the issue proposing a use case. Some regular contributor of the working group will try to summarize and facilitate the discussion, and at some point will either close the issue (if the consensus is that the use case is not relevant or appropriate), or will produce a pull request with the description of the use case as a file for this directory.

That pull request will be reviewed by regular contributors of the working group, and anyone else. Finally, based on the reviews, the use case will be finally approved or not.

Issues and pull requests can also be discussed during the regular meetings of the working group, and in the CHAOSS mailing list (remember to use the "[wg-gmd]" tag in the subject of the message).

Examples of goals and questions

Just to give an idea (until we have some use case approved, which could act as an example), a goal for a use case could be something like "Learning about external contributions to OSS projects promoted by my company".

Questions in this line could be like:

  • "How many external contributors we have?"
  • "Which part of the activity is done by external contributors?"
  • "Which ones are the key areas for external contributors?"
  • "In which roles are external contributors collaborating?"
  • "How is the onboarding process for external contributors?"

Blog series "Metrics in use"

All these use cases could be the basis for a blog post in the series "Metrics in use" in the CHAOSS blog.