Research project on how FOSS project sustainability is affected by mismatched upstream/downstream conceptualizations
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

2.7 KiB

Synthesized list of tensions

  1. Tensions around attention management expectations for communications
    1. Expectations of whether communication from upstream to downstream should happen: the expectation that users should be able to maintain an uninterrupted focus on their own work (encapsulation) vs. the expectation that users should have an ongoing awareness of happenings upstream (non-encapsulation)
    2. Expectations of who is responsible for communicating information from upstream to downstream: the expectation that it is a maintainer’s responsibility to proactively ensure that information reaches users through whatever means are needed (encapsulation) vs. the expectation that it is a user’s responsibility to find, monitor, and filter their own information streams and give feedback to upstream maintainers as needed (non-encapsulation)
    3. Expectations regarding social tradeoffs in communication types: the efficient but depersonalized character of automated asynchronous convenience (encapsulation) vs the community boding that occurs between maintainers and users when interaction is required (non-encapsulation)
  2. Tensions around degree of cultural intervention
    1. Expectations that project comms are intentionally designed/structured for maintainer team, (encap) or the broader community (non-encap)
    2. Expectation that signup, etc. should be automated equality (encap) vs. human gatekeeping flexibility (non-encap)
    3. Expectation that power differentials (in either direction) are important and should be made visible and responded to (non-encap) vs rendering them “inconsequential” (encap)
  3. Tensions around designing for maintainer learning
    1. Existing knowledge to hit the ground running vs. onboarding/training new contributors
    2. Designing to enable long term (non-encap) vs. short term (encap) contributions
    3. Encapsulation as hospitality (if we’re thoughtful about hiding unnecessary details, this will be friendlier to use), vs. transparency for learnability (if people can see how things work, they can learn how things work)
    4. Conversely, encapsulation for learnability (if we hide complexity, learners can focus more on basic concepts) vs. transparency as hospitality (inviting people to see how things work).
  4. User privacy vs. maintainers having having data about usage so they can anticipate future needs
  5. Tensions around resource management, like the benefits of having solid financial infrastructure vs. the concerns over potential takeover or reprioritization of project goals and directions by corporate sponsors

Note that this is partially taken from rough ideas generated at