Improving PR Throughput and Contributor Experience in OpenELIS

1

Hi all,

I wanted to share some observations and a potential direction for improving PR flow in OpenELIS.

This idea was triggered during last Thursday’s discussion when @pmanko mentioned that PR handling and review cycles are currently a blocker. After that, I started going through PRs one by one just to understand what’s actually happening.

Patterns I Observed

After spending some time digging into PRs, a few patterns started repeating:

  • Reviews tend to happen in bursts, not continuously

  • Review responsibility is concentrated among a small number of maintainers

  • Many PRs remain idle despite being ready for review or merge

  • Long-lived PRs often end up in merge conflict loops

  • Contributors are sometimes not available by the time feedback comes in

  • Larger PRs become harder to review as they age

At one point I tried to look at this more top-down and match these patterns with common open-source scaling issues I’ve seen before. Honestly, I wasn’t even sure if I was overthinking it at first, but the funny part was that instead of spotting just one or two usual suspects, it felt like the whole checklist showed up together — like they all decided to attend the same meeting for once.

That’s not really a negative thing, it just shows that the project is at a stage where process and tooling need to catch up with growth.

Approach 1: Extending GitHub Actions

Since OpenELIS already uses GitHub Actions and labeling, the first idea was to improve that layer:

  • Better labeling (size, type, priority)

  • Auto-assign reviewers based on labels

  • Smarter stale handling instead of fixed timers

  • “Ready-to-merge” tagging for low-risk PRs

This would definitely improve things to some extent.

However, thinking a bit deeper, this approach has clear limitations:

  • GitHub Actions are rule-based, not context-aware

  • They don’t handle reviewer load balancing

  • They can’t prioritize PRs dynamically

  • They don’t address the burst-review behavior

  • Existing automation already gives signals, but doesn’t really drive decisions

So this improves visibility, but not the underlying flow.

Approach 2: PRFlow — Intelligent PR Lifecycle Management

Instead of adding more rules inside GitHub, the idea is to introduce a lightweight external layer that manages PR flow more intelligently.

Core Idea

A small service that works alongside GitHub and:

  • Understands PR context

  • Tracks lifecycle state

  • Makes decisions on assignment, prioritization, and nudging

High-Level Architecture

GitHub PR Events → Webhook / Action → PRFlow Service → Decision Engine → GitHub API (labels, comments, assignments)

Not completely sure yet how tightly this would integrate (pure webhook vs hybrid with actions), but that can be figured out during implementation.

Key Components

1. PR Classification Engine

Classifies PRs based on:

  • Title

  • Description

  • Files changed

Output includes:

  • Type (bug, feature, test)

  • Area (backend, frontend)

  • Size (small, medium, large)

  • Risk level

2. Reviewer Assignment Engine

Instead of static assignment:

  • Map PRs to a reviewer pool

  • Consider recent activity and load

  • Assign dynamically

This directly helps reduce the reviewer bottleneck.

3. Priority Scoring Engine

Each PR gets a score based on:

  • Age

  • Size

  • Activity

  • Risk

This helps surface:

  • Older PRs that are being ignored

  • Smaller PRs that can be merged quickly

4. Lifecycle State Tracking

Each PR moves through states such as:

  • awaiting-review

  • awaiting-author

  • stale-risk

  • ready-to-merge

5. Action Engine

This is where actual behavior changes:

  • Notify reviewers when PRs are waiting

  • Notify contributors when action is needed

  • Highlight low-risk PRs ready for merge

  • Handle stale PRs differently based on context

  • Detect merge conflicts early and prompt rebase

Expected Impact

  • More consistent review flow

  • Reduced backlog

  • Better visibility into pending work

  • Improved contributor experience

  • Reduced load on maintainers

Open Questions

  • How should this integrate with existing GitHub Actions?

  • Should this remain lightweight or evolve further?

  • How much automation is appropriate?

Next Step

If this direction looks reasonable, I can start working on a small prototype to validate the idea.

Would appreciate any feedback before moving forward.

1 Like