Update OLM WG Meeting Template

[awgreene]

I'm creating this discussion in response to a conversation held in today's OLM Working Group and Triage Meeting in which @anik120 visited the OLM V1 project view and @joelanford pointed out that ongoing work has been tracked in Milestones for each of the individual projects. We need to update the Working Group and Issue Triage Agenda to better accommodate the new issue tracking process. I propose that we:

• Close the OLM V1 Project View)
• Update the OLM V1 Working Group and Triage Meeting Template by:
  -- Removing the link the the OLM V1 Project View and linking to each of the subproject milestones as proposed in the meeting.
  -- Removing the "Next Milestone Idea Generation Check-in" because the working group typically skips this bullet and the work should be generated naturally in each subprojects milestones.
• The agenda could look something like:

[Month] [Day], [Year]
Host: [name of host]

Briefs and RFCs Under Review:

• [link] | Due Date: yyyy/mm/dd

Old Action Items Checkpoint:

• [item]

Discussion Topics:

• [github handle/name] - topic

Milestone Check-In:

• Catalogd
• Operator-Controller
• Rukpak
• Deppy

Action Items:

• (host) Create next meeting agenda
• (host) Open the floor for hosting volunteers for the next meeting
• (recorder) Upload Recording to the Operator Framework Youtube Channel

[anik120]

What's the replacement for Milestone IdeaGeneration Check-in? I.e

• which backlog can community members throw in feature requests?
• See what's in the roadmap beyond the current milestones laid out?

[awgreene]

I've updated the proposed template to reflect @ncdc's suggested changes.

If we want to track milestones "for real", we essentially need folks who are driving them. This means that we spend time to plan what features, bug fixes, and tech debt we want to cover in n+1 and beyond. Once we agree on the scope of a milestone, we do not add anything else to it, at least not without some sort of consensus. In multiple previous OSS projects I've worked on, milestone scope creep was a huge problem.

That's a great point @ncdc , do we want to invest the time it'll take to formally manage milestones and prevent scope creep? I've heard many people encourage embracing a Kanban development methodology, if we were to follow that I suspect that the milestone boards would be more of a discovery mechanism to track what's planned to land in a release.

EDIT:

I would also encourage removing any milestones called "backlog." As an alternative, I'd recommend:
Have a GH action that adds all new issues to a "New" column in the OLM v1 project
Periodically + frequently triage the New issues, moving any to the Backlog column that we plan to work on at some point

I glossed over this and didn't make the connection that this was the Kanban alternative approach until the second read, which I would advocate for.

[grokspawn]

I'd like to second this agenda proposal:

I would propose this agenda:

1. Checkpoint old action items
2. Discussion topics
3. Milestone checkins

[everettraven]

I'm +1 on the agenda proposed by @ncdc

I don't have a strong preference on the milestone process, but I figure it might be worth sharing how it is currently done for the Operator-SDK:

• During issue triage:
  • Go over the issue and determine:
    • Does it need to make it into the next milestone? If so, add it without any assignees. Otherwise leave no milestone or assign to "Backlog" milestone (although I'm +1 on removing these types of milestones).
  • Open the floor for those in the meeting to pick up the issue. If it is picked up, ask if they would like it to be assigned to the next milestone (i.e do they think they could get it done by the next release?). If no one volunteers, add labels and leave no milestone or assign to "Backlog".

At any point, if an issue is deemed to be a "Release Blocker" it is added to the milestone and marked as such with a label. At any point someone can request to be assigned to any unassigned issue and the milestone for it updated to the next milestone.

Having gone through this process, I wouldn't call it ideal and agree with @ncdc that if we want to do real milestones we should be much more strict on what that means and ensure the maintainers of the subprojects are appropriately discussing what work should be done in each milestone.

[joelanford]

In multiple previous OSS projects I've worked on, milestone scope creep was a huge problem.

@ncdc In those projects, did they follow time-based releases? My impression is that if we do what Bryce is talking about, we can be a bit more lenient on adding stuff to milestones because the worst case scenario is that we get to the release day and kick it back out if it isn't a blocker.

Obviously if we don't think something can be completed or should be in scope for a milestone, we should not allow it in or remove it early.

My impression of how this would work is that maintainers would treat it as a finger in the wind for what will be complete by the time the release day rolls around.

[ncdc]

We tried to do time-based releases for kcp, yes. We had a not-so-great habit of over-aggressively adding things to the next milestone ("sure, it seems like we should do that soon!"). But we didn't have capacity to just keep adding things. The result was we'd get to release day and have to kick a lot of issues out of the milestone because they weren't done (or even started).

The way I'd maybe do it:

1. If a maintainer / group of maintainers determines that an issue is a "must have" for the upcoming milestone, by all means, include it. But ...
2. The default behavior should probably not be "sure, let's add it to the next milestone"

Basically, be conservative about what we add. If someone is in the middle of working on something, it's totally fair to add that to the milestone if they think it can be finished in time for the next release.

[awgreene]

@joe and @ncdc brought up a great point that it's difficult to discover existing RFCs and their lazy consensus dates, I would like to append a section where we include a link to the Brief/RFC and its lazy consensus date.

[awgreene]

I've updated the template to include the Briefs and RFCs Under Review section.

[awgreene]

I was speaking with @joelanford, @ncdc and @oceanc80 and we got on the topic of Issue Triaging. The weekly meeting is called OLM WG and Issue Triage Meeting and we haven't done much issue triaging.

Our discussion focused on a few points:

• There is a general sentiment that in person issue triaging isn’t very effective
• We think that it would benefit the community if we embraced closing issues asynchronously.
• There is a concern that if “everyone is responsible for triaging issues asynchronously, no one will close issues asynchronously”.

The goal of this thread is to identify how we'd like to triage issues as a community and decide how this might impact our "OLM WG and Issue Triage Meeting"

[awgreene]

One suggestion that came from the conversation that spawned this ticket was to create a dedicated "Issue Triager Role":

• The assignee is responsible for looking over existing issues in each of the repositories and identifying issues that could be closed. If they aren't sure if the issue should be closed, they can send a message in slack.
• The role would be assigned to someone during the Working Group Meeting.
• The Stale Bot would still close long lived stale issues.
• Community members can continue to close issues as they see fit, even if they aren't assigned to the role.

[ncdc]

What I found in other projects was that there wasn't a lack of people willing to close issues. It was more that if a bunch of issues came in, there wasn't any guarantee that they'd at least all be triaged and "categorized" (not a bug, critical bug, rfe, needs discussion, etc.) in a timeline manner.

[awgreene]

I purposely omitted other responsibilities from the proposed role because:

• Our project doesn't categorize issues in any capacity right now
• We have a backlog of issues that are effectively RFEs / "we'll need to do this someday" issues, some of which seem to warrant closing.

I figured the role could address bullet 2 before we introduce more structure to our issue backlog, but I'm open to discussing this now if there's interest.

[awgreene]

I've moved this discussion to #370 so we can finalize the WG Agenda changes.

[awgreene]

Marking this as closed, the Working Group Agenda Template has been updated to reflect the agreed upon changes.