# Improving PR Throughput and Contributor Experience in OpenELIS

**URL:** <https://talk.openelis-global.org/t/improving-pr-throughput-and-contributor-experience-in-openelis/2277>\
**Category:** Uncategorized\
**Created:** [April 14, 2026, 9:54pm UTC](https://talk.openelis-global.org/t/improving-pr-throughput-and-contributor-experience-in-openelis/2277 "2026-04-14T21:54:51Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rohan\_Bhalerao](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/rohan_bhalerao/32/1069_2.png) [@Rohan\_Bhalerao](https://talk.openelis-global.org/u/Rohan_Bhalerao)\
**Post date:** [April 14, 2026, 9:54pm UTC](https://talk.openelis-global.org/t/improving-pr-throughput-and-contributor-experience-in-openelis/2277/1 "2026-04-14T21:54:51Z")

</div>

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

```auto
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.