Rename Pull Requests to Push Requests (Or standardise on Merge Request)

[0x73746F66]

Select Topic Area

Product Feedback

Body

Real title: Why Upstream is Failing and How We Can Fix It

Clickbait title aside, yes this has a GitLab reference, please ignore that in the discussion (I know you won't)..
But what we’re really talking about are two key issues leading to a systemic problem in open source software (OSS).

The problem is the lack of features and fixes being pushed upstream. We’ve probably seen the stats a few different wasy: a few hundred projects get contributions from downstream, while countless others don't, millions of projects may survive and thrive if this dynamic changed. We know the situation is dire, and the users, whom we claim to prioritise, suffer the most.

So, what are the two key issues here?

1. Downstream incentives are nearly zero. This is harder to address but easy to avoid. (I mean intentional avoidance as a strategy, we are already avoiding due to less smart reasons)
2. Forks’ control over upstream benefits, is backwards. This is easy to fix by addressing the avoidance of first issue.

Brace yourselves for some hard truths.

OSS Maintainers Don’t Understand Git PR

Have you ever seen a Pull Request created by a major project like React or Spring? The key term here is created a "Pull" Request, not downstream creating a "Push" Request. Yet, open source maintainers often operate under the assumption that downstream improvements must justify why they should be included upstream in a PR. This mindset is detrimental to the community and puts downstream contributors at a disadvantage.

It’s called a "Pull" Request for a reason.

As a maintainer, you care about your project more than anyone else. So why do you expect others to push changes to you? Shouldn't you be pulling improvements from forks? Do the upstream maintainers not want to Pull feature up? I think they do but Github UX is making the situation a "too hard basket" thing for them..

The Solution: Rethink the PR Process

Maintainers, you should be actively seeking out and pulling valuable features and fixes from downstream forks. If you genuinely care about your project, why wait for others to push improvements to you?

Here’s how we can make this process better:

1. (for maintainers) Adopt a Pull Mentality:

   • Proactively look for useful changes in downstream forks.
   • Open a PULL REQUEST to bring these changes upstream.

2. (for GitHub) Enhance GitHub’s Fork Experience:

   • Provide code owners with a private enhanced view of forks.
   • Offer a PR experience that highlights potential downstream contributions.
   • Implement health scores and prioritization tools to identify valuable code (reason for private view).

Call to Action

Downstream projects are often content to continue using their forks without contributing back, due to a lack of incentives. It’s time to change this dynamic. By adopting a pull-first mentality and improving the tools available to maintainers, we can ensure that more features and fixes make their way upstream, benefiting the entire community.

GitHub, step up and enhance the fork experience to make this vision a reality. It’s time to pull our weight and truly prioritize the users we claim to serve.

Let's start using the term "Push Request" so the message get's out there