Retrospective‐Notes‐2024.11.27

Chair	Timekeeper	Note Taker
LC	IG	JH

Present:

• In person: FA IG TW LJ GR JD LC
• Online: JH KB ES CMS SC DK

Previous sprint

Instrument configurations on gitlab

• **Action: LJ to persevere with trying to sort out the dodgy commits which prevent us from doing this. **

Security - cabin pc passwords on whiteboards

• we have been adding these to keeper as we go to support calls.
• we should not give out passwords over the phone.

Release versioning

• we agreed to move to YY.MM.patch for the next release.

Demos

• these should be part of the PI template to have them done before a whole cycle after the release.

Current Sprint

Security of the current NDX set up

we should set something up to talk about this in the group meeting.

Timing of sprint meetings

GR has meetings in advance that cause clashes. can we be a bit more flexible about sprint meetings? KB has predicted sprint dates for the next year. It's difficult to book meeting rooms in this way because there are always clashes. GR has agreed to take some of the labour off rescheduling by finding new rooms if need to reschedule and then updating the meeting. This would mean jsut the meeting changes, but sprint deadlines will remain. we should always mark ourselves as out of office, in our own and the expt. ctrls. calendar, to make both of these tasks easier.

Multiple repos on the project board

• this is a good thing and it's working pretty seamlessly.
• this means issues are much more isolated to where the actual code is
• it's quite easy to transfer issues now, this is great

Closing old tickets

• lots of work has been happening to close old/dead tickets
• main IBEX issue repo is still useful for general tickets, we can transfer if needed.
• it takes a lot of time to go through old tickets as we have tickets that are over a decade old. there is a big list now which is for culling, KB needs assistance from the group to look through these and has marked some with "verify" for this.

Professional versions of pycharm

would like the professional versions as vs2022 not quite as good

• action: JH will ask irene for numbers for half the group and all the group, we will then talk about it again

Group mailing lists

• there are a few different mailing lists for the experiment controls, we should try and make these more concise as there is a mismatch in the members of each.

• one of these is a mailbox, one is a mailing list, some are sharepoint groups.

• all of the above are showing up in outlook - we might not have control over them so may need to ask someone else?

• we should write down what we want to do about these groups and do it.

• **short term action: could FA or CMS make sure that the members are at least the same. ** FA: we may be able to reduce them down to one anyway.

Release notes numbering

• we should make the "Upcoming" release notes the next version.
• refer to previous sprint discussion on this for more details

Demo timing

• already discussed in previous sprint

Tracking of email support requests out of cycle

• out of cycle we should have a rota - will discuss in group meeting

Locking the office when not in use

• we should lock the office when we're not in it. no-one can get locked out as it's a keypad so there's not really an excuse.

Next release RC possibility

• next release is looking more complicated because of dependency updates, can we create release candidate for pre release so we can be told about all the broken stuff before we deploy in feb.
• this is quite tight as we need to be creating the next release in January
• CRISP may be busy, but other instruments may be willing, though unlikely as we're currently in cycle.

work experience students

do we have suitable work for students?

• yes, we can do this, and there is plenty suitable work.
• we could have 2 students and they could work together?
• we may not have enough desks for this so may have to be strategic when people are on leave etc.
• if out of cycle much easier for someone to WFH for a week. we can also create space in end office for one of them

Mad/Sad/Glad

Mad:

• no one is mad

Sad:

• no one is sad

Glad:

• Lots of people working on bluesky, great that it worked so well
• number of issues has dropped by 300
• ruff is good as it's improved quality of code and caught bugs that may not have been found.

Other:

• could we be stricter about timekeeping in the review section so we're not rushed in the retrospective. we should use the time estimated section in the slide as it makes timekeeping easier.