You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That could be turned into a heuristic for "how much incoming there is per week". That's probably a good start. A page with all your repos, and their relative incoming rates (probably broken down with a week-by-week graph and then also an "average over the last month, 6 months, year" singular stat.
The follow up to this would be to try and correlate the incoming rate with how much time is actually needed to triage that rate. Like, if we even just guess that triaging an issue takes 30 minutes on average and another comment on an issue adds another 10 minutes[1], that's even a dumb way to start estimating how much time triage costs (at a minimum).
([1]: we should use an input box for these heuristics, probably)
If we could figure out how many actually get triaged / week then we could do more magic. Then, we could correlate that rate (triaged/wk) with the incoming (incoming/wk), and knowing how much a repo is currently staffed with, figure out how much actual dev time is needed to triage all the incoming.
The text was updated successfully, but these errors were encountered:
This came out of a discussion this week
That could be turned into a heuristic for "how much incoming there is per week". That's probably a good start. A page with all your repos, and their relative incoming rates (probably broken down with a week-by-week graph and then also an "average over the last month, 6 months, year" singular stat.
The follow up to this would be to try and correlate the incoming rate with how much time is actually needed to triage that rate. Like, if we even just guess that triaging an issue takes 30 minutes on average and another comment on an issue adds another 10 minutes[1], that's even a dumb way to start estimating how much time triage costs (at a minimum).
([1]: we should use an input box for these heuristics, probably)
If we could figure out how many actually get triaged / week then we could do more magic. Then, we could correlate that rate (triaged/wk) with the incoming (incoming/wk), and knowing how much a repo is currently staffed with, figure out how much actual dev time is needed to triage all the incoming.
The text was updated successfully, but these errors were encountered: