2024-10-30

Chair	Timekeeper	Note Taker
CMS	KB	LC

Present:

Previous Sprint

Automation: we now have it on the sprint board, with labels being added/removed when moving a card through columns
Ruff/Pyright day: we did this.
Using task table instead of task board: this seems to work quite well
Was remarked last retro that there felt like fewer calls for lat cycle, however after doing the maths it was also our most support-heavy cycle of the year

Initial proposal was to move them from 10-12 to 10:30-12:30
- This however cuts into lunch hours, meaning that those who arrive early will have to wait even longer to eat and go hungry for a bit.
- Additionally can cause issues with people putting meeting early afternoon in diaries which might altogether remove your lunch break
Balance is people starting early and needing to eat vs needing to travel in in the mornings later to avoid paying for peak tickets
JD suggestion: what is stopping us from moving to an afternoon meeting?
- This technically goes against agile methodology (theoretically no work going on between review and planning, in practice that never happens)
- However we’re not held to agile irrevocably, so why not?
- There used to be a lot of post-planning work, but not any more
- Could lead to there being many meetings on a single day when in-cycle which is bad for support
Going to try it as an afternoon meeting for the next few months

Won’t let us use it due to bad commits
would have to rewrite history on 4 instrument branches (thankfully not on any others)
LJ willing to take a look

GR highlighted the fragility of the security on NDX machines in the teams channel
- default user/pass was found on web search
Bigger problem than was highlighted in the message
going to revisit with GR present to make sure no points misrepresented

Should we have scientists share their passwords with us in keeper? There were a few instances where we needed them and had to look on a whiteboard for them
- Generally don’t need to use them but e.g. IMAT has a couple of machines we need to log into for cameras
- A user called us on the support phone when they needed the cabin PC password, and the local contact was neither local nor contactable, so we had to tell them to read words on the whiteboard until one of them sounded like a password to us
  - Should we even be giving them out? Probably not.
Could go round the halls once a year looking for passwords on whiteboards and adding them to keeper
Could also just ask the scientists if they don’t mind giving us the passwords

Every release for a while has been a major release and incrementing the large version number
Could be confusing figuring out which instruments a given release was deployed to
Will instead move to YY.MM.Patch format from next release (now 25.02.0) from next release onwards

Will bring this up again when GR present
More labour to check, but LC willing to do a little rescheduling on further out days if the team is ok with it

Should not be a whole cycle after release, should put it in PI template
It’s a good way to ensure whole team is visible to science groups for more than just specific devices etc.
Even if only 3 out of the 5 demos have people show up, will still be worth it

Mad:

SC mad of pyright because there’s now work needed before submitting to review, but… Glad:
SC glad at the same time that it’s teaching better python practices
Collectively glad that old code is being updated to follow pyright
- As such less messing around with it when you change a single file