Limit Active GitHub Issues Per User

by Henrik Larsen 36 views

Hey guys! Today, we're diving deep into a really cool automation strategy using GitHub Actions: limiting the number of active issues a user can handle at once. This is a fantastic way to prevent bottlenecks, ensure a balanced workload, and keep your team's productivity soaring. Let's get started!

Goal: Preventing Overload

The main goal here is to prevent users from getting swamped with too many tasks simultaneously. By setting a limit on active issues, we can help team members focus, deliver high-quality work, and avoid burnout. But here's the catch: we don't want to block anyone who's actively involved in testing or reviewing. Those stages are crucial, and we want to keep the momentum going.

Think of it this way: imagine a scenario where Alice is assigned one active issue and then takes on another – all good! Bob, on the other hand, is juggling two active issues and tries to grab a third. That's where the limit kicks in. But Charlie, who has two issues in testing, can take on another without a problem. Smart, right?

Why is This Important?

  • Balanced Workload: Nobody wants to be overloaded. Limiting active issues ensures a fair distribution of tasks across the team.
  • Focus and Productivity: When team members aren't spread too thin, they can concentrate better and produce higher-quality work.
  • Reduced Bottlenecks: By preventing individuals from hoarding tasks, we can keep the workflow moving smoothly.
  • Happy Developers: Overwhelmed developers are unhappy developers. This helps ensure everyone is working at a sustainable pace.

Breaking Down the Behavior

So, how does this magic actually happen? Here’s a breakdown:

  1. Trigger: We kick things off with the issues.assigned event. This means the action springs to life whenever someone is assigned to an issue.
  2. Counting Issues: The first step is to count how many issues the user is currently assigned to.
  3. Filtering Issues: Now, we need to filter out the issues that are still considered "active." This means excluding any issues that have already reached the testing or review stage. We can identify these based on labels (e.g., testing, review) or even project columns if you're using GitHub Projects.
  4. Comparing to the Limit: Next, we compare the number of active issues to a predefined limit. This limit can be set globally for the entire team or tailored to specific teams (e.g., design, backend).
  5. Taking Action: If the user exceeds the limit, we automatically unassign them from the newly assigned issue and leave a comment explaining why.

This comment serves as a gentle nudge, letting the user know about the limit and the reason for the unassignment. It's all about transparency and clear communication.

Technical Deep Dive

To make this happen, we'll be leveraging the power of the GitHub REST API. This API allows us to query issues assigned to a user and, optionally, the GitHub Projects API if we need column-based filtering. Here’s a more technical look at the logic:

  1. Filter Out Issues: We start by filtering out any issues that are already marked as being in review or testing. This is crucial for allowing users to continue working on those critical phases.
  2. Count Active Issues: Next, we count the remaining active issues – the ones that are not in testing or review.
  3. Reject Assignment (If Over Threshold): If the count exceeds the predefined limit, we reject the assignment. This is where the unassignment and comment come into play.

Rules: Configuration is Key

One of the coolest things about this approach is its flexibility. We can configure the rules in a separate file (e.g., configs/limits.json) to make it easy to manage and update. This file might look something like this:

{
  "defaultLimit": 2,
  "teamLimits": {
    "design": 1,
    "backend": 3
  },
  "allowedReviewLabels": ["testing", "review"]
}

Let's break down what these configurations mean:

  • defaultLimit: This sets the default limit for the number of active issues a user can have across all teams. In this example, it's set to 2.
  • teamLimits: This allows you to define specific limits for different teams. For instance, the design team might have a limit of 1, while the backend team has a limit of 3. This is super useful for accommodating varying team sizes and workflows.
  • allowedReviewLabels: This is an array of labels that indicate an issue is in the review or testing phase. Issues with these labels won't be counted towards the active issue limit.

Customizing Limits for Teams

Having team-specific limits is a game-changer. Maybe your design team works on more complex, time-consuming tasks, while your backend team handles a higher volume of smaller issues. Tailoring the limits to each team ensures the rules are fair and effective.

Imagine Dave, who's on the design team (limit = 1). If Dave tries to take on a second active issue, bam! Rejected, due to the team-specific cap. This level of granularity makes the system much more adaptable.

Examples: Putting It All Together

Let’s walk through a few examples to solidify how this works:

  • Scenario 1: Alice is Assigned to 1 Active Issue, Takes a Second → ✅ Allowed Alice is cruising along, perfectly within the limit.
  • Scenario 2: Bob is Already Assigned to 2 Active Issues, Takes a Third → ❌ Unassigned + Comment Bob’s hit the default limit. The action kicks in, unassigns him, and leaves a friendly reminder.
  • Scenario 3: Charlie Has 2 Issues, Both Marked testing, Takes One More → ✅ Allowed Charlie’s all good! Those testing labels mean these issues don't count toward the limit.
  • Scenario 4: Dave (Team: Design, Limit = 1) Tries to Take Second Active Issue → ❌ Rejected Due to Team-Specific Cap Dave’s team-specific limit steps in, preventing him from taking on too much.

These examples highlight how the system adapts to different situations, ensuring the rules are applied consistently and fairly.

Technical Details: Making It Happen with GitHub Actions

Alright, let's get a little more technical and talk about how we can actually implement this using GitHub Actions. GitHub Actions is a powerful automation tool that lets you run workflows in response to events in your GitHub repository. In our case, we'll be using it to monitor issue assignments and enforce our active issue limits.

Trigger: issues.assigned

As mentioned earlier, our workflow will be triggered by the issues.assigned event. This event fires whenever someone is assigned to an issue, making it the perfect hook for our automation.

APIs: GitHub REST API and GitHub Projects API (Optional)

We'll primarily be using the GitHub REST API to interact with issues. This API allows us to:

  • Query issues assigned to a user: We need this to count the number of active issues a user is currently working on.
  • Unassign a user from an issue: If a user exceeds their limit, we'll use this to automatically unassign them.
  • Leave a comment on an issue: We'll use this to explain why a user was unassigned.

Optionally, if you're using GitHub Projects and want to filter issues based on their column, you can also use the GitHub Projects API. This gives you even more flexibility in defining what counts as an