Iteration Retrospective 2025-03-06

General sentiments

JC – Changes in review handling seem to have made things run more smoothly (checking awaiting review at the end of each standup)

JE – Agree

JM –

JW – not sure how to optimize my efficiency to resolve hefty tickets.

LW – Similar, was disorienting to come in mid-orientation. Lots of reactive work rather than executing on my long-term plans.

JM – Similar, board procedure doesn’t reflect my work, with lots of shifting requirements.

JE – I’m having several instances where just doing a task is way easier than opening a ticket, assigning it a column, putting it in an epic

MT – From the comments above, it seems like a lot of our work isn’t planned out. Is this good/bad?

JE – It seems like a lot of our tasks aren’t software things that have reqs specified in advance, rather things that require a lot of communication.

…

JE – This procedure is made to handle things that change on a two week basis… Not sure if there’s something to be gained by having all work need to be blocked out in fairly unchangeable two week chunks….

JM – My project would be impossible without changing requirements on a weekly or sub-weekly basis. Ex. for besmarts work, I thought I wanted to structure a meeting to get a definition of a function that I could implement… but by the end of the meeting I wasn’t tasked to implement a function at all.

JC – I think I got to a natural stopping point and had my meeting with LW today, and we decided to close many tickets and make new ones for other approaches. That may be why things looked like they were moving more. In the sprint before I kinda stuck to the definitions of the tickets where I had planned them out with dependencies and the result was convoluted. Now I had a few “topical” tickets that sat… maybe that’s not good either.

JW - I feel the residual fatigue of the onsite meeting, and maybe what we’re describing is just another face of setting out to do too much work.

JE – Possibly, lots of accumulated fatigue from recent travel.

MT: I think the board state accurate represents my work. This was not a productive sprint for me. I also had almost no work planned at the beginning of it, and it’s hard to fell accomplished without having defined accomplishments completed. End up spending a lot of time on user support, which isn’t satisfying.

LW – I think the board state doesn’t reflect my workload well. Too many tickets to view at once, and it doesn’t fit the real work well. Keeping big vague tickets open fits my actual workload better than breaking things down into discrete tasks.

Handling daylight savings

JW

• US advances 1 hr on 3/9

• AUS retreats 1 hr on 4/6

• LW and JM are willing to stick with current schedule until April

• No change for now

Who/when/how do we update the big roadmap and add/modify epics?

JW

Org policy around who is responsible for dealing with CI failures

MT

MT – Thought about from a few perspectives:

• Ex. JM opening a PR to add feature in interchange and having CI fail for reasons that aren’t his fault

  • JM experiences confusion/frustration

  • project owner can force-merge so they aren’t so concerned

• I think CI failures are quite urgent, and if not handled quickly will gum up whole org.

JC – Talking about CI failures during PR review, or things broken by upstreams (ex. numpy)

MT – Nightly test failures, like things broken by upstreams

MT – Can implement codeowners file to ensure that a particular person is notified (as opposed to the current state which is just to notify the most recent committer). Can also list approving reviewers (and divide this by subfolder).

MT – Also motivated to do this because in a lot of cases I try to submit PRs to projects and I ahve to fix CI in the process

JW – I’m in favor of codeowners files

JM – Me too

MT – I’ll take responsibility for rolling this out.

MT – Priority for failing CI?

JW – Kinda tough for some repos like qcsubmit with sporadic failures. But generally I think we should put tickets for failing CI in urgent column so it gets seen and actioned in max 24 hours.

JE – Agree - I think infra team membership should mean that failing CI is urgent priority.

MT will open PRs to roll out codeowners files

When CI fails, a ticket should be added to the urgent column indicating this (can be opened by anyone who spots it, but it’s the owner's fault if it’s not)

…

MT – There’s probably an exact goldilocks zone for prioritization of this, but a good-enough approximation for this to fit into our processes is to get human attention on it within 24 hours.
JE – Product owner can choose to fix immediately without opening a ticket, otherwise should open a ticket.

Standards around hero merging

MT

Opening a GitHub issue from Zenhub UI - is there a case in which we mean to do that? Could have this fired off to /dev/null

MT

The default repo was changed from openff-toolkit to “status”

General board lifecycle - When do I move tickets around? When am I expected to have things sorted?

JW