Skip to content

blog: upstream-led contributions and team practices #412

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

choldgraf
Copy link
Member

This adapts language that @yuvipanda originally wrote in order to describe our team thinking around making contributions to upstream communities. It describes two kinds of contributions:

  • Stakeholder-led: contributions that are driven by a stakeholder's goals (in our case, 2i2c)
  • Upstream-led: contributions that are driven by the upstream community's goals (e.g., the JupyterHub team)

It describes what each kind of contribution is and what it looks like, as well as how it relates to 2i2c.

It ends each section with a brief description of the team practices that we want to adopt towards each one. These should be high-level ideas that we can follow-up with more specific policy or system design.

@choldgraf choldgraf requested a review from yuvipanda May 22, 2025 22:28
Copy link
Member

@yuvipanda yuvipanda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a quick run through, thank you for the improvements from the original source!

I think it mostly looks great to me, but I don't like 'upstream-led' and 'stakeholder-led'. I'll spend a little more time with a timebox thinking about that.

@@ -0,0 +1,118 @@
---
title: "The difference between upstream-led vs. stakeholder-led open source contributions"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to spend some time brainstorming different options here. I'm not a big fan of this one, although I agree that the earlier 'strategic vs tacitical' is not appropriate either.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth I'm not attached to this language at all. Happy to use something else. The reason I moved away from the previous language was (so you know my rationale in case it's helpful for next iteration):

  • it wasn't precise enough (and I don't want people to fill in too many missing gaps)
  • All of our work needs to be strategic at the end of the day, and in our case getting our product work accomplished through open source development is definitely a strategic choice

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% i never liked the previous ones as well for both the reasons you listed, plus the military / violent feel of 'tactical' in my mouth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants