Issue triage and relabeling issues

[brad2014]

I'm intending to work with individual team members to deal with the large number of open issues, do a full-sweep triage.

In the process, I'll reorganize how bugs are labeled to make it easier to do ongoing triage.

I'm creating this issue as a place to make notes and comments.

[brad2014]

An initial draft of the documentation on triage and labeling is in the wiki:

https://github.com/internetarchive/openlibrary/wiki/GitHub-Issues---Triage-and-Maintenance

[brad2014]

• Migrate and merge "Type:" labels
• Migrate and merge "Priority:" labels
• Migrate and merge "Needs:" labels
• Migrate and merge "Closed:" labels
• Migrate and merge "State:" labels
• Migrate and merge "Data:" labels (work with @hornc)
• Migrate and merge "Affects:" labels (work with @mekarpeles)
• Migrate and merge "Module:" labels
• Migrate and merge "Theme:" labels
• Confirm 2019 milestone tags, and discuss mileston 2019Q2 and Q3 tags
• Grey out rarely-used labels, and delete never-used labels.
• Update documentation on labeling and triage.

[brad2014]

@mekarpeles, I think the above breakdown is complete. Is there anything you want to add? Incidentally, this is, I think, an example of something that "needed breakdown", but is not an epic (it won't have subissues, it's not our intention to divide up the work).

[xayhewalo]

I'm continuing a project in the same vein of this issue here: https://github.com/internetarchive/openlibrary/projects/13. The goal is to properly label all open issues by end of 2019.

edit: typo

[tfmorris]

I've updated Brad's note with the correct username for mek. @mekarpeles wasn't pinged before when @brad2014 wrote his question.

[xayhewalo]

on #2317 @tfmorris commented:

I'm not sure why ever issue needs an assignee. We have way more issues than people to work on them all the employees are being tasked to work on things just for show, so they're not even available.

I think we should adjust the guidelines to acknowledge that there are some things which are important, but not assigned to anyone.

A few things:

The comment suggests that the assignee is doing the work to resolve the issue. This is not necessarily true. In short, the assignee will be the person responsible for gathering/providing the info needed to resolve the issue. More details on the Wiki. It often makes sense for the assignee to be an employee or a long-term volunteer since they would know the code base better.

Second, marking an issue as important and assigning it to no one is exactly the problem I am trying to resolve. There are a lot of issues with no assignee that haven't been touched since the issue was made. Ensuring every issue has an assignee surely won't completely fix this problem, but it at least increases accountability.

Lastly, the process I'm using is open to suggestions. The goal is to make the open issues more manageable and also improve the workflow for addressing issues.

Edit: a typo

[tfmorris]

If an assignee is responsible for triage, that means that they need to investigate, attempt to reproduce, examine the code, etc. Bug reports definitely need to be triaged, but in the vast majority of cases they were triaged years ago and often if it was, say, 3+ years ago, they've been revalidated in the last year or two.

The reason bugs aren't getting fixed is most emphatically not because they don't have "assignees." It's because a) there are too few bug fixers and b) those that are available are off working on other things. Sometimes its fixing higher priority bugs, but often it's some completely unrelated odyssey. In the case of employees, they work on what their boss tells them to. Longstanding bug reports are never part of that priority discussion. That is why they don't get fixed.

[mekarpeles]

I feel like this is in a pretty good place. Going to close for now.