Finding Signal Through The Noise

As the main­tainer of Harper, I read through dozens of is­sues and pull re­quests per day and count­less more per week. There is a con­stant flood of new prob­lems to fix and new code to re­view. At times, it can get over­whelm­ing.

I’ve been work­ing re­cently to re­duce the amount of noise I en­counter when de­ter­min­ing what to work on. I’m shar­ing my find­ings here to help other novice main­tain­ers han­dle the tor­rent. Hope­fully, there are some ideas here that you find in­sight­ful.

When your open source pro­ject gets big enough, you in­evitably hit a point where the flow of bug re­ports or fea­ture re­quests ex­pands be­yond what you’re in­di­vid­u­ally able to fix or im­ple­ment. If you’re like Jeff Geerling, this might hap­pen when you find your­self main­tain­ing a larger num­ber of pro­jects. Ei­ther way, it’s clear that there will come a time where you need to start mak­ing hard de­ci­sions on how to spend your time.

Set A Policy

Jeff’s so­lu­tion, which I’ve adopted, is to set well-de­fined poli­cies for which is­sues are al­lowed to slip through the cracks.

The strat­egy is sim­ple in essence. The main­tainer, Geerling or I in this case, di­rectly ad­dresses is­sues and PRs which are im­por­tant to the ex­ist­ing func­tion­al­ity of the soft­ware first. New fea­tures or mi­nor bugs come sec­ond. Fea­ture re­quests that help a sin­gle per­son or a bug re­ports that ad­dress a rare edge case are of low­est pri­or­ity.

If an is­sue or pull re­quest can­not be ad­dressed within 30 days of its open­ing, it is marked stale. If an­other 30 days pass be­fore it be­comes ac­tive again, it is closed. Over time, unim­por­tant top­ics are cleared away, leav­ing only the ones crit­i­cal to the pro­jec­t’s mis­sion.

A pol­icy like this sets “no” as the de­fault and helps pre­vent run­away code qual­ity de­clines. I in­sti­tuted it on Monday. If it needs re­vi­sion, I’m open to com­ments and feed­back.

Harper’s False Positives

This pol­icy stands in the face of an al­most over­whelm­ing num­ber of is­sues re­lated to false-pos­i­tives in Harper’s al­go­rithm. Here’s a rep­re­sen­ta­tive ex­am­ple.

Since these false-pos­i­tive re­ports rep­re­sent such a sig­nif­i­cant plu­ral­ity of the is­sues on GitHub, I feel the need to han­dle them sep­a­rately from every­thing else. They’re usu­ally re­solved quickly but left open out of ne­glect. They’re triv­ial enough for me to fix, but not for me to fol­low-up. Mov­ing for­ward, if any­one needs to re­port an is­sue re­lated to a false-pos­i­tive, please do so here.

Develop a Sense of Importance

There is no al­go­rithm to de­ter­mine which is­sues or PRs are the most im­por­tant to a pro­jec­t’s suc­cess. Typ­i­cally, I’ll read through five or so, and pick the one that “feels” the most im­por­tant to work on. It’s of­ten a bal­ance of pri­or­i­tiz­ing time-sen­si­tive items, items that could re­sult in pub­lic­ity, and use­ful­ness to my per­sonal work. It’s hard to put it into words, which is why it must be de­vel­oped, not taught.

What Do You Think?

I con­sider my­self a novice main­tainer, so I’d love to hear from more ma­ture main­tain­ers. How do you find sig­nal through the noise?

---

Additional Reading

• Why I close PRs - Jeff Geerling