A smart way to prioritize tasks on open source and side projects

TL;DR; Keypup prioritization rules can help you better monitor your open source and side projects by automatically prioritizing issues and pull requests needing a review or requiring an action. It's all configurable to suit  your own workflows.

So  you manage private projects using scrum or kanban? Properly organize your issues and have them assigned to your team members? That's great! Well done on organizing the team!

But what about these open source projects you maintain on the side? What about these small private projects that do not get updated often and tend to be managed outside of the product development flow?

It's not always easy to be on top of side projects. Issues and pull requests get raised but don't always get noticed, the backlog gets filled with stale or inactive issues over time. Maintaining side projects takes time and we don't alway have it.

If you find yourself thinking that you should give more love to these projects then we have a solution for you:  prioritization rules.

Prioritization rules are used to automatically prioritize items in your Keypup priority inbox based on matching conditions. They can also be used to create reminders.

So let's explore some common use cases and see how Keypup can help.

Use case 1: I do not notice when someone raises an issue on my open source repos

When an issue gets raised on a repo, GitHub and GitLab will send you an email notification. If you are like me, you will likely miss out on these due to the volume of emails you receive every day.

Whenever someone raises an issue on one of our open source projects - e.g. cloudtasker or cloudenvoy - I want to review and label it. That's my way of acknowledging the issue and structuring the backlog.

Relying on emails is not possible for me - so let's go ahead and create a prioritization rule in Keypup to update my priority inbox when a new issue is raised.

You can access your prioritization rules from your profile menu at the bottom left of the screen.

Prioritization Rules Menu

From there you can click on New Rule and create a prioritization rule that looks like this:

Prioritization Rule for unlabelled open source issues

With this rule in place, next time someone raises an issue you will see something like this in your priority inbox.

Prioritized Open Source Issue

Easy enough right?

Let's explain the rule  step by step. You'll see it's easy to adapt it to your own requirements.

  • State = open: We only want to prioritize open issues.
  • Type = issue: For this rule we want to exclude pull requests
  • Labels length = 0: The labels field is a text array. We want to prioritize all issues which haven't been assigned a label yet (untriaged issues).
  • Created at > 168 hours ago (7 days ago): I don't want issues to stay in my inbox forever. If I haven't labelled the issue after 7 days, there must be a good reason for it. Putting a time condition on the created at timestamp ensures your inbox doesn't get polluted with items you are not going to look at. Note that you could use "updated at" instead - this would re-prioritize the issue after 7 days if someone updates it (description update, comment etc.).
  • Project: We use a OR group to match our two open source projects.

Alright that's a good start. Now let's see another use case.

Use case 2: Reviewers don't get assigned on pull requests

Only owners and collaborators can assign reviewers on pull requests.

Therefore if someone opens a pull request on an open source project and you don't notice it, it's likely to remain stuck there for a while.

Fortunately we can setup a prioritization rule - similar to the previous one - to let us know when a pull request needs a reviewer assigned.

Prioritization Rule for pull requests requiring a reviewer

With this rule in place you should see the following kind of item in your inbox next time someone opens a pull request on your open source project:

Prioritized Open Source Pull Request

Here is the rule explained step by step:

  • State = open: We only want to prioritize open pull requests.
  • Type = pull_request: For this rule we want pull requests only
  • Reviewers length = 0: The reviewers field is a text array. We want to prioritize all pull requests which do not have a reviewer yet. Once a reviewer is assigned, Keypup will automatically take care of prioritizing the pull request in the reviewers' priority inbox.
  • Created at >= 168 hours ago (7 days ago): Same as before, we do not want items hanging in the inbox forever. Putting a time expiration for actioning items is good practice.
  • Mergeability = mergeable: Ensures that we do not waste time assigning a reviewer if the pull request is conflicting. Authors should fix their pull request first.
  • Build status green or none: Again, this is the responsibility of the author to fix the build if broken. The rule will still work if you do not have a build in place thanks to the none condition.
  • Project: We use a OR group to match our two open source projects.

If you notice that contributors open their pull requests way before it is ready to be reviewed, you could also add condition like Updated at <= 72h ago (3 days ago). This will force a cooldown period of 3 days of inactivity (= no more work is to be done) on the PR before it gets prioritized in your inbox.

Use case 3: My backlog is full of stale and inactive issues

It's a bit annoying when open source projects get cluttered with stale issues.

Reviewing the pipe of what can be done only to discover that such or such issue has been fixed or is no longer relevant is a bit of a pain.

We, maintainers, should try to remain diligent when managing the backlog of open issues.

The following rule automatically prioritizes stale issues reaching 3 months of inactivity and does so, for three days. This gives enough time to review the issue and decide whether it should be kept or closed.

Prioritization Rule for stale issues requiring review/closing

With this rule in place any stale issue will be prioritized for three days:

Prioritized Stale Issue

Here is the rule explained step by step:

  • State = open: We only want to prioritize open issue.
  • Type = issue: We're only interested in issues for this rule
  • Updated at <= 2160 hours ago (90 days ago): Any issues which hasn't been updated within the last 90 days will be selected (= stale issue).
  • Updated at >= 2232 hours ago (93 days ago): Excludes issues updated more than 93 days ago. The two "updated at" conditions create a range filter ensuring that stale issues are only prioritized for 3 days. The time range approach is a nice way of creating temporary reminders.
  • Project: We use a OR group to match our two open source projects.

Now to further improve this rule you could:

  • Further refine the updated at range or the inactivity duration
  • Add conditions on labels (e.g. exclude "roadmap" labels)
  • Enforce that there are no assignees on the issue
  • Enforce that the issue recommended action is different from wait for implementation. The action wait for implementation means an open pull request is resolving the issue.
  • Create a second prioritization rule matching issues on one year inactivity so as to get a second reminder in case you snoozed the first one :)

Wrapping up

If you spend a fair amount of time reviewing the status of your projects, or - on the contrary - feel bad because you don't do it enough, then prioritization rules can definitely help you automate these review tasks.

Prioritization rules are used to automatically prioritize items in your inbox based on matching conditions. Combined with time ranges (see use case 3) they can also be used to create reminders.

Adding prioritization rules to your Keypup account is like training a personal assistant to remind you of things. The more you add rules the smarter the engine gets.

And yes - we do support regex matching on PR/issue title and body, so you can develop very powerful and fine-grained rules if you want to ;)

About us

Keypup is on a mission to help developers and tech leads work better with each others on development projects. Our platform automatically centralizes, prioritizes and assigns people and actions on issues and pull requests to optimize your development flow.

Don't get lost because you have to juggle with twenty pull requests across five development projects. We'll clean and organize that for you to ensure a smooth landing.

You may also like reading: