Browse Source

update to oct 2019 status

master
Mel Chua GitHub 1 year ago
parent
commit
158bc4cca5
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 8 deletions
  1. +12
    -8
      README.md

+ 12
- 8
README.md View File

@@ -2,9 +2,9 @@

The Mismatches project is a research project on how mismatched conceptualizations between upstream maintainers and downstream users of a Free and Open Source (FOSS) digital infrastructure project interact to affect the community health and thus sustainability of such projects.

It is part of the [Ford/Sloan cohort on digital infrastructure research](https://www.fordfoundation.org/ideas/equals-change-blog/posts/announcing-13m-in-funding-for-digital-infrastructure-research/) and is based at [RIT](http://rit.edu). Steve Jacobs and Mel Chua lead the research team.
It is part of the [Ford/Sloan cohort on digital infrastructure research](https://www.fordfoundation.org/ideas/equals-change-blog/posts/announcing-13m-in-funding-for-digital-infrastructure-research/) and is based at [RIT](http://rit.edu). [Steve Jacobs](https://www.rit.edu/directory/sxjics-stephen-jacobs) and [Mel Chua](http://melchua.com) lead the research team.

This webpage is a placeholder that currently summarizes a broad overview of what we're trying to do; stay tuned for updates.
This webpage provides a current summary of what's going on. We are currently wrapping up our third and final interview rounds and preparing for an in-person analysis deep-dive in early November with consultants from our project community. For up-to-date access to interview transcripts and project files, see [our github repo](https://github.com/FOSSRIT/mismatches).

# Project summary

@@ -28,19 +28,19 @@ This project investigates how the diversity of conceptualizations both helps and

## What methods will you use to answer it?

We propose a narrative interview methodology with a publicly viewable dialogue structured over multiple rounds. Interviews will be situated within a critical FOSS infrastructure project - something that a lot of projects use, and that would be disruptive if it went down.
We are using narrative interview methodology with a publicly viewable dialogue structured over multiple rounds. Interviews will be situated within a critical FOSS infrastructure project - something that a lot of projects use, and that would be disruptive if it went down. In this case, [PyPI](https://pypi.org) was chosen as the project case study -- it is the package index for one of the most widely used programming languages in the world (as of 2019), and had disruptive outages until a recent rewrite specifically aimed at addressing the project's sustainability concerns.

We will interview both (A) maintainers of these widely used FOSS projects and (B) technical downstream users of the same regarding their conceptualizations of (1) how healthy FOSS communities work, (2) who is responsible for aspects of that health, and (3) the state of that particular FOSS project's community.
We are interviewing both (A) maintainers of PyPI and (B) technical downstream users of the same regarding their conceptualizations of (1) how healthy FOSS communities work, (2) who is responsible for aspects of that health, and (3) the state of that particular FOSS project's community. The entire research project design, including interview protocol, consent forms, recruitment text, etc. is available in [our github repo](https://github.com/FOSSRIT/mismatches).

Interview excerpts answering these questions will be circulated amongst participants in subsequent interview rounds, first within groups (maintainers see other maintainers' responses, downstreams see other downstreams' responses) and then across groups (maintainers see downstream responses, downstreams see maintainer responses). To foster public dialogue, transcript excerpts will be made available under an open license as the interviews progress, with participant consent.
Interview excerpts answering these questions are being circulated amongst participants in subsequent interview rounds, both within groups (maintainers see other maintainers' responses, downstreams see other downstreams' responses) and across groups (maintainers see downstream responses, downstreams see maintainer responses). To foster public dialogue, transcript excerpts will be made available under an open license as the interviews progress, with participant consent.

Transcripts will be analyzed for ontologies, or underlying conceptualizations of FOSS projects presupposed by interview narratives. Ontological shifts will be tracked as participants respond to each other. Analysis will also be public and open-licensed, giving the FOSS community an opportunity to see how research of this sort is done.
Transcripts will be analyzed for ontologies, or underlying conceptualizations of FOSS projects presupposed by interview narratives. Ontological shifts will be tracked as participants respond to each other. Analysis will also be public and open-licensed, giving the FOSS community an opportunity to see how research of this sort is done. Interim analytical notes are posted in [our github repo](https://github.com/FOSSRIT/mismatches) as they are created.

## What data or resources will you use to answer it?

This project relies on three sets of data/resources.

The first is the interview corpus with upstream and downstream developers that we will collect as part of the project. We expect to interview at least 3 upstream and 3 downstream (for a total of 6) developers for the target FOSS community.
The first and most important source is the interview corpus with upstream and downstream developers that we will collect as part of the project. We are interviewing 3 upstream and 3 downstream developers for the target FOSS infrastructure project, which is [PyPI](https://pypi.org). The raw data is being posted to [our github repo](https://github.com/FOSSRIT/mismatches) as these 6 narrators open-license their transcripts. They have consented to being publicly identified as part of our radically transparent research approach, and we would not be able to do this project without them -- thank you, Naomi Ceder, Terri Oda, Jackie Kazil, Nick Coghlan, Donald Stufft, and Ernest Durbin III!

The second is existing literature, both scholarly and non-scholarly (i.e. books, blogs, etc.) on FOSS community dynamics. These serve as sources of additional conceptualizations of FOSS communities as well as venues to engage in dialogues about them.

@@ -48,4 +48,8 @@ The third consists of analytics and metrics on software projects such as those r

## What is your vision of success?

We want to be able to identify these different conceptualizations and then identify and codify the mismatches in terms of how easy they are to address and what might be effective in resolving them. It may be that we are able to identify overall problem and challenge types within these efforts and then be able to provide “recipes” for them to achieve greater stability. It is our sense that these “recipes” will be in the areas of human communication, management, social engineering solutions vs. technological solutions; though there may be software tools around organization, scheduling etc that might be part of suggested best practices that emerge.
Our initial vision was to identify different conceptualizations of sustainability and being well-maintained, and then identify and codify any mismatches in terms of how easy they are to address and what might be effective in resolving them.

After collecting more than half the data and beginning analysis, we've found that the issue seems to not be _conflicting_ conceptualizations of sustainability and well-maintainedness, but rather _incomplete_ or _ill-defined_ ones. Furthermore, there seems to be something particular about _infrastructure_ projects as opposed to non-infrastructure software projects, and something particular about _community-driven_ projects (as many FOSS projects are) as opposed to _corporate-driven_ projects (which may have FOSS licenses, but are still backed by a corporate entity).

We are still planning to identify overall problem and challenge types within these efforts and then be able to provide “recipes” for them to achieve greater stability. We continue to sense that these “recipes” are in the areas of human communication, management, social engineering solutions vs. technological solutions. However, there may be software tools around organization, scheduling etc that might be part of suggested best practices that emerge.

Loading…
Cancel
Save