---
# System prepended metadata

title: OLM Issue Triage Improvements
tags: [development process]

---

---
tags: development process
---
# OLM Issue Triage Improvements

## Summary
The OLM Issue Triage meeting is a bi-weekly public meeting where the OLM team triages outstanding issues in the primary OLM v1 repositories (OLM and registry). The meeting was created to help triage the large backlog of open OLM issues and try to be more responsive to the needs of the community. 

In this sense, it was successful as it forced the core OLM team to be more responsive to new issues that came in. However, it has become apparent that there are some issues with the issue triage meeting in its current form. 

## Issues with Issue Triage Meeting
* Most of the current focus of the OLM team is on newer APIs (FBC, Rukpak, deppy, etc) and there is not much day-to-day activity on the existing OLM codebase outside of high priority bugfixes. Therefore there isn't much interest or context for those triaging OLM issues, since there is not much focus on legacy OLM at this point. There is also limited desire around adding features to the existing set of OLM APIs, which limits the effectiveness of triaging new feature requests. 
* Attendance is spotty, and most of the people with context on legacy OLM have moved on to other projects. Newer members to the OLM team have been focusing on the newer APIs. As a result, the effectiveness of the meeting has gone down since it was introduced. 
* There still isn't a clear path to bringing triaged issues into the scope of the sprint, to actually deliver solutions to the upstream community. OLM has generally dealt with a large support burden downstream, which does not leave much time to tackle additional upstream issues. This limits the effectiveness of issue triage as a whole. 


## Proposed Solutions 
### Repurpose the meeting
The issue triage meeting can be repurposed to focus on issues that are present in the newer APIs. Individuals who are interested in specific OLM issues can bring those up at the start of the meeting, so those can be triaged as well. Because the meeting will now cover topics present in the new APIs, which most of the OLM team is focusing on, the meeting would have more purpose and be less of a context switch. OLM issues would still need to be triaged out of band however. 

### Hold the meeting less frequently 
If bi-weekly is too frequent for members of the OLM team to join, we could commit to hold the meeting monthly instead, but focus on having full team attendance. This way, the meeting would be more useful, since more members of the team are present. Alternatively, we can cancel the meeting if not all team members can commit to attending that particular week. 

### Cancel the meeting
The number of upstream issues opened against OLM has gone down since there are less new features being introduced to OLM. The upstream community has also not grown. It's possible to commit to simply triaging the open issues out of band by individual team members and not have an issue triage meeting. Issues that affect the community or need further attention can be discussed in the separate OLM WG meeting. 