Issue label structure

[MaxGhenis]

Our labels are getting a bit unwieldy. For example, typing ma in the label searcher to assign an issue to Massachusetts yields a bunch of other matching label names. Many repos have label prefixes to address this issue.

Here's one potential taxonomy:

• state/{ca,ma,etc.}
• program/{tax,snap,wic,etc.}, possibly program/tax/{income,property,sales}

Alternatively, we could have the label match the jurisdication, i.e.:

• {gov/irs, gov/usda/snap, gov/states/in}
• contrib/ubi-center/basic-income

Another layer could be the funder: funder/{cgo,policyengine,etc.}.

We could also distinguish layers with colons, e.g. program:gov/usda/snap and funder:cgo.

We could also organize other types of labels, like testing, validation, etc., though I think the greatest need is around the variables. Feedback very welcome.

[fedderw]

Here's one potential taxonomy:

• states/{ca,ma,etc.}

This seems like the minimum to me.

This plus variable path to post general possible path?

• states/md/tax

[martinholmer]

The structure of the labels is an important topic, but I see another problem. Currently there are nearly 400 issues and there is no easy way (at least that I know about) to learn about an issue's priority. Once an issue gets pushed off the first page (which contains only about 25 issues), there is a tendency for it to be forgotten even if it should have a high priority. I suppose a "top-priority" label could be used by the project management to identify the N issues with the highest priority. Another approach would be for project management to organize "sprints" (a concept from agile software development) in which a specified set of issues would get resolved.

Any thoughts about how to set priorities on resolving issues? It seems as if some kind of priorities need to be set by project managers so that there is a sensible balance between resolving issues that call for new features and resolving issues that call for fixing existing features.

@MaxGhenis @nikhilwoodruff @fedderw

[MaxGhenis]

We use ZenHub for project management, which supports sprints and pipelines, e.g. Sprint Backlog would be high priority. But we've gotten lazy about it in the past couple of months. Currently Nikhil and I are pretty much the only ones addressing general issues--other contributors focus on more specific projects like the tax code for a specific state--and we each review the backlog every now and then, so it hasn't been too big an issue. But I agree we should revisit it, especially once more contributors get up to speed to work on issues beyond their particular focus area.

In the meantime, issues tagged as bugs generally come first, unless they're a policy that's not featured in the PolicyEngine app.

[martinholmer]

I guess one way to manage a large number of issues is to use GitHub's built-in Project capability. One of the features it adds is priority labels. @MaxGhenis and @nikhilwoodruff, have you ever considered using this Project capability to manage the work that is going on in this repository? Like any other approach, the GitHub Project is a trade-off: gaining a better managed project at the cost of extra work.

[fedderw]

There's also a pretty robust Notion github integration. I made a quick little demo

Not sure it's much, if any, better than Projects at this point, since it doesn't appear to support Github issue labels yet

[fedderw]

The main thing is that you could create a "stale issues" view

[martinholmer]

@fedderw, Thanks for the Notion demo. Not having the labels is a major shortcoming it seems to me.
Does Notion support any way of assigning priorities to GitHub issues?

[martinholmer]

@MaxGhenis said in #1015:

... we each review the backlog [of issues] every now and then, so it hasn't been too big an issue.
But I agree we should revisit [the topic of how to formally manage issues], especially once more contributors get up to speed to work on issues beyond their particular focus area.

In the meantime, issues tagged as bugs generally come first, unless they're a policy that's not featured in the PolicyEngine app.

@MaxGhenis, thanks for the background information. I think this "in the meantime" prioritization of open issues makes sense and has the virtue of not imposing extra work on project managers.