|
1 | | -Something goes in here |
| 1 | +| Chair | Timekeeper | Note Taker | |
| 2 | +|-------|------------|------------| |
| 3 | +| GR | ??? | SC | |
| 4 | + |
| 5 | +# Previous sprint |
| 6 | + |
| 7 | +PI changeovers confusing |
| 8 | + |
| 9 | +Shared laptop helpful |
| 10 | + |
| 11 | +Ticket priority - probably not enough data to tell whether there was any change. |
| 12 | + |
| 13 | +Source code in dev manual - yes move it - ticket exists |
| 14 | + |
| 15 | +Manual system tests on release |
| 16 | + |
| 17 | +Build nodes |
| 18 | + |
| 19 | +Windows patching / IBEX deployment - note added to draft email by KB |
| 20 | + |
| 21 | +GALILOLD is bad |
| 22 | +- Should we update GALILNEW to be actually new, otherwise GALILNEW is a bit old. |
| 23 | + |
| 24 | +Remind people when they are on first line support |
| 25 | + |
| 26 | +Zipping up builds, sophos is horrible. Tickets. Many tickets. Some of which are conflated with each other. |
| 27 | + |
| 28 | +Use NDXMOTION to do beckhoff stuff, don't install XAR locally. JH removed from install & build wiki page. |
| 29 | + |
| 30 | +# Current Sprint |
| 31 | + |
| 32 | +### Defunct emails that looks like it's associated with us but isn't. |
| 33 | + |
| 34 | +FA has sorted this. |
| 35 | + |
| 36 | +### Instrument Demos |
| 37 | + |
| 38 | +FA: how to balance too early (scientists on holiday) vs too late (not enough test time) |
| 39 | + |
| 40 | +KB: think we should book demos week after deploy. |
| 41 | + |
| 42 | +Conclusion: try to book 2 weeks before cycle |
| 43 | + |
| 44 | +### Instant awards scheme |
| 45 | + |
| 46 | +LC: Yes put people forwards for awards. Nominating whole teams / more people will tend to get a bit more scrutiny. |
| 47 | + |
| 48 | +### Tips/tricks teams channel |
| 49 | + |
| 50 | +ES: Minor tips & tricks that aren't worth a whole wiki page, maybe a lightweight way to share these little things. |
| 51 | + |
| 52 | +KB: creating the teams channel as we speak |
| 53 | + |
| 54 | +FA: more curation/organization might be good long term if it gets too big. |
| 55 | + |
| 56 | +KB: if channel gets too big then we can move things out of teams channel to somewhere else |
| 57 | + |
| 58 | +IG: OneNote? |
| 59 | + |
| 60 | +KB: Onenote in teams not very good |
| 61 | + |
| 62 | +GR: Maybe let's go for a channel this sprint and then review |
| 63 | + |
| 64 | +Various: is it searchable enough? |
| 65 | + |
| 66 | +FA: how categorizable is it? |
| 67 | + |
| 68 | +LJ: Make replies to top-level "theme" posts? Similar to retrospective channel? |
| 69 | + |
| 70 | +Conclusion: try teams channel, evolve it over time as needed. |
| 71 | + |
| 72 | +### Release timeline |
| 73 | + |
| 74 | +GR: Let's not spend too much time discussing this |
| 75 | + |
| 76 | +### The end of 🐐 is nigh |
| 77 | + |
| 78 | +DK: 🐐💀 at end of financial year? |
| 79 | + |
| 80 | +KB: No. End of project is September 2025. But most people won't be booking significant time to ibex post June. |
| 81 | + |
| 82 | +GR: Just to be clear this is the 🐐 project, not the 🐐 product |
| 83 | + |
| 84 | +KB: next PI we might be looking at doing things differently. August. |
| 85 | + |
| 86 | +DK: Can we have more time for internal team/technical priorities |
| 87 | + |
| 88 | +FA: Have a formal 80/20 split for tickets which are scientist-driven/not-scientist-driven, but there's also scope for "personal development" type time outside the ticket framework. |
| 89 | + |
| 90 | +FA: Post ibex finish we can review some of our IBEX tech choices, some bits of 🐐 are looking a bit dated. |
| 91 | + |
| 92 | +### Wikis |
| 93 | + |
| 94 | +GR: 3 wikis exist, sometimes with duplicate content. Happy to tinker. |
| 95 | + |
| 96 | +IBEX: scientist facing |
| 97 | +Dev: dev facing |
| 98 | +User: how to use ibex |
| 99 | + |
| 100 | +Conclusion: go for it George. |
| 101 | + |
| 102 | +JH: repository-specific info - migrate to `README` or docs of each repo. |
| 103 | + |
| 104 | +LJ: Searching? |
| 105 | + |
| 106 | +ES: Search at org level |
| 107 | + |
| 108 | +### Pyright |
| 109 | + |
| 110 | +JH: people will be upset but it's a good idea |
| 111 | + |
| 112 | +TW: didn't actually cause too many issues in practice |
| 113 | + |
| 114 | +KB: still some instruments to migrate in summer |
| 115 | + |
| 116 | +### Standup |
| 117 | + |
| 118 | +CMS: Move "friday" standup tasks to "thursday"? |
| 119 | + |
| 120 | +LJ/KB/GR: Discussion about whether we might lose code review time |
| 121 | + |
| 122 | +LJ: should we be stricter about actually doing the code reviews |
| 123 | + |
| 124 | +### Staff updates vs standup |
| 125 | + |
| 126 | +JH: Big announcements (UKRI/STFC/NatLabs level) that various people in the team miss if clashes with standup |
| 127 | + |
| 128 | +KB: All staff meeting might take priority anyway |
| 129 | + |
| 130 | +Various: discussion about tangentially related things |
| 131 | + |
| 132 | +ES: is standup actually important? |
| 133 | + |
| 134 | +KB: standup is important to connect to others |
| 135 | + |
| 136 | +GR: We can probably justify missing one standup every so often |
| 137 | + |
| 138 | +Conclusion: don't know and/or don't care, other meetings might take priority, as long as ops stuff e.g. nagios gets checked. "Someone" will take care of it. |
| 139 | + |
| 140 | +### |
| 141 | + |
| 142 | + |
| 143 | +# 😠😢😄 |
| 144 | + |
| 145 | +- FA 😄 we made changes to lots of stuff in release and got away with it |
| 146 | +- LJ 😄 about stress(full) rig |
| 147 | +- ES 😄 about OPCUA |
| 148 | +- GR 😄 about 🌞 in the evenings when leaving work |
| 149 | +- CMS 😄 that we've run EMMA on newer windows version/hardware |
| 150 | + * CMS 😄 OpenGENIE & SECI work on windows 11 (?!) |
| 151 | +- FA & KB & others 😄 about SECI 💀 |
| 152 | +- IG 😠 that his 💻 got wiped |
| 153 | +- GR 😄 that this meeting wasn't stupidly long |
0 commit comments