From 6da3b61a1c2393049a51626a0dd9aac84e13bc23 Mon Sep 17 00:00:00 2001 From: Tom Willemsen Date: Mon, 20 Apr 2026 10:57:21 +0100 Subject: [PATCH] Remove retrospective notes --- doc/Overview.md | 2 +- doc/client/coding/PV-Switching.md | 2 +- doc/processes/Retrospective-Notes.md | 12 -- .../meetings/Meeting-Roles-and-Rotas.md | 4 +- .../meetings/Sprint-Review-and-Retro.md | 2 +- .../meetings/Technical-Debt-Stand-down.md | 1 - .../Retrospective-Notes-2018.02.14.md | 32 ---- .../Retrospective-Notes-2018.03.14.md | 30 ---- .../Retrospective-Notes-2018.09.26.md | 21 --- .../Retrospective-Notes-2018.10.29.md | 28 ---- .../Retrospective-Notes-2018.11.21.md | 45 ----- .../Retrospective-Notes-2018.12.20.md | 36 ---- .../Retrospective-Notes-2019.04.24.md | 29 ---- .../Retrospective-Notes-2019.09.11.md | 50 ------ .../Retrospective-Notes-2019.10.09.md | 85 ---------- .../Retrospective-Notes-2019.11.06.md | 47 ------ .../Retrospective-Notes-2019.12.02.md | 45 ----- .../Retrospective-Notes-2020.01.08.md | 30 ---- .../Retrospective-Notes-2020.02.05.md | 75 --------- .../Retrospective-Notes-2020.03.04.md | 111 ------------- .../Retrospective-Notes-2020.04.01.md | 25 --- .../Retrospective-Notes-2020.05.28.md | 38 ----- .../Retrospective-Notes-2020.06.24.md | 66 -------- .../Retrospective-Notes-2020.07.22.md | 63 ------- .../Retrospective-Notes-2020.08.19.md | 50 ------ .../Retrospective-Notes-2020.09.17.md | 38 ----- .../Retrospective-Notes-2020.10.16.md | 97 ----------- .../Retrospective-Notes-2020.11.11.md | 53 ------ .../Retrospective-Notes-2020.12.16.md | 36 ---- .../Retrospective-Notes-2021.01.06.md | 24 --- .../Retrospective-Notes-2021.02.03.md | 81 --------- .../Retrospective-Notes-2021.03.03.md | 38 ----- .../Retrospective-Notes-2021.03.31.md | 64 -------- .../Retrospective-Notes-2021.05.05.md | 63 ------- .../Retrospective-Notes-2021.05.26.md | 39 ----- .../Retrospective-Notes-2021.06.23.md | 92 ----------- .../Retrospective-Notes-2021.07.21.md | 54 ------ .../Retrospective-Notes-2021.08.25.md | 68 -------- .../Retrospective-Notes-2021.09.22.md | 57 ------- .../Retrospective-Notes-2021.10.28.md | 27 --- .../Retrospective-Notes-2021.11.17.md | 70 -------- .../Retrospective-Notes-2021.12.15.md | 66 -------- .../Retrospective-Notes-2022.01.05.md | 54 ------ .../Retrospective-Notes-2022.02.02.md | 124 -------------- .../Retrospective-Notes-2022.02.23.md | 83 ---------- .../Retrospective-Notes-2022.03.23.md | 109 ------------ .../Retrospective-Notes-2022.04.20.md | 74 --------- .../Retrospective-Notes-2022.05.18.md | 91 ---------- .../Retrospective-Notes-2022.06.15.md | 103 ------------ .../Retrospective-Notes-2022.08.10.md | 69 -------- .../Retrospective-Notes-2022.09.07.md | 126 -------------- .../Retrospective-Notes-2022.10.05.md | 77 --------- .../Retrospective-Notes-2022.10.26.md | 98 ----------- .../Retrospective-Notes-2022.11.23.md | 65 -------- .../Retrospective-Notes-2023.01.04.md | 50 ------ .../Retrospective-Notes-2023.02.01.md | 53 ------ .../Retrospective-Notes-2023.03.08.md | 70 -------- .../Retrospective-Notes-2023.04.12.md | 51 ------ .../Retrospective-Notes-2023.05.10.md | 39 ----- .../Retrospective-Notes-2023.06.07.md | 17 -- .../Retrospective-Notes-2023.07.12.md | 36 ---- .../Retrospective-Notes-2023.08.09.md | 54 ------ .../Retrospective-Notes-2023.09.08.md | 54 ------ .../Retrospective-Notes-2023.10.04.md | 35 ---- .../Retrospective-Notes-2023.11.01.md | 48 ------ .../Retrospective-Notes-2023.11.30.md | 36 ---- .../Retrospective-Notes-2024.01.08.md | 26 --- .../Retrospective-Notes-2024.01.31.md | 33 ---- .../Retrospective-Notes-2024.03.06.md | 38 ----- .../Retrospective-Notes-2024.04.03.md | 76 --------- .../Retrospective-Notes-2024.05.01.md | 34 ---- .../Retrospective-Notes-2024.05.22.md | 87 ---------- .../Retrospective-Notes-2024.06.19.md | 50 ------ .../Retrospective-Notes-2024.07.17.md | 55 ------- .../Retrospective-Notes-2024.08.07.md | 48 ------ .../Retrospective-Notes-2024.09.04.md | 42 ----- .../Retrospective-Notes-2024.10.02.md | 49 ------ .../Retrospective-Notes-2024.10.30.md | 72 -------- .../Retrospective-Notes-2024.11.27.md | 106 ------------ .../Retrospective-Notes-2024.12.18.md | 63 ------- .../Retrospective-Notes-2025.01.07.md | 23 --- .../Retrospective-Notes-2025.02.04.md | 81 --------- .../Retrospective-Notes-2025.03.05.md | 155 ------------------ .../Retrospective-Notes-2025.04.03.md | 146 ----------------- .../Retrospective-Notes-2025.05.07.md | 66 -------- .../Retrospective-Notes-2025.05.08.md | 55 ------- .../Retrospective-Notes-2025.07.10.md | 68 -------- .../Retrospective-Notes-2025.07.31.md | 41 ----- .../Retrospective-Notes-2025.08.28.md | 71 -------- .../Retrospective-Notes-2025.10.02.md | 90 ---------- .../Retrospective-Notes-2025.10.30.md | 59 ------- doc/searchscorer.js | 5 - doc/tools/Shared-utility-scripts.md | 2 +- 93 files changed, 6 insertions(+), 5147 deletions(-) delete mode 100644 doc/processes/Retrospective-Notes.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2018.02.14.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2018.03.14.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2018.09.26.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2018.10.29.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2018.11.21.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2018.12.20.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2019.04.24.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2019.09.11.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2019.10.09.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2019.11.06.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2019.12.02.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.01.08.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.02.05.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.03.04.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.04.01.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.05.28.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.06.24.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.07.22.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.08.19.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.09.17.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.10.16.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.11.11.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2020.12.16.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.01.06.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.02.03.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.03.03.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.03.31.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.05.05.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.05.26.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.06.23.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.07.21.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.08.25.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.09.22.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.10.28.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.11.17.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2021.12.15.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.01.05.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.02.02.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.02.23.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.03.23.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.04.20.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.05.18.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.06.15.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.08.10.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.09.07.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.10.05.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.10.26.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2022.11.23.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.01.04.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.02.01.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.03.08.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.04.12.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.05.10.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.06.07.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.07.12.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.08.09.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.09.08.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.10.04.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.11.01.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2023.11.30.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.01.08.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.01.31.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.03.06.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.04.03.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.05.01.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.05.22.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.06.19.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.07.17.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.08.07.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.09.04.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.10.02.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.10.30.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.11.27.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2024.12.18.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.01.07.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.02.04.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.03.05.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.04.03.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.05.07.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.05.08.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.07.10.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.07.31.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.08.28.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.10.02.md delete mode 100644 doc/processes/retrospective-notes/Retrospective-Notes-2025.10.30.md diff --git a/doc/Overview.md b/doc/Overview.md index 38c44e93b..3ef532065 100644 --- a/doc/Overview.md +++ b/doc/Overview.md @@ -34,8 +34,8 @@ overview/Links-and-Resources ## Documentation & Processes - [How to edit this documentation](Editing-the-Wiki) -- [Notes from Retrospectives](processes/Retrospective-Notes): Notes from Sprint Retrospective meetings are recorded here. - [Decision Log](processes/Decision-Log): A place to write down decisions made. - [Documentation](processes/dev_processes/Project-Documentation): Documentation of the project and processes _(including why we have 3 wikis)_ - [Data Protection](processes/admin/Data-Protection): Data Protection & GDPR as it applies to IBEX. - [Links & Resources](overview/Links-and-Resources): Useful external links & documentation. +- Notes from Retrospectives are now located under `General > Group Meetings` in teams (including old retrospective notes) diff --git a/doc/client/coding/PV-Switching.md b/doc/client/coding/PV-Switching.md index 8926cc352..1e895648a 100644 --- a/doc/client/coding/PV-Switching.md +++ b/doc/client/coding/PV-Switching.md @@ -28,7 +28,7 @@ This extension point is setup in `uk.ac.stfc.isis.ibex.instrument/META-INF/MANIF This sets up the name of the extension point and the schema. The schema is in `/uk.ac.stfc.isis.ibex.instrument/schema/uk.ac.stfc.isis.ibex.instrument.info.exsd` (click Schema on previous page). -This defines the methods that should be fulfilled by the plugin that want to sign up to this extension. +This defines the methods that a plugin must implement to use this extension point. In this case there are three methods: - `preSetInstrument` - this will be called before the instrument is switched. This is useful for closing resources diff --git a/doc/processes/Retrospective-Notes.md b/doc/processes/Retrospective-Notes.md deleted file mode 100644 index c84602512..000000000 --- a/doc/processes/Retrospective-Notes.md +++ /dev/null @@ -1,12 +0,0 @@ -# Retrospective Notes - -Notes from sprint retrospective meetings. - -```{toctree} -:reversed: -:glob: -:maxdepth: 1 -:titlesonly: - -retrospective-notes/* -``` diff --git a/doc/processes/meetings/Meeting-Roles-and-Rotas.md b/doc/processes/meetings/Meeting-Roles-and-Rotas.md index 9aac58ff2..54ff2af6e 100644 --- a/doc/processes/meetings/Meeting-Roles-and-Rotas.md +++ b/doc/processes/meetings/Meeting-Roles-and-Rotas.md @@ -23,10 +23,10 @@ It was decided that we would set up a rota for the various roles in IBEX meeting - Keep an eye on the end time of the meeting - give everyone a five minute warning - If the meeting is scheduled for more than an hour to indicate the halfway time to make sure we take a break -### Note taker in Retrospective: +### Note taker in Retrospective/Group Meeting: - Keep notes of the discussed points -- Add them to the wiki with a link on the [main retrospective notes page](../Retrospective-Notes) +- Add them to the meeting notes folder under `General > Group Meetings` in teams ### Note taker in Planning: diff --git a/doc/processes/meetings/Sprint-Review-and-Retro.md b/doc/processes/meetings/Sprint-Review-and-Retro.md index 832092cd4..0bc91cf3a 100644 --- a/doc/processes/meetings/Sprint-Review-and-Retro.md +++ b/doc/processes/meetings/Sprint-Review-and-Retro.md @@ -13,7 +13,7 @@ 1. Go through each person's slide and get them to demo and mention tickets they have done 1. Discuss any issues and goodness in the code -1. Review the [retrospective notes](../Retrospective-Notes) from the previous meeting, which will be found at the top of the page. The items to discuss will be located under 'Items from this retrospective:' and 'Other comments (Mad/Glad/Sad)' +1. Review the notes from the previous meeting, which will be found at the top of the page. The items to discuss will be located under 'Items from this retrospective:' and 'Other comments (Mad/Glad/Sad)' 1. Open up Teams > IBEX Developers > retrospective and discuss any items below the relevant post: diff --git a/doc/processes/meetings/Technical-Debt-Stand-down.md b/doc/processes/meetings/Technical-Debt-Stand-down.md index fca8022bb..70ad444b0 100644 --- a/doc/processes/meetings/Technical-Debt-Stand-down.md +++ b/doc/processes/meetings/Technical-Debt-Stand-down.md @@ -45,7 +45,6 @@ Try to make sure all tickets by the end of the day are in a good state. - `dbchecker` vs `dbunitchecker` vs `dbchanges` - Python 3 Compatibility - User manual updates e.g. https://github.com/ISISComputingGroup/IBEX/issues/2763 and https://github.com/ISISComputingGroup/IBEX/issues/3814 -- Update the specific device IOC pages see [here](../retrospective-notes/Retrospective-Notes-2020.05.28) - Tidy up code, remove unneeded parts - Discuss what to do with pv sets - Fix epics unit tests (https://github.com/ISISComputingGroup/IBEX/issues/5539) diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2018.02.14.md b/doc/processes/retrospective-notes/Retrospective-Notes-2018.02.14.md deleted file mode 100644 index c780d0d5d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2018.02.14.md +++ /dev/null @@ -1,32 +0,0 @@ -# 2018-02-14 - -## Sprint_2018_01_18 -#### Date of Sprint Retrospective: 14-02-2018 - -1. Testing API Changes - * we made a change to genie_python (changed enumerated types) but did not create unit tests to test the changes. This came back to bite us. - * we had a similar issue with #2942 - changes to DB records had impacts elsewhere, which caught us out. - * Lesson: make sure there are tests that test your changes. - -1. SM300 Motor - * We estimated 8 points for this (thinking it was a big ticket). In reality, it required much more effort than 8 parts. - * Creating a motor_record was more complex than we expected. - * we didn't really have a good understanding of SM300 motors - -1. Identify IOCs we can contribute back to EPICS Community - * We have quite a collection of IOCs now. Some could be of value to others. - * Identify IOCs that would be useful to others. Work out the best way to package them up for distribution. DO to organise a meeting to discuss further. - -1. Deployment - * We left deployment until the last minute, mainly because we were waiting for GEM & SANDALS tickets to be completed. - * We should recognise that we don't have to delay the release for late tickets. We can proceed with the release and hot-fix any instruments that require the late tickets. - -1. Build Speed - * Full, clean builds on Windows take rather a long time - up to 8h. - * We should investigate ways to speed up the build. Consider as a topic for stand-down day. - -1. Identify Motion Control Tickets - * create a motion control label in GitHub to allow the Motion Control group to easily identify tickets of interest to them - DO to action - -1. Shadow Instrument Scientists - * Individual members should shadow instrument scientists for time-to-time - to watch them using IBEX and to learn how it could be improved, to better support the things they need to do. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2018.03.14.md b/doc/processes/retrospective-notes/Retrospective-Notes-2018.03.14.md deleted file mode 100644 index 0bf21877a..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2018.03.14.md +++ /dev/null @@ -1,30 +0,0 @@ -# 2018-03-14 - -## Sprint_2018_02_15 - -### Date of Sprint Retrospective: 14-03-2018 - -1. Build Performance - * builds are now much faster. - * there is still room for improvement. - -1. Windows 10 testing - * Windows 7 will be supported by Microsoft for only two more years. - * over time, instrument machines will migrate to Windows 10 (probably the new LTS version of Windows 10) - * we need to be prepared for this - * also need to consider what happens to SECI during this time period - -1. Prune the Backlog - * we agreed the backlog should be pruned. Be ruthless about it! (we can always re-open tickets if we are too ruthless). - -1. In coming sprints we will prioritise Script Server work, then E4 migration and then support for LSS scripting & graphing (because scripting & graphing will benefit from the Script Server and E4 work). - * Kevin will follow up with Andrew Caruana to get more details of LSS scripting requirements. - -1. How do we track user requests? We will create a process that adds a re-request label and consult this during planning - - Can we do better about managing expectations? Probably not but can increase the visibility of the request using re-request label - - Is it acceptable to tell people a feature can not be achieved because of engineering constraint? Yes if it is not an experimental critical feature; but probably check with the group first. If it is experiment critical we need to flag this and be creative. - -1. How do we create scientist release notes? They should be created during the release by the release builder (see wiki). - -1. Workflow for genie python development? See ticket 3046 - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2018.09.26.md b/doc/processes/retrospective-notes/Retrospective-Notes-2018.09.26.md deleted file mode 100644 index 06fcd556d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2018.09.26.md +++ /dev/null @@ -1,21 +0,0 @@ -# 2018-09-26 - -1. Want to put Tools in one place. [John: maybe 2 - deployed and non-deployed]. Examples are - - config checker - - config upgrade - - caget - - archive data grabber - - ioc generator - - installation and upgrade scripts. - - Added to [tech debt idea page](/processes/meetings/Technical-Debt-Stand-down) -1. OPI Python logic should be tested, for future OPIs test logic. - - see [#3619](https://github.com/ISISComputingGroup/IBEX/issues/3619) -1. Change meeting lengths, planning should be 30 mins shorted and prep should be 30 minutes longer. -1. Create a ticket to look at removing stale branches.[#3620](https://github.com/ISISComputingGroup/IBEX/issues/3620) -1. OPI should be sent to scientist for who it is being developer (added to IOCworkflow and [OPI Creation](/client/opis/OPI-Creation)) -1. Add Readme to all submodules explaining purpose, these can link to documents in module especially for standard epics docs. This is so everyone knows what things do. It would also be good to remove old code submodules that are not needed and generate dependency lists. - - Added to [tech debt idea page](/processes/meetings/Technical-Debt-Stand-down) -1. Finally looked at cycle problems slack channel. This is not a good method of recording these let think of something else. -1. `Friday Days` and `Tech Debt Days` both still important if we have time in the sprint -1. Story points, is it ok? Yes broadly it seems like a good estimation tool. -1. Another Nicos dev? Tom said yes. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2018.10.29.md b/doc/processes/retrospective-notes/Retrospective-Notes-2018.10.29.md deleted file mode 100644 index 4731a18d0..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2018.10.29.md +++ /dev/null @@ -1,28 +0,0 @@ -# 2018-10-29 - -Generally slow sprint because of holidays. Please announce holidays to Kevin where possible so it can be planned in. - -* Should we automatically measure how long tickets took? - * No this is too hard but we should add comments to tickets which took too long or was overestimated. PM will pick this up at sprint end and make us a list to discuss. -* Changes over a certain size to be pair reviewed? - * Yes for the moment create a label to indicate this - * Look for a tool to measure complexity change (ticket being added) -* Access control on `INST:LIST`? - * No fine for the moment, but change process for setting it to include a review before running. -* Review column > 10 items, ok? - * Maybe because there were many tickets for release. Rory to monitor it for next time. -* Remove old Jenkins jobs? - * Yes, Freddie to check that nothing is extra is captured in the old jobs and to back up then remove -* Remove E3 client and RCPTT? - * John to check that it hasn't been run on any instrument and then create a ticket to delete jobs after backup of Jenkins and move it to client folder (instead of `client_E3`) - * John to create RCPTT test transfer tickets -* Wiki checks should be smarter? - * Yes, Liam to write a ticket -* Drop in sessions? - * Last one good with Ron - * Check the [list](https://github.com/ISISComputingGroup/IBEX/wiki/Instrument-Control-Drop-in-Session) - * Monitor success, has been asked for in and out of cycle by scientists - * Ask Mantid team what they do -* More demonstrating - * Yes, please start powerpoint and review earlier - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2018.11.21.md b/doc/processes/retrospective-notes/Retrospective-Notes-2018.11.21.md deleted file mode 100644 index 9a5a583f0..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2018.11.21.md +++ /dev/null @@ -1,45 +0,0 @@ -# 2018-11-21 - -Short sprint with too many tickets made it weird; make sure next sprint is reasonable. - -- Good to install before machine physics; everyone agreed. - -- 2nd console issue should at least document [I have added to user manual). There is a ticket to discuss larger issue - -- We should link from places in the GUI to the user guide on at least all views. Ticket created #3814. - -- Migrating instruments vs improving gui/ fixing bugs - - We are happy we are making deadlines for migrations but it is a push - - Make sure that we prioritize IOCs better within an instrument, what should be done now vs later - - LVDCom vs EPICS IOC usually epics is better we have not been back to any ones we said we would quickly do and come back to! - -- How much to push the Script server? - - push it, it is the way forward - - should provide training - - mention in upcoming demos (there is a list of advantages) - - [X] Dom to create a template of questions to ask at Instrument scientist demos - -- Simulation mode - - look at Adam's scan simulation library - - integrate into NICOS - - make it easier to use - -- Future Ideas - - Ask Kevin how it works - - Review it a couple of times a year - - this page needs updating - -- Script migrations - - Should be done more with scientists so they own the script. Change wording on the migration page [done] - -- Move sprint end to after Christmas [done] - -- Maintenance View - - We should worry more about long-term maintenance of the project now we are delivering it to multiple machines. We have some tickets "in flight" and we should make sure we don't deprioritise them because it is important for the future. - -- Bunch of tickets: - - https://github.com/ISISComputingGroup/IBEX/issues/3817 - - https://github.com/ISISComputingGroup/IBEX/issues/3816 - - https://github.com/ISISComputingGroup/IBEX/issues/3815 - - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2018.12.20.md b/doc/processes/retrospective-notes/Retrospective-Notes-2018.12.20.md deleted file mode 100644 index ebf804652..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2018.12.20.md +++ /dev/null @@ -1,36 +0,0 @@ -# 2018-12-20 - -## General - -* Should we add the impact of our tickets to help us prioritise them? - * Decided to try initial sort by urgent and important quadrants. - -## Mad - -* Review column has been very full - * Remember to put one in, take one out - * Has been hard because some people have been stuck on long tickets -* Muon separator became a black hole of time - * Can we highlight time spent on this? [Kevin given action] - * Deadline set was not realistic, in that they still haven't plugged in the kicker. This is something to learn for future projects -* Hard to track progress through projects. - * We should investigate story mapping to illustrate the stories we are working on and their progress -* Hard when you go down to an instrument to decide whether a device is connected properly. Talked about cable mapping tools and getting electronics to fill in forms - * Decided to start recording it whenever we go down to an instrument on IOC specific pages. - -## SAD - -* Tickets which scope creep are bad, it is hard to recognise when items are going to creep - * Be mindful of estimates, if you are meeting then bring it up immediately - * Stop scope creep for IOC by adding an analysis step (Keithley 2001 was example) - * [John to add to process between sprint prep and planning if that is ok this feels like when we should do this] - -## Glad - -* Friday and Tech debt days were good, it was good to see them in the sprint again -* New instrument migrations were good. Process is now a fine art -* Instrument demos were useful with good feedback -* Live view was "ridiculously useful" -* ENGINX thought their requests had been well managed - * All instrument scientists were happy seeing improvements in IBEX - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2019.04.24.md b/doc/processes/retrospective-notes/Retrospective-Notes-2019.04.24.md deleted file mode 100644 index 74c21b5eb..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2019.04.24.md +++ /dev/null @@ -1,29 +0,0 @@ -# 2019-04-24 - -## Stressed Feeling - -The major issue this sprint was the feeling that no progress has been made this sprint and that we are very busy. There is a general concern that the next sprint we have said we will convert a new instrument but there is a feeling we do not have time for this. The new instrument will be resolved at sprint planning. Progress this sprint has been slow because: - -- lots of support calls because of the loss of a key member of the group -- Easter holidays and APR season took time out of the sprint -- we need to make sure we can do the number of points in a sprint. -- need to be prepared to say "No" to requests sometimes; if someone doesn't want to do this or are not sure then request should be passed to team lead, group lead or PM. - -## Number of Reworks - -Have a lot of rework tickets, to help this we have agreed to do informal reviews if possible before the ticket goes into review. (This has been added to [workflow](/processes/dev_processes/Tickets-and-their-Workflow)) - -Also agreed to try and make pull requests smaller. - -## Emulators in Support Modules - -We want a discussion about what should be in support modules. Should the emulator and/or OPI be in here? - -## Use LUA - -In general, we would like to LUA instead of `st.cmd`. There is little risk to this we should start by converting an IOC and make sure it works and then add it to the device generator. [Ticket#4288 created]( https://github.com/ISISComputingGroup/IBEX/issues/4288)] - -## Pending Tasks - -We should make sure that pending tasks scheduled for the next sprint are in sprint planning. [Added to sprint planning description](../meetings/Sprint-Planning) - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2019.09.11.md b/doc/processes/retrospective-notes/Retrospective-Notes-2019.09.11.md deleted file mode 100644 index 36180a5ac..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2019.09.11.md +++ /dev/null @@ -1,50 +0,0 @@ -# 2019-09-11 - -## Release was on schedule (or close enough) - -Just a note to be happy about. - -## Releasing fixed bugs - -We should always merge the hotfix and then prioritize the clean up for that hotfix. - -## Retrospective post-it notes vs magic board - -There are positives and negatives to both. -We can write solutions to problems on the back of post-it notes. - -## Server moves and releases clashing - -It is difficult to coordinate due to reliance on facilities I.T. etc. - -However, we should improve our communication when it comes to this sort of issue. We should organize meetings in which we discuss what we know about (or at least the rough plans) for the issue ahead and attempt to come up with a shared plan that will work around the issue e.g. release earlier or delay the release. - -## Standups - -* Are standups still useful? - * Yes -* Could we make them more useful? - * Possibly - * We do well at stopping conversations getting too long and technical - * Sometimes there are lots of small tasks which are not worth talking too much about at standup - * What we can do is to elaborate more on how far we are through certain tickets - * We should focus specifically on the **fine-grain** of what we have achieved yesterday and what we want to achieve today e.g. how far are we through a ticket, not that we are just working on it - * We should talk about blockages more -* Can we try to share blockages even if we are no longer blocked? - * Yes it may be helpful for others so they can easily know who to come to if they get blocked by the same thing -* Can we look at ticket steps to complete? - * Yes -* Should we split into 2 groups so we can talk for longer? - * No - * It is useful so that we are all updated on what everyone is doing in the team - * It is useful so that when we are impeded we have more expertise to help - * Talking for longer is out of the scope of a standup. As such we should organize to have other discussions/meetings if required, for example for subprojects that are occurring - -## At SAG can we emphasize emergency jobs if they are large? - -This has already happened at the SAG meeting earlier in the day before this retrospective - -## After/during sprint retrospective should we note down and work out ways to implement what we have discussed? - -This is already being done in these notes. - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2019.10.09.md b/doc/processes/retrospective-notes/Retrospective-Notes-2019.10.09.md deleted file mode 100644 index a4f2cd02d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2019.10.09.md +++ /dev/null @@ -1,85 +0,0 @@ -# 2019-10-09 - -## How do we know if we're using flash reviews too much? Is it a problem? - -Flash reviews are for small and/or urgent changes. - -Before asking for a flash review we should consider the size and urgency of the change. - -When we flash review we are still adding code to the codebase no matter how small, thus our reviewing should be as rigorous and considered as normal reviews. - -This rigour does not take away from the benefit of flash reviews as our process (using the slack channel) brings it to the attention of people quickly and allows us to skip the normal movement of tickets in the project board etc. meaning it is still faster. - -We seem quite happy with our flash review process, but we should still be careful to not overuse it by carefully choosing when to ask for a flash review or not. - -## Is the review column ordering obvious and understood? - -The simple answer is no. - -People had mixed ideas about how we were meant to be ordering the column. - -Further to this, the ordering was inconsistent with the ready column and the new GitHub projects tool for moving tickets between columns inside the ticket puts the ticket at the bottom of the column (contradictory to our current process). - -We have decided to flip the ordering so that we insert tickets into the review column at the bottom and take tickets from the top. - -This makes our workflow consistent with our ready column and the GitHub tool. - -## Is it useful to log "extremely" quick support issues? - -Pros: - -- Allows the person working on the support issue to solidify the issue further in their mind -- Allows the sharing of information and creation of a dialog about the support issue -- Allows us to refer back to information on past support tickets that occur again -- Creates a process where we can easily understand what has happened and review any changes that are to be made - -Cons: - -- Possibly wastes times of the person working on the support issue if it is very simple -- Some issues are ongoing so the ticket may stay around for a while and clog up the board -- Often a support issue is a repeat of other support issues so we are repeating our logging of information in new tickets when we do not need to - -Ideas and answers: - -- Support issues should have tickets for the pros listed above -- We are creating a new project board for support tickets so they do not clog up our development board -- Discussed: Having a process in a support board or other board for common support issues so we do not need to repeat the logging and can simply add a "+1" to it -- Suggestion: A review of a support ticket should include checks for whether the relevant information has been added to FAQs, troubleshooting or other parts of the user manual - -## What do people think of the new "Pending Tasks" board? - -The board is very useful for time-sensitive tasks and is good for workflow management. - -A couple of people thought the name was not representative of the use case of the board. - -### Sub-discussion: Why are tickets referenced on the board with a note and not simply the ticket itself? - -We wanted to add the time to the ticket so the answer was to reference them and add the date as a note. - -We decided that if the ticket is on the pending tasks board we should add the date to be done on/by to the name of the ticket, as in "ticket-land" we would not necessarily know that the ticket is time-sensitive. - -## Our builds/system tests have failed because the db unit checker reports a bad db that has just been pushed - -It shows that our continuous integration is doing its job at least partly. - -We should have a process that stipulates of running the db units checker on our code before we merge a pull request. - -Ideas: - -- Have this on a git hook (there is a Friday ticket for this already) -- This should be on the reviewer's checklist when reviewing tickets on EPICS-ioc - -## Our system tests are unhappy, this makes us unhappy - -Having all these tests tangled up it is very difficult to know when a bug or problem has been introduced into the codebase by accident. We would like to be able to turn up and say "The system tests are failing which isn't like yesterday so what's been added to the codebase since then". - -First step: Work out why our tests are failing! 3 tickets should be made (one for each system tests pipeline) to review why this is happening. -Second step: Once we know why we should make a plan to improve our system tests and actively work on - -Also noted: If we could finish the parallelisation of the system tests they would be easier to run on our machines so understanding why one has failed would become easier. This would, however, increase the complexity of the system tests so it could possibly cause more issues. - -## Should we prioritize reworks in the ready column? - -Yes, for definite. - -When we have done a review and set it for rework we should tell the assignee that we have done so. They can then prioritise their work accordingly. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2019.11.06.md b/doc/processes/retrospective-notes/Retrospective-Notes-2019.11.06.md deleted file mode 100644 index 761f60c5c..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2019.11.06.md +++ /dev/null @@ -1,47 +0,0 @@ -# 2019-11-06 - -## How to handle non-critical but serious bugs - -e.g. IOC is updated to fix bug. We know it could be used on other instruments but isn't being used now. What do we do? - -The procedure we decided on is documented [here](/deployment/patch/Modifying-Code-on-an-instrument) - -## Stop doing 0 point tickets - -0-point tickets are skewing the analysis of our capacity to get work done in the sprint. - -0-point tickets are often unplanned tickets such as support. - -There were 2 possibilities: - -- Recalibrate the pointing system to be sensitive and not include 0 points -- Allocate a block of points to multiple tickets that would be 0 points e.g. 5 points to support - -We have decided on the first (recalibration). It has been noted it will take 3 to 4 sprints until we have calibrated ourselves to work with the new points system. - -We need to understand that the points count for when a ticket is started to when it is truly finished and in the complete column. - -Because the points system is now more sensitive to smaller tickets it means that we will get tickets with very high points. This highlights our need to split tickets more carefully, which is something we need to work on. It has also been noted that some tickets (e.g. writing an IOC) do not make sense to split. We need to be careful with how we handle these. - -## What is our process for reviewing support tickets? Should we have a designated support reviewer as a helper to the person on support? - -This question was noted because at one point there seemed to be a lot of support tickets in review that seemingly weren't being reviewed quickly enough. - -Using the flash review process is recommended for support tickets that are small enough. - -It has been noted that we could have a support reviewer that is responsible for ensuring support tickets are reviewed throughout a cycle, though no plan was put in place to do this. - -It has also been noted that most people do, but that we should ensure when we finish a ticket and move onto a review, that review should be of the same complexity as the ticket we have just finished or we should do multiple reviews to match the complexity. - -## We seem to sometimes have reflectometry, pending tasks and HIFI tickets on the IBEX board. Is this deliberate? We don't point and prioritize them the same, should they be on their own boards and not the IBEX board? - -These tickets are also contributing to IBEX so should be in the IBEX board and pointed accordingly as well as their own board. Their own board is more used to track the progress of the sub-project. - -Having these tickets in the IBEX board helps people working in those sub-projects to remain aware of what needs to be reviewed etc. - -We should remove the review column from the reflectometry board. - -## In sprint retrospective should we quickly discuss our progress on the last retrospectives notes and plans? - -Yes. - \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2019.12.02.md b/doc/processes/retrospective-notes/Retrospective-Notes-2019.12.02.md deleted file mode 100644 index 9aadcb640..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2019.12.02.md +++ /dev/null @@ -1,45 +0,0 @@ -# 2019-12-02 - -## Should we make support tickets private? - -The concern is that we include sensitive information in support tickets and that this may either break GDPR or cause security concerns. - -We have decided that we should not make support tickets private. The sensitive information that could be in these tickets (or in regular development tickets) should be placed in the icp shares and a link provided to that information which can only be followed in house. - -## We should have more demos at review - -Yes. The standard should be to demo a ticket and only if there is no reasonable way to do this we will "mention" it. It is worth encouraging people to demo rather than mention prior to the sprint review. - -## We should have fewer single points of failure - -Yes. When handing out responsibilities and jobs we should be more careful to not place the full responsibility in the same person's hands each time. This could be done by pair programming, or splitting tasks into smaller tasks and distributing these subtasks between people. - -We should be aware that it is an issue and consider this at standup and when defining how we run planning. - -## Should the supporter check Nagios oddities spotted during standup? Should these be ticketed as support tickets? - -Our current process is to note the oddities at standup and pass any issues out to people at that point. This is good because we share out the issues to people who may not have come across them before reducing single points of failure. - -It, however, has been noted that we have a few persistent Nagios issues that should either be ignored or chased down. We should create a ticket to deal with these, maybe as part of our fix all tests day? - -We should not put too much time into this as Freddie is setting up a new monitoring system. It has also been noted that not only Freddie should do this. We should do it collaboratively to reduce single points of failure. - -## Dealing with unique challenges of talking to hardware and limited testing - -We should make more use of our test instruments/have a more structured approach to using them. No concrete plans were put into place about how to make this reality. - -## Sprint planning took 3 hours, is this ok? - -In short: We are agreeing to spend more time on sprint planning (3 hours with structure breaks). We aim to take a more conscious approach to not talk about implementation and instead focusing on acceptance criteria. - -We came to the conclusion that the extra time is ok. We possibly have not been spending enough time planning. We have a large team with relatively long sprints. - -However, we recognise that we need to take a more structured approach and be conscious of how we are running planning meetings. In regards to this, we have decided to lengthen planning to 3 hours with a structure break in the middle. - -We must also consider our productivity in the meetings. It has been recognised that we often spend more time discussing implementation than we should. Though some discussion is necessary to understand pointing we often go a step further than is necessary. We have planning poker for a reason and we do not need to talk in as much detail to decide upon points. If we must discuss detailed implementation in a group this should be done in smaller more focused discussions at another point. - -We should focus on creating acceptance criteria for tickets and either agree on them in the meeting or if we cannot we should have a process for dealing with this. What was suggested was to create spike/exploratory tickets with the information we have and then spin out new tickets with solid acceptance criteria. We do this to a certain extent but maybe a more structured approach should be taken? - -We have also noted that we may need to structure our tickets better with flow charts and acceptance criteria in a standard format. - -It was also noted that preplanning has often taken longer than expected as well and we should consider how the whole process fits together and affects each other rather than just planning. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.01.08.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.01.08.md deleted file mode 100644 index b95c583f3..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.01.08.md +++ /dev/null @@ -1,30 +0,0 @@ -# 2020-01-08 - -## Losing track of requirements - -Some requirements of the system, especially those which are older might only be held in the memories of developers rather than written down. - -We concluded that all requirements must be covered with system tests. This would prevent any more requirements from only being honoured by the developers who know them. - -To make sure that we haven't dropped any requirements, we should go through the IBEX requirements document (~70 pages) and use this to generate more system tests. We should not do this all at once. - -## Statistics on sprints - -It would be useful to see the stats on how many points we have completed in the previous sprint before the review. - -These statistics are already made as part of managing the IBEX project. What would be distributed would probably be the number of completed tickets at the point the report was compiled. - -## Do we list the support systems in the release schedule? - -Some of our systems, such as DEMO, have ended up with out of date software, such as SQL. Are these support systems in the release schedule and maintained appropriately? - -Created a ticket to make a decision about the best approach: https://github.com/ISISComputingGroup/IBEX/issues/5072 - -## Dev Release Notes - -We are about to make a release but the release notes are missing a lot of the changes which have been made. - -We should be more careful when starting and reviewing tickets, this process is documented on the [wiki](/processes/dev_processes/Tickets-and-their-Workflow) (and also many PR templates). - -## Config checker and systems tests caught several bugs -There was much rejoicing πŸŽ‰ \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.02.05.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.02.05.md deleted file mode 100644 index a2bfb672c..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.02.05.md +++ /dev/null @@ -1,75 +0,0 @@ -# 2020-02-05 - -We are happy with how well we have coped with a sprint that threw a lot at us. Thank you everyone for working hard. :) - -## ENGIN-X Portable Galil: Could we have identified the cables as the problem sooner? - -Cables were tested individually to spot faults but the issue was that both the cables were faulty and weren't tested together earlier on. - -It is noted that there were a lot of possible causes for the problem and it was hard to isolate the issue to this. - -Solution: A portable laptop with IBEX installed on to test. - -- We will have Kathryn's old laptop when set up -- Need to add this laptop to the releases -- Has an IBEX Builder account -- We should add a local admin account - -## Update list of component stewards - -Yes, we should, it is very out of date. - -People should be consulted as to who should be added. - -The components stewards should all be STFC people at this stage. - -## Script generator testing feels stalled - -This is due to not having or knowing the availability of licenses for squish testing. The licenses are limited to 5 for writing and one for running (used by the builds). - -We need to work out who has a license and who should have a license. We should have a floating license so people who need it but not very often, can use it. - -Kevin will inquire about options for licensing in terms of having a floating license or changing the names on the license. - -## A near trivial ticket #4938 (LOQ Eurotherm) took less than 1 day to resolve, but 45 days (elapsed time) to review. -Why? - -This ticket was not put in review so people were not aware of it. Sometimes these things slip through, but we should always be careful to follow procedure. - -Thank you Dom for checking up on these things to keep it in order. - -## Are we all using the review column correctly? Should it be prioritized? Should there be an urgent review tag? - -The review column is prioritized (the top is the most urgent to review). There is an urgent tag to use that applies to the whole tickets life cycle. - -These urgent tickets should be placed higher in the column and we should be working through the column as per [procedure documented](/processes/dev_processes/Tickets-and-their-Workflow) - -## Training deployment - -Deployments had to be done late the night before training because the training room was booked up the day before. - -We should book out the room for a certain time (probably a day) before the training so we have time to deploy to them. - -A positive point was that our deployment took 3 hours between 2 developers for 16 machines, which is fast, well done John and Tom. - -An alternative to be would be to have virtual machines with IBEX deployed on that we can remote desktop too. This would be a slower experience and we are not sure about connectivity from ATLAS and R78, but this could even be more realistic. - -We have [extensive documentation for training](/processes/meetings_with_scientists/Training-Instrument-Scientists-in-IBEX) - -## This sprint was a bit stressful with EMU and a few things such as IE unexpectedly thrown at us - -We've coped with it well but it would be nice to have something like a Friday to make up for it. - -## We should think about spreading responsibilities away from Tessella people so as not to silo information for when they leave :( - -We need to be able to do things without Tessella people to prepare for them leaving. This includes areas such as support, training and the SANS DLS. - -In all areas, STFC people should make a conscious effort to offer their help when possible and Tessella people should make a conscious effort to ask for help. - -This is as simple as including a third person in a conversation between to Tessella people. - -We could make a label for tickets that it is very important to have STFC people on? - -## Should component stewards be STFC people? - -Yes, as noted in component stewards discussion documented above diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.03.04.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.03.04.md deleted file mode 100644 index 69194565f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.03.04.md +++ /dev/null @@ -1,111 +0,0 @@ -# 2020-03-04 - -## We should update component stewards - -Yes, this was missed after the last retrospective. Some combination of James, Kathryn and John to do. - -## Squish licenses - -- We are happy with what we have for the budget we have -- Floating licenses/more licenses will cost more - -## There are lots of tickets completed πŸ‘ There are lots of tickets also in ready πŸ‘Ž - -- Possible reasons: - - Lots of support tickets (1/3rd of the sprint) - - Lots of tickets leftover from EMU rush -- We are not extremely unhappy about this as we got a lot done, but it would be good to manage it better - -Suggestion: To encourage throughput we prioritize reworks and reviews over current tickets as well as new tickets. - -- Pros - - These reworks and reviews are likely a higher priority than our current ticket so it fits in with our prioritization - - It should encourage tickets to not hang around in ready and review and decreases their time from ready t complete - - May encourage people to document their progress more on a ticket when they are recording what they have done prior to switching to a rework -- Cons - - More context switching - - Switching state of a machine from one ticket to another takes time - -Conclusion: This cannot be a blanket rule as there are many edge cases. For a sprint, we will try this. People should find a practical stopping point in their current ticket to do a rework if the situation arises. The metrics to decide on this will be: does everyone hate it? Has our throughput increased? - -## Should we create support tickets for all work for all instruments (SECI and IBEX) whether in cycle or not and whether we're contacted individually or not - -Yes, within reason. - -- The documentation is useful for future issues to create context -- It should be recorded as support, otherwise, it seems we are pulling in tickets without the proper process -- Helps to capture our effort -- Support is defined as: if a scientist needs help -- SECI tickets should be recorded only if they are of relevance to IBEX -- If a support call took very little time e.g. writing the ticket would take more time it may not be worth it - - It stops being time-effective or useful to others -- If a support call is one of a common theme we should record all them together as a tally to identify areas of the system we should improve - -## We should demo more in sprint reviews - -Yes, we need to take steps towards this. - -- DEMO should be deployed to earlier to give people a chance to set up their demo - - There is now a reminder for a few of us to remind the group we need to deploy at the start of the week so it is organised earlier -- We don't necessarily need to demo on DEMO it can be on our own machine - - Though demoing on DEMO can be useful to point out issues surrounding performance, state that we did not experience on our own machine etc. -- It is a good chance for a dress rehearsal prior to scientist demos (we are a more forgiving audience) - -## Should we try again with inviting scientists to sprint reviews? Relying on "proxy" product owners has failed multiple times recently - -- We are happy with the current process of having separate scientist demos. -- Getting them to come is difficult and would extend reviews a lot. -- However, we should be more strict in demoing to scientists. - - We should organise these as part of the release (added to the ticket template) - -## Clean up after upgrade - -Upgrade process was leaving a trail of mounted network disks. Upgrade scripts should clean up after themselves. - -There is a ticket for this. https://github.com/ISISComputingGroup/IBEX/issues/5208 - -## Dashboard bug: This was an unnecessary own goal. Why did our testing (system, automated, manual) not catch these? - -Reasons why it wasn't caught: -- Wouldn't have been seen unless we had neutrons -- We haven't got 100% coverage -- The push for EMU made us rush -- Mistakes can be made -- Our simulation isn't very strong for pretending we have neutrons - -Actions: -- We should be more aware to use TDD - - It is noted that it is difficult to know what to test on legacy code and that it is easy to spot a bug when you know what bug you're looking for -- If we demoed it may possibly have been caught, we should be more strict with demos - -Positives: -- We were fast and reactive with our fix -- We are more aware of this now and know we should be more careful in testing and reviewing - -## EMU: Switch back to SECI failed because of the presence of 32-bit Open Genie components. Is it likely to occur on other muon instruments? How should we avoid? - -- This is now fixed -- There may be more banana skins -- As part of our migrations, we should test that we can go back and plan for a possible switchback - - This has been added into the steps here: https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Migrate-an-Instrument-Control-PC -- This was tricky to catch -- We should have a set of standard things to test across similar instruments e.g. motors for refl and start/stop for every one - -## Linter is perceived as slow by some instruments. The linter may not really be slow, but is perceived as such by some instruments. How can we make ourselves more conscious of performance? - -- We have a ticket and ideas for speeding things up. https://github.com/ISISComputingGroup/IBEX/issues/5210 -- HDDs rather than SSDs have slowed us down here, there is a plan to upgrade. -- Manual tests should have time limits. -- Demoing and testing on demo should help us with this. -- We should try to be aware of how our code changes performance. -- Memory leak has added to this concern -- We should consider writing more squish performance tests -- We should check with the SAG how important they think performance enhancements are -- ScriptServer may help with the speed - - We should add linting to the script server - -## Make a standard email to send release notes out when we make a release. Release process should include sending this out. - -Yes, added to the process in [creating a release](/deployment/Creating-a-release) - -[Standard email format](/deployment/deploy/Updating-Instrument-Machines) (not necessarily a good email, please consider it's contents). diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.04.01.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.04.01.md deleted file mode 100644 index 8a7707aee..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.04.01.md +++ /dev/null @@ -1,25 +0,0 @@ -# 2020-04-01 - -## We still didn't update component stewards - -This keeps being missed. - -## We should repoint tickets before planning - -- Now added as step to [sprint planning](/processes/meetings/Sprint-Planning) - -## At least whilst working from home retrospective notes should be put in a dedicated teams channel - -## In teams we can't use ticks/crosses easily for flash reviews - -- Instead use shocked face emoji as looking, happy face as approved and sad as rejected. -- Using a spreadsheet is too heavy so remove this - -## Should we come up with a template for instrument demos? - -Yes, the demo ticket should include this. We should make sure that more junior members of the team have sufficient input in to doing demos. - -## Reviews have slowed since moving to working from home - -- This could be due to people not being confident in how to review - we should make sure that PRs include instructions on how to review -- We could monitor who is owing reviews but this seems a little draconian, John will look into doing it. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.05.28.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.05.28.md deleted file mode 100644 index 134de8341..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.05.28.md +++ /dev/null @@ -1,38 +0,0 @@ -# 2020-05-28 - -## Specific Device IOC Pages on wiki - -As discussed in previous retrospective the [Specific Device IOC page](/Specific-IOCs) has grown to be about both the software and the hardware. This means that having the IOC in the title is misleading. It may also be good to review the kit we have listed there and make sure we have a good amount of info for devices and that they're well organised. I have added a [note](/processes/meetings/Technical-Debt-Stand-down) to do this in the next tech debt stand-down. - -## Organisation during meetings - -We can sometimes overrun or get off topic in meetings. This is especially bad on ZOOM as it's harder to pick up on social cues and there isn't someone physically kicking you out of meeting rooms. To help with this we should have a checklist of things we do at the start of each meeting, if appropriate: -* Explain the meeting's purpose -* Appoint a time keeper, responsible for saying if the meeting is overrunning or suggesting breaks when appropriate -* Appoint someone to take minutes if decisions are being made in the meeting - -We should also ensure we pause if we drastically change topics so that people can have a chance to leave the meeting and notify people on teams if we feel that others might be interested in the topic. - -## Onboarding - -We're onboarding a new member in August, this may be tricky whilst working remotely. We have to be particularly careful that we: -* Make it obvious that lots of people are asking question all the time and that it's encouraged to do this -* Make sure we make efforts to catch up with new starters and see if they are struggling with their specific ticket - -Adam mentioned that one thing he would have found very helpful as a new starter is a step by step guide on how to write an IOC, see [here](https://github.com/ISISComputingGroup/IBEX/issues/5435) - -## Working Remotely - -We haven't had so many unplanned tickets, which is good. This is likely due to no support and less casual interactions with other groups. Losing these casual interactions, especially with scientists, may be bad: -* There may be information we're missing from the 'bumping into' scientists, they also might be less aware of what we're up to. On the other side it might be good that people are only getting in touch when they have important information to share -* Teams isn't great for casual discussion as it's limited to chat within teams rather the whole organisation -* We have the IBEX users group in teams but it's not been widely used. We should start using it ourselves to announce things in a casual way, which will hopefully lead to more scientist use. John will use it to announce the `b.` namespace introduced in https://github.com/ISISComputingGroup/IBEX/issues/5401 -* We should make sure that we responds on this teams chat quickly to encourage people to use it - -## General thoughts on the sprint - -* We missed the target number of points for this sprint -* Having a visible burn-down chart that is automatically updated would be good. We currently have an automatically updated spreadsheet but no chart (http://shadow.nd.rl.ac.uk/ibex/) -* We should avoid taking things out of the bucket before reviews -* Can we set up a tool to tell us how long a ticket has been sitting in review. Freddie will add functionality into the project board task to tell us when a ticket has been review for over a week -* There was some discussion on how to remember when you have tickets that you asked to be reworked that you need to re-review. It was suggested that people put a note on the ticket or look into configuring gut hub alerts for this diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.06.24.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.06.24.md deleted file mode 100644 index 615eb1da0..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.06.24.md +++ /dev/null @@ -1,66 +0,0 @@ -# 2020-06-24 - -## Previous Retrospective - -We should make a ticket to add to the project board checks that notifies us when a ticket has been in review for a week or more. Currently, the project board checks code is not in git. - -## The new method of running planning and pre-planning, where we point as we assign to high, seems to cut out a lot of duplicated discussions and lets us have shorter meetings. - -Yes, we like this! πŸ‘ - -## Could we use the same password for all zoom meetings and have it included in the email? - -This issue has been resolved by clicking the link. There are two passwords a numeric for the phone and a regular password. - - -## Recording Architectural decisions - -There was a discussion at the LabVIEW user group meeting today about documentation. One thing that was recommended as particularly useful by one contributor (and seemed interesting to me) was to keep architectural decision records (ADRs). We often meet to discuss things and make decisions but don't necessarily formalise the results so they can be tracked and easily located later. They might also have an audience in our user base and in training for future developers. i.e. why is it done like this? - -https://github.com/joelparkerhenderson/architecture_decision_record - -We have a [decision log](/processes/Decision-Log), which is being used more and more, and it is becoming useful. We should use a more solid template. The link above has some good ideas of how to layout this template. - -## Added tickets - -John created an added tickets channel. Kevin has already been recording these added tickets. It is useful to be able to track which tickets have been added and why. Therefore we will create a label and people are expected to write on the ticket why it was bought in. John will remove the Teams channel. - -We need to be aware of why we are adding tickets and we should only be doing this in discussion with others (especially those likely to disagree with us). We should also look out for patterns emerging with tickets being added in. If there is a pattern we need to plan to reduce the need to bring in tickets at the root, maybe something is not currently robust enough or we need to consider our planning further. To find this pattern we will need to look at the reasons for tickets being bought in and possibly flash reviews (though we do not want to add extra process to flash reviews as that is not their purpose). - -## How do we think the background phone call for tech debt day went? - -Some felt it useful and enjoyed being connected with the team, others weren't so interested. If people wish to create it then on Friday afternoons they are encouraged to do so, making the idea become semi-regular. People don't have to join in if they do not want to. - -## We didn't get full participation in tech debt stand down. Why? Do we care? - -We rarely ever get full participation. Some feel there was less this time around, others feel there was the same amount but different people were involved. We still believe it is above the threshold before we start to wonder if the days are worth it. People aren't obliged to join in, but it is a nice opportunity to work on something different. - -## Panning poker site vs zoom poll? - -We prefer the site. The only issue being that the values don't match our scale. There are other sites we could look at though. - -## Microphone quality - -Some people are difficult to hear in meetings due to low quality microphones. It is not always obvious to the person speaking. Thomas, Bish and Chris now have solutions or solutions are on their way. We can test out our own audio in Teams and Zoom. Dom is a `dalek` today. - -## EPIC tickets processes - -We like Kathryn's suggestion:"I'd like to propose the following process, that should allow enough sanity for whoever is tracking the points, as well as being able to be worked with in a sensible fashion: the EPIC is added to proposals, we point and timebox against the EPIC. When the end of the timebox, or end of the sprint is reached - whichever comes first - points are assigned to the sub-tickets that were undertaken, the EPIC is sent back to the proposals column (if there is still work to do on it), the points value and timebox reference removed, as well as the face of whoever was working on it so that we aren't prejudiced for prioritisation. There is probably some refinement to this needed, but it might make it less painful for us to use them" - -## Only 3 tickets in review and only 1 of 4 tickets in ready were not reworks - -Yes, we like this! πŸ‘ - -## Regular snapshots of the burn down graph are useful - -Yes, this is really helpful to see! We don't want to end up chasing metrics though. - -## New style of release notes was very helpful during demos and drop-in sessions - -Highlights and breaking changes sections are good! Make sure that the person doing the ticket writes it in a nice and verbose way. We should add writing the highlights and breaking changes into our processes. - -## Timings of the review meeting - -Can we do a time per ticket in the review? Another suggestion is to put estimated times on the slide. - -What we chose was to order the review slides by the longest time first. When someone puts their slide in they should insert in between one that they believe to be longer and one that they believe to be shorter. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.07.22.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.07.22.md deleted file mode 100644 index 158ebd013..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.07.22.md +++ /dev/null @@ -1,63 +0,0 @@ -# 2020-07-22 - -## Previous Retrospective notes -* Still need to make the ticket for stale reviews (DO will make and propose for next sprint) -* Architectural decisions - getting better at using the [decision log](/processes/Decision-Log). Copy the style of the last decision is the current 'template' -* `added during sprint` label exists - label being used, adding a comment or to the description seems to be used appropriately and we should keep doing so -* Friday open channel - didn't really happen, but if we want to do it we should. Should make more of an effort with the new starter -* Burn down charts are good - the pinned info on teams was highlighted -* Release notes style is better - but must remember during demos that there are previous releases that need to be included when talking to the scientists -* Timings of the review meeting - this one was a short one, but we think that shortest first would be a better order for ease of timings, it would be helpful to add a rough idea of how long the slide should take (sprint review template created and uploaded) - -## Addition of size labels - functionality added with no documentation -Documentation has been added since -In use on all public repositories, based on the number of lines of code, adds the size automatically on creating the PR -Some people find it useful, others see it as nonsense - use the information if you want to - -## When marking as impeded need to make sure we add a reason why -Sometimes this is forgotten, brought up as a reminder - -## Starting to get a lot more late arrivals to meetings -We will start on time anyway -You can always log into the meeting before it starts -Consider using snooze not dismiss (so 15-minute warning, hit snooze, 5-minute warning - log on) (Editors note - you can change the delay on your pop up from outlook if you have it open in your own calendar to something else possibly if the standard 15 minutes doesn't suit you) - -## Coffee often has low attendance -Some people not necessarily willing to start the meeting if no one is there already - it is suggested that you start it and carry on working - put it in the background -Camera off is fine for coffee -Whilst working remotely we are meant to have two meetings each day, and coffee is our second one, better attendance would mean we don't have to consider something more formal -Leaving early is fine, arriving late is fine - -## The burn down chart we are using shows an increasing gap in the number of points between completed tickets and the total number in the completed and review columns - we are implementing more tickets than we review -The end of the sprint will have been thrown by the release etc. but the gap increased slowly from the beginning -The number of tickets in and out should be staying static, but the number of tickets has increased as well (end of the previous sprint there were 3 tickets in review, end of this sprint there are 11) -There are some instances where there is nothing available to review either because they need specialists to review them, they are already under review, or they were by the developer looking for a review -A code chat on how to review was suggested, it has been added to the ideas list and will be done sooner - this would be a discussion rather than a presentation -Will create a channel to go through reviews, what was hard, what was easy, things that have been left off, things that should not need to be done by the reviewer -Consider doing reviews as a group again for some tickets -Flash reviews - maybe need a different process, also need to get better at rejecting flash reviews - if you can't review it in less than half an hour using just the git code view it probably isn't a flash review -We will expand the use of the flash reviews channel to include urgent reviews as well by adding a link (e.g. for test fixes) to the ticket (rather than the PR), as anything that will take more than an hour combined should be accounted for with a ticket and points - -## It great to see a good number of live demos, and they were good demos too - -## Were any of the tickets added regressions of existing functionality? Are there any patterns? -Yes - we caught them and fixed them in the manual testing -Previous regressions - yes, some had been seen before in other releases, some had appeared historically and not been fixed. -Macros not being saved - needs a Squish test -If it can be automated and failed then we need to need to get it automated -Need to check if we can have a squish day, but need to confirm how many instances can be used at a time -The spreadsheet is long, and not straightforward, need a system test day to automate those that we can and verify those that we can't and what can be fixed -Need to also consider other ways of recording the tests and their statuses - -## Do we want rotas for the meeting roles? -Possibly useful: one for chairing, one for timekeeping, one for note-taking - create and try them - -## How did the release go? -It was close to the line, and it was stressful - there was quite a bit of out of hours working to get it done -There is a mix of it feeling that it is a long time before it might be used for various reasons, however, we are deploying and going to be able to demo before the scientists need to use it which is a good thing to have achieved and probably better for our reputation -Releasing close to cycle has risks, and it was asked about releasing again before the cycle, any bugs found we can patch and fix, but not release new features as we are currently unable to test thoroughly enough for that "last minute" style of release -That kind of "last-minute" release can be done confidently, but it takes a lot of time to reach that stage of test coverage -There was a discussion about bugs being released and the impact, and how far we are from being able to test everything, OPIs are an example of untested items which are widely used - -## There is a reflectometry goal being aimed for, and there is a plan for that which has increased confidence -There was a brief discussion of plans and their usefulness in tracking progression - whilst a plan might not last long, it is often reassuring to have a starting point at least \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.08.19.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.08.19.md deleted file mode 100644 index e7c615f20..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.08.19.md +++ /dev/null @@ -1,50 +0,0 @@ -# 2020-08-19 - -## Previous retrospective notes - -* We are fine with the size labels on PRs -* We are fine with the way impeded issues are handled -* arrival at meetings- got better immediately after but diminished again, we will start on time anyway -* Might try to virtually "get up" in teams to prompt others to join standup -* coffee attendance is slightly better but still less than ideal. -* we were implementing more tickets than reviewing, this seems to have changed now - - this being brought up has driven people to review more - - we've got more points done than predicted, maybe because of not doing as well last sprint. - - try not to read too much into the burn down graph -* meeting roles seem to be working -* did we make this release more stressful by imposing arbitrary deadlines? Possibly, but it's more likely that they will always be stressful - - maybe don't leave enough time between manual system tests and first deployment - - need to have a meeting about manual which system tests need to be removed - -## Recording zoom code chats -* can only store them for 3 months anyway, and need to have permission of all involved, so might be not worth the effort -* especially if something changes in the future making the code chat outdated, a new watcher might become misinformed -* only record if somebody is unable to attend but wants to see it -* only record if everyone is comfortable being recorded, if you are uncomfortable being recorded but not willing to speak up about it, contact K.B. or D.O. and they will champion the issue. - -## Mantid has a week after release to tidy up -- this is equivalent of our tech debt stand down, but for a week. -- Mantid has more of a need for this than we do due to the size of their team and the manner in which they manage their development -- We might put aside a "no new dev work" sprint in long shutdown, and maybe 1 week per year of this, but no changes right now. - -## Should we run the system tests locally more? -* No, this is the purpose of the build servers, only run them on your machine if you think it will break a system test -* Could try to put something on Jenkins to highlight what was added since the last success, but this might not be possible/helpful given the large number of repositories they are reliant on -* Perhaps add a step in the PR template to check if anything might impact a system tests, but might be hard to follow due to breadth of system tests - -## Instrument demo pages -* Change it to one page with headers for the each release instead of one per demo meeting. -* Move all previous pages into same format. - -## Low scientist attendance to some demos -* If only one person is attending molecular spectroscopy demos each month maybe add them to another group to save dev time -* Potentially present to their group meeting, check with them. - -## Good progress with points completed -* we've got more points done than predicted, maybe because of not doing as well last sprint. -* try not to read too much into the burn down graph -* will see if it continues to next sprint - -## Stand up order -* If people want to change it then they can do so at their leisure, list is useful so people don't get surprised by being at the start, also highlights people who aren't there. - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.09.17.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.09.17.md deleted file mode 100644 index 39e8fddb3..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.09.17.md +++ /dev/null @@ -1,38 +0,0 @@ -# 2020-09-17 - -## Previous retrospective notes - -* Try recording code chat in upcoming code chat -* Mantid has a week after release to tidy up - Not necessary for us as because of our development management style -* Only run system tests locally if you think it will break the system -* Instrument demo page - One page with headers for each release instead of one per demo meeting. -* Sprint 2020.08.19 went well -* Can change stand up order - - - -## Making Review easier - -* Suggest classes/files as a starting point -* Leave some tips on reviewing - -## Undocumented features - -* Some tools such as slack were still being used by the IS and the knowledge about the tool was not distributed evenly nor maintained in the wiki -* Document any information/features that you know which could be useful to the team for development/support. - -## Hard to keep track of support Email (answered/unanswered) - -* Possible to remove fluff? -* 5-6 different email for the same topic which is hard to remember (maybe get in touch with Freddie?) - -## Test environment for our product - -* Installing and running script generator was fine on dev machine whereas it failed on user's machine. We should always test the installation process in an environment which better represents a user's machine. -* Careful with acceptance criteria -* Think about pre-requisite - - ## Deciding when to move sprint meetings and prioritise other tasks - -* Let others know that you will not be able to attend sprint planning during stand up -* Poll to reschedule sprint meetings \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.10.16.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.10.16.md deleted file mode 100644 index 163fd29d9..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.10.16.md +++ /dev/null @@ -1,97 +0,0 @@ -# 2020-10-16 - -## Last retro - -- We should remember to leave notes for the reviewer -- John will make a page for undocumented features -- We should put emojis next to the email in teams to say we are handling the email -- We should always reply from experimental controls where appropriate rather than our own email -- Freddie will bypass footprints and send directly to experimental controls mailbox for SANS or the Muons -- Dom to check if ticket for script generator testing environment (Ticket is [here](https://github.com/ISISComputingGroup/IBEX/issues/5701)) - -## As per an article in in.brief from HIFI. To quote: `Thanks to the work of the ISIS computing team, the group were then able to access the computers that control the beamline, turning their office into a replacement hutch for the week` so the solutions we put in place are being acknowledged, and are proving useful - -Chris MS: Yes, nice to get that warm fuzzy feeling - notes of diamond and a hint of rabbit too - -## Just a note to recall that technical chats should happen in the technical channel, as it gives people the option of dropping in if they have something to contribute or want to learn about something. It also provides an indication as to whether the conversation has been had or not so that we can see that the help has been given if needed, or not as the case may be - -We should make an effort to move private chats to technical where appropriate. Though we often do this, the more effort to do so should increase knowledge sharing and allow people's input who may otherwise not be involved. - -## [10/6 12:33 PM] Oram, Dominic (STFC,RAL,ISIS) - -Tom, John and I had a discussion about the best way to treat patches that instrument scientists send us for general IBEX code. With a view of wanting to expedite these to encourage scientists to work with us we thought the process should be: - -There must be a ticket created with the code attached in some way: - -- This ticket is a support ticket as we're supporting the scientist in getting their code into IBEX but is therefore 0 points -- The ticket goes straight into review and is reviewed by one of us in the usual process -- If we're happy then it's merged, if not we put it as rework and ask the scientist to do the rework. If the scientist is not happy doing the rework we will propose it as usual for one of us to look at - -I'm trialing this process with [#5776](https://github.com/ISISComputingGroup/IBEX/issues/5776) - -[10/6 4:20 PM] Woods, Kevin (Tessella,RAL,ISIS) -I think this is a good idea, but I have a couple of queries: - -- Is it really a 0 point ticket? If it requires anything other than a trivial amount of effort, then it is not a 0 point ticket. -- Scientists don't always consider the wider picture. Their solution might work for their particular needs, but often it won't easily generalise or may not be maintainable. We should take care not to accept code that generates a high maintenance overhead. - -Yes we agree, though it should not be a 0 point ticket. -Dom will write this process onto the wiki. Done [here](/processes/dev_processes/External-Contributions). - -## As well as when preparing new instruments we should probably consider IBEX and genie_python training more regularly as a reminder and most especially for new starters - -When we do IBEX training we should invite others than the targeted instrument. We should also run a yearly training course to catch any new starters and others that feel they need training. - -## We now have support calls coming in via a number of channels - e-mails (whether direct or to ISIS Experiment Controls), Teams, phone calls (and Zoom voice-mail messages). Should we have someone who is responsible for making sure each incoming issue is assigned to an individual for investigation & resolution? The task could be done on a weekly rota basis (like the role to run the daily stand-up meetings - in fact, it could be done by the person running the daily stand-up meetings) - -Traditionally this has been done by the "ISIS supporter of the week" who is also the on call person in the evening, but including more people in the role is probably a good idea - -[Monday 10:15 AM] Woods, Kevin (Tessella,RAL,ISIS) - -OK. In that case, maybe all it needs is for the "ISIS supporter of the week" to make it clear that incoming issues have been assigned and/or are being dealt with. Perhaps just a quick message in Teams? - -There is a supporter of the week who should make sure everything is being handled. This is not necessarily to handle it themself, but to ensure someone has taken an action. Supporter of the week should put emojis on the dealt with emails in teams if the person handling it has forgotten. - -We should all log into zoom when we start work so we can pick up calls. Freddie will move the zoom call hours to be 10-5. - -## nagios being extremely slow often slows down standup while we wait for it to load. Could we get nagios moved to a faster server? - -It's very * 3 painful. - -It is on the list of things to move onto better servers. - -We will leave it as it is and just handle it at standup. - -## I really like the oversight that we get with people using the ISISExperimentControls email address. Can we expand it more to include things like the discussion being had with PEARL about migration? - -This would enable sharing of information between us. - -John thinks that we should trust everyone to do work and then ask if help is needed and write docs to summarise. This would avoid clutter and noise on the email. We should add any information and conversation from emails onto the ticket. - -Conclusion: If a ticket has been written from an email chain then we should put it on the sharepoint and link it. - -## We have a number of tickets that are still on the board, have had little movement and we just move from sprint to sprint. Even worse there are tickets in the backlog that have had work done on them a while ago but no subsequent movement. This makes me sad because it feels like we have a lot of half finished jobs that we are close to being able to call done but not quite. How can we get these tickets over the finish line? If the people that were doing them are now busy can we assign others to just finish them off? Could we do a tech debt day on just going around and finishing these tickets? - -Kevin: Seconded, Attached is a list of the tickets marked as "in progress" today (13th October). I have highlighted in red tickets that have been "in progress" since before the current sprint (I strongly suspect these tickets are not actually making any progress). I have highlighted in yellow tickets from the current sprint that have been "in progress" for over two weeks. - -We still have some tickets like this. There have been some tickets in the backlog that were not on the board but were actually complete. There are also tickets out there we need to document and test but were "completed" a long time ago, we should not be afraid to admit we don't have the time and ask for someone else to finish it off for us. - -Let's create a label saying "I don't have time to finish this can someone else pick it up" which means we don't have to take people's face off them. Done, see "To pick up" ticket. - -Lets check the in progress for stale tickets. - -## We've done most of a cycle with users on python 3 :) - -Yes! :) - -There were a few wobbles. - -## We have been hitting our target for points done in a sprint more since we can see the burndown chart - -Yes! - -It can feel artificial and a bit micromanagementy. It is also not truly accurate. - -Some feel more motivated because you see progress. - -Reminds us if there's loads of support tickets we haven't put through. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.11.11.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.11.11.md deleted file mode 100644 index 3e01fb467..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.11.11.md +++ /dev/null @@ -1,53 +0,0 @@ -# 2020-11-11 - -## Last Retrospective - -- Documentation for our approach for external contributions [here](/processes/dev_processes/External-Contributions) -- Invite for training course went out to all scientists. Had 3-4 extra scientists join that were new to ISIS. We should perhaps run one every couple of releases or so. -- Running the training course remotely went fine. Lessons learned: - - Could have used some more training machines to be set up - - More time would have been beneficial in places - - It was harder to bring additional trainers in a remote course. Only one can speak at a time, as opposed to in person, where the second trainer can walk around and help with individual issues. -- Supporter of the week: Can't tell at the moment how this is going, we have not really been in cycle yet -- Had another case where replies from scientists got missed because the initial email was sent from a private inbox. Please remember to use the ISIS email account for mass emails. - -## Items from this Sprint - -### It would be helpful to have an e-mail template to use when informing scientists that we wish to update instrument control PCs. Obviously, the reasons for each update differ, but there are some common points we should always include: -1. why we are proposing an update -1. when we are proposing to perform the update (making sure we give plenty of notice) -1. asking scientists to respond with days/time that are most convenient to perform the upgrade -1. explain the consequences if a scientist declines the update or fails to respond. -There may be some other points we wish to include. -A template will help us to always remember these key points. - -- Yes, this is a good idea. Should also include a list of issues that are being fixed with the update. DO has volunteered to add a template to the wiki. -- If you are unsure about whether an email to scientists is appropriate, do not be afraid to run it past someone else. This is a common and valuable thing to do - -### Last year we did not run a short sprint over Christmas (sprints starts were 7/11/2019 and 9/1/2020) - this year we currently have a sprint scheduled for 10/12/2020. Do we wish to have a short sprint this year or do the same thing as last year? - -Christmas sprint has about 12 working days. What should we do with this time? We don't want to make this a full sprint to save us spending extra time on sprint planning etc. Options: -1. Extend sprint starting tomorrow to 6/1/2021. -1. Could do a long sprint starting from 10 Dec.? - Means we may come back in the new year and not remember what we planned -1. Extend sprint starting tomorrow by a week to 17/12/2020. New sprint starts 6/1/2021. Week before Christmas is for Fridays/Tech Debt/finishing off tickets - -Decided on option 3. This will hopefully give us a nice clean slate for the new year. - -### It's been a long time since we've had a Friday, can we have a week of them? Or maybe a whole sprint full? See Freddie's message above - -See above - -### POLARIS is happy that our sample changer update caught the fact that a sample was dropped and stopped the experiment so that it could be corrected - -Good! They were happy that while they did lose time, they did not lose much time. - -### Our current sprint is 2020_10_15 but our "slides" are sprint review 2020_11_11, should the ppt reflect the sprint name and not the date the sprint review was carried out? That would make correlating at any later stage easier if required. - -Yes, this is a good idea. Call the file `Sprintreview_start_`. Add start and end dates on first slide - -## Additional Comments - -- We are happy that POLREF is now running on IBEX and SURF is planning to use it this cycle. -- We are making good progress on SANS2D. Different groups coordinating well with each other (us, scientists, network team, ...) -- We are excited about Windows 10 updates. Build is "mostly" automated, process is now documented on SysAdmin manual, everyone should in principle be able to set this up. -- What to do with trivial support issues? Creating a ticket every time seems like a lot of overhead --> Put them in a teams channel, then record them permanently in a ticket at the end of the sprint. `support-issues` channel has now been created \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2020.12.16.md b/doc/processes/retrospective-notes/Retrospective-Notes-2020.12.16.md deleted file mode 100644 index 915667dbf..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2020.12.16.md +++ /dev/null @@ -1,36 +0,0 @@ -# 2020-12-16 - -## Items from the retrospective before last -### Supporter of the week -- If on-call keep an eye on the emails etc -- It's good that people are keeping an eye on it, just need to remember to add the note -- The being on-call/supporter of the week wiki was highlighted -- The wiki page needs updating, including which teams channels to watch over and checking up on pending tasks that are due that day -- DO volunteered to update the notes with some aspects -- CMS will have a look sometime about any other tasks - -## Items from the last retrospective -### Email template -- Still needs to be done, DO will look at this -### POLARIS Sample Changer -- POLARIS was happy, but transferring to SANDALS meant that the system was not easy to use there, partly due to balancing the needs of different instruments, and partly due to the present working situation -### Support channel -- Helpful, but probably need to keep an eye on patterns/trends. However, the developers are usually pretty good at keeping an eye on those -- Useful for the quick issues but which still allows knowledge to be shared - -## Items from this retrospective -### Drop-in sessions and the shared/private email discussion -- Ways to fix the response options are listed, and the wiki has been updated with appropriate instructions -- Training and similar should follow the same pattern -### Release notes -- Lots in the dev notes that were not moved into the release notes, and there may be some that are missing from the dev notes as well -- There are tickets in the backlog that cover this, these will be proposed for the β€œFriday” sprint -- Review should have an entry in the Dev release notes, review complete needs to be added to the scientist visible release notes -### Presence on site not enough if there are multiple tasks at once -- Considering more people on-site to allow for meetings and support, and deal with multiple items -- Remind the other teams that advance warning of things moving that may need help to set up advance warning helps us to make sure that we can provide an appropriate level of support - -## Additional Comments -- Did very well with the tickets, we should be happy with the graph -- Board is relatively clear -- Tickets in progress or in review get completed, tickets in ready and the bucket will be considered for inclusion in the Friday sprint, any not added will be reprioritised as standard in January diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.01.06.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.01.06.md deleted file mode 100644 index bd56ada17..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.01.06.md +++ /dev/null @@ -1,24 +0,0 @@ -# 2021-01-06 - -## Items from the retrospective before last -### Email template -- Still needs to be done, DO added to his list. -### POLARIS Sample Changer -- DO suggested a reasonable amount of time (~3 days) is required with the device to finish off remaining issues. - -## Items from last retrospective -### Drop-in sessions and the shared/private email discussion -- Initial invitation can be sent from shared ISIS ExptCtrls account. Select setting to not require response to avoid clutter. -### Release notes -- New process in place and automation following shortly -### Presence on site not enough if there are multiple tasks at once -- Plan at moment is to have 2 people on site per day if restrictions allow and demand dictates. Will wait to see how current situation develops before deciding on strategy and rota. - -## Items from this retrospective -- Friday tickets not being reviewed quickly enough, true for general tickets too. Reviews should take precedence over rework, especially towards end of sprint. -- Suggestion to have Monday morning for reviews to save context switching between consecutive work days. Developers should at least self-assign tickets to be reviewed at this time. -- Friday "sprint" went well and was enjoyed on the whole. Other ongoing tasks did get in the way of people taking on a specific Friday ticket. -- Discussion about shorter sprints to concentrate on specific matters (c.f. Mantid tidy-up week) "Technical Debt Sprint"? Decided not realistic in cycle, but more likely in longer shutdowns. - -## Additional Comments -- Discussion on GitHub price plans followed main meeting \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.02.03.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.02.03.md deleted file mode 100644 index cdb7feb89..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.02.03.md +++ /dev/null @@ -1,81 +0,0 @@ -# 2021-02-03 - -## Items from the retrospective before last -### Email template -- now done - -## Items from last retrospective - -### Friday tickets not being reviewed quickly enough, true for general tickets too. Reviews should take precedence over rework, especially towards end of sprint. -#### Suggestion to have Monday morning for reviews to save context switching between consecutive work days. Developers should at least self-assign tickets to be reviewed at this time. -- Seemed to work pretty well but not everyone is always available on Mondays to do reviews -- Ended up with a lot in review because we had quite a lot of things under review -- throughout the sprint there were a lot of plateaus in the burndown chart - could be to do with interviews etc. By the end of the sprint we were quite above the line -- the dips on the burndown chart are Mondays so it must be working -- Sprint was in January - quite a lot of things that are out of our control, dark and dingy and not really able to get out much. Given the circumstances we think we did the best we could and the Monday review slot proved to be effective - -### Friday "sprint" went well and was enjoyed on the whole. Other ongoing tasks did get in the way of people taking on a specific Friday ticket. -- it was - -### Discussion about shorter sprints to concentrate on specific matters (c.f. Mantid tidy-up week) "Technical Debt Sprint"? Decided not realistic in cycle, but more likely in longer shutdowns. -- beginning of long shutdown maybe we'll do a technical debt sprint - -## Items from this retrospective - -### We have a number of tickets that are effectively "tidy up hotfixes". Can we have a sprint focusing on this at the start of the long shutdown? -- would be nice to get them more properly fixed -- there are some things we did very quickly last year, it'd be good to look at those again. -- long shutdown probably isn't the right time as they're not that important, perhaps this shutdown would be better? -- list will be made for these tickets - -### Suggestions for streamlining planning a bit more: - -- when we decide a ticket is high priority, leave it in the "proposal" column initially (just move medium/low out). we can then sort it directly into the right place in high later on -- maybe we should do away with "bottom of high column" tickets. we never get to the bottom of high. just put it in medium and save ourselves some time when we order them - - or just make an effort to change our thinking so low is low, medium is medium and so on. Bottom of high should really be in medium. -- when the contractors leave we could think about how effective we are doing planning - it goes on for a long time -- we should see if priority can be done using planning poker on the new poker site as this might be a bit fairer - - -### We should update all the Zoom invitations for all our sprint meetings - Daily Stand-Up, Planning, Pre-Planning, Review & Retrospective - to have Alternative Hosts. That way, we don't have to create a new meeting just because the person who created the original meeting invitation isn't around. -- need to confirm this works on zoom - the issue is somebody being in another meeting they have scheduled and zoom will not let you have two meetings you have created running at the same time. The docs suggest an alternative host can start a meeting if "join before host" is not enabled -- we'll test it out - -### record of systems time -- Have been trying to feed systems tickets from tasks through the project board to keep some form of review possible. Generally it is a case of creating a controls ticket which contains non-public system details and then encapsulating it into an IBEX ticket with a reference. This means that it can be reviewed and passed along though the IBEX board. Currently, it is not possible for me to add an estimate of the time taken to do the ticket as a label other than zero (I think with training) without it breaking the more strict conventions of the IBEX project point checks. - - We could add a few more generic systems labels. in blue, say, which are "1/2 day", "1 day", "2 days" etc. or possibly put the detail in the ticket title e.g. "Clone a new instrument machine (1 day)". This is more of a historic reference - or these points could be added to the control systems ticket in the conventional way - but they may be a bit less visible on the IBEX project board. The systems tickets are very often incremental and can be re-done regularly as a process so this is less attractive - although it could be a guide to the time to run the whole ticket once. - - we could have a separate private repository and a label for them, the tickets in IBEX could point to the private repo. The point of this is so that it can be put on the IBEX project board - - -### if there is a support ticket which doesn't involve any code changes there is not likely to be much in the way of a sensible release note for the users -- we could simply check the label for "support" and skip the release note mechanism -- alternatively, only generate a release note request if someone makes a pull request and not from the ticket itself - -### I like the new release note PR system, should we always change the PR title to be "Ticket YYY: " rather than have "Update ReleaseNotes_Upcoming.md"? It doesn't affect the operation of the mechanism, but I think it looks nicer when listing all the PRs -- If we agree this in the retrospective we could put it as a warning on the checker -- github doesn't make this easy like they do with PR body templates -- we should start doing it anyway -ACTION: Dom should update the project board checks to check these - -### Whether rightly or wrongly, we've stopped using the Reviews channel, are we happy with that situation? -- never really took off, was made for discussing reviewing best practices etc. -- we don't use lunch either as no one is on site - -### Do we need to think about paying for the planning poker site? -- probably, but there are alternatives, we will try them out first. - - trying this out at next planning meeting - -### Creating a new ticket to fix errors introduced by a PR feels wholly and egregiously wrong -- resolved, confusion was caused so next time don't be afraid to change titles to make things clearer - -### How good were our estimates for individual tickets? -- ok, but musr migration took twice as long because jack was involved as well, this isn't a bad thing because now someone who isn't as experienced has been shown what to do for future migrations -- this is probably reflected in the burndown chart - - -### This may not be the appropriate place to discuss this, but if so, how is "Coffee Time" working for everyone? I notice it tends to be a few usual suspects joining, so I just wondered why that might be... Bad timing? People busy? Not keen on chatting? Too many VCs already? This may not be a huge problem, but we do need to at least try to keep in touch. Are people doing that separately perhaps and therefore don't feel the need for a group chat? -- difficult to stay in the zone sometimes when working as its a bit like context switching, not because we don't like talking to people its just difficult -- sometimes have meetings at that time -- do we need to have an evening round-up? -- should we do coffee at the start of the day? or move stand up -- maybe we should have an activity or something for a bit of fun at coffee - show and tell, something else? werewolf? suggestions on teams social channel diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.03.03.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.03.03.md deleted file mode 100644 index 0ec879a47..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.03.03.md +++ /dev/null @@ -1,38 +0,0 @@ -# 2021-03-03 - -### Items from last retrospective - -* Monday reviews are still working well -* We're better at being stricter for high/medium/low -* We have now set general meetings to have alternative hosts -* When systems tickets get added to review (mostly by CMS then they will be pointed based on expected review time) -* Release notes PR system is still well liked -* Games on Friday coffee has attracted more people, which is good - -### Items from this retrospective - -#### New planning site -* No need to add ticket numbers for each story when pointing -* We should start the session afresh before each planning to stop phantom accounts hanging round -* It's ok not to have don't-knows on the priority points - -#### Why are some people quiet in pointing tickets etc -* People have different communication styles -* We should discuss estimates but it might be worth taking less time on wildly different estimates -* Quieter people tend to be unsure and voting on gut reaction (which is fine) and feel like they learn more after the discussions -* We will try the chair being the first person to input in the discussion of points -* By missing out on the quieter people way may be losing the concept of how complex is it for the average developer - -### Adding flash reviews to release notes -* If it's a flash review that needs something in the release notes it's probably not a flash review -* Flash reviews were originally created to be process-light -* We just did a large change in how we did release notes, we should see what users think about this first. Next release we should discuss -* If reviewing a flash review and you think it's very user facing then ask them to put in release notes -* When we do the instrument demos we should ask what people think of the release notes - -### Spread of ticket sizes -* Pair programming more would be good, we may be doing less of this remotely but it's still happening -* We could split tickets more but we're pretty good at this -* We should do more splitting up in an ad hoc way rather than up front as developers will know a bit more at that point -* We should encourage newer developers to pick up big tickets too -* We should ask at the end of planning if we have too many big tickets \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.03.31.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.03.31.md deleted file mode 100644 index 1a0870943..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.03.31.md +++ /dev/null @@ -1,64 +0,0 @@ -# 2021-03-31 - -## From last last retro - -- Monday reviews were working well until this week (mostly with cycle stresses) -- Doing well for using medium and low -- We haven't been putting system tickets in because the review column is long and we're trying to get everything in for cycle -- Release notes PR system we are happy with -- We haven't done games on Friday coffee for a couple of weeks - - This may be work pressures but it would be good to make a bit of an effort to organise/join it - -## Items from the last retro - -- New planning site is getting easier -- Re-voting and the chair starting the discussion has helped to improve the discussion -- If a flash review needs release notes then it is not a flash review -- Big tickets aren't scary we should encourage people to pick them up when it is not possible to split them up - -## How to manage security issues - -- Could use the private git-repo or Microsoft teams board and link from Github -- There are lots of different types of security vulnerabilities and there is a current concern from the organisation about security -- The important thing is that we have enabled a conversation about it in planning - -Action: Chris MS Will ask Anthony from FIT how they do it - -## Ticket, PR and branch cleanup in long shutdown - -- We should do this as we notice them -- We should also do a proper cleanup over the shutdown -- Most of the backlog is surprisingly valid -- Has been added to the long shutdown list - -## What can we do to ease situations like the one we are currently in where we are short staffed (for very valid reasons), but when the urgent workload is high? - -- Shall we do a 5-week sprint? - - We have APRs, new starters, IBEX training, lots of stressful things coming up - - Let's be careful what we add to the sprint - - Still keep a bucket - - We think 5-week sprint is better than 3 week -- Can we only point for 4 weeks of work and do Fridays if we're not doing support? - - Concern is that we underestimate Friday tickets and overestimate their importance - - Fridays are nice to have so may relieve stress - - Or could do technical bookkeeping tickets e.g. the above-mentioned Ticket, PR and branch cleanup (we'll leave that choice up to the dev) - - Fridays do help user experience improvement -- Yes we're going to do this -- Let's talk about this after the fact so we can organise the start of cycle sprints in a more solid way -- We like these ideas -- We can change the length of sprints to ensure releases are created in good time for the cycle - - We can do a full release earlier on and a patch release later - - In the long shutdown, we can do a few releases so we are ready - - Can we get more of a manual release process into squish to reduce this - -## Themed sprints - -- Decide on one or two themes for a sprint -- Prioritise the theme in their own columns -- Have a couple of people dedicated to each theme with others helping them and others focusing more on support -- Needs management because we aren't fully sharing that information with the rest of the team -- People can take on different themes and lead each time so it is shared around - - Ensure people have rotated around so we don't lose the ability to work on lots of different parts of the system -- Support can be set as a theme -- We should bear this in mind in planning -- Kathryn will upload document with idea of how to manage the project with themes and variable sprint lengths diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.05.05.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.05.05.md deleted file mode 100644 index fe02dc1b9..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.05.05.md +++ /dev/null @@ -1,63 +0,0 @@ -# 2021-05-05 - -## Items from last retro -* Managing security issues - current org. concern because of many different types of security vulnerabilities -* Ticket, PR & Branch clean-up - do a proper cleanup over the shutdown, and as we notice them -* Short-staffed when urgent workload is high - point for 4 weeks of work and do Fridays if not doing support -* Themed sprints - -## Future Ideas wiki [page](https://github.com/ISISComputingGroup/IBEX/wiki/Future-Ideas) -- Used for long-term planning, "idea repository". Should we maintain this? - - people haven't added anything in there recently - - unsure of how to keep track of things in the long term - - good place for things that are nice to do and would like to when we have the time - - great place for tasks for placement/graduates -- Keep it - -## Planning Poker Rooms - anonymous voting -- traditionally the selected cards are not anonymous - - would we prefer anonymous, or displaying the vote cast? -- No strong opinions, keep it as is - -## Experiment Controls email - using too much? -- hasn't bothered anyone -- good to see what goes in and out - -## All releases seem to be stressful -- this round has been relatively calm, but it has still had its moments - - there have been discussions in the past, but is it worth thinking about it and revisiting it towards the end of this calendar year? -- do deployments much earlier, 2 weeks is too late; can deploy early is release is ready -- release was getting pushed back because of MUSR, stop doing that - release for all instruments and do a MUSR patch release late -- make sure to tell the scientists that we are deploying to establish hard deadline; scientists also want a window, so they know when to be available -- don't delay the release unless it breaks instruments - if not ready before the start of release sprint, don't add it - -## This sprint has been stressful -- need time to decompress after this sprint -- pushing ourselves hard to get things ready for cycle - this is affecting morale -- we should think about ways to avoid this happening again -- it has been a bit stressful but overall people feel ok -- if it helps, can "dial-down" next sprint - -## Technical articles channel -- we should send more technical articles round the group, should we have a channel? - - don't want people to feel obligated to read it - - reading could be allocated as training time - - see if people are okay with 2 chapters in a month, if not maybe 1 chapter - - neutron training course was the same (though it was more on the physics side of things), while this could be more about software -- this channel could be good training. Try to pick a book or online articles and discuss it at a code chat, see how it goes - -## Support tasks - 0 pointers or not -- How are we counting support tasks? 0 pointers or not? - - allowed to be 0, but if it takes time it shouldn't be - - burndown chart is -20 because of the support chunk - - decide capacity according to trend and keep to it -- carry on with support being 0 as long as it doesn't take too much time - -## Second week in cycle too early for sprint review -- is second week in cycle still too early for a sprint review? still busy on support. - - always going to be hard and there's always the possibility of support calls in the middle of it - - maybe split the meetings to be "less interrupted" if something comes up, instead of having a long meeting -- yes, split reviews and retrospectives. - -## Half an hour is too short for retrospective -- Change meeting time to an hour \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.05.26.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.05.26.md deleted file mode 100644 index 6f8553329..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.05.26.md +++ /dev/null @@ -1,39 +0,0 @@ -# 2021-05-26 - -### Previous retrospective notes discussion - -* Happy to keep burndown chart calculation as is. i.e. begin with estimate of capacity covering all projects - -* Technical Articles meeting arranged and suggestions for books etc. requested. - -* Zero points possible for support tasks, if only few minutes spent. Suggestion to count and categorize posts in "support-issues" channel to spot patterns. Agreed to discuss before next cycle at end of long shutdown. - -* Split of review and retrospective meetings: most people accept. Agreed to alter order of meetings and having on separate days i.e. review Tuesday, retrospective Wednesday, planning Thursday. Will have think about how it could work during next sprint, but not change anything, and try in practice next cycle. - -* Variable sprint lengths also accepted by most, as long as not too long (>6 weeks?). - -* "Friday" ticket time: most agreed with KVLB plan to have a week of them every now and again. - -### Retrospective Notes 26/05/2021 - -* Agreed to keep same chair for both sprint review and retrospective meetings. - -* Suggestion to add alarm history to Alarm view - add to Muon snag list and discuss at later date. Can add Friday ticket label for interesting tasks. - -* Remove "Complete" Column. Easier for reviewer to close ticket at end of review (if work satisfactory). - -* User feedback - HLM website proved useful for tracking a problem. - -* Discuss sprint themes at pre-planning meetings - agreed to continue. - -* "Support" label tickets requiring release notes - discussion on release notes in general. Another label will be created for "Release notes not needed" to apply to any ticket, support and otherwise. Reviewer to check. - -* Snags lists popular, at least with Muon group, also for reflectometry. Will eventually be one for each science group if many requests/problems come in from them. Not everyone in group keen on the idea until after migrations. Some confusion between definition of snag list and prioritised list of instrument tasks. - -* Release & deploy schedule discussed. Balance between features and stability for instrument scientists - some prefer each one. Don't want to deploy too late in a shutdown so IS testing time is reduced. - -* Cable and connector amnesty during shutdown (Short of particular types of MOXA cables). Generally agreed good idea. DPK voluntold to organise. - -* Suggestion to visit each cabin and blockhouse to tidy & label wiring, especially in rear of cabins. Possibility for a Friday or TechDebt ticket. - -* Cycle went well. Support calls at manageable levels, although busy at start with hardware issues (DAE etc) as well as week before. POLREF unlucky with many issues. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.06.23.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.06.23.md deleted file mode 100644 index b64311f2a..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.06.23.md +++ /dev/null @@ -1,92 +0,0 @@ -# 2021-06-23 - -### Items from the last retro: -* add Alarm history to alarm view - hadn't been added to Muon snags list, has now, discuss at later date. -* "Support" label tickets requiring release notes, this has been changed we use the "no release notes" label now if things don't need release notes. -* Return to discussion about snag lists and balance between features and stability for instrument scientists. Meeting with group leaders in future might help with this. -* Visit cabin and blockhouse to tidy & label wiring only had a ticket for one instrument. Tickets for all or large ticket with checkboxes? Do this with someone else, will be difficult with 1 person, possibly 3 on pearl. -* Cable amnesty, a start has been made, but possibly talk to halls committee? problem of not knowing where cables have been so don't know if they need checking etc. Ask health physics for advice? - -### Email to teams: -* Create a ticket in support issues. Discussion should happen here. -* Have emails forwarded to more people to avoid having it marked as read if it's seen by anyone. - * note for who would be happy to have emails forwarded to you from the exp-controls inbox. - * Possibly forward ticket only the first time, this way you don't get all the replies? - * Ticketing system? get Footprint status? - * almost no one used Footprints web interface, this is why its in teams - -### Proposed tickets were added to the planning board before the pre-planning meeting. Good! - -### How did Tech debt go? -* Tried something different with allowing a bit more time rather than tech-debt day. -* Never had the planning meeting because we were partway through the week and the pre-tech debt ticket wasn't finished yet. -* A lot of people didn't get much tech-debt done because of having things to do already probably because of not having a meeting? -* Will be stricter next time with tech debt. -* didn't feel like people were willing to engage, and cycle was a pain so not pushed, next tech debt isn't in cycle. - -### Work-life balance -* messages and emails out of working hours can lead to a lack of work-life balance and burnout, please take time when your not always thinking about work. - -### Reflectometry Board -* Purpose of the board is to give a prioritised list to pick items from. - -### Change to automation of review complete column -* Change the name to done? -* if something is closed we can know what state it was in. -* completed label has been removed - -### Issue Templates -* Discuss at next retrospective when Jack is present? -* Suggested template has a lot that would need to be removed -* At least having headings might be useful -* Similar to Pull request templates. -* a lot to change on the first line so might as well delete, could just be less detailed about what needs to be in it because new people could just look at other issues and experienced people would just delete it. -* can we select different templates? - -### In Progress Impeded and Ready -* Labels are useful, could be helpful on different project boards. -* Possibly automate them? - -### Un-touched project boards -* several project boards haven't been updated since 2019 -* support board leftover from before teams channel -* remove them - -### Burndown behind or not? -* discuss another time when relevant people are here. - -### Investigating new technologies -* When do we try new tools that might be useful to the project? -* Migrations have to be done, so give the first 6 months to see how well migrations are going perhaps? -* Raise technology and discuss whether possible benefits are worth further investigation. -* Future ideas board? -* Fridays come in weeks, good time to look into it? -* Review migrations to see if we're ahead or behind and then consider them, possibly 3 months in. - -### Meeting times -* A lot of the time only 1 or 2 people in meeting room at the start -* are times/days problem or people not being ready? -* This review/retrospective has had a very short review, somewhat a-typical. - * more often runs on to 2 hours. -* We split them while we were in cycle to avoid missing both due to support. -* once new starters are in address that's a good time to update it -* Having them together means it can work as this time needs to be free. -* Split them during cycle and not outside of cycle -* block out more time, start earlier, finish same time, more time for a break between review and retrospective if the review takes a full hour. -* 3 o'clock start and 1.5-hour run leads to outside of core hours. could move it to 2 until 4 but most people not bothered by 4:30 finish. -* Start at the same time but have a longer break, very likely to overrun. - -### Important dates -* Server shutdowns and electrical shutdown dates made be useful to have on the experiment controls calendar. -* Other important dates might be useful to have in there. -* check if shared calendars work with alerts. -* Overlaying of calendars. - -### Students -* how often coming in -* supervision of them -* get higher occupancy of the room? have screens added? - * may have to wear a mask -* needs quick resolution -* have them on site the first week, but possibly not have them in every day that week? - \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.07.21.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.07.21.md deleted file mode 100644 index b84bfc57a..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.07.21.md +++ /dev/null @@ -1,54 +0,0 @@ -# 2021-07-21 - -## Items from last retro - -- Tech-debt and Fridays have been collaborative which is good! Similar comments about planning tickets for Friday. Plan is to make a ticket to organise Fridays/tech-debt so meetings are had to plan and review tickets. We should have 2 standups to encourage collaboration or a channel that is always open to drop in and out of. -- Improved automation of the board is nice. -- Kathryn has deleted a couple of unused project boards which is good. -- Code chats should be organised to talk about investigating new technologies. -- Important dates: we need to check if alerts work, adding important dates have been useful -- Having new starters on site means that we organise ourselves more to get on site which is good. We should look at continuing this. - -## Coffee - -- Let's make coffee a very short second stand-up and then people can stay on for coffee -- It's ok to send apologies if you're busy just like in the mornings -- Need agreement from Freddie -- Compulsory to either attend or message why you are not attending - -## Passivity - -- We don't tell people we need to do something until we are doing it, we should give more warning for things like getting requirements, doing deployments etc. -- How can we become more proactive? -- Who owns the NDX, how can we share it better with the instrument scientists? This needs to be discussed more in depth -- An example is the SANS2D migration where scientists didn't know about the component steward and talked to different people for each ticket - -## Keeper - -- Someone needs to try out keeper to discuss how it works and present if we can use it and how to migrate to it (maybe at a code chat) -- Jack will do it, James will organise the code chat - -## Issue templates - -- We can have multiple templates to choose between (this is useful for releases and a generic release template) -- Our current generic template contains a standard title "Component: Short description", a user story with some more detail, acceptance criteria and some extra notes -- We can change the generic template but we need to make sure our process is light and tickets are readable -- Though including things like where is the code -- We use issues as user stories not issues in reality -- Jack has previously used - 1. How: What is the issue - 2. Where: Where the issue is likely to be (being as specific as possible inducing relative file paths etc) - 3. How: How did the issue come about - 4. Reproducible: Yes/No and any additional information - 5. How to test the issue is resolved: A set of instructions / a script / include test file if required to act as a reference for the developer when tackling the issue and the reviewer when work is complete. -- Both Jacks will write their own and compete to win the ultimate issue template - -## Burndown suggesting we haven't done enough - -- Yes it was difficult to calculate this at the start with so many unknowns - -## Tasks board isn't being interacted with much - -- We will put some into proposals that we can do as actual tickets -- It's not so useful out of sprint -- We should tidy it up soon diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.08.25.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.08.25.md deleted file mode 100644 index 38277a8a4..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.08.25.md +++ /dev/null @@ -1,68 +0,0 @@ -# 2021-08-25 - -## Items from last retrospective - -- Suggestion about changing of coffee - we did it during the tech debt week then stopped. If you have a late coffee you might just be saying what you're about to say in the following morning. Maybe it should be a catch up on problems - though we already do this in technical. Once we start coming onto site more we won't need to do coffee or a second standup. -- Keeper - still need to do this - ACTION on JH -- Issue templates - JA has a pull request sat waiting for this so we could use this. Adam also has a template. - ACTION: get this merged and see if we use it -- Burndown suggesting we haven't done enough - It was a difficult one to calculate. This sprint was a bit easier to calculate points for and we seem to be more on track. Hooray! -- Tasks - Not tidied up yet, KB will do so before the end of the week(ACTION). - - -## Items from current retrospective - -### IOC tests turning into a useless metric -We have made a ticket for this and planned/proposed it, we dealt with it at the time. - -### Checkstyle being prioritised over IOC tests -Ditto, we are dealing with it. -They are slightly prioritised because they are much easier fixes than fixing IOC tests and it takes a lot more effort to fix IOC tests. Missing documentation in the GUI is also very important for the future. Checkstyle is an easier graph to look at because it's stable and reported on the jenkins job. We should fix both rather than concentrating on one or the other. - -DO mentioned checkstyle can be a bit heavy handed, it complains if you don't write docs for every function. Should we be doing it on all of our other languages? Yes we should, though this adds another metric that needs to pass - -We should run this on pull requests instead and make the build fail if the warnings go up. JA will put a ticket in for this for the next tech debt. We have a build for this already but it's rather broken and not plumbed in as it stands. - -### It was strange but really good that members were in the office and having a discussion on teams -Meant that people off-site could jump in at points which helped with teamwork and hybrid working. There are some funny side effects with this if you are sat in the office like hearing things twice over but overall it worked OK. When we're back at work we should maybe worry less about distancing and use things like the big screen for standup and so on to get around that problem. - -### Avoiding re-adding release notes back into ReleaseNotes_upcoming in after a release -We should add a ticket to write a script that will rebase all tickets to the current master/main and avoids this problem. This script should be run after doing a release. ACTION: JH create ticket - -### Happy that the Python version being incompatible was spotted while doing the release -It was good that we did the release in the shutdown because mid cycle this could cause panic. -We should be careful about dependency updates because we aren't necessarily building on the same machines as we're deploying to. If BR hadn't have noticed this we could have ended up with problems after creating the release or even worse deploying it. - -### planning board has columns for themes - do they work? has the automation been working -Automation has been VERY helpful and project board checks are now pretty much solely moaning about release notes rather than invalid labels. -themes in the planning board are possibly not that useful. - -### Was the release at the start of the sprint useful? -We used to do it at the end and this time tried to do it at the beginning. Think it was useful, meant it didn't overrun from the last sprint. - -### is the "added during sprint" label helpful and if not shall we remove it -Yes and therefore No. - - -### Discussion around sprint themes -DO does not like themes because as a manager it's tricky to give people the answer to "what should I work on next" without context of the tickets in the theme. Beforehand it was just "pick something from the ready column" but now it takes longer because it's difficult to advise on the tickets we aren't sure about. We also don't talk about it during planning which we used to but we don't really have enough time to do it. We have a large team and it's hard to talk about every ticket because it takes up so much time. Themes give us an idea of things we HAVE to do in the sprint, for a migration for example beforehand there may have been things left out of the migration because we didn't get round to them. - -We have had less planning discussions but this may or may not have had implications on managers and so on as it puts more pressure on them to know about all of the tickets in the theme. - -The problem at the moment is the sprint is completely full with themed items which leaves us with no room to pull things into the sprint if needed. - -What about if we had themes but got people to prioritise the top 3-4 tickets for each theme depending on what is high priority for the themes. - -In pre planning we could ONLY discuss theme stuff to get around having stupidly long planning meetings where we discuss themes AND other proposed tickets. - -We have lots of new starters so the order of the ready column doesn't matter because most people don't pick a ticket off the top of the ready column. We could get component stewards to prioritise the ready column. - -To summarise what we're going to do: -Preplanning: we will only discuss themed tickets that have been proposed by component stewards -planning: we discuss anything that has been proposed since pre planning and generic tickets that don't fit in themes. - -Once the planning meeting is over the general tickets from high/medium will go into the planning board, KB will do this, and the themed tickets will be put into the project board by the component stewards who can then order them based on priority. - -Where is this process documented? -It's in the files in general, we should update the wiki to point at the spreadsheet showing component stewards, who is working on themes etc. - - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.09.22.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.09.22.md deleted file mode 100644 index 4a02bdc1b..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.09.22.md +++ /dev/null @@ -1,57 +0,0 @@ -# 2021-09-22 - -## Items from last retrospective - -* IOC tests being a useless metric had - lots of progress but still needs some work -* Checkstyle being prioritized too high - not much else to say -* Good to see people in the office having a teams meetings - again good, now going to start booking meeting rooms though for larger meetings -* Avoid re-adding release notes - ACTION: JH to create ticket -* Incompatible python version spotted when doing release - good -* Themes columns on planning board - current system is nice, automation is helpful -* Release at start of sprint - will be trying it again this time -* "added during sprint" label - opinions unchanged -* Sprint themes discussion - Feelings that themes have caused issues with prioritization - - -## Items from current retrospective - -### Tests not passing -* close to getting them done -* consistent failures taken out, need to keep an eye on fixing them - -### Team morale -* Potential of an away-day, but need to take into account different conference levels -* Possibility of booking a conference room big enough for everyone on site -* FA going to talk to people individually to assess comfort levels -* Office occupancy will be continually assessed, looking to increase occupancy levels in various ways (keep an eye on CO2 monitor) - -### Feeling the distance that being remote has caused -* Feeling that we're doing a good job - -### Burndown chart jumping -* This was mostly due to a lot of big-point reviews going through at the same time, including release and tech-debt week - -### Planning Fridays -* JH not a fan of the concept of planned Fridays as opposed to spontaneously picking up tickets for them, but understands that this could be too chaotic -* Whilst remote especially, best to have some planned conversation before starting to work on tickets to replace the small office conversation that would otherwise occur -* A week of Fridays might be too long, especially getting reviews through -* Next Friday week, consider only starting new Friday tickets on Monday and Tuesday, then only working on existing tickets and reviews for the rest of the week - -### Would people prefer being told which themes they're meant to be working on -* Everyone seems on board with this, KB happy to continue letting people know and willing to move things around if a developer has preferences. -* Assignments posted in "announce" on teams after planning - -### Noting how much IBEX work done at end of sprint -* Suggestion that people let KB know at the end of a sprint how much time was actually spent on IBEX -* Happy to be half-day granularity - -### Working with EMU Scientists -* Good that we were able to talk with scientists, set up kit with them etc. - -### Squish -* Now that we have a floating squish license, should run training for developers so that everyone is able to write tests - -### Information about accessing blockhouses -* Hard to remember safety walkthroughs for all instruments, best to find the scientist to do it for you -* Should be a copy of local rules on/near the door if needed - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.10.28.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.10.28.md deleted file mode 100644 index f6024f04d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.10.28.md +++ /dev/null @@ -1,27 +0,0 @@ -# 2021-10-28 - -## Items from last retrospective - -* IOC tests are better but still a bit flaky. Some fail on some servers but not others but down to only 4 failing -* We would rather not remove the failing tests but will propose a ticket to fix them -* JH has created a [ticket](https://github.com/ISISComputingGroup/IBEX/issues/6862) to avoid merge conflicts on release notes - -## Items from current retrospective - -### Sprint Planning was Fast -* Likely due to good pre-planning - -### Fridays/Tech-debt -* We are probably having too many of these so need to reduce the frequency -* People generally like having them for a full week but also find it hard to slot the Friday work into other things happening that week -* Could have a nominated number of points for Fridays over the whole sprint but this would be hard to manage -* It's hard to make it a "fun day" when remote and spread over a week -* ACTION: KB will think about ways to make it more fun - -### Moving configs from control-svcs -* ACTION: DO to create [ticket](https://github.com/ISISComputingGroup/IBEX/issues/6863) - -### Managing Squish License -* ACTION: LC to make spreadsheet to manage who has the license (is set up on teams) -* Discussed restarting the server every night but this will kick the CI off so will not do it -* There are instructions on the wiki for how to restart the license server if someone has taken the license \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.11.17.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.11.17.md deleted file mode 100644 index c8715b487..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.11.17.md +++ /dev/null @@ -1,70 +0,0 @@ -# 2021-11-17 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| [@ThomasLohnert](https://github.com/ThomasLohnert) | [@Adam-Szw](https://github.com/Adam-Szw) | [@JackEAllen](https://github.com/JackEAllen) | - ---- - -## Items from last retrospective -- A Squish Spreadsheet has been made by [@LilithCole](https://github.com/LilithCole) to manage who has the license located in General on MS Teams. -- IOC tests are better but still a bit flaky. Some fail on some servers but not others but down to only 2 from 4 failing. -- There are now instructions on the wiki for how to restart the license server if someone has taken the license. -- Friday Tech Dept: ACTION: [@KathrynBaker](https://github.com/KathrynBaker) will think about ways to make it more fun - ---- - -## Items from current retrospective - -## Workflow -### Next Sprint will include a FRIDAY -Try and get everyone in if possible - more fun when people are in the office + food! - -### Timekeeper also moderates voting room -It was agreed that the timekeeper should act as the moderator for voting rooms to enforce voting does not overrun time allocated for an issue. - -### Move some documentation into repos as to wiki? -- URL's should be added to repositories and WIKI to include links to relevant repositories and resources. -- Repositories should include URLS to all relevant information such as WIKI pages, manual locations (where applicable), Server locations and other associated repositories (for example an IOC repo should include URL's to emulator and OPI). -- [@ThomasLohnert](https://github.com/ThomasLohnert) will make an issue for this which includes script generator automatic documentation. -- [@JackEAllen](https://github.com/JackEAllen) will also make issues to tackle adding of URLS to some repositories as Friday tickets in the next Sprint. -- A suggestion mentioned was to try and ensure that URLS are present for each repository as part of PR acceptance criteria. - - -### Large backlog of reviews this sprint a sign of insufficient training or other barriers? -* It was highlighted that reviews are not easy if information reviewers need to review a PR is not provided. To improve on this, It was suggested that PR's should include verbose instructions for testing including: - - Machine locations - - Relevant documentation needed (manuals, wiki pages) - - Tasks involved to test PR are listed in the order that they should be tested. -- A suggestion agreed upon was to modify issue templates to include the header "How to Test" to be completed when the developer is ready to submit work for review to list testing instructions. -- [@JackEAllen](https://github.com/JackEAllen) will update issue template to action this. - -### Implement repository linters to remove code format and styling from review process. -- During discussions about barriers for reviewing PR's, it was suggested that we could add linters as git actions to remove the need to review code format and styling from the review process to allow developers to focus on the logic and speed up the review process. -- It was agreed that this would be nice for some repositories - mainly Python -- It is known that Mantid host [technical training](https://github.com/ISISNeutronMuon/ISISTrainingCentre) within ISIS Computing Division, which can extend to Experimental Controls and others performing computing roles within ISIS. [@JackEAllen](https://github.com/JackEAllen) will contact Mantid to follow up on this to see if we can attend a joint training sessions on Jenkins to provide all members within IBEX the knowledge to create git actions with Jenkins to action the implementation of Linting and other tools to handle code styling and format. - -### Use Squish only for reviews during last week of sprint -Mutual agreement that during the final week of a sprint, the squish license should be used primarily for reviews only. -The priority of squish license usage during the final week of a sprint can be prioritised as: -- High: Reviews -- Medium: Reworks -- Low: New work - ---- -## Equipment - -### The office mic is barely legible for stand-up, is there a better solution we could use? -- [@rerpha](https://github.com/rerpha) will contact [@KathrynBaker](https://github.com/KathrynBaker) / [@FreddieAkeroyd](https://github.com/FreddieAkeroyd) to discuss solutions to resolve this. Options discussed included: - - Mic mounted to the ceiling - - Mic that everyone can hand around the office (Not the most Covid secure option) - - Order a VC system if cost effective so we can hear and see everyone in the office. - ---- - -## Other - -### Would everyone be interested in organising a secret Santa this year to get us in the festive mood? -Everyone is interested in a secret Santa and festive meal in the new year. -- [@JackEAllen](https://github.com/JackEAllen) will organise the [secret Santa](https://www.elfster.com/). -- [@LowriJenkins](https://github.com/LowriJenkins) will organise the meal for the new year. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2021.12.15.md b/doc/processes/retrospective-notes/Retrospective-Notes-2021.12.15.md deleted file mode 100644 index 3a2cad0a2..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2021.12.15.md +++ /dev/null @@ -1,66 +0,0 @@ -# 2021-12-15 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| [@JackEAllen](https://github.com/JackEAllen) | [@daryakoskeroglu](https://github.com/daryakoskeroglu) | [@Adam-Szw](https://github.com/Adam-Szw) | - ---- - -## Items from last retrospective - -### Next Sprint will include a FRIDAY - -### Timekeeper also moderates voting room -We didn't get to test it yet. We should try this at the next opportunity. - -### Move some documentation into repos as to wiki? - -### Large backlog of reviews this sprint a sign of insufficient training or other barriers? -We made some effort to increase amount of reviews coming through, especially among junior team members. -As we are making effort towards adding more of 'how to review' instructions to our tickets, we need -to keep in mind not to post any security risks that come with having our project be a public repository. These -could for example include IP addresses, device names etc. - -### Implement repository linters to remove code format and styling from review process. - -### Use Squish only for reviews during last week of sprint -Mutual agreement that during the final week of a sprint, the squish license should be used primarily for reviews only. The priority of squish license usage during the final week of a sprint can be prioritised as: -- High: Reviews -- Medium: Reworks -- Low: New work - -We tried to follow this ruleset during this sprint and it seems to have worked. We agreed to keep this in place. - -### The office mic is barely legible for stand-up, is there a better solution we could use? -This issue hasn't been dealt with yet. - -### Would everyone be interested in organising a secret Santa this year to get us in the festive mood? -We did the secret Santa and the team enjoyed it. We are yet to organize a new year's meal. - ---- - -## Items from current retrospective - -### Centralise the snag lists to the IBEX project sharepoint -These are generally not as readily visible as the projects etc. are in GitHub - -### Apart from trying to be organised next time and realise in better time when it isn't worth having a pre-planning meeting, are we happy with not having one when it feels unhelpful? -Considering how this is a rare situation, we agreed that the best way to deal with it will be asking this question at the end of the standup, so that people can have an opportunity to voice their opinions on this. - -### This keeps getting brought up, but I think we should have a 'cull' of icp-write members for the sake of security in case anyone's GH account is compromised and they are difficult to reach -For the security reasons we agreed to: -- Everyone should make sure that they are using 2-factor authentication on Github -- We might want to look into removing members who have not been on the project for a long time - -### Start over the rotas in the new year -We decided to go for it as nobody had an issue with that - -### Some new members of the team have trouble merging branches on various repositories due to lack of permissions - -### What is the best way not to forget to update submodules - should `EPICS_repo_checks` post a message to Teams on failure? -- We decided not to add message on teams. -- We might consider adding checks or 'todos' in the templates to remind people. -- Optionally we could add a pre-commit message check. - -### When adding new sections or editing existing sections of the wiki, I would like descriptions to be as verbose as possible to be more accommodating to new members within the team -We can make things more verbose where we can, but we have to look out for possibility of duplicating information. Where it exists, we should favour linking other pages rather than keeping extensive amounts of information on one page. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.01.05.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.01.05.md deleted file mode 100644 index 216feebfc..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.01.05.md +++ /dev/null @@ -1,54 +0,0 @@ -# 2022-01-05 - -### Items from Retrospective before last: - - The office mic is still often illegible. - - as of this meeting still an issue. - -### Items from Previous Retrospective: - - Centralise the snag lists to the ibex project sharepoint. - - not discussed as Kathryn did not have access to reflectometry. - - - Cull icp-write members for security: - - Require users to have 2-factor authentication on github. - - This will remove everyone who doesn't have it already enabled. - - This may handle most of those who need to be removed. - - This will only effect write access. - - Look into removing members who have not been members of the project in some time. - - Change them to read-only? - - - New team members still running into permissions problems on some repositories: - - Often issue is to do with different permission settings for writing and merging. - - Might be possible to automate adding new members to permissions using github actions. - - Jack Allen to look into this. - - - Best way to handle reminders about updating submodules. - - Ideas: - - Message on teams? - - todo in issue template? - - pre-commit message check? - - Repo-checks do actually catch this, but this usually delays being noticed until the next standup. - - - Adding to/Editing wiki sections. - - Try and make things more verbose, but if information would be duplicated then using links instead. - - Finding things can be extremely difficult on the wiki, so: - - Try and make names of pages clear and relevant. - - The wiki likely needs a cleanup, probably still the best option for documentation though. - - Searching better at top left within repository, rather than using the wiki provided search-bar. - - -### Items from this sprint: - - Discussion of how we want to handle versioning, differences between Major/Minor/Patch: - - What we would classify as a major change and what the scientist would may differ greatly. - - If we want to change this, we might have to change how we deploy, or how we number versions, or both. - - If these things change we may also have to alter our build system to avoid changing more than is necessary. - - Discussion of deployment at other facilities. - - There doesn't seem to be a common approach among them. - - More use of static builds with unrolled DBs? - - multiples versions of asyn at a lot of other facilities. - - We've avoided this for ease of testing. - - Discussion to be continued at next retrospective. - - - This sprint was very short: - - Seemed to work fairly well, and was well tracked by shadow. - - Was useful as a tech-debt sprint, similar to Mantid's post-release period. - - Up to date calenders would make it easier for sprints similar to this to be planned in future. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.02.02.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.02.02.md deleted file mode 100644 index ff7c67491..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.02.02.md +++ /dev/null @@ -1,124 +0,0 @@ -# 2022-02-02 - -## Items from last sprint: - -Can we make our deployment process clear with respect to version numbers of current and previous? Major/Minor/Patch version. -How do we account for e.g. hotfixes, roll-backs, patches, etc. Or a deployment of a single IOC, or a support module? (e.g. StreamDevice) - -- Perhaps link to wiki page from GUI `About Box` showing versions and hotfixes (exists already). Or an ID suffix on version number? -- Each IOC and module has a version number created during build. Can then compare. -- How do other facilities handle this? -- Decided need to discuss in separate meeting. - -------------------------------- - -## Items from Current Sprint (2022_01_06) - -How to account to support work? - -- comment on `Support Channel` in Teams -- KVLB will review at end of sprint and account for points spent - - -What would everyone's opinion be on trying to bring in one or two issues each sprint to automate some of the manual tests we do as part of preparing for releases to slowly begin chipping away at them to speed up release testing? - -- Use Squish as we have it -- Always good to speed up release testing -- Difficult to prioritise testing higher than instrument work -- Occasionally convert one test after creating ticket and then review -- Have a list of tests/tasks/tickets on wiki for "spare moments" e.g. on Friday afternoon -- Decided to get ISIS cycle(s) out of the way first and then have another think, probably a meeting. - - -Would revisiting the concept of code freezes be a good idea? - -- Already do something approximating code freezes -- Discuss at meeting above if required - - -Can we consider using GitHub Discussions to contain technical conversations? I feel it may help us as a team to better organise and archive technical discussions taken place under custom categories and pin important conversations (sort of like an internal stack overflow). I believe it may also help reduce duplication of questions asked and answered within the team. - -- Group worried about number of search locations -- Any technical question should already be answered on wiki, add it if not. -- Suggested that JA give a Code Chat on the subject -- UKRI Universal Documentation Project ("UDOC") - option for our manuals(s)? - - -Might be interesting to just discuss the idea of the ICD lightning talks we attended this week, seemed an interesting idea. Maybe we could put an odd slot in for one or two (e.g. one after stand-up once a week?). Not necessarily to to do a block meeting of them but let a few technical tricks and ideas out of the bag in a 1-2 minute slot. Could also be presented to ICD if appropriate. - -- For info: 4 to 6 months is frequency for ICD talks -- Book weekly slot and people can volunteer if have something to talk about -- After Stand-Up meeting is ideal, if time allows and not running in to next meeting -- Give people option not to attend if not interested -- Suggestion is to have after Stand-Up of final day of sprint - - -What would everyone's opinion be regarding merging the Social and random teams channels together to reduce the number of channels we have? -Is there history in one or both chats that we particularly care about and would prefer not to lose? - -- Group not been using certain channels very often, so no harm in removing. Especially "lunch" as was only used in lock-downs. -- Always option for individuals to hide any channels on own client -- OK to delete "social", "lunch" and "reviews". DONE. -- Suggestion to have "system" channel for CMM to record activities. e.g. reclone system, fix RAM, alter GFX car, move physical machine or VM. May be better on Sharepoint on a per instrument basis. - - -Can we discuss [this ticket](https://github.com/ISISComputingGroup/IBEX/issues/6973#issuecomment-1015399722) as a group to look at automating the release build? -- all documented on wiki, so assumed straightforward to create Jenkins job. -- deployment more involved and risky. start task with just automated release and then run system tests. -- create ticket for automating release, not deployment. Win10 deployment is very different to current system, so will revisit when in place. - - -If we can be more descriptive / verbose with PR titles and descriptions, I like the idea of using the auto generated release notes feature on GitHub for release tags going forward. Currently PR's vary quite a lot in how well they are written so the auto generated release notes don't look very nice. -If we can be stricter with how well we write PR's and commit messages (title and body), I would like to place the Release notes link in the release tag like we do already and then the auto generated release notes beneath that to be more descriptive with the changes included in each release tag per repository. - -- with tags, can automate release notes by selecting appropriately -- summarise commits in PR -- possible to create "draft release" as nightly build? -- can't see benefit. difference in customer and developer release notes. may not work for customer, as specifically created for instrument. -- suggestion to create demonstration release using most recent release for comparison. - - - -We probably don't need to buy a mic for the office webcam now, but it's probably worth shutting the door at standup as people walking past the office can be picked up on it now with the "low" noise suppression option ticked on zoom. Otherwise though I think it's much clearer! - -- camera angle too narrow to show all present. -- suggestion to try separate mic and camera - - -`DDaT` launch PC recycling and sustainability scheme (sharepoint.com) Volunteers required to re-image obsolete (but still useful) IT equipment for resale to staff or donation to charity. Scheme currently being run from Polaris House, but maybe if/when expanded to RAL, could be an idea for a team-building exercise (or perhaps more of a bus man's holiday!) - -- probably more useful team-building exercises we could do, like joint programming, or hackathon. - - -------------------------------- - - -### Extra comments: - -Run out of tickets for people to pick up during sprint, so bear in mind for planning meeting. - -- probably due to large tickets (e.g. deployment, release) -- ask on General channel so can help with work on current themes - - -Are we planning a late Christmas meal, if not then something else e.g. pizza or something on site? - -- can consider now restrictions relaxed -- respect opinions if people don't want to attend or can't -- can book large conference room for social distance for activity e.g. lunch -- need ideas for numbers attending so that office capacity accounted for -- can meet at Dish on Harwell campus for those on site? - - -OK to pick up "Friday" ticket at any point? - -- Yes if all other sprint work done -- useful for training - - -Sprint Review: - -- Release created and deployed on time -- See how deploying early worked for the upcoming sprint/cycle - did we create more patches as a result? Did scientists test early as that was the whole point? - - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.02.23.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.02.23.md deleted file mode 100644 index 967d50d2f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.02.23.md +++ /dev/null @@ -1,83 +0,0 @@ -# 2022-02-23 - -## Items from last sprint: - -How to account to support work? -- Some tickets were created with appropriate amount of points in them - -What would everyone's opinion be on trying to bring in one or two issues each sprint to automate some of the manual tests we do as part of preparing for releases to slowly begin chipping away at them to speed up release testing? -- Use Squish as we have it -- Always good to speed up release testing -- Difficult to prioritise testing higher than instrument work -- Occasionally convert one test after creating ticket and then review -- Have a list of tests/tasks/tickets on wiki for "spare moments" e.g. on Friday afternoon -- Decided to get ISIS cycle(s) out of the way first and then have another think, probably a meeting. - - -Would revisiting the concept of code freezes be a good idea? -- Not discussed in this retrospective - -Can we consider using GitHub Discussions to contain technical conversations? I feel it may help us as a team to better organise and archive technical discussions taken place under custom categories and pin important conversations (sort of like an internal stack overflow). I believe it may also help reduce duplication of questions asked and answered within the team. -- Not discussed in this retrospective - -Might be interesting to just discuss the idea of the ICD lightning talks we attended this week, seemed an interesting idea. Maybe we could put an odd slot in for one or two (e.g. one after stand-up once a week?). Not necessarily to to do a block meeting of them but let a few technical tricks and ideas out of the bag in a 1-2 minute slot. Could also be presented to ICD if appropriate. -- For info: 4 to 6 months is frequency for ICD talks -- Book weekly slot and people can volunteer if have something to talk about -- After Stand-Up meeting is ideal, if time allows and not running in to next meeting -- Give people option not to attend if not interested -- Suggestion is to have after Stand-Up of final day of sprint - -What would everyone's opinion be regarding merging the Social and random teams channels together to reduce the number of channels we have? -Is there history in one or both chats that we particularly care about and would prefer not to lose? -- Channels merged, topic closed - -Can we discuss [this ticket](https://github.com/ISISComputingGroup/IBEX/issues/6973#issuecomment-1015399722) as a group to look at automating the release build? -- Not discussed in this retrospective - -If we can be more descriptive / verbose with PR titles and descriptions, I like the idea of using the auto generated release notes feature on GitHub for release tags going forward. Currently PR's vary quite a lot in how well they are written so the auto generated release notes don't look very nice. -If we can be stricter with how well we write PR's and commit messages (title and body), I would like to place the Release notes link in the release tag like we do already and then the auto generated release notes beneath that to be more descriptive with the changes included in each release tag per repository. -- Discussed as part of current retrospective, notes below - -We probably don't need to buy a mic for the office webcam now, but it's probably worth shutting the door at standup as people walking past the office can be picked up on it now with the "low" noise suppression option ticked on zoom. Otherwise though I think it's much clearer! - -`DDaT` launch PC recycling and sustainability scheme (sharepoint.com) Volunteers required to re-image obsolete (but still useful) IT equipment for resale to staff or donation to charity. Scheme currently being run from Polaris House, but maybe if/when expanded to RAL, could be an idea for a team-building exercise (or perhaps more of a bus man's holiday!) - -## Items from current sprint - -How patched is the release? Was the timings good for us, did we get the change requirements before the cycle started? -- We still need some tidying to be done on sans2d -- Patching was made easier thanks to visual studio version being the same and -because we had a developer build -- We had releases done by the time of testing on the instrument giving us extra time -- Overall we are happy with this. This workflow should be documented on wiki - -If we can be more descriptive / verbose with PR titles and descriptions, I like the idea of using the auto generated release notes feature on GitHub for release tags going forward. Currently PR's vary quite a lot in how well they are written so the auto generated release notes don't look very nice. -If we can be stricter with how well we write PR's and commit messages (title and body), I would like to place the Release notes link in the release tag like we do already and then the auto generated release notes beneath that to be more descriptive with the changes included in each release tag per repository. -- We looked at the draft of auto-generated release notes -- We decided that we should think about making pull request titles more descriptive but -we will not be spending time on auto release notes - -Would it help to know the points expected at the start of planning meetings to help with the awareness of what we can do? -- We will implement this and see how it goes for a couple of sprints - -Do we want to rethink the way we approach discussion tickets? We often spend time discussing a discussion, then ask about MUST/SHOULD/COULD/WANT/NOT, then finally (hopefully) have the discussion. There are quite a few of these "decide on architecture" discussions in the backlog, and they can impede the code being done as we don't get around to the discussions. How about I (or someone else if they want to) books an architecture meeting for an hour or so every sprint or two (as with planning and review/retro they won't count for points). The agenda for the meeting will be based on recent proposals to begin with, and shared in advance. A backlog of discussion tickets can then be created and maintained offline (rather than in existing meetings). -- We should treat those tickets as a separate backlog for this purpose -- Meetings will be setup and we will try this for some time to see how it goes - -Should we think about splitting planning during cycle too? -- We will be splitting during the cycle too so that team members that could be on -support during one meeting can then join another meeting - -We frequently run into problems with Eclipse RCP environments (IBEX client and Squish), would it be worth sending some people on some kind of training courses? I feel a bit guilty as I haven't found a lot of time recently to help people resolve these and I'm always just kind of muddling through myself, I think having some more expertise in the team would be useful. Anyone interested be learning more about this? -- We could send someone to a training on this and then that person would be able to help rest of the team with Eclipse related problems. We need to decide who should attend the training - -I don't really understand the distinction between https://github.com/ISISComputingGroup/IBEX/wiki and the developers manual - should we merge the two? -- There is a reason to the separation. One is for developers only and the other for everyone -- We might have some content that's in wrong places that needs to be looked at -- We could use some version history but we are not urgent about this - -Should we have a "team day" every month/other week where everyone comes in? -- Yes. There is a proposed date of 25th of March - -## Additional notes -- We discussed the issue of camera in the office diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.03.23.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.03.23.md deleted file mode 100644 index a33f9c74e..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.03.23.md +++ /dev/null @@ -1,109 +0,0 @@ -# 2022-03-23 - -## Items from last sprint - -How patched is the release? were the timings good for us? -- Not very patched compared to last time we looked at it. SANS2D have a few patches but are happy. -- Overall happy with release timings. Workflow is still not documented on the wiki. - -PR auto generated release notes -- Extra overhead but we should be better at titling PRs anyway for tracking - -Points expected at start of meetings: -- still trying this - -Discussion tickets: -- Now trying architecture meetings, we need another one but it might not be this sprint given we've got cycle, release and deploy -- we should do one about networks but we should hold fire as there will be changes - -Should we think about splitting planning during cycle as well as review/retro? -- We are leaving as one for now. - -Eclipse RCP training: -- has been decided that a few people are going on a training course for it. Freddie may also do the course as well as he has a license. - -Should we merge IBEX/wiki and the developers manual? -- some things will be changed and moved around, this is still in progress. -- instrument info moving to the dev manual, this is in progress -- main ibex manual is being rearranged a bit, "" - -Team day: -- we have this coming up on the 25th of March - -Camera in the office: -- now even wider angle -- not pointing in the right direction at the moment -- stack of books or mounting it on the wall might be an idea to make it even wider - -## Items from this sprint - -Can we set a challenge to the team to get stale reviews done and get the project board checks to stop moaning and giving warnings? -We can cheat about this slightly to stop them getting stale -- There's always a reason things are stale? No, sometimes it's just the way it is. -- Generally if it's at the top of review it's either been there the longest or it's very urgent. -- This is more of a reminder rather than a discussion. Why do we have things in review that have been there for months? - - Hard to review/not urgent/no one understands it anymore perhaps - we should get these done anyway. - - We should say about them more in standup and get them through review - - If it's hard to review, perhaps we should give more info in the ticket on HOW to review it. - - This is getting better, we are moving in the right direction. Some are squish test tickets which can be tedious to review. Perhaps we should have a discussion at standup if there is a ticket that is difficult to review. - - pair review may be an idea to get through the tickets that take a lot of time. - -Should we hit the button to get rid of everyone from the GH org who does not have 2FA enabled - - we need a way of doing this for `ISISBuilder` - - we might be able to do this via an app or email rather than text message for it. - -We should have a known issues page for accelerator beam stuff being down like the MCR news that the scientists can use for update -- Should be something we can all edit -- why don't we use the shared inbox? because people who want to know might not be scientists so we cant just email all of the scientists. -- we should put this alongside where our shared phone number is listed and put it on that page as it might stop people from calling -- we need a discussion with the internal web admins in the computing group? to discuss this - -Zoom now works if you're logged in from multiple places. hooray! - -INTER could not find the new zoom support phone number so ended up coming to the office instead. the previous number is now redundant as all landlines have been removed. -- We should get some cards laminated again with the details on as the ones round site are out of date. ACTION: get these printed. Perhaps we could put a QR code of the our web page on it. And a picture of a goat! DKg would like to do the designing of these cards. KB will send DKg the previous one -- 1763 should still work from the existing landlines in cabins, but will ring to zoom. We couldn't ring them back without looking up their number on the intranet -- this is inconsistent as WISH seemed to come through with their own numbers... -- If you add them to contacts they show up as their instrument name. - -We decided to move parts of the IBEX wiki into the code repo, would it be an idea to do the same to the dev wiki? -- this makes it easier to view version history -- you can still edit it online and it makes it slightly clearer to view the structure of the wiki -- this is easy to do -- this will break the wiki check so we should keep this in mind - though this is easy as well -- one click less to have the same info -- we should double check this won't break relative links etc. and retain history - -Graylog move to SCD cloud -- created a Friday ticket for this, didn't quite get it working -- the ticket for making `graypy` more hardy should be treated with a higher priority than the instance location as it caused some scripts to fail - -Hackathon to move all IOCs into support directory -- we should do this instead of the next Friday as a hackathon, they are fun -- ACTION KB will propose a date - - -Sigh of relief for TS1 commissioning being pushed back -- we are doing well at supporting TS2 I think - so might be a good thing that we can carry on just doing so as it gives a chance for junior members of the team to help with support more. -- there are positives and negatives for this -- more work may need to be done in a shorter time, so there is an element of panic here too. It also mixes up our timelines slightly for things like win10 etc. - -What is making people sad/mad/glad -- There were 49! conversations in the support issues channel. We have been very busy but we are doing well. -- It has calmed down a bit now, we have managed to jump the hurdles well. - -- It would be good for junior members of staff to come along with support calls especially ones that require being in person -- hard to do this remotely as we don't immediately log everything in support-issues as it is happening -- there is no shame in saying "I'm not sure let me check with the team" -- Would the Sandwich students like to come along to support calls? yes -- There is a sense of ownership when you pick up a support call but this does not mean you're solely responsible for that problem - -Call queues - has the ring timer for call queues for level 1 been reduced? It seems to ring for a very short time and then go to the next level - this can make it difficult to have time to get everything ready to answer the phone -It's too short. Perhaps we should get everyone a lab phone as it's easier to accept a call on a phone than with a headset. - we will increase the ring time for 15 seconds as 10 seconds was too short to be able to answer it before moving onto the next person - -In terms of the amount of support calls we got done we should be proud of ourselves as we've been off sick/on leave etc as a team. We shouldn't be disheartened by the state of the burndown - we have been doing brilliantly. - -As someone who cares about the user interface side of things I am glad that we've had lots of changes recently - they are tangible things that show up and show change in IBEX so although they might be seen as "nice to haves" they are very useful. - -Lightning talks - we forgot what was happening so that was the reason we didn't have much to talk about. SJ will put a note on the code/gui chat page diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.04.20.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.04.20.md deleted file mode 100644 index d0b687497..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.04.20.md +++ /dev/null @@ -1,74 +0,0 @@ -# 2022-04-20 - -## Items from last sprint - -Stale Tickets: - - We have warnings for long periods, perhaps there should be errors for even longer ones? to force us to look into ones that have been there for a long time. - -2FA on on github: - - Make sure every account we care about has it enabled because others will be kicked out. - - Possibly send an email, though github may actually do this itself. - - ISIS build does have 2FA. - - Done. - -Zoom contact details: - - Check for old support number and remove it (just TS2 for now) - - Print out new laminated ones - - Its possible that the call queues are mangling caller ID, might need to test it. - - Possible that if its forwarded from queue 1 to 2 it might say its from call 2. - - This can cause issues with calling people back. - - Some have caller ID and some don't. - -Moving Wiki into the code repo: - - Would be just moving the ibex wiki repository to the main repository. - - Possibly hold off to evaluate a different solution that Jack is looking into. - - Docusaurus, Jack may be hosting a talk on this. - - Good built in search engine, same one as stackoverflow. - -Graylog move to SCD cloud: - - No updates to getting it working on SCD just yet. - - Check with SCD cloud support. - - Running in docker has been somewhat unreliable. - - We don't currently have Graylog running. - -Moving IOC tests and emulators to support directory: - - Happening on Friday. - - -## Items from this sprint -Cable Testers: - - It would be good to know if we had dead cables before giving support calls. - - Patch testing for Pearl - - Possibly worth borrowing from SCD in short term but might be better to have our own. - - Check with Anthony Shuttle for suggestions. - - We're not network engineers, but useful to know that the cables we're bringing around work. - - Possibly this: - - `https://www.amazon.co.uk/dp/B07WRV3N5F/ref=sspa_dk_detail_0?psc=1&pf_rd_p=828203ef-618e-4303-a028-460d6b615038&pd_rd_wg=V07Nd&pf_rd_r=9DJ8RGN71F7P4VQGVWHY&pd_rd_w=2aYQS&pd_rd_r=4daea718-1c03-482c-89c5-3ae3a10df11c&s=diy&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEyOEhJUUNEMkxYVDhMJmVuY3J5cHRlZElkPUEwNTg1NzIyWlNNRlNINUlLT05XJmVuY3J5cHRlZEFkSWQ9QTA4NzIwNTYzTDFJN0Q0WlhJRjZBJndpZGdldE5hbWU9c3BfZGV0YWlsJmFjdGlvbj1jbGlja1JlZGlyZWN0JmRvTm90TG9nQ2xpY2s9dHJ1ZQ==` - - More expensive but less risk of damaging things. - -Github Discussions: - - How to use this compared with the wiki. - - When the discussion is solved does it move to the wiki? - - Perhaps ticket based discussions? - - Discussions tickets are often organise a meeting about this topic, rather than just discussing it on github, using discussions wouldn't allow us to point it. - - Private discussions probably only possibly at the organisation level or in a private repository. - -Should we continue drop in sessions in cycle: - - We never really get many people, and when it is they often just ask about a support call. - - Why do they not turn up at them, do they not find them useful or are they too busy etc. ? - - Maybe they shouldn't happen in cycle - - FIT don't seem to do them anymore or if they do we're not on the list. - - They're less of a burden thanks to zoom. - - We can ask the scientists if they want us to keep doing them at a meeting. - - They are the customer so we should let them decide. - - Might be a way to not spam them with emails once a month. - -System Tests: - - Still some transient errors, but they are actually passing occasionally. - - Possibly autosave saving state or something similar? - - At least we know they're mostly working now, so we can pay more attention to errors. - -This Sprint: - - Test galil was very useful for the wish collimator debugging - - Hopefully next cycle will be a bit calmer because no migrations. - - Lets us focus on Win10 and other migrations for summer like TS1. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.05.18.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.05.18.md deleted file mode 100644 index 473631931..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.05.18.md +++ /dev/null @@ -1,91 +0,0 @@ -# 2022-05-18 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| [@ThomasLohnert](https://github.com/ThomasLohnert) | [@davidkeymer](https://github.com/davidkeymer) | [@JackEAllen](https://github.com/JackEAllen) | - ---- - -## Items from last retrospective - -Cable Testers: - - It would be good to know if we had dead cables before giving support calls. - - Patch testing for Pearl - - Possibly worth borrowing from SCD in short term but might be better to have our own. - - Check with Anthony Shuttle for suggestions. - - We're not network engineers, but useful to know that the cables we're bringing around work. - -*Cable Testers have arrived and work quite well!* - -Github Discussions: - - How to use this compared with the wiki. - - When the discussion is solved does it move to the wiki? - - Perhaps ticket based discussions? - - Discussions tickets are often organise a meeting about this topic, rather than just discussing it on github, using discussions wouldn't allow us to point it. - - Private discussions probably only possibly at the organisation level or in a private repository. - - *Leave as is for the moment and remove if we can't find a use for it after a significant period of time has passed with no usage* - -Should we continue drop in sessions in cycle: - - We never really get many people, and when it is they often just ask about a support call. - - Why do they not turn up at them, do they not find them useful or are they too busy etc. ? - - Maybe they shouldn't happen in cycle - - FIT don't seem to do them anymore or if they do we're not on the list. - - They're less of a burden thanks to zoom. - - We can ask the scientists if they want us to keep doing them at a meeting. - - They are the customer so we should let them decide. - - Might be a way to not spam them with emails once a month. - -*A survey has been sent out to ask for feedback on this. We should have an answer by the next Retrospective meeting regarding whether we should continue with drop in sessions as they are or not.* - -System Tests: - - Still some transient errors, but they are actually passing occasionally. - - Possibly autosave saving state or something similar? - - At least we know they're mostly working now, so we can pay more attention to errors. - -*Still seem to get transient errors, but far less frequent. Builds VHD broke on an update, but otherwise fine.* - -This Sprint: - - Test galil was very useful for the wish collimator debugging - - Hopefully next cycle will be a bit calmer because no migrations. - - Lets us focus on Win10 and other migrations for summer like TS1. - -*The cycle has been quieter that the last with no serious issues such as the collimator. Support calls in the morning have become far less frequent.* - ---- - -## Items from current retrospective - -## Workflow - -### Windows 10 and Other Migrations. -Win10 and other migrations should be one of the main focuses over the summer. - -### Disk cleaning Automation -Time should be spent looking into using [@ChrisM-S](https://github.com/ChrisM-S) powershell script to automate cleaning of drives, moving over IOC logs periodically as part of a cron job. - -A discussion ticket should also be written up to discuss how we could automate truncating the database without affecting active runs. - -### Splitting up GitHub Issues More Finely - -A discussion took place about splitting up issues that involve writing IOC's, Emulators and systems tests as the work is usually always contained within 1 large issue. It was agreed to keep this as it is and change how we approach developing the IOC, system tests and Emulators and document the process in the wiki. - -The process discussed was to write the minimum functionality required to have a working IOC with only one function, and system test and gauge how long it would take to write the rest based on the time required to write one function. -It was also agreed that development should be done in a way that allows for the work to easily be split into additional issues if needed. - -### Sprint Lengths -How we currently run sprints was discussed in relation to how we adapt the length based on cycles and support. It was agreed that [@KathrynBaker](https://github.com/orgs/ISISComputingGroup/people/KathrynBaker) will spend a couple of weeks looking into trialing a nested sprint where sub-sprints occur for each theme within the main sprint and present this in the next Retrospective. - -### Support During Cycle -Support during the cycle has been eerily quiet... - -### Beckhoff -Small Beckhoff in a box is missing? maybe on IMAT? -Look into buying test license for Beckhoff. -Keeps hearing about weird errors from Beckhoffs - Pester motion control to get a fix. - -## Equipment - -New docks have arrived! - -Network Cable Tester arrived works well! diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.06.15.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.06.15.md deleted file mode 100644 index f9210ab66..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.06.15.md +++ /dev/null @@ -1,103 +0,0 @@ -# 2022-06-15 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -|[@LilithCole](https://github.com/LilithCole) |[@LilithCole](https://github.com/LilithCole) | [@daryakoskeroglu](https://github.com/daryakoskeroglu) | - ---- - -## Items from last retrospective -## Workflow - -### Windows 10 and Other Migrations. -Win10 and other migrations should be one of the main focuses over the summer. -_No change, still as it is._ - -### Disk cleaning Automation -Time should be spent looking into using [@ChrisM-S](https://github.com/ChrisM-S) powershell script to automate cleaning of drives, moving over IOC logs periodically as part of a cron job. - -A discussion ticket should also be written up to discuss how we could automate truncating the database without affecting active runs. - -_Did not have a chance to discuss this sprint, need a discussion this sprint._ - -### Splitting up GitHub Issues More Finely - -A discussion took place about splitting up issues that involve writing IOC's, Emulators and systems tests as the work is usually always contained within 1 large issue. It was agreed to keep this as it is and change how we approach developing the IOC, system tests and Emulators and document the process in the wiki. - -The process discussed was to write the minimum functionality required to have a working IOC with only one function, and system test and gauge how long it would take to write the rest based on the time required to write one function. -It was also agreed that development should be done in a way that allows for the work to easily be split into additional issues if needed. - -_Agreed that the process will be used_ - -### Sprint Lengths -How we currently run sprints was discussed in relation to how we adapt the length based on cycles and support. It was agreed that [@KathrynBaker](https://github.com/orgs/ISISComputingGroup/people/KathrynBaker) will spend a couple of weeks looking into trailing a nested sprint where sub-sprints occur for each theme within the main sprint and present this in the next Retrospective. - -_Kathryn did a presentation about nested and sub-sprints in this retrospective_ - -### Support During Cycle -Support during the cycle has been eerily quiet... - -_No cycle this Sprint, hence another quiet Sprint_ - -### Beckhoff -Small Beckhoff in a box is missing? maybe on IMAT? -Look into buying test license for Beckhoff. -Keeps hearing about weird errors from Beckhoffs - Pester motion control to get a fix. - -_@rerpha is discussing about buying test licence for Beckhoff with the motion team._ -## Equipment - -New docks have arrived! - -Network Cable Tester arrived works well! - -_People who started using the new equipment are happy with them_ - ---- - -## Items from current retrospective - -### Project board channel on MS Teams stopped working -No one is using this channel so it was agreed that it should be removed. -@FreddieAkeroyd knows the best way to remove it from channel list. - - -### Rota table in "Meeting Roles and Rotas" wiki page is confusing -"Week Commencing" column causes confusion as it only relates to the Stand-Ups. - - -It was agreed that @KathrynBaker will split table in 2, one for Sprint Planning meetings and other for Stand-Up meetings. - -### Alternative to Plan It Poker -Plan It Poker webpage was down in the last Pre-planning meeting but it came back to life. - - -@KathrynBaker found a new website alternative to Plan It Poker: Scrumpy - - -Benefits: add issues direct from GitHub, add comments to the chain and more user friendly. - - -The members decided to try for the next Sprint Planning meeting. - - -Kathryn demonstrated how to link to GitHub. - - -No registration needed, can log in with a GitHub account but not necessary. - - -### Suggestion for different ways of managing the work in Experiment Controls -@KathrynBaker did a presentation about a different approach of managing work we are doing in Experiment Controls. -Key notes from the presentation: -* Consider all the work we have to do as "program". -* Program Increment (PI) would be things to be done between now and next release. -* Sprint is still a sprint, instead of following Scrum, we can aim to reduce Work In Progress and reduce sprint length to find a better rhythm. -* Each program will have a Kanban board: Program Kanban, Program Increment Kanban, Sprint Kanban -* More information about this management approach can be found here: https://www.scaledagileframework.com/program-and-solution-kanbans/ -* Rough timeline suggested: -* * Sprint 2022_05_19 We decide if we would like to try -- The voting happened on zoom, we will give it a try. -* * Sprint 2022_06_16 Make sure we are carrying nothing forward, and getting everything we need in for the next release done. -* * Sprint 2022_07_14 Build release, testing, prepare for training. -* * Sprint 2022_08_11 IBEX Training, deploy to TS1, hackathon/tech debt removal/something, PI planning, sprint planning -* * Sprint 2022_?_? Sprint retrospective for previous sprint, sprint planning diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.08.10.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.08.10.md deleted file mode 100644 index 64abf68f5..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.08.10.md +++ /dev/null @@ -1,69 +0,0 @@ -# 2022-08-10 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| [Lowri Jenkins](https://github.com/LowriJenkins) | [Jack Harper](https://github.com/rerpha) | [Thomas Lohnert](https://github.com/ThomasLohnert) | - ---- - -## Items from last retrospective - -_(discussed these items very briefly to get to Kathryn's new items before she had to leave)_ - -#### Disk Cleaning Automation: -- Job could be automated but it's not trivial. No new updates for now -- Discussion on a possible solution will be added to our list on Teams (Thank you for volunteering [@DavidKeymer](https://github.com/davidkeymer )!) - -#### Splitting up issues more finely: -- We have not had an opportunity to implement this yet in the last sprint. - -#### Quiet cycle: -- Cycle has continued to be relatively quiet in terms of support. - - ---- - -## Items from current retrospective - -### Sprint - -#### Should we delay start of next sprint? -- KB suggested sprint planning/start for the coming sprint can be be delayed by a week to finish off large volume of items in ready/in progress -- Agreed upon by all - -#### PlanitPoker vs. Scrumpy - which is better? -Scrumpy Pros: -- Github tickets are more easily tied into the service -- Asynchronous voting - People can vote in advance if they will be away for planning - -Cons: -- You can only be in one room at a time, difficult to do priority / points in parallel. We could use both in a hybrid solution but might create more overhead than utility - -We will stick with PlanitPoker for now but keep Scrumpy in mind as an adequate backup if needed. - -### Customer relations - -#### Are people interested in uniforms (e.g shirts) for representing IBEX on support calls? -- Jack H feels that users can be confused about our role sometimes when we turn up on support calls -- Other support teams have specific outfits to clearly identify themselves as qualified support staff -- This does not need to be mandatory, but it might be nice to have the option -- Not everyone likes uniforms, can we have other items to identify ourselves? e.g. hats -- Jack H will investigate available ISIS "branding" options and report back at next retrospective - -#### Support phone number: -- New label with updated contact information has been printed and displayed in TS1 & TS2 blockhouses. Done! - -### Team Interaction - -#### Coffee attendance is extremely low, should we find an alternative for team building? -- Attendance has fizzled to near zero - perhaps a symptom of more people being back in the office -- Suggestion to steal Weekly Coffee & Cake idea from Mantid instead. People in the room agreed this sounds like an appropriate rhythm. -- We will do this in a conference room to enable people to join remotely. Should be convenient for conference room availability. -- We have picked Friday afternoon as the regular time for this for now. We can consider varying the days of the week this takes place if this otherwise excludes anyone from attending. - -#### Should we have standup in G06 instead of the office?: -- Team generally in favour, (more space, better sound). -- Availability may present an issue -- We will trial it when the room is next free in the morning. - - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.09.07.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.09.07.md deleted file mode 100644 index 950ea6b1f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.09.07.md +++ /dev/null @@ -1,126 +0,0 @@ -# 2022-09-07 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| [Lilith Cole](https://github.com/LilithCole) | [Lowri Jenkins](https://github.com/LowriJenkins) | [Jack Allen](https://github.com/JackEAllen) | - ---- - -## Items from last retrospective - -_Items discussed in the previous retrospective_ - -### Sprint - -#### Should we delay start of next sprint? - yes and did -- KB suggested sprint planning/start for the coming sprint can be be delayed by a week to finish off large volume of items in ready/in progress -- Agreed upon by all - -#### `PlanitPoker` vs. Scrumpy - which is better? - `planitpoker` stick with for now -Scrumpy Pros: -- Github tickets are more easily tied into the service -- Asynchronous voting - People can vote in advance if they will be away for planning - -Cons: -- You can only be in one room at a time, difficult to do priority / points in parallel. We could use both in a hybrid solution but might create more overhead than utility - -We will stick with `PlanitPoker` for now but keep Scrumpy in mind as an adequate backup if needed. - -## Customer relations - -### Are people interested in uniforms (e.g shirts) for representing IBEX on support calls? - retuning to later -- [Jack Harper](https://github.com/rerpha) feels that users can be confused about our role sometimes when we turn up on support calls -- Other support teams have specific outfits to clearly identify themselves as qualified support staff -- This does not need to be mandatory, but it might be nice to have the option -- Not everyone likes uniforms, can we have other items to identify ourselves? e.g. hats -- [Jack Harper](https://github.com/rerpha) will investigate available ISIS "branding" options and report back at next retrospective - -### Support phone number: - done -- New label with updated contact information has been printed and displayed in TS1 & TS2 blockhouses. Done! - -## Team Interaction - -### Coffee attendance is extremely low, should we find an alternative for team building? - tried coffee - attendance better if someone brings cake -- Attendance has fizzled to near zero - perhaps a symptom of more people being back in the office -- Suggestion to steal Weekly Coffee & Cake idea from Mantid instead. People in the room agreed this sounds like an appropriate rhythm. -- We will do this in a conference room to enable people to join remotely. Should be convenient for conference room availability. -- We have picked Friday afternoon as the regular time for this for now. We can consider varying the days of the week this takes place if this otherwise excludes anyone from attending. - -### Should we have standup in G06 instead of the office?: - seems better than the office G34 and G06 -- Team generally in favour, (more space, better sound). -- Availability may present an issue -- We will trial it when the room is next free in the morning. - - ---- - - -## Items from current retrospective - -### How Would People Feel About Trying Moving Stand-up Next Door to the Conference Room G06? -* G06 camera better placed. -* G34 is just nicer! -* Sound quality much better when the room is designed for it! -* Seeing and hearing people in the office much better. -* As some of those working remotely can be hard to hear, one option could be to get people headsets to be more audible. - -### Uniforms for the Team -To make it clearer to users that we are from the experiment controls team and not just random members of the general public who have wandered in and started unplugging things, uniforms were discussed. - -* [Jack Harper](https://github.com/rerpha) found an online resource for ISIS branded clothing which is used by other groups: -Found a place to order clothes from: http://www.artisanshirts.co.uk/ -The uniform would be optional as not everyone would necessarily like to wear it. - -Tasks left to do on this topic: -* Find out if there is a specific procedure for ordering ISIS branded clothing- maybe ask Jamie. -* Check what they can produce -* If there is a specific piece of clothing that someone would prefer to have, let Kathryn know directly ("I might be convinced to wear a this"). - -### Could we book rooms for an hour for code chats? -The answer: "Yes, just let the organiser know how long you need" - -### Could we make the repo_checks jenkins job statuses go to the #Jenkins teams channel rather than #General? -Possible solution discussed: -* We could try and automate builds and stop checks temporarily. -* [Jack Allen](https://www.github.com/JackEAllen) will place an existing GitHub workflow developed for personal use into a repository to be adapted to work through Jenkins. The main piece of work that will need to be undertaken to do this is setting up an authentication token for the Jenkins user to be able to push to the repository as the GitHub workflow developed relies on a personal access token which is not suitable for use in an organisational repository. - -Actions Taken: -* Wiki has been updated to include workflow: [shared utility scripts](/tools/Shared-utility-scripts) -* A template repository has been created which can be used as it is, or as a starting point for integration into Jenkins CI/CD: https://github.com/ISISComputingGroup/Update_Submodule_Workflow_Action - -### Would it be helpful whilst we are trying something different with planning if I run the next sprint planning meetings as well? -A resounding yes! `:thumbsup:` - -### Coffee Attendance -Try running only on Wednesdays and Fridays interchangeably to be inclusive of those working remotely on one of the two suggested days. - -### Potentially controversial: should we have a timekeeper for stand-up :question: :question: :question: -stand ups have recently been getting longer and longer, we need to keep them short and sweet. Daily stand-up is constructed for people to speak for a short period of time due to getting tired standing up. Those of us working remotely sit down so happy to talk longer. -When anything slightly in more depth needs to be discussed it should be broken into a separate meeting. - -To resolve this: -* Everyone should be more proactive and aware that you can interrupt someone to move on. ("words, then muting people, then violence as a last resort" :punch: ) -* Turn up on time! - We should make a start no later than 10:03am. -* To keep things moving, we should move on from looking through status screens to individual status's by 10:15am no matter what. - -### Checkstyle - How to Try and Reduce How Often We Check It As Part of Stand-up -Suggestions: -Anyone can merge is checkstyle remains the same or decreases - only admins can merge if needed and checkstyle would goes up. -Automate checkstyle in GitHub to become part of the review (can't be missed this way). Up to developer discretion to allow merging in if checkstyle would increase, but generally only allow to be merged in if checkstyle remains the same or decreases. - -The only complexity mentioned with this is we would need to tell Jenkins which branch to compare against master and that master would need pulling to ensure it is up to date. - -Action taken: -[Jack Allen](https://www.github.com/JackEAllen) will create an issue to explore the viability of automating through GitHub and label as tech depth. We will leave checkstyle as it is for now, but be stricter with merging in pull requests and be more concise with updates in stand-up - no harm in saying "can I catch you afterwards" to resolve checkstyle increases. - -Actions Taken: -- Issue to explore viability of automating through GitHub: https://github.com/ISISComputingGroup/IBEX/issues/7346 - -### Currently, It is Hard to Find New Developer Issues - -Currently, it is hard to find appropriate worthwhile issues for new starters and members in the team early in their careers - Can we be more liberal with adding things? - - -From the discussion held, there doesn't seem to be enough appropriate tickets at the moment which is why it may be hard to find new developer issues. - -Older issues are potentially suitable, but not necessarily documented well enough for new starters to pick up. -As people see appropriate tickets, they should update the description if still relevant and add the "new developer" labels to them once checked by Kathryn who is currently going through all tickets. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.10.05.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.10.05.md deleted file mode 100644 index e6279b982..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.10.05.md +++ /dev/null @@ -1,77 +0,0 @@ -# 2022-10-05 - -| Chair | Timekeeper | Note Taker | -| -------- | --------- | ---------- | -| David | Chris | Lilith | - ---- - -## Items from last retrospective - -_Items discussed in the previous retrospective_ - -### Standup in meeting rooms -Already doing it, happy with it. - -### Code chat bookings -Will do so. - -### Planning chairs -Kathryn continue for this PI. - -### Coffee Attendance -Better weekly, need to avoid maintenance days (whoops). - -### Standup time -Better recently! - -### Checkstyle -Now 0! Make them error instead of warn? Tom will delete from standup links and make build error. - -### New developer issues -Maybe training 1 and training 2 to determine how in-depth tickets will be - -### repo_checks in general -Frequency has changed, but staying in general ---- - - -## Items from current retrospective - -### Wiki/comms - -### Hard to read diagrams -If you use a dark background on github, a lot of images with transparent backgrounds are hard to read. In future, try to upload with solid backgrounds - -### Discussion meetings -Scheduled as-and-when we can, another coming up this sprint - -### Who is working on a support issue? -Is there an easy way to make it clearer who is currently looking at a support issue so that we don't step on each other's toes or neglect an issue. -Shocked face on support thread to show if you're looking into this, smiley when done. - -### Standing up at stand up -Do the people on-site still need to stand up? Currently talking to a series of torsos, danger that if we sit down we'll start taking longer again. Will try this week, see what happens. - -## Process - -### DO we want to be officially limit the number of tickets in `in progress`? Theoretically should be swapping between `in progress` and `impeded` as needed. -Theoretically project board checks should be policing us on this, however our "standard list of warnings" isn't something that we should have. -Impeded could be used as a "parking space" for when you need to take a pause in a ticket for rework hardware testing etc. - -### automate update submodules as a github actions? -Might be just enough times when it wouldn't work that it won't be worth it. Possibly make a manually Jenkins build for it, but seems about as much effort as manual process, so probably leave it - -### Training issues -See above, possibly pointing training too. - -### On site rota -Possibly re-work it, discuss during group meeting - -## misc -###Uniforms -Shelve this discussion, not enough support from team about this - -## Any Other Business -### Support -Lots of support issues this sprint! Assigned 13 points this sprint, not done that since February. Well done! Maybe due to TS1 coming online imminently, network changes, win10 changeover, etc. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.10.26.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.10.26.md deleted file mode 100644 index 254ab392e..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.10.26.md +++ /dev/null @@ -1,98 +0,0 @@ -# 2022-10-26 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| [Freddie Akeroyd](https://github.com/LilithCole) | [Jack Harper](https://github.com/rerpha) | [Lowri Jenkins](https://github.com/LowriJenkins) | - -## Items from last retrospective. - - G34 vs G06 - Opinion doesn't seem particularly strong either way. - - Whichever is more convenient? - - Current Booking is until Christmas. - -## Items from this retrospective -- Uniforms - - Conclusion is no - -- Change to onsite rota One less person, do we want to change rota to rebalance it. - - Yes we should before cycle - - Perhaps a discussion for group meeting. - - do we follow the one on teams or the one on the wall. - - -- Good first issues and Training - - Implemented - - Good first issues for basics - - Training for still good training, but more complex than good first issue. - -- Planning and Pre planning - - Remove pre-planning until we start over-running on planning meetings again. - -- Windows 11 builds - - Whats FIT policy? - - Doesn't exist yet? - - Other IT departments starting to move - - Instruments are Win10 we can just say this is what we support - - It would be nice to know if something is fundamentally broken - - we won't be fixing it for a 6months - a year - - Perhaps just test squish and system tests on win11 with a win10 built client - - have to be occasional due to squish license - - squish only takes an hour though, so should be schedulable - - full build node note really needed at the moment, as we're unlikely to have developers or instruments on it. - -- Laptop and Desktop - - weak laptop at home to remote into work desktop? - - easier to not forgot. - - do we need a machine we can take down to hall if we only have desktops on site? - - we do, but need to do an inventory on them/IT equipment in general. - - do we have enough build nodes? - - we also have a little tripod table so you can use it to put laptop on where you are. - - win11 laptop talks to win10 fine over remote desktop - - -- cake with Mantid - - generally happy with the idea? - - only concern is some people on Mantid are entirely remote and might be left out? - - how do we avoid them and us scenario for people working remotely? - - do benefits outweigh this or not? - - Discussion with people from Mantid would be necessary to handle this would be wise. - - potential approach for hybridization? - - breakdown of how many people remote vs local? - - if were meeting with accelerators, do we cycle between them etc? - - periodic "joint coffee"s perhaps - - Do we want something similar with accelerator controls people as well? - - That might be useful since they are epics newcomers - - do they have coffee meetings or the like? - - they might all be on site on Wednesdays? - -- Previously running column - - relatively new, (this or last deploy?) - - could the version and previous version be automatically be on the wiki page? - - irrelevant to whether or not we actually want to display that information on the front page of ibex - - Table is already noisy and cluttered, its potentially useful, but is it useful enough to clutter this table more - - the page itself is noisy and cluttered, not necessarily specific to that table - - The quick summary of how many release notes to check is useful - - should it be on a separate page? - - Instrument details pages? - - Scientists will rarely want this, but if they do are likely to cause trouble if they can't find it. - - instrument pages horrendously out of date and unmaintained - - keeping it to homepage might be useful. - - was it added for us or because scientists wanted it? - - uncertain. - - Add links to instrument names to instrument page and put it there? - - Should we be updating instrument pages? - - Info is still useful just go through it with the mentality of "when was this migrated, how old is this page" - - Return to this discussion, currently undecided. - - perhaps add a link to the deploy wiki page on where to find the previous version in logs after an install if you forgot to check? - -- Merging Ibex.wiki and developers manual? - - project manager vs technical - - how often do scientists search the wiki? - - user manual doesn't know what version is on an instrument, - - needs time spent on it - - helps to be able look in one place for information - - however this is just for us, so if there's reason for it to be split then probably better to leave it as is. - - possible that some information is in the wrong wiki. - - for those who didn't know, wiki on the same repository as release notes. - - this means that github search -> organisation -> wikis will find information on any of these. - - possibility of website pointed at checked out search to git using git grep - - or Docusaurus perhaps? \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2022.11.23.md b/doc/processes/retrospective-notes/Retrospective-Notes-2022.11.23.md deleted file mode 100644 index 64e95266c..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2022.11.23.md +++ /dev/null @@ -1,65 +0,0 @@ -# 2022-11-23 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| Lilith Cole | Freddie Akeroyd | Thomas Lohnert | - -## Items from [last retrospective](Retrospective-Notes-2022.10.26): - -### Windows 11 builds: -> Perhaps just test squish and system tests on win11 with a win10 built client -- FA: correction - we should rather have a win11 built client talking to win 10 build server - -### Laptops and desktops: -- If current laptops die, they are likely to be replaced with a desktop machine and more lightweight laptop for remote desktop access & more mobility (easier to bring to halls) - -### Cake with Mantid: -- Still keen to do this, but delay until the new year. Starting a new meeting series in December is unlikely to capture a lot of attendance - -### previously running column: -- Jack was the person who brought this up, lets have this discussion when he is involved in a separate meeting - - -## Items from this retrospective: - -### How should we deal with support calls asking for help with work that could have been planned work if scientists told us about it? -- Issue: this sometimes means we would have to drop other urgent work to assist with these tasks which affects other customers. Do we need to put our foot down more? -- Things to consider: - - Will not doing this cost beam time? If not, we can justifiably not do it and just write it up as a ticket. - - Will doing this task be a rabbit hole and take up an unreasonable amount of time? We should at least have a go and try to fix it in 1-2 hours rather than ignore the request completely. If the work extends beyond that, we should be justified to say "sorry we don't have enough resource to spend on this right now, you should have told us earlier" - - If you are uncomfortable doing this, consider looping in Kathryn Baker as Project Manager -- Further action: - - Should we bring this up at the next SAG? - - SAG has switched focus so not all of them might be present. We could bring it up with group leaders separately - - Peter: Similar situations from Culham, solution was to go to team leader and let them prioritize the work - - It may be difficult to find a person with the power to make that decision, e.g. if groups are in different divisions - - Can we monitor how often this actually happens? - - Happens infrequently enough but annoying when it does. - - --> **We will keep an eye out for more of these situations but take no further action for now.** - -### Items from Post Cycle Washup Meeting: -> Reflectometry - HTS is working well now - thanks Tom -> -> Reflectometry - Plotting is improved (thanks Tom), but they do want the functionality to do things like zooming back [Editor's note: already implemented at time of meeting] -> -> Reflectometry - The slits logic changes are looking good where they are in use - thanks Freddie - -- Just mentioned for retrospective as it is nice to highlight positive feedback esp. from reflectometry group, who to experience a lot of snags - -### Is "Previously Running" Column on instrument overview useful? -- Posted something on technical to discuss this but people who could answer were not around at the time -- Discuss this offline, just give the post on `technical` a bump - -### Should we push back on overly complicated requirements that spiral in scope? -- Example: RIKEN requesting very specific GUI behaviours that add a lot of complexity -- There is only so much pushing back we can do, otherwise it will discourage migration to IBEX. -- Pushing back should be done at the point of gathering requirements. This can look like: - - Offering a simplified version of the functionality that is being asked for. Try to get to the heart of what problem we are trying to solve - - Ask for precise answers of what is needed now & what will be needed later so we can prioritize more effectively - - Kathryn: If you feel uncomfortable pushing back, put me in the loop - this is my job - -### General encouragement to pick up reflectometry tickets: -- Thomas L: I have ended up giving reflectometry tickets to Nikola since they were suitable and no one had picked them up late into the sprint. This is ok but not ideal from a perspective of passing on / retaining specific knowledge -- People may be busy with other things that demand attention which is absolutely fine -- If you are a bit intimidated by reflectometry and that is a factor, always feel free to talk to Thomas to pair up. These tickets have been selected for being well scoped and not too nasty as an introduction! diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.01.04.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.01.04.md deleted file mode 100644 index d89dd3a88..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.01.04.md +++ /dev/null @@ -1,50 +0,0 @@ -# 2023-01-04 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| Jack Harper | Hannah Cawley | Nikola Roev | - -## Items from [last retrospective](Retrospective-Notes-2022.11.23): - -### Windows 11 builds: ->> Perhaps just test squish and system tests on win11 with a win10 built client ->- FA: correction - we should rather have a win11 built client talking to win 10 build server -- Contact Facilities IT and ask for their Windows 11 migration plans. After which discussions about this topic can proceed with more relevant information. - -### Should we push back on overly complicated requirements that spiral in scope? -> - Example: RIKEN requesting very specific GUI behaviours that add a lot of complexity -> - There is only so much pushing back we can do, otherwise it will discourage migration to IBEX. -> - Pushing back should be done at the point of gathering requirements. This can look like: -> - Offering a simplified version of the functionality that is being asked for. Try to get to the heart of what problem we are trying to solve -> - Ask for precise answers of what is needed now & what will be needed later so we can prioritize more effectively -> - Kathryn: If you feel uncomfortable pushing back, put me in the loop - this is my job -- Previous talking points were reinforced. General consensus was maybe trying to simplify requirements. - -### Is "Previously Running" Column on instrument overview useful? -> - Posted something on technical to discuss this but people who could answer were not around at the time -> - Discuss this offline, just give the post on `technical` a bump -- An easily accessible web page on a public wiki is convenient for people doing support off-site as well as scientists. -- The information on the page might not always be correct as it needs to be updated manually when an instrument changes versions. -- Having the previous version adds clutter to the `Home` page. -- A proposed solution was adding a link to an auto-generated web page that will hold the version history of each instrument. - -### General encouragement to pick up reflectometry tickets: -> - Thomas L: I have ended up giving reflectometry tickets to Nikola since they were suitable and no one had picked them up late into the sprint. This is ok but not ideal from a perspective of passing on / retaining specific knowledge -> - People may be busy with other things that demand attention which is absolutely fine -> - If you are a bit intimidated by reflectometry and that is a factor, always feel free to talk to Thomas to pair up. These tickets have been selected for being well scoped and not too nasty as an introduction! -- Discuss again when Thomas L. is present. - - -## Items from this retrospective: - -### Is point allocation for support appropriate: -- A little bit on the low side but generally accurate. - -### Migrating to new GitHub projects system and separating issues: -- Separating issues to their own repositories will make them less searchable and easier to be overlooked. -- New system has convenient features and will probably be used in the future. - -### Coffee: -- Regular coffee meetings should continue. -- Organising a meeting with Mantid might be challenging as they have a lot of remote members. -- Accelerator meeting is more doable, should discuss again after follow up for more details. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.02.01.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.02.01.md deleted file mode 100644 index 229dcb204..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.02.01.md +++ /dev/null @@ -1,53 +0,0 @@ -# 2023-02-01 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| JH | NR | DK | - -## Items from [last retrospective](Retrospective-Notes-2023.01.04): - -### -> Is point allocation for support appropriate? -- Best to apply points earlier in the sprint - -### -> Migrating to new GitHub projects system and separating issues -- Decided _not_ to use GitHub Pages for the moment, but will review at later date - -### -> Coffee -- Too tricky to invite MANTID group to coffee (as they work remotely more often), but should be possible with accelerator controls group. **FAA** talking to Ivan about this anyway - - -## Items from this retrospective: - -### Try to automate more of release workflow to avoid errors -- Discuss when ticket is next proposed (at following planning meeting) - -### Shorter sprints to avoid unplanned work? -- Try to be better about adding tickets that anyone can work on -- OK to add urgent tickets any time -- Group would rather _not_ have more context switching with more frequent and shorter meetings -- Suggested splitting tickets down further, but some can't be and so still wouldn't be finished by sprint end -- Decided to keep as is, but bear in mind the option in future - -### CO2 monitor, is it still effective? Perhaps worrying too much about it? -- Agreed that indication useful for air quality if nothing else -- Dilemma between high CO2 levels and room temperature with windows open -- SHE group and/or Estates to be contacted for current policy -> **TL to do this**. - -### Recent AwayDay very worthwhile and productive -- Good to have Hannah & Sonya there for alternative perspectives and input -- Suggestion to discuss long-term plans more often -> **TL to elaborate** -- Hopefully ideas from the day will be implemented, or at least prioritised with rest of work - -### Could be more ambitious with migration schedules -- Feeling that the group could get on with the migrations and finish them. **KVLB** agreed, but reported that the team is too stretched to cope at the moment -- Remaining migrations have most equipment catered for -- Tickets will be created for remaining kit and proposed as training for new starters. Starting soon with PEARL and HIFI. - -### General thought that the group is not currently working on 'large'(er) projects -- TS1 & TS2 coming up soon, so best not to take too much on at the moment - -### Prediction that TS1 coming back online will generate many problems for the group, having not been run for ~18 months -- Lots of equipment has been switched off and/or disconnected during that time, so the group is expecting many calls even if the problem is not actually with the control software itself (but it shows the symptoms) diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.03.08.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.03.08.md deleted file mode 100644 index 005ef67db..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.03.08.md +++ /dev/null @@ -1,70 +0,0 @@ -# 2023-03-08 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| LJ | JH | HC | - -## Items from [last retrospective](Retrospective-Notes-2023.02.01): - -> Try to automate more of release workflow to avoid errors - - Will be discussed in planning meeting (2023/03/09) succeeding this one. - -### -> Shorter sprints to avoid unplanned work? - - No extra discussion concerning this. - -### -> CO2 monitor, is it still effective? Perhaps worrying too much about it? - - Discussed below. - -### -> Recent AwayDay very worthwhile and productive - - Have had some follow up from this: quick wins meeting, and also various discussions. - - Mentions of assigning a day to tackle the various areas in groups: Thomas L volunteered to organise. - -### -> Could be more ambitious with migration schedules - - David and Kathryn on the case creating the new starter tickets. - -### -> General thought that the group is not currently working on 'large'(er) projects - - All agreed that not taking on too much is reasonable, given cycle and TS1 ("lots" of support!) - -### -> Prediction that TS1 coming back online will generate many problems for the group, having not been run for ~18 months - - A lot of support, but surprisingly was mostly TS2 related. - -## Items from this retrospective: - -### Standup: standing in the conference room - - Generally agreed upon that it's only fair enough as remote workers are sitting: we have reached the conclusion that people are welcome to sit/stand as they please - - Mentioned that as there is a culture of standing, unless enforced we will most likely continue standing out of habit. Thus, we will have sit-down standups for the following sprint. - - Evaluate our time efficiency next sprint, and consider the need for a timekeeper (or decide to have stand up standups again). - -### CO2 monitor - - See Thomas L's picture in teams: this is the most up-to-date guidance. We often surpass the 800 mark (e.g., _open windows, reduce occupancy_) in the office, even when it's not particularly full - as we are expecting new starters next month, this is not acceptable. - - The two solutions were seen as either living with the windows open (estate's advice, but it's winter so not particularly viable) or pushing estates for a better ventilation system. - - Freddie to ask estates. - - In the mean time, we will try to leave a fan running: evaluate our satisfaction with this next sprint. - -### Concerns regarding recording hotfixes - - General agreement that it's currently a pain to record hotfixes, and too easy to accidentally skip/miss the hotfix step on the upgrade step. - - Agreed to remove the version numbers from the hotfix page, but migrate these elsewhere as they are useful for support calls. - - Jack H to remove the version numbers from [Instrument Information / Hotfixes](https://github.com/ISISComputingGroup/IBEX/wiki#instrument-information--hotfixes), and add a link to each instrument's wiki page with the version numbers there instead: this will make the information there more concise. - - Tom W to write ticket for investigating technical solutions for this. - -### Database truncation -- All in agreement this is necessary -- There is a [ticket](https://github.com/ISISComputingGroup/IBEX/issues/5818) proposed for this, but it may want updating with some of the technical information mentioned in the meeting. - -### Barriers which prevented [Instrument Demos](https://github.com/ISISComputingGroup/IBEX/issues/7584) from being done - - General feeling that recording yourself is uncomfortable: proposed idea of one person recording, and another editing to overcome this. - - Still very much considered valuable and a good idea. - - Discussed the lack of demo meetings, and how these can be valuable for IBEX input. Decided that it's more sensible to encourage the instrument scientists to come to us, rather than imposing meetings on them. - - Agreed actions: - - Skip demos for this sprint: it's been long enough that we should focus on preparing for the next sprint's instead. - - Each sprint's demos will cover the changes occurred since the last, as then we get a nice archive going forwards. - - Create videos both for each feature in the sprint, and the sprint features as a whole (creative license for the person doing the ticket to decide which way to do this). - - Brought up larger issue of not picking up high priority tickets. Decided this can be rectified by also keeping an eye on the 'Ready' column and the tickets at the top when checking the project board during standup. - - Hannah to note this in standup links file on teams so we remember going forwards. - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.04.12.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.04.12.md deleted file mode 100644 index 98ece6191..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.04.12.md +++ /dev/null @@ -1,51 +0,0 @@ -# 2023-04-12 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| NR | HC | JH | - - -## Items from [last retrospective](Retrospective-Notes-2023.03.08): - -### Standing in the conference room at standup -- people do whatever they want - -### CO2 monitor -- nothing yet, but getting warmer so less of an issue. FA to ask estates - not sure if done yet? - -### Concerns regarding recording hotfixes -Some tickets have been created for this now. - -### DB truncation -there is a ticket proposed for this to create/use mysql instance - -### Barriers for instrument demos -decided to leave them in the end -brought up larger issue of picking up higher priority tickets -- this sprint we have done this more, so just need to keep aware of it - - -## Items from this retrospective: - -### We should set up manual squish test rota -- ticket created to see which ones can _actually_ be automated. ticket has been proposed. -- we should create tickets each time we do this to track progress and be transparent. - - -### Flash reviews hanging round -- perhaps we should bring them up at standup on Mondays to get them through -- should add this on to the Monday reviews (project board etc.) -- add to list of things to check at standup on a Monday and assign people -- should we use a different way of telling about flash reviews? have to be careful about making it too heavyweight. -- checking at standup requires little extra effort, we should do this. -ACTION add this to standup list - -### Are we getting a benefit from discussing points? -- we should properly revisit this time when KVLB is here. - -### What information needs to be shared so that others can lead planning? -- not 100% confident in leading the PI boards - it has been explained but still not sure. -- do we need to not look at the PI boards - they are project planning but perhaps we need to just know how many points we have to play with -- discuss this again when KVLB is here. - - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.05.10.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.05.10.md deleted file mode 100644 index 402efe4a5..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.05.10.md +++ /dev/null @@ -1,39 +0,0 @@ -# 2023-05-10 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| JH | DK | TL | - -## Items from last retrospective: - -### Standup: -- Everyone can stand or sit as they please. - -### CO2 monitor -- We will observe policy, nothing else to add for now. Likely to become less of an issue now that it is warmer and we can open windows more easily - -### Recording hotfixes -- Ticket to improve process is in ready. -- Version numbers have been removed from IBEX overview table to make it more readable. Added link to different page displaying live versions instead. - -### Database truncation -- Nothing to add - -### High priority tickets -- During standup, we have been pointing out high priority that have remained at the top of ready for a long time. This is good and we should keep doing it. - -## Items from this retrospective: - -### People other than KB leading sprint planning -- People are comfortable enough leading the sprint planning meeting, except for the program increment bit. -- People are also unsure about all the other pre- and post-admin surrounding the actual meeting itself. -- DK volunteered to check we have a comprehensive list of necessary steps written down on the wiki (or elsewhere that's accessible) - - We have [sprint planning](/processes/meetings/Sprint-Planning) - check this is up to date - -### Other comments (Mad/Glad/Sad) -- Glad: Support has been going well, feels like we have been good at addressing issues. However, we are also aware that TS1 has not come online yet, will likely make support more challenging -- Glad: We managed to condense a 4hr retrospective meeting into 30 minutes -- Question to new starters whether they have any feedback on onboarding process? - - Evan: It's going well, I have a good general idea of what's going one - - Any issues we had came from wider STFC/UKRI, not this team (e.g. account login issues) - - We should try to make more use of any opportunities to take the new starters to instrument halls \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.06.07.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.06.07.md deleted file mode 100644 index 357ba7109..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.06.07.md +++ /dev/null @@ -1,17 +0,0 @@ -# 2023-06-07 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| HC | LC | NR | - -## Items from last retrospective: - -### People other than KB leading sprint planning -- Meeting instructions will be updated. -- People are interested in trying to run the meeting. - -## Items from this retrospective: - -### Other Comments -- Sprint progressed better than expected. -- Check if on-site rota needs to be balanced better. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.07.12.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.07.12.md deleted file mode 100644 index 60181a91d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.07.12.md +++ /dev/null @@ -1,36 +0,0 @@ -# 2023-07-12 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| TL | NR | HC | - -## Items from last retrospective: - -### -> Check if on-site rota needs to be balanced better. -- Some shifts made so Wednesday is has better coverage, but this has been done and all seems better distributed. - -## Items from this retrospective: - -### Leading Planning: what information needs to be shared/what do we think about sharing the responsibility -- LJ ran the last planning meeting, and LC is scheduled to run the next. All went well last meeting, so agreed it would make sense to start a rota so we can assign responsibility as we do with all other meetings. - -### Outdoor Coffeeβ„’ -- HC and LJ had a trial run and thought it was lovely! -- General consensus of hybrid coffee doesn't work well. Thoughts: - - We currently have staggered on-site Coffees so that all with different onsite days get to attend. However, this was multiple rota shifts ago, so maybe this needs a rethink. So, maybe we only host in person Coffee, as online can be a bit intimidating to join. - - Maybe we consider hosting a separate optional online coffee - could be a chat, could be a zoom call. - -### Mechanism to propose tickets for future sprints, not necessarily the next one - - KB mentioned PI board is exactly for this, and people are welcome to utilise it for this purpose. However, we should consult KB before adding tickets on so it doesn't get horrifyingly cluttered. - - This would also be appreciated as it means not all the responsibility falls on to one person! - - Agreed solution (along with any notes in the ticket to detail the expectations): - - For [PI_2023_02](https://github.com/orgs/ISISComputingGroup/projects/4), tickets can be added to the PI board, in the ['Next PI' column](https://github.com/orgs/ISISComputingGroup/projects/4/views/5) - - For later PIs, tickets can be added to the correct sprint column in the 'Breakdown by Sprint' view - -### Other comments (Mad/Glad/Sad) -- Sad: Have had a very busy sprint with onboarding and support, so highest priority tickets haven't been completed. - - TS1 having lots of problems with odd changes we haven't been informed about, and bits of equipment that haven't been moved in ages. We'll have a few more instruments showing up in September so can expect similar support issues then. -- Sad: H & N leaving :( -- Mad: FMR - "if FMR comes back it will be drop kicked off the top of R80" and JH will cry - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.08.09.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.08.09.md deleted file mode 100644 index 393a9e823..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.08.09.md +++ /dev/null @@ -1,54 +0,0 @@ -# 2023-08-09 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| FA | LC | ES | - -## Items from last retrospective: - -### Wednesday was missing some coverage -- We have shifted the rota around a bit to balance experienced people with new starters. Cycle starts end of September, Lowri will be back in September, this should help with coverage. - -### Mechanism to propose tickets for future sprints, not necessarily the next one - - KB mentioned PI board is exactly for this, and people are welcome to utilise it for this purpose. However, we should consult KB before adding tickets on so it doesn't get horrifyingly cluttered. - - This would also be appreciated as it means not all the responsibility falls on to one person! - - Agreed solution (along with any notes in the ticket to detail the expectations): - - For [PI_2023_02](https://github.com/orgs/ISISComputingGroup/projects/4), tickets can be added to the PI board, in the ['Next PI' column](https://github.com/orgs/ISISComputingGroup/projects/4/views/5) - - For later PIs, tickets can be added to the correct sprint column in the 'Breakdown by Sprint' view - -## Items from this retrospective: - - -### Burndown Chart skewed due to BAU tasks, IBEX vs. non-IBEX tickets -- It all works if amount of Project and BAU added stays consistent; if not, the point average will be going up and down. -Based on IBEX+; It makes the most sense to put that all on the board. If you have an idea of how much work there is and what you’re doing you can better estimate. -- The main idea of the burndown chart is to help estimating and current sprint work. -- What is exactly included in β€œ+” part of β€œIBEX+”? We might not be pointing stuff which is not IBEX and also is not β€œ+”, but should that count on the burndown chart. General scope definition of "IBEX+" explicitly might be necessary -- IBEX work could be more than the β€œ50%” discussed in previous planning, if it’s work done that is not part of the migration project/process - -### Start moving New grads into support stuff? -- Usually this is done after a year and a bit after, but we are somewhat short staffed, so getting an idea for the process generally; i.e. going down to the halls, etc. with those who are on support for ES and DM might be good to start soon. - -### IBEX training course -- For New Starters vs. for New Scientists/Users -- Learning things such as, "How do I add a block in IBEX?" and other stuff would help out when doing support. -- Might be a good idea to run a training course for us, would not need to set up external machines. Are we running a β€œproper” IBEX training course soon? - - Since we are migrating new instruments, e.g. Muon instruments are migrating and such. There might be new scientists who have started on new instruments that would benefit from this. -- Need to send out an email to check interest on external training. Need NDXDEMO/NDXTEST if doing for Scientists/Users -- We can make NDXTEST relatively easily for this, and we have the space and capacity to do this. -- Training course sounds like a good idea; if we just run it for developers we can just do it in G.06 on our own machines, once we have all the new starters, the week of the 20th of August. After that we can sort out if we’re doing it for scientists as well - - -### Other comments (Mad/Glad/Sad) -#### SAD: -- TL: Beckhoff issue generally, Motion Group loss of staff, temporarily losing Jack to them -- JH: INTER might have delays due to safety issues, probably starting off just their own experiments without any users. Not sure how they’ll deal with the safety issue. They pressed a β€œstop” yesterday which caused a large heavy thing to drop, which had hazard potential if someone had been standing underneath it. Various safety concerns with loss of power, etc. This will probably make INTER stuff run a bit slower. -SURF is most likely going back to Galils as well, as they don’t have anyone to do Beckhoff - -#### MAD: - -#### GLAD: -- FA: We got through a lot of useful tickets, and a lot of tickets generally, and we have good new people in the team. -- LC: Happy the last big block of MUSR is done and on schedule. -- ES: Seeing the cryostat/ needle valve work was cool -- FA: Hasn't been too warm which is nice in the office, we aren't overheating. - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.09.08.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.09.08.md deleted file mode 100644 index dcfaa251f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.09.08.md +++ /dev/null @@ -1,54 +0,0 @@ -# 2023-09-08 - -| Chair | Timekeeper | Note Taker | -| :-------- | :---------: | ----------: | -| ES | KB | DK | - -## Items from last retrospective: - -### Burndown chart -- Discussed elsewhere (as item in current sprint below) - -### Supporting instruments (new starters) -- Keep taking them to the experiment halls to gain experience - -### IBEX Training course -- Good idea for all new starters in group, as well as new scientists/support technicians -- Run two courses? e.g. one for ExptCtrls team members and one for scientists - -*** - -## Items from this retrospective: - -### Burndown chart reflecting BAU (now using actual work ratios: IBEX to BAU). -- agree to keep with this as seems to reflect previous sprint productivity reasonably accurately - -### Delegating other IBEX project management tasks -- e.g. SE devices project representative and manage group's resulting work -- Action for group to think about which tasks they'd like to take responsibility for. Can discuss at next retrospective -- Need place to put list of tasks so that people can take them on (e.g. Teams form, tick boxes on ticket/wiki, Outlook task list on ExptCtrls calendar) - -### ES asked about reinstating the office screen to display build status etc. -- Need to ask CMS about previous control machine or a replacement - -### Winter meal out -- Discussed and that someone (usually a new graduate) should volunteer soon. - -### A group activity of some kind would be beneficial and enjoyable. -- ES suggested a visit to CCFE for a tour and then invite them to ISIS in return. - - -*** - -### Other comments (Mad/Glad/Sad) -#### SAD: -- KVLB sad JH not in team at moment, but glad he'll be back soon. - -#### MAD: -- ZK mad that bug left in TPG IOC after release. - -#### GLAD: -- KVLB v glad release, deploys, testing, etc went well and completed on time. -- Everyone glad team is back to full strength, in terms of numbers anyway. -- WS & IH very glad of help with getting started in team and project. -- ES glad he now has ~75% knowledge to be able to answer questions from other new(er) starters diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.10.04.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.10.04.md deleted file mode 100644 index 55d1b2c1f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.10.04.md +++ /dev/null @@ -1,35 +0,0 @@ -# 2023-10-04 - -## Items from this retrospective: - -### Attempting return to scrum poker online due to continued issues with planitpoker - -### Squish test rota - - Attempt to slowly increase squish test coverage of manual system tests - - The developer who is on standup that week - - Not everyone can do this. - - That's fine, only if developer is capable - - Week on standup, add one squish test to replace a manual system test. - - -### Another Away Day - - Last away day was organized from higher up - - What topic would be covered - - Long-term plans for team? - - Review of topics covered at last away day? - -### Central Archiving - - SQL server hosted by SCD or anyone else - - Do we have time to focus on this? - - How much time do we lose truncating databases? - - not necessarily related to this, still likely need to truncated could implement auto truncation when its also in central location - - this would be a good thing to do, but possibly a long-term issue - - possibly use Archiver appliance? - - Out of hours support from SCD issues - -### Private documentation -- If we make documentation private we can put in non public information in, possibly sharepoint because it's already GDPR compliant -- need someone to take time to look into it. - - not the highest priority -- More document fragmentation will make information even easier to miss. - - link to the sharepoint pages from the wiki, that way still single point of entry. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.11.01.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.11.01.md deleted file mode 100644 index d8d231a7a..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.11.01.md +++ /dev/null @@ -1,48 +0,0 @@ -# 2023-11-01 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| LC | DM | TL | - -## Items from last retrospective: -- **IBEX training course:** FA did an EPICS course for new starters, but not one for IBEX from a user perspective. We may have effort available to do this in the next PI. -- **Project management delegation:** Tasks will start being allocated as appropriate to distribute the project management workload (unless people volunteer) -- **Office screen reinstatement:** - - We have not found a new machine for this yet. - - We could use one of the old unused datastreaming machines - - New machine does not even necessarily need windows, just a very lightweight OS capable of running a web browser - - JH has offered to use a Friday afternoon to set a machine up. -- **Winter Meal Out:** DM and WS to start looking into options the day after retrospective. -- **CCFE Tour:** Has not yet progressed beyond the idea stage. - -*** - -## Items from this retrospective: -- **(GLAD) New features:** Just relaying some positive feedback from instrument scientists, particularly regarding new Alarms functionality and Moxa Mappings perspective. -- **Wiki restructuring:** ES has progressed this work as part of the recent "Friday", but still ongoing -- **Central MySQL service:** JH has talked to SCD about implementing a central Mysql service. We need a proper discussion on how exactly this should be implemented but we have a contact in SCD now and we know that it is possible. -- **Should we have Standup every day?:** - - Motivation for retrospective comment was that it was perceived to be getting in the way of things like support during cycle while not adding that much (e.g. "I'm going to continue working on my ticket") - - There was a sentiment that by not having it every day we would lose more than we gain - - Checking on services regularly is important - - We have decided to keep it but should make more effort to keep it brief: - - Chair to prepare more by looking at checks and services ahead of the meeting / fixing minor issues as appropriate. There may be a bit of a transitional period as we collectively build the habit, others may remind the chair of this process for the time being - - Be more strict in mentioning what you achieved the day before in individual updates -- **PI board for planning**: We have decided to try running the next planning meeting off of the PI board instead of the IBEX Project Board -- **Merchandise:** There is a strong desire among new graduates and industrial placement students to get ISIS merchandise. - - We do not want to make wearing this mandatory - - Raise with FA for follow up. JH has the contact of the supplier and will start to collect an order from the team - -*** - -### Other comments (Mad/Glad/Sad) -- **Flat Github structure:** We don't have a good way of grouping tickets hierarchically. This would make it easier to do IOCs in parallel if its split up into sub-tickets - - We have tried this before but found that IOCs are not usually "big" enough to warrant lots of sub-tickets, and it can make development more awkward in places where developing the whole thing in parallel is more convenient - - A more structured approach to categorizing tickets hierarchically might be useful e.g. for larger features like Client, Script Generator, etc. -- **Documentation:** Is lacking in places - - It's up to everyone to keep this up to date. If you notice something missing, feel free to add it - - Sometimes the person looking for the information does not have the required knowledge to add the information, but they can ask for help with writing it, or try to write it after they have acquired the knowledge e.g by asking someone, and then getting them to validate it afterwards - - Generally, making more frequent use of diagrams in the documentation may make information much more accessible than a wall of text. e.g. A diagram showing the flow of information / macros / db loads etc. in an IOC would be very helpful. - -#### GLAD: -- KB happy with everyone pulling together to get PEARL running \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2023.11.30.md b/doc/processes/retrospective-notes/Retrospective-Notes-2023.11.30.md deleted file mode 100644 index a94cd0164..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2023.11.30.md +++ /dev/null @@ -1,36 +0,0 @@ -# 2023-11-30 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| DM | ?? | DK | - -## Items from last retrospective: - -- Wiki restructuring: catch up with ES when returned. -- Central MySQL service: SCD can host, but need requirements first. E.g. Possibly 20 instruments x 20 Gb x 5 cycles per year -> ~2Tb per year. Motor positions particularly useful to log for reinstating. Suggest separate meeting to discuss. -- Should we have Standup every day?: Been trying 30 minutes limit. Feeling is that not much quicker, but an improvement. Suggest host checks errors before meeting to avoid digging through links and logs. LC felt hosting went more smoothly when checked pages beforehand. Depends on number of errors. -- PI board for planning: Will use for planning meeting on 11/01/2024. Report back next sprint retrospective. -- Merchandise: Regarding other groups' policy on keeping jumpers, nothing back from MN yet as been on leave. No problem ordering jumpers as company in science warehouse. DK will order with JH help so that FA can approve. -- Flat GitHub structure: Add pull requests in tickets to development workflow to avoid automatic closing when merging a single PR. Need some investigation of GitHub behaviour as still seems to do this. -- Documentation: Still lacking in some areas, but external users say IBEX wiki very useful and extensive. - -*** - -## Items from this retrospective: - -- Weekly coffee rolling rota: LC has created calendar invitations. -- Migrate new project board style: Now checks are done via application rather than automation(?). May create problems for existing checks if converted. ZS will try on current PI board and report back. -- Regular Code reviews: Each Monday Standup meeting been extended to 1hr to accommodate code review. First one this week which went well. Thanks to JH for stepping in. -- JH mentioned EPICS meeting and asked how many from group would go. Includes training sessions, so good for new-starters. April 15th-18th 2024, week before a cycle. Another EPICS meeting in October and NOBUGS in September. -- KVLB highlighted next sprint is only three weeks to avoid cycle clash. - -*** - -### Other comments (Mad/Glad/Sad) - -- FAA sad that many tickets still under review after Christmas break – anomaly because of long break and people forgot which tickets they were reviewing? Suggest look at first five ProjectBoard warnings each week and ask about reviews status. Can remove and re-add 'under review' labels to reset check. -- KVLB sad about lack of responses from ARGUS instrument scientists. -- All glad that Christmas meal went well – thanks to WS and DM. -- FAA glad most tickets complete and reviewed before end of sprint, especially those for release. -- LC glad system tests green before building release next week. -- LJ glad that gap closed between tickets and reviews on burndown chart. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.01.08.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.01.08.md deleted file mode 100644 index 86d81ba36..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.01.08.md +++ /dev/null @@ -1,26 +0,0 @@ -# 2024-01-08 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| CMS | ES | IG | - -Present: -- In person: IG GR JD TW -- Online: JH KB ES CMS SC DK FA LJ - -## Previous sprint - -### No notes of significance - -## Current Sprint - -### Calendar now shows First Line Support allocations - -### The Christmas meal was excellent and well organised - -### PAT testing and SW Release -CMS raised the forthcoming scheduled PAT testing. We should consider synchronising the next software release activities around it and also how best to restore systems to their states prior to PAT testing equipment shutdown. - -## Mad/Glad/Sad -- LJ Glad - Had a good break over the Christmas holidays. -- KB Glad - People managed to extend the Christmas break somewhat. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.01.31.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.01.31.md deleted file mode 100644 index 791c64f7f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.01.31.md +++ /dev/null @@ -1,33 +0,0 @@ -# 2024-01-31 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| WS | ZK | DM | - -## Items from last retrospective: - -The items from the last retrospective were recapped, no additional comments were made. - -- Weekly coffee rolling rota: LC has created calendar invitations. -- Migrate new project board style: Now checks are done via application rather than automation(?). May create problems for existing checks if converted. ZS will try on current PI board and report back. -- Regular Code reviews: Each Monday Standup meeting been extended to 1hr to accommodate code review. First one this week which went well. Thanks to JH for stepping in. -- JH mentioned EPICS meeting and asked how many from group would go. Includes training sessions, so good for new-starters. April 15th-18th 2024, week before a cycle. Another EPICS meeting in October and NOBUGS in September. -- KVLB highlighted next sprint is only three weeks to avoid cycle clash. - -*** - -## Items from this retrospective: - -- Manual testing: The manual test process seems to be an improvement now that they’ve been transferred. JH suggested decoupling coupled tests and replace that by adding what the previous test was, or perhaps link them. -- Deploy Script: Discussions regarding the amount of user input required, and simplifying the deploy script. The idea of two deploy scripts or automating the user responses was discussed to retain the ability to alter deployment steps (i.e. in case of rerunning tests). Further discussion requires for this item. -- Code review: It was suggested that code review should be moved to a different day – KB will attempt to do so, if available. -- Modular Instrument Control Virtual Machines: Code-Chat on the topic to be organised by LJ. -- Korea EPICS Meeting: There would need to be justification to send more than two members of staff if there was no training at the event. The event program appears to be incomplete as of this discussion. JH, ES and DM appeared interested in attending. Item was still unresolved, it was suggested that a separate meeting should be set up to discuss signing up to the event. -*** - -### Other comments (Mad/Glad/Sad) - -- ZS is Sad that WS is leaving. -- ES is Glad the release went well, and works. -- JH is Glad Excel is no longer being used for manual system testing. -- KB mentions the next sprint duration is 5 week diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.03.06.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.03.06.md deleted file mode 100644 index d12f2a6a5..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.03.06.md +++ /dev/null @@ -1,38 +0,0 @@ -# 2024-03-06 - -```{note} -This meeting is unfinished and to be continued. -``` - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| IH | DK | ZK | - -## Items from last retrospective: - -- Manual testing: Use GitHub project board now. -- Deploy Script: Automated unit tests are needed to make sure. -FA recommends maybe using a config file (predefined answers for steps), further discussion needs to take place to decide how we want to move forward with this. -- Code review: Happened and was successful. -- Modular Instrument Control Virtual Machines: Another code chat this Friday is coming up but this will be the topic of discussion for next one. -- Korea EPICS Meeting: There is a lengthier discussion in our teams channel. JH is the only one that the team and management can justify to send. The reasons include that training does not appear to be general/as useful as anticipated. Another reason is the limited budget. - -*** - -## Items from this retrospective: - -- KB: Item carried over (to the next sprint planning) were left in same order: everyone seems to be fine with that, saves a bit of time. -- ZK: move code review extension to Thursday, KB acted on it and works well -- JH recommends putting screenshots in the release notes. Ideas: - - Put more context and pictures into ticket header - - Place image links in the Release Notes (not images themselves) - Specific implementation is not clear yet. -- - -*** - -### Other comments (Mad/Glad/Sad) - -- - -> Date: 06/03/2024 diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.04.03.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.04.03.md deleted file mode 100644 index d7a71e757..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.04.03.md +++ /dev/null @@ -1,76 +0,0 @@ -# 2024-04-03 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| SC | ES | LC | - -## Items from last retrospective -- items from last sprint left in same order- all good -- code reviews moved to Thursday - been finding it good -- More context and pictures in ticket headers, screenshots in release notes - - packing release notes full of images felt impractical, put links instead - - image added to ticket header by developer before putting it into review - - image will be on the branch you're working on - -## Items from the current retrospective - -### Looking at ISIS beam status page at standup in cycle -- a lot of time beam is off without us realising -- will give us context for the day with regards to possible scheduling -- could make just a PV on our dashboard, if you want more news look at the teams channel -- push back about adding another check to morning standup instead of keeping an eye on teams - -### Ticket context -- Want bad examples of tickets, action on ES for this -- Will bring this up again next retro -- Should we have a longer planning meeting to properly go over what a ticket would entail, and make sure it is written properly with correct acceptance criteria? - - Will run into problem where "the person whose domain this ticket belongs to" is absent - - This was something we used to do a bit of in pre-planning - - Is it worth recording planning meetings so we can reference the discussion later (timekeeper) - - Possibly have a note-taker for planning, will try it in next planning - -### Ordering the priority columns in planning -- People seem to pick up the tickets that they feel able to do/interested in -- Position in ready does (or at least should) influence order tickets are taken -- Feeling that it may not matter too much with 6-monthly releases, however patches change this -- Prioritising adds more time to talking about tickets, however planning meetings are already very short -- Sometimes people skip tickets because it's in an area they aren't familiar enough with, or is not clear what needs to be done -- Enforcing the order will push people into areas they're not comfortable, which would be good in the long term - - We're allowed to make mistakes, you don't have to succeed from the outset (especially if it isn't urgent) - -### Splitting PM duties -- KB to split duties with GR - -### Make sure flash reviews don;t get missed -- track on github, flash reviews column on task board -- checking the teams channel on Monday is good, but there's a chance tickets get buried - -### Finding out tickets aren't needed -- this has happened in the past, we try our best, sometimes we are given incorrect information -- When picking up a ticket, verify with scientists what exactly they want for it (add this to the dev wiki) - - Alternatively contact relevant sample environment team - -### standup length -- keep it to fewer points -- keep engaged during checking of tests/instrument health - -### github actions -- might be useful instead of jenkins builds -- spin up a windows environment for us -- started looking into a few, can be difficult -- where it's easy, try it, run it in parallel with existing builds, turn of the jenkins versions when no longer needed -- wiki check might be easy enough to move - - Friday ticket to do this - - KB already trying to move project board checks -- not sure if we can have project level actions - - actions are repo level, org level we'd need an app, however we can make our own (KB already trying this) - -### Mad sad glad -- LJ Friday went well, had both meetings, interesting tickets, completed in time -- SC glad he tried programming elsewhere in EPICS - - Some OPI standards were difficult to find, in fact most hidden in checker script - - we don't have a standards page, but we do have an example template OPI we should use - - perhaps make a Friday ticket to make the checker script more clearer -- ZK glad about description of the ticket that didn't end up being needed -- ZK glad SC bringing new tools into the meeting - - happy to try it, but many of us unsure about its used diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.05.01.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.05.01.md deleted file mode 100644 index ec20f66b4..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.05.01.md +++ /dev/null @@ -1,34 +0,0 @@ -# 2024-05-01 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| CMS | | SC | - -## Items from last retrospective -- More context and pictures in ticket headers, screenshots in release notes - - ES pointed to two things: -1. In certain cases the ticket is otherwise well written but the requirement has changed. -2. [6053](https://github.com/ISISComputingGroup/IBEX/issues/6053) is a good example of a well written ticket. - -- Flash reviews as task - - LJ ==> Important that these aren't ignored and picked up with due urgency. On the task board if there are no updates we generally overlook the board. However with flash reviews on the board, no update could mean important reviews haven't been taken up. We need to be careful when checking the task board. - -## Items from the current retrospective -- Going to carry on not prioritising the columns in planning -- Flash reviews are on task boards. If the board isn't updated, we still need to check the flash review items. -- Moving to online meeting also from office - - SC ==> Offline meetings restrict us from using online tools. They also mean that meeting rooms are booked - sometimes much bigger than the number of members present. - - KB ==> Issues with hearing and not comfortable with multiple people talking even with noise cancellation headphones. - - LJ ==> Issues with echo and delay in delivery. - - We're going to keep having meetings as hybrid, as multiple people in a zoom call in the same room is limiting for some of the team -- Discussions on Burndown chart - - KB explained that the burndown chart isn't typical burndown chart, but customized for ISIS. - - LC suggested to invert the Y axis of the graph. -- Discussions around rotating logs off - - CMS ==> When is the file closed and available for moving/truncating/copying - also applies particularly to console logs? When to truncate the DB? - -## Mad sad glad -- LC glad that user training went well, interesting discussions. -- DK glad Chronus is working well despite some niggles. - - glad additional people on the support call is helpful - - sad there is an increase in support calls. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.05.22.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.05.22.md deleted file mode 100644 index d3de4ca6e..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.05.22.md +++ /dev/null @@ -1,87 +0,0 @@ -# 2024-05-22 - -## Power Point slides - -1. **Lowri**: - - - Worked on a Friday ticket, adding component/configuration details. - - Dealt with LabVIEW remote VI for easier communication. -2. **Sudeepta**: - - - Attempted a Java 21 build for CSS. - - Developed a custom emulator for Lindy PDU changes. - - Worked on JMC-based profiling of instruments. -3. **Evan**: - - - Set up EPICS build pipeline on Windows 11. - - Dockerized an IOC for a Friday ticket. - - Updated EPICS dependencies. -4. **Freddie**: - - - Added PVAccess client library to Genie Python. - - Reviewed tasks. -5. **George**: - - - Updated Jenkins build checks. - - Managed storage for non-science data on PCs. -6. **David**: - - - Investigated Moxa RS485 settings. - - Searched for an amplifier for Sudeepta’s project. - - Handled Attocube issue and other tasks. -7. **Jack**: - - - Discussed pearl camera differences. - - Demonstrated Kepco IOC with PVAccess. - - Highlighted PVAccess benefits. -8. **Daniel:** - - - Worked on IBEX Windows 11 build. - - Reworked IBEX buttons. - - Dockerized the IOC. - - Organized demos and reviewed system tests. -9. **Isaac:** - - 1. McLennan Power cycle ticket - 2. Helped refactor IbexButtonBuilder - 3. Created several tickets for alarms based on a James Lord email - 4. Web Dashboard work - 5. IOC emulators kill processes more efficiently on ctrl+c tickets -10. **Zsolt:** - - 1. Updated PyLint - 2. Helped refactor IbexButtonBuilder - 3. Significant improvements/work done to Device Generator -11. **Ian:** - - 1. Onboarding work - -## Old Retro - -Keep flash reviews on the tasks. Leave a comment on the note saying picked up for review. - -Keep having hybrid meetings - -IP students don't have work phones so don't insist we use our phone all the time so not compulsory - -Better labelling for burndown chart - -Draw attention to impeded through a new mechanism. - -## Current Retro - -EPICS top PR Lowri says that there should be a better way to manage the submodules. Jack offered solution and Lowri updated the wiki page to reflect this. - -If discussion ticket and clear acceptance criteria for outcome of discussion whoever assigned to to create the discussion just does it. If the implementation ends up going beyond the points then make another ticket for the rest of the implementation. - -## Mad/Glad/Sad - -*Sad:* -Short but productive sprint -Some of us missed the Aurora - -*Mad:* -EPICS base has hundreds of merge conflicts - -*Glad* -Ian has joined \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.06.19.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.06.19.md deleted file mode 100644 index 2934806fb..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.06.19.md +++ /dev/null @@ -1,50 +0,0 @@ -# 2024-06-19 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| FA | IH | ZK | - -## Items from last retrospective - -- EPICS top PR Lowri says that there should be a better way to manage the submodules. Jack offered solution and Lowri updated the wiki page to reflect this. - - Page has been updated and device generator matches it - -- If discussion ticket and clear acceptance criteria for outcome of discussion whoever assigned to to create the discussion just does it. If the implementation ends up going beyond the points then make another ticket for the rest of the implementation. - - Create ticket if necessary only. - -## Items from the current retrospective - -- Put PyCharm on NDX-s: - - Scientists want this instead of Notepad++ - - We want to discourage use of NDX (client-server based approach) - - Don't want scripts to be run from PyCharm - - They want: autocomplete and syntax highlight, we want: them not to be able to run scripts from it. - - Bottom line: we need more context and requirements formalisation (Jack and Lilith might have a good idea on their requirements based on their recent interactions with scientists) - -- extra role for planning meetings - - notetaker will take on this responsibility - -- Ticket format: - - suggestion of reworking the ticket template with some better guidelines on what to include at certain sections (Testing is the one mentioned) - - reviewer should use what's on the ticket as a starting point and not solely rely on description - -- 15 minute rule in standup: - - fill out first 15 minutes with operations stuff - - we most of the time don't wait if we know people won't make it - - seems like it's going to stay as it is - - come up with alternative solutions and discuss next sprint - -- Joining meeting from the office through your PC: - - Some say it went well, some say it was difficult to hear conversation. - - result: ok for one-offs but do not intend to make it general - -- Certain number of people answer some Jenkins and Nagios checks and results - - could have a code chat on how to interpret status - -## Mad, Sad, Glad - -KB: Glad that Tom is back on the team -FA: Glad that the rack is in place and office looks neater thanks to Jack and others in the office helping out, Also glad many tickets went through and migration is going well. - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.07.17.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.07.17.md deleted file mode 100644 index 2214e69b9..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.07.17.md +++ /dev/null @@ -1,55 +0,0 @@ -# 2024-07-17 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| LC | CMS | DK | - -## Present -- in person: LC, LJ, IG, FA, TW, JD, GR -- online: SC, DK, CMS, JH, KB, DM - - -## Previous Sprint 23/05/2024 - -- PyCharm on NDX control machines - could potentially run scripts via the IDE causing confusion; would produce an extra load on NDX machine -> discourage use if/when possible - -- Extra role for planning (not sure what - timing? editing tickets?) - possibly too much for notetaker to do -> agreed can try at next planning meeting then reassess. - -- Ticket formatting/template - nothing done towards this to date -> LJ will create a ticket to rewrite the template - -- 15 minute Stand-up split -> revisit next retrospective as not enough information this time. - -- Join meeting from office PC -> OK for time being for one-off meetings when room not available. - -- Interpreting Nagios -> LJ will organise a codechat - - -## Current Sprint 20/06/2024 - -- Python standards -> JH suggested a code chat or code review to discuss the changes. LJ agreed and reminded the group that we have standards already, now we'll enforce them - -- Assign ourselves as reviewer of a PR -> all agreed good idea. - -- Have a `Pending` column in tasks board rather than two columns -> KB created mockups of potential new task board (link in `Dev-Changes-Memo` Teams channel). `View 4` agreed as best option. Discussion of labels, sorting of columns, etc. KB will write up some instructions on how to use the system, and to link them from said Teams channel. - -- Fleeces for new starters - T-shirts and polo shirts also requested -> JH will get some quotes - -- Should `email-exp-controls` Teams channel contribute to support issues effort calculations? -> all agreed to only discuss issues in this channel in 'support-issues' for accounting purposes. 'Read Only' access applied to channel? - -- New web dashboard - JH would like to further develop -> TW suggested a code-chat/review of what's been done already before deploying. Agreed would be done on 25/07/2024. UPDATE: JH gave talk & demonstration on morning of 01/08/2024. - -- NOT looking at project board in Stand-Up meeting (as new checks cover most issues) -> agreed to check weekly during Friday's meeting as a trial. - -- Adding new sub-modules to EPICS Top repository -> agreed to create and add empty submodule (to master branch) at beginning of ticket, reviewer will then populate during final merge - -- Concern over large number of 'in progress' tickets -> suggestion to use 'impeded' label more freely rather than just for external reasons. - -- 15 minute wait during Stand-Up - awkward with gap in middle while those present wait for others who've said they'll be late. Sometimes gap filled with looking further at system issues -> LC suggested to start 10:15 and do personal updates first, then look at system status. LC has checked meeting room availability. Agreed we'll try this for two sprints and review next but one retrospective. **Highlight this for reviewer of said sprint** - - -## Mad/Glad/Sad - -- KB was glad we finished the sprint with no tickets in the `Ready` column. Suggested explanation that we underestimated the number of tickets we were capable of completing. -- FA glad Beckhoff issues fixed, JH all of the above for the same reason! -- DK and LC glad Open Day demonstration went well and thanked everyone involved. -- DK and others glad JD has made very good start and fitted in to Team well. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.08.07.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.08.07.md deleted file mode 100644 index faf336d8f..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.08.07.md +++ /dev/null @@ -1,48 +0,0 @@ -# 2024-08-07 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| DM | DK | IG | - -## Present -- in person: DK, JD, TW, IG -- online: LC, LJ, DM, SC, CMS, JH - - -## Previous Sprint - -- Python standards -> JH suggested a code chat or code review to discuss the changes. LJ agreed and reminded the group that we have standards already, now we'll enforce them. LJ to discuss at the forthcoming sprint planning meeting. - -- Assign ourselves as reviewer of a PR -> all agreed good idea. - -- Have a `Pending` column in tasks board rather than two columns -> KB created mockups of potential new task board (link in `Dev-Changes-Memo` Teams channel). `View 4` agreed as best option. Discussion of labels, sorting of columns, etc. KB will write up some instructions on how to use the system, and to link them from said Teams channel. -> LJ commented that it's an improvement. - -- Fleeces for new starters - T-shirts and polo shirts also requested -> JH will get some quotes -> Not done yet - Jack is happy to pass on acquisition information in case anyone else gets some time to do it. - -- Should `email-exp-controls` Teams channel contribute to support issues effort calculations? -> all agreed to only discuss issues in this channel in 'support-issues' for accounting purposes. 'Read Only' access applied to channel? -> Yes it's read-only. - -- New web dashboard - JH would like to further develop -> TW suggested a code-chat/review of what's been done already before deploying. Agreed would be done on 25/07/2024. UPDATE: JH gave talk & demonstration on morning of 01/08/2024. -> JH is planning to work on this next sprint. - -- NOT looking at project board in Stand-Up meeting (as new checks cover most issues) -> agreed to check weekly during Friday's meeting as a trial.-> all finding it a good thing. - -- Adding new sub-modules to EPICS Top repository -> agreed to create and add empty submodule (to master branch) at beginning of ticket, reviewer will then populate during final merge. -> Not yet done. - -- Concern over large number of 'in progress' tickets -> suggestion to use 'impeded' label more freely rather than just for external reasons. -> Doing alright. - -- 15 minute wait during Stand-Up - awkward with gap in middle while those present wait for others who've said they'll be late. Sometimes gap filled with looking further at system issues -> LC suggested to start 10:15 and do personal updates first, then look at system status. LC has checked meeting room availability. Agreed we'll try this for two sprints and review next but one retrospective. **Highlight this for reviewer of said sprint** -> All agree that 10:15 is much better. - - -## Current Sprint -- DK: I think it would be beneficial to the team if every member of it showed a summary slide at each sprint review, no matter how large or small their own perceived contribution to the project may be. -> Unanimous agreement generally. -- FA: Could we move sprint planning to be 10:30 to 12:30 which would be more in line with our start time to allow people travelling further to get to the meeting in time? We could also then use the existing 10:15 stand-up slot for a triage of any support issues for when planning is in cycle. -> There was a certain amount of disagreement due to potential conflicts with out of core-hours, in particular lunchtime. Needs further discussion. -- TW: Could we encourage signing off messages sent from the shared mailbox with something like "Tom (on behalf of exp controls)" or similar? Not just for our scientists actually, sometimes it's a bit tricky as a developer to find out who replied to one of the messages. -> Agreed within the team that we should always try to associate a 'human' with a communication. -- LJ: Do we want to be more strict about re-pointing tickets at sprint change-overs/when putting them into review? we started this sprint with supposedly a large amount of points in review, but often when this is the case it's actually not representative of amount of work to be done. -> There was some discussion and no conclusion was reached. Needs further discussion. -- TW: SURF caused a lot of support issues this sprint, which fell disproportionately on one or two team members. The feeling is that we are taking the blame for issues outside of our control. -> TW suggested more pairing when addressing SURF support calls. All agreed this was a good suggestion. JH/DK suggested a presentation to the dev team on the software architecture etc. to increase familiarity. - - -## Mad/Glad/Sad - -- LC: Sad that Isaac was leaving and he will be missed. -- DK: Sad about SURF issues. -- LJ: Glad that we now have coding standards in place and that we can now build on them. -- IG: Mad that had to share a meeting room with very active rodents above the ceiling. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.09.04.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.09.04.md deleted file mode 100644 index 0474aafe9..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.09.04.md +++ /dev/null @@ -1,42 +0,0 @@ -# 2024-09-04 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| KB | LJ | JD | - -## Present -- in person: GR, LC, LJ, TW, JD IG -- online: SC, KB, DK, DM, CMS - - -## Previous Sprint - -- Unanimously decided to keep the 10:15 stand up meeting - as it is better than having a large gap in the middle. -- People have been signing off messages sent from the shared mailbox with their names which is good. -- Decided to talk about moving sprint planning meetings (to 10:30) next retrospective as FA is not present. - -## Current Sprint - -- KB: Suggested that the deadline for proposal tickets going into next sprint should be 6pm the evening before. Unanimous agree and reminders should be sent out to enforce this, at least until it becomes a habit of the team. -- GR: Priority of tickets being ignored: - - Either don't assign priorities to tickets or take action to make sure that people are picking up the more important ones. - - The aim is for higher priority tickets to be picked up regardless of whether they're interesting or not. - - The main alternative is for it to be enforced that everyone picks from the top of the list which isn't ideal either. - - New starters should be encouraged as they progress to go for more higher priority tickets depending on ability. -- TW: Creating a release is painful: - - We ought to create a 'CI' like process for releases so that when it comes to producing a release, there aren't lots of unexpected problems to solve in a small time constraint. -- JH & TW: Code reviews at Thursday standups: - - Decided that if no one volunteers to do a 'show and tell' then the ticket at the top of review will be picked and the code will be looked at by the team. As it is a review, it should be understandable by the whole team anyways. Also helps whoever is about to pick up the review. -- LJ & KB: `Repointing` Tickets: - - Decided that with the burndown chart coming back there is no need to repoint tickets either during the sprint or between sprints. There was concern about a loss in resolution in how much time a ticket will take after end of a sprint. - - -## Mad/Glad/Sad -- DK: Glad that the deploys went well and that the manual testing process had gotten faster. -- KB: Glad that the changes to the tasks board were working well with the team and that the updated project board automation was almost back. -- Mad that CR11 hadn't been fixed regarding the microphone issue and ceiling pigeons. -- LJ: Sad that she had been ill. -- LC: Mad that she was manually updating the burndown, then became ill. - -## Other -- TW: Technician Training with scientists. David volunteered to help Tom with the training. \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.10.02.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.10.02.md deleted file mode 100644 index 5c407f41d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.10.02.md +++ /dev/null @@ -1,49 +0,0 @@ -# 2024-10-02 - -| Chair | Timekeeper | Note Taker | -| :--------: | :---------: | :----------: | -| CMS | FA | KB | - -### Present: -- in person: FA, TW, JD, IG -- online: JH, KB, GR, SC, CMS, DK, LJ - -## Previous Sprint -* Failed to remind, but 6pm on the Wednesday before the planning meeting is OK -* Possibly gone too far the other way at the moment re show and tell, some concern that we are now presenting there things which should be a code chat - -## Current Sprint -* Timekeeping when talking about own tickets - * Others can and should help in this situation -* Bluesky presentation was good -* Nicer UI for the github configs repo - * Ongoing, new authority types set up, need to keep testing - * Action: JH will follow up on this -* VMS service and controls link - * Discussed at group meeting - * Controls moving to EPICS and a future option may be something different -* Ticket labels - * Are they still useful for viewing tickets in other locations? Yes for some - * Automation will help -* Day for Ruff/Pyright fixing - * We should have one - * Have this instead of a Friday day in the Sprint - * Action: KB to find a suitable day -* Testing all IOCs - * Mainly resolved in the thread - * First task is to resolve running tests in parallel -* Planning meeting timings - * Defer a second time to when Freddie is present -* Task board view - * Use a table rather than a board, gives better information in a good order - * Need to ensure flash reviews are brought to the top - -## Mad/Glad/Sad -KB: As PM, sad that only one out of three instruments has migrated, but glad that they have been delayed for good reasons - -DK: Glad the training went well - -JH: Feels there have been fewer calls for basic items - -## Other -Nothing discussed \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.10.30.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.10.30.md deleted file mode 100644 index 6f7243b45..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.10.30.md +++ /dev/null @@ -1,72 +0,0 @@ -# 2024-10-30 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| CMS | KB |LC | - -Present: -- In person: FA, TW, JD, IG, LJ, LC -- Online: JH, SC, CMS, ES, KB - -## 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 - -## Current Sprint -### Moving planning meetings later in the day -- 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 - -### Using Gitlab for instrument config branches -- 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 - -### ISIS Branded merchandise for new starters -- JH Hopefully getting around to it this week - -### NDX security -- 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 - -### Cabin PC passwords -- 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 - -### Release numbering -- 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 - -### Moving sprint meetings based on availability -- 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 - -### Demos -- 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/Sad/Glad -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 \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.11.27.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.11.27.md deleted file mode 100644 index d1fb02f33..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.11.27.md +++ /dev/null @@ -1,106 +0,0 @@ -# 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 just the meeting changes, but sprint deadlines will remain. we should always mark ourselves as out of office, in our own and the experiment controls. 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 February. -- 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. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2024.12.18.md b/doc/processes/retrospective-notes/Retrospective-Notes-2024.12.18.md deleted file mode 100644 index d09dfe8bb..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2024.12.18.md +++ /dev/null @@ -1,63 +0,0 @@ -# 2024-12-18 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| FA | GR | JD | - -Present: -- In person: IG GR JD -- Online: JH KB ES CMS SC DK FA - -## Previous sprint - -### Security of NDX set up -- Decided not to talk about this in group meeting but rather have a meeting dedicated for it - -### Closing Old tickets -- Backlog has been reduced by 300 so far -- Mention of creating a list of tickets that need 'verifying'- could do this as part of standup - -### Pycharm Pro -- Waiting to hear back form Irene regarding getting the whole team set up - -## Group Mailing Lists -- There are multiple mailing list for exp controls, we should try and make them more concise -- Having a sharepoint mailing list might be useful for letting people e.g summer student access sharepoint (CMS) -- Worth holding a meeting? - -### Demos -- Muons still need demoing for (JH + SC) -- Should we still provide a demo even though the next release is right around the corner? -- Its important to be interacting with users especially muons (Agile) (KB) -- Demoing to muons whilst demoing winter release could be risky. Better off apologising to group - -### Email support rota out of cycle -- In place (KB) - -### Work Exp Students -- Application put in for 2 students. -- FA concerned about desk space -- JH asked if it would be possible to have an apprentice? -- KB was concerned that we might not be eligible for one - -### Other -- Make sure to be running latest MySQL and other components to begin 'testing' for a release candidate. (FA) - -## Current Sprint - -### Points added to project board (KB) -- Can now see a tickets points from repos and project board -- Additional to point labels -- Points allocated per ticket need to be the same so automation being worked on - -### Standup/Meeting rotas- put roles in exp controls calendar -- This would take too much time (KB + LC) - -## Mad/Glad/Sad -- FA Mad/Sad - HIFICRYOMAG memory being hogged by Sophos - could look at Microsoft alternatives? -- KB Mad/Sad - People outside of the team making decisions on our behalf where they shouldn't be e.g Admin by request -- FA Mad/Sad - Industrial Placement restrictions for next year -- CMS & most others Glad that Christmas Meal was organised so well and held. Sad that FA and SC couldn't make it. -- DK Glad - support rotas are working well. Needs review (FA) -- FA Glad - Log files more clear & rotating properly -- FA/JH Glad - Bluesky testing continues to be going well \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.01.07.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.01.07.md deleted file mode 100644 index 4a298e59d..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.01.07.md +++ /dev/null @@ -1,23 +0,0 @@ -# 2025-01-17 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| CMS | ES | IG | - -Present: -- In person: IG GR TW JD -- Online: JH LJ KB ES CMS SC DK FA - -## Previous sprint -- Points added to project board (KB) -- Calendar now shows first line support. -- Christmas meal was excellent. - -## Current Sprint (short) - -### PAT Testing -- Could cause issues with release, so need to try to synchronise activities. - -## Mad/Glad/Sad -- LJ Glad - Glad for a good Christmas break. -- KB Glad - People managed to extend their Christmas break somewhat. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.02.04.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.02.04.md deleted file mode 100644 index 06b20f5e6..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.02.04.md +++ /dev/null @@ -1,81 +0,0 @@ -# 2025-02-04 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| TW | | JH | - -Present: -- In person: IG GR KB -- Online: JH TW ES CMS SC DK FA LJ LC JD - -## Previous sprint - -nothing - short sprint - -## Current Sprint - -### PI changeovers can be confusing -Christmas PI changeover was tricky - if there are any ideas to make this easier please suggest. - -### shared group laptop -it's very helpful (in fact it may even be another "excellent helper"?) to take to meetings and to the halls - -### ticket priority -medium and low have been picked up ahead of high priority tickets this sprint. In this case the release tickets were dependent on each other, but that doesn't explain all of them. -we should pick from the highest priority downwards regardless of if we want to do it or not. - -### putting code in the source code of the dev manual -we should move these out to the _code_ repository, not the wiki repository, as they are a bit of a pain to see otherwise as you have to clone the wiki repository. - -### manual system tests on release -are the statuses currently in place enough? should we split into `fail`, `fail - fix`, `fail - noted`? Yes. Issue proposed to do this and improve the template: https://github.com/ISISComputingGroup/IBEX/issues/8633 - -### build nodes -they are slow. we should axe off NDW1757, it's terrible. Can we have faster build nodes? -we could build over the network and split things client/server as servers have caches. The main bottleneck for build nodes at the moment is disk speed, perhaps we need more node. -we could consider using dev machines overnight as jenkins nodes. Would have to be careful about soak testing etc. -RIP NDW1757 - -### feedback from scientists - confusing "instrument patching" / "ibex deployment" email -can we combine these better so that its less confusing? -we had the opposite request last time. -we don't normally send out "done" emails as it's just extra admin. perhaps we should start doing so? - -### galil-old is bad -yes, it's bad, we should test the new one, it's hard to maintain and keep features up to date. -galil-old caused issues over the last release as it relies on VS2010. -the new galil driver isn't quite there yet, we need to test on CRISP (they're happy for us to do so) - -### email sent to unclear -it was an old FIT email - we'll delete it. - -### nice that we can pip install genie_python now -yes - -### first line support -we should remind people who are on first line support the next week - we'll start doing this at standup. - -### zipping up builds -Sophos is horrible and tries to read the millions of files that e.g. client builds are made up of - we should zip these up. -we should also do this with the ibex backup from NDX to data-old. -turns out we already do this! but we should make our nightly builds not bother with leaving the unzipped build. that will save a lot of files - -### TwinCAT on developer machines -we should not bother installing it on developer machines, and leave NDXMOTION to run TwinCAT XAR so it can simulate Beckhoffs. - -## Mad/Glad/Sad - -glad - release done! - -glad - pat testing done! - -glad - interviews done! - -glad - we won't get timing system issues this cycle (allegedly) - -mad - the release was not fun - -mad - partial derivatives and asymmetry is hard - - - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.03.05.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.03.05.md deleted file mode 100644 index bf4ba5706..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.03.05.md +++ /dev/null @@ -1,155 +0,0 @@ -# 2025-03-05 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| GR | ??? | TW | - -## Previous sprint - -PI changeovers confusing - -Shared laptop helpful - -Ticket priority - probably not enough data to tell whether there was any change. - -Source code in dev manual - yes move it - ticket exists - -Manual system tests on release - -Build nodes - -Windows patching / IBEX deployment - note added to draft email by KB - -GALILOLD is bad -- Should we update GALILNEW to be actually new, otherwise GALILNEW is a bit old. - -Remind people when they are on first line support - -Zipping up builds, Sophos is horrible. Tickets. Many tickets. Some of which are conflated with each other. - -Use NDXMOTION to do Beckhoff stuff, don't install XAR locally. JH removed from install & build wiki page. - -## Current Sprint - -### Defunct emails that looks like it's associated with us but isn't. - -FA has sorted this. - -### Instrument Demos - -FA: how to balance too early (scientists on holiday) vs too late (not enough test time) - -KB: think we should book demos week after deploy. - -Conclusion: try to book 2 weeks before cycle - -### Instant awards scheme - -LC: Yes put people forwards for awards. Nominating whole teams / more people will tend to get a bit more scrutiny. - -### Tips/tricks teams channel - -ES: Minor tips & tricks that aren't worth a whole wiki page, maybe a lightweight way to share these little things. - -KB: creating the teams channel as we speak - -FA: more curation/organization might be good long term if it gets too big. - -KB: if channel gets too big then we can move things out of teams channel to somewhere else - -IG: OneNote? - -KB: Onenote in teams not very good - -GR: Maybe let's go for a channel this sprint and then review - -Various: is it searchable enough? - -FA: how categorizable is it? - -LJ: Make replies to top-level "theme" posts? Similar to retrospective channel? - -Conclusion: try teams channel, evolve it over time as needed. - -### Release timeline - -GR: Let's not spend too much time discussing this - -### The end of 🐐 is nigh - -DK: πŸπŸ’€ at end of financial year? - -KB: No. End of project is September 2025. But most people won't be booking significant time to ibex post June. - -GR: Just to be clear this is the 🐐 project, not the 🐐 product - -KB: next PI we might be looking at doing things differently. August. - -DK: Can we have more time for internal team/technical priorities - -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. - -FA: Post ibex finish we can review some of our IBEX tech choices, some bits of 🐐 are looking a bit dated. - -### Wikis - -GR: 3 wikis exist, sometimes with duplicate content. Happy to tinker. - -IBEX: scientist facing -Dev: dev facing -User: how to use ibex - -Conclusion: go for it George. - -JH: repository-specific info - migrate to `README` or docs of each repo. - -LJ: Searching? - -ES: Search at org level - -### Pyright - -JH: people will be upset but it's a good idea - -TW: didn't actually cause too many issues in practice - -KB: still some instruments to migrate in summer - -### Standup - -CMS: Move "Friday" standup tasks to "Thursday"? - -LJ/KB/GR: Discussion about whether we might lose code review time - -LJ: should we be stricter about actually doing the code reviews - -### Staff updates vs standup - -JH: Big announcements (UKRI/STFC/NatLabs level) that various people in the team miss if clashes with standup - -KB: All staff meeting might take priority anyway - -Various: discussion about tangentially related things - -ES: is standup actually important? - -KB: standup is important to connect to others - -GR: We can probably justify missing one standup every so often - -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. - -### - - -## πŸ˜ πŸ˜’πŸ˜„ - -- FA πŸ˜„ we made changes to lots of stuff in release and got away with it -- LJ πŸ˜„ about stress(full) rig -- ES πŸ˜„ about OPCUA -- GR πŸ˜„ about 🌞 in the evenings when leaving work -- CMS πŸ˜„ that we've run EMMA on newer windows version/hardware - * CMS πŸ˜„ OpenGENIE & SECI work on windows 11 (?!) -- FA & KB & others πŸ˜„ about SECI πŸ’€ -- IG 😠 that his πŸ’» got wiped -- GR πŸ˜„ that this meeting wasn't stupidly long \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.04.03.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.04.03.md deleted file mode 100644 index 730eb5574..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.04.03.md +++ /dev/null @@ -1,146 +0,0 @@ -# 2025-04-03 - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| JD | ??? | SC | - -## Previous sprint -### Defunct emails that looks like it's associated with us but isn't. - -FA has sorted this. - -### Instrument Demos - -FA: how to balance too early (scientists on holiday) vs too late (not enough test time) - -KB: think we should book demos week after deploy. - -Conclusion: try to book 2 weeks before cycle - -### Instant awards scheme - -LC: Yes put people forwards for awards. Nominating whole teams / more people will tend to get a bit more scrutiny. - -### Tips/tricks teams channel - -ES: Minor tips & tricks that aren't worth a whole wiki page, maybe a lightweight way to share these little things. - -KB: creating the teams channel as we speak - -FA: more curation/organization might be good long term if it gets too big. - -KB: if channel gets too big then we can move things out of teams channel to somewhere else - -IG: OneNote? - -KB: Onenote in teams not very good - -GR: Maybe let's go for a channel this sprint and then review - -Various: is it searchable enough? - -FA: how categorizable is it? - -LJ: Make replies to top-level "theme" posts? Similar to retrospective channel? - -Conclusion: try teams channel, evolve it over time as needed. - -### Release timeline - -GR: Let's not spend too much time discussing this - -### The end of 🐐 is nigh - -DK: πŸπŸ’€ at end of financial year? - -KB: No. End of project is September 2025. But most people won't be booking significant time to ibex post June. - -GR: Just to be clear this is the 🐐 project, not the 🐐 product - -KB: next PI we might be looking at doing things differently. August. - -DK: Can we have more time for internal team/technical priorities - -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. - -FA: Post ibex finish we can review some of our IBEX tech choices, some bits of 🐐 are looking a bit dated. - -### Wikis - -GR: 3 wikis exist, sometimes with duplicate content. Happy to tinker. - -IBEX: scientist facing -Dev: dev facing -User: how to use ibex - -Conclusion: go for it George. - -JH: repository-specific info - migrate to `README` or docs of each repo. - -LJ: Searching? - -ES: Search at org level - -### Pyright - -JH: people will be upset but it's a good idea - -TW: didn't actually cause too many issues in practice - -KB: still some instruments to migrate in summer - -### Standup - -CMS: Move "Friday" standup tasks to "Thursday"? - -LJ/KB/GR: Discussion about whether we might lose code review time - -LJ: should we be stricter about actually doing the code reviews - -### Staff updates vs standup - -JH: Big announcements (UKRI/STFC/NatLabs level) that various people in the team miss if clashes with standup - -KB: All staff meeting might take priority anyway - -Various: discussion about tangentially related things - -ES: is standup actually important? - -KB: standup is important to connect to others - -GR: We can probably justify missing one standup every so often - -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. - - -## Current Sprint -### On call. -Jack H: I much prefer doing the weekend on call first as we are now, as opposed to the weekdays-then-weekend we were doing previously, feels like the worst bit is out of the way at the start. - -David K: Also better for managing cover for the weekend before cycle and the short final week of cycle - which was the original idea for changing the on-call period, IIRC. - -### Centrally-hosted MySQL Database - Status? -David K: What's the status of this? The ticket was last proposed two years ago: [IOC Log Server: Push to a central MySQL instance Β· Issue #5820 Β· ISISComputingGroup/IBEX](https://github.com/ISISComputingGroup/IBEX/issues/5820). Is this dependent on the move to Archive Appliance? -We were recently asked to extract data after a local database had been backed-up and truncated on RIKENFE, so had to import it from the network share, which took several hours, then create CSV files of the requested data using the 'IOC log query' script. The instrument scientist could have done all of this themselves from the Log Plotter perspective using the 'Data Export' panel if a central MySQL database had existed. - -### On-site rota -George R: a) for (very good reasons on the whole) we have a situation where the only people on site to day are the ones who only work on site. I accept this might occasionally happen, but I would like to keep an eye out for recurrences of this, as it may suggest that the rota is not working and needs revisiting. -b) Can we agree a process for how people permanently change days and advertise it - -Kathryn B: I thought the rota was the guaranteed days on site, and extras as necessary or swap with someone else to maintain the minimum cover - so if you need to be in an onsite meeting on a day you would normally not be on site, you just come to site and work there instead of at home. - -David K: the up-to-date rota is in a tab in the announce channel: [Onsite Rota](https://teams.microsoft.com/l/entity/1c256a65-83a6-4b5c-9ccf-78f8afb6f1e8/_djb2_msteams_prefix_2670613932?context=%7B%22channelId%22%3A%2219%3Aeaf1bd106e2d4df78f4ea9f7aa3d003d%40thread.skype%22%7D&tenantId=3f66361c-a87e-4158-8f61-99e82db3cac8) - -### EPICS Collaboration on site -George R: It was great to see Evan working with a colleague from Accelerator Controls today. Can we do more to build links with other RAL EPICS users and share knowledge/expertise across groups? -Freddie A: We have had meetings with accelerator controls in the past, but these dropped off at some point, we can restart. I'd offered to host the next "EPICS Oxfordshire" meeting onsite for start of this year, but then as STFC were hosting a full collaboration meeting it was decided to postpone until later in year. - - -## πŸ˜ πŸ˜’πŸ˜„ -- KB πŸ˜„ **Bluesky scripting** has gone really well so far, and I think the message from Diego asking for it on zoom is a great example of this ([diego.alba-venero@stfc.ac.uk via email: bluesky on Zoom](https://teams.microsoft.com/l/message/19:4e381ff6b5674230a74878b1355eec22@thread.skype/1743159129191?tenantId=3f66361c-a87e-4158-8f61-99e82db3cac8&groupId=d9946ec3-a454-424f-b673-5ffcb9f9ade0&parentMessageId=1743159129191&teamName=IBEX%20Developers&channelName=email-exp-controls&createdTime=1743159129191) -posted in IBEX Developers / email-exp-controls on 28 March 2025 10:52) - -- TW πŸ˜„ We eventually had SECI free cycle!! - -- CMS πŸ˜„ Teams for planning seemed to go very smoothly, should we be moving other meetings? \ No newline at end of file diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.05.07.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.05.07.md deleted file mode 100644 index d1bedf8b4..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.05.07.md +++ /dev/null @@ -1,66 +0,0 @@ -# 2025-05-07 -## Sprint 2025_04_03 Retrospective (2025-05-07) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| FA | ??? | DK | - - -## Previous previous sprint - -- TW: New wiki style better for searching, can still use GH search. Other search plugins available to improve further, will investigate. -- JD: PyRight day postponed as people busy. - - -## Previous sprint - -- FA: Possibly host central MYSQL instance ourselves. CMS will investigate server options. -- FA: May need to revisit onsite rotas later in year. -- LJ: EPICS collaboration on site - more local contacts made through recent meeting. - - -## Current Sprint - -### Move retro notes away from dev wiki? -- LJ: if not wiki for retro notes, then not definitely _not_ MS Teams. -- TW, GR: MS Teams not good for searching. -- TW: Concatenate all notes into one page to help searching? -- KB: Not recommended for general search results as will pick up all matches in wiki including notes. -- FA: Exclude some retro notes from search results? -- TW: Sphinx can be configured accordingly. -- GR: Try above and revisit next sprint retro? -- ALL: Yes. -- TW: Can add tags to pages to aid searching/result filtering. - -### Office spring clean? -- GR: Will put something in calendar for an afternoon. -- Various: Boxes, monitors, dead chairs to get rid of. - -### Now no SECI - Tech Debt day to remove references? -- KB: Some VIs still used. -- KB: Releasing to HIFI & ARGUS in August and then testing, so can't remove all SECI before that. -- Various: Then start SECI removal after next release? -- LC: will book date for beginning of September. - -### IBEX Training: -- TW,LJ: SECI no longer covered in course so went more quickly. Also fewer trainees this time. -- KB: Expand course to cover more functionality and fill time instead. -- LJ: Will create ticket to cover changes. - -### No longer look at project board during Stand-Up meeting once per week? -- GR: Do auto project board checks satisfy requirements? -- LJ: Need to check uptake of tickets from top of Ready column. Not currently covered in checks. -- KB: Could be added to checks (e.g. ticket taken from below one of higher priority). -- LC: Auto check better idea - people will forget what board looks like from week-to-week for comparison. -- FA: Useful to see names of tickets on auto check results. Need context for results. -- KB: This can also be added to checks output. -- LJ: Not much more gained by 'physically' looking at board. -- GR: Should still look at board at time of release to check progress of specific tickets. -- KB: Can always _optionally_ look at board. LC changed Stand-Up instructions. - - -## πŸ˜ πŸ˜’πŸ˜„ -- FA,DK: πŸ˜„ EPICS meeting on site went very well. Thanks to local organisers. -- LJ: πŸ˜„ IP recruitment process over (nearly). LC: Offer going out soon. -- CM: 😒 about Oracle purchase freeze and GPC removal. -- DK: 😒 that was low turnout for IBEX training. diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.05.08.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.05.08.md deleted file mode 100644 index 415fc95cb..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.05.08.md +++ /dev/null @@ -1,55 +0,0 @@ -# 2025-06-10 -## Sprint 2025_05_08 Retrospective (2025-06-10) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| ~~KB~~ LC | LC | ~~ES~~ GR | - - -## Previous sprint -- **Move retro notes away from dev wiki** - TW confirms that retro notes demoted in wiki search results now. GR noted slight pain in creating page for today's notes. Agreed no further action for now. -- **Office Spring Clean** - complete -- **SECI Tech debt day** - KB confirmed LC Booked for September -- **IBEX Training** - KB confirms working on updating materials -- **Stand-up instructions** - no further discussion -- **IP Recruitment process** - process is over, long live the process. - -## Current Sprint - -### Network dependency of our architecture -- GR suggested given FA comments, perhaps we should agree we are willing to be dependent up to router C -- FA confirmed that now FIT doing support out of hours, we could confirm we will rely up to hub -- Was discussion then as to whether Accelerator controls are dependent on router C or not. -- Agreed need for a nuanced position as a group on what parts of network we wish to be resilient to. -- FA highlighted Bob Mannix position used to be that they should run when disconnected from router C. FA to confirm wit Ivan current position. -- related - FA confirmed impact document has gone to HG to then be escalated by ISIS upwards - -### Moving / Mirroring on call spreadsheet to sharepoint -- TW - in order to be accessible from home when site network down -- FA - could also use Teams -- JH - Could we use ISIS Sharepoint -- General agreement Teams would be a good place for it as remains private to us ans would be accessible when network down. -- FA confirmed ISIS page has old group mobile number removed. -- KB agreed to move it to a tab of the support issues channels - -### Spring clean -- thanks - -### Network outages -- TW - most outages didn't take much recovery time - -### Many instruments hit 100G/24hr limit on export only area -- TW - MAPS, Polaris, NIMROD all hit limit. CMS demoed NIMROD solution in code review. Agreed in code review to extend deployment -- CMS confirmed that given time it can be deployed more widely (in response to FA question). CMS expressed concern about knock on impact on how careful people may be as a result of change. -- FA - has emailed MAPS about the creation of RAW files as well as Nexus files. RAW files do not compress as well as nexus (can be one order magnitude). Not writing raw file may well solve this issues for some of these issues. Should watch for this. -- Discussion of other log files and reasons for storage and history (CMS to email FA about one specific case to check if case involving 100s file/run needed) - -#### Migration of wiki -- KB - thanks for maintaining history in migration -- JH - we have migrated user manual. What should we do with IBEX wiki? KB suggested we should think about what to do with the content. Agreed some of it was related to historic project. -- JH - we have a site network copy of the ibex wiki - Gollum is serving it on Shadow. Do we need it. Agreed Gollum can be taken off and wiki was only there as other 2 were. - - -## πŸ˜ πŸ˜’πŸ˜„ -- FA 😠 Network πŸ˜„we got through it all -- KB πŸ˜„ SECI free for two cycles diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.07.10.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.07.10.md deleted file mode 100644 index 2ccb41a47..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.07.10.md +++ /dev/null @@ -1,68 +0,0 @@ -# 2025-07-10 -## Sprint 2025-07-10 Retrospective (2025-07-29) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| SC | IG | LJ | - -## Items from previous Retrospective - - Notes not uploaded - -## Items from this retrospective: -### Network Ports - - Having a R55 network port exempt from NAC has been useful for various bits of setup. maybe we could ask for a few more R55 and or R80 ports spread around the office (and label them) so that if bring registered equipment for testing we can more easily? - - Isn't that fairly simple just patching? - - Unfortunately not, virtual private network - - is it just the NAC Exempt, or is it R55/R80 - - It's a bit of both, NAC Exempt is useful, but R55/R80 is also useful - - R55/R80 IP address situation, maybe it would be better if we could get a NAC exempt R3 port? - - Even if equipment has tools to configure, its difficult if you don't have mac address/ip address - - Movable equipment might need to be move between networks as well. we may need to push back that we need a different process for network access - - Can FIT do this? or would they just send you Anthony - - they send you a questionnaire asking for mac address and windows version, so useless for say, a lindy switch - - FIT don't really look after this, there just forwarding on to DI. - - Weren't we talking to Anthony about this? - - Yes but don't know what the answer is yet/haven't chased up. - -### NDW1926 Linux build? - - Build Nodes NDW1926 can't run win11, can we convert it to a linux box so we can actually have "our" linux build server, as the rest is on the cloud, or will that just become another system to maintain that we don't want. - - we could put windows server long term support on it, or force upgrade it to win11 and see how long it lasts? - - Might catch us out, have a build fail due to unsupported OS on the machine etc. and end up on a debugging rabbit hole - - ESU licence used to be 3 years for Β£100, Β£200, Β£400 for support. At the moment they are very cheap, but we don't know for certain that its the same - - could downgrade it to win-server 2019 long term support and get support til 2029 - - SCD Cloud is no longer stable, is it important to move away from it - - Nothing critical relies on the cloud - - Actually release_branches do, could we move those to shadow? - - Rare that cloud is down long enough to actually effect this - - its mostly just checking-out and tagging things, could we move this to a github action? - - Jack looking into it - - If this doesn't work, could also run on the same system as the automation. - - -### IBEX Wiki things needed to be done - - JH gonna put the message in the list of things to do in the Documentathon - - decision that needs to be made, Demos and associated pages, either keep them here in "code" or move them to the dev manual, or time tables and notes get added to the ticket to that set of demos. - - Yes we'll do that, timetables and Notes will now be on the demo ticket. - - Do we have any broken links now? - - There shouldn't be, all links in the program should be to the user manual, not the ibex manual - - links are hardcoded in the code, no one location to check them, might be better to have a property file as a single source of truth about all links we are using. - - That's potentially a lot of little changes in the gui, but worth doing. - - Might be helpful for it to work in different languages if needed to. - - Welsh? - - SC will make a ticket, but no time for it this sprint, maybe next sprint or the one after. - - -### #8349 was in backlog for a long time, why? - - FA has made some changes and put it in review - - Looks to be issues that occur on pearl but not dev machines - - Previously tested on different ioc with same plugins, now testing on same ioc in simulation so hopefully more likely to work - - -## πŸ˜ πŸ˜’πŸ˜„ - - πŸ˜„ IOC tests caught the fact that a modbus dependency update switched the definitions of some data-types between signed and unsigned. - - Nice because this is exactly what the tests are there for - - It was listed as a major breaking change, so not unexpected - - πŸ˜„ No urgent items for release. - - 😒 to lose JD - - πŸ˜„ to see that SOPHOS is going away - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.07.31.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.07.31.md deleted file mode 100644 index 2ca0d688b..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.07.31.md +++ /dev/null @@ -1,41 +0,0 @@ -# 2025-07-31 - -## Sprint 2025-07-31 Retrospective (2025-08-27) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| ~~FA~~ GR | ~~CMS~~ JH | DM | - -## Items from previous Retrospective -### NDW1926 Linux build? - - JH states that it is faster. - - JH notes that NDX1926 was switched off in October as it can’t run windows 11 and as a result we will be down one build node. - - JH suggests we consider buying another build machine. Further discussions during the Experiment Controls Group Meeting need to be had about purchasing machine before it is critical. - -### IBEX Wiki things needed to be done (Documentation) - - JH states this issue is ongoing, as sprint it coming up he will double check time frames. - -## Items from this retrospective: -### Navigation of folders during deployment - - Discussion were had around the organisation of the \\isis\shares into a scratch directory, KB mentioned that scratch could be a misleading/confusing name. - - JH suggests moving releases up the directory tree. - - JH will provide a proposal in advance about his plans to change the file structure and give people an opportunity to add comments. - -### globals.txt v config ioc macros - - Telling people that globals.txt exist and that they would need to change them. - - A ticket will be created for the next sprint. - -### First line support - - Pushed forward to next retro due to FA absence. - -### Deployment - -### Windows defender - - JH mentions it better than Sophos. - -### Disk space - - Postponed to another meeting or next retro. - -## πŸ˜ πŸ˜’πŸ˜„ -πŸ˜• Nothing captured - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.08.28.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.08.28.md deleted file mode 100644 index b129bc825..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.08.28.md +++ /dev/null @@ -1,71 +0,0 @@ -# 2025-08-28 - -## Sprint 2025-08-28 Retrospective (2025-10-01) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| TW | KB | IG | - -## Items from previous Retrospective -### NDW1926 Linux build? - - *ACTION*: FA To check with CMS how to adopt Windows 10 LTS for build server. - -### ISIS Shares (\\isis\shares) organisation - have not got around to it yet. - - Carry over to next retro. - -## Items from this retrospective: -### Review of First Line Support - - Discussion were had around the adoption of the first line support procedure. - - GR identified that there was a problem where some issues were not picked up and missed from being actioned. - - GR suggested a formal handover at the end of a week, perhaps write up a Friday summary of the week. - - GR mentioned that Top Desk is the corporate platform and maybe we should look at using it. - - FA Mentioned `Jira`, but it's not free and we would need to look at licensing. - - FA suggests adopting a system where we can enter issues and close them out. - - *ACTION*: FA to consider options in conversation with team members. - -### Developer Manual - protection of master branch - - There was a bit of a debate in comparison between the ease of updating the manual versus the -ideology that documentation should be at the same quality as code. - - It was decided that instead of committing directly to master, we should have a trial period of -creating PRs and flash-reviews. This policy should be reviewed at a later date to consider its efficacy. - -### Documentation on wiki instrument-information--hotfixes - - JH raised the question as to whether we need to our hotfix/deploy process and suggests that we -should either keep the hotfixes page up to date or remove it. - - FA suggests creating a flash review or ticket. - - Remove the Hotfix column. - - Deploy scripts to not prompt to add text to the hotfix column. - -### Wiki instrument information pages are significantly out of date - - GR asked whether we should make an effort to improve them, as having a page is useful for instrument support? - - TW posed the question as to whether we should use the existing pages as a starting point or bin them and start again? - - *ACTION*: TW to place a warning at the top of every page stating that the current information is -historical content and may not be up to date. - -### Disc space - - TW stated that small discs on various machines has caused repeated issues. - - *ACTION*: GR to set up a group meeting with CMS to discuss. - -### Weird permissions on stage-deleted - - Could we modify permissions of the stage-deleted folder or perhaps don't use it? - - Issue bumped until CMS is available to discuss. - -### Timings of deploys - - GR commented that deployments being scheduled only a couple of weeks before cycle and during Summer holidays -can be problematic, the Summer being of particular issue. - - We should attempt to deploy a week earlier and deliver demos earlier. - -### Deploy script refinement - - TW pointed out that occasionally a manual step in the deployment process does not get done, but -there is no check that it actually has been done. - - The Road-map should incorporate procedures to address this. - -### Renaming of 'server-common' - - JH suggested that we should rename 'server-common' to 'ibex-ca-helpers'. - - FA suggested 'ibex-epics-helpers' - - *ACTION*: JH to find some suitable names - -### Galil-old branch - - FA suggested that a repo check on galil-old would be a good idea. - - *ACTION*: FA to create a ticket to create a repo check on galil-old. - diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.10.02.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.10.02.md deleted file mode 100644 index 34569e989..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.10.02.md +++ /dev/null @@ -1,90 +0,0 @@ -# 2025-10-02 - -## Sprint 2025-10-02 Retrospective (2025-10-28) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| JH | TW | KB | - -## Items from previous Retrospective -### Review of First Line Support - - FA talked to DI about `JIRA` it will do what we want, but cost is a query - - The other solution available was not going to do what we need. - -### Developer Manual - protection of master branch - - Trial in progress - -### Documentation on wiki instrument-information--hotfixes - -### Wiki instrument information pages are significantly out of date - - Warning included - -### Weird permissions on stage-deleted - - Issue bumped until CMS is available to discuss. - -### Galil-old branch - - FA has created a ticket to create a repo check on galil-old. - -## Items from this retrospective: -### Disk space -- Many examples in thread, none of which are database truncation. -- Caution for network going down is in place, but not enough space necessarily for the data coming in should the network go down. -- Return again when CMS is in the room. - -### Support for non-`NDH`/`NDX` -- Evidence that at one point NDCs were our responsibility, but that was not widely known about. -- Existing remote viewing/control (`Daxtens`) also getting out of support. -- See [Instrument Machine Standards](https://stfc365.sharepoint.com/:w:/r/sites/ISISExperimentControls/_layouts/15/Doc.aspx?sourcedoc=%7B6CC20F26-86D9-4F1B-8BEA-0E96B69E5A32%7D&file=Instrument%20Machine%20standards.doc&action=default&mobileredirect=true) for the existing evidence -- *Action*: FA to make sure the expected policy for support and machine names is written down and agreed by CMS, the rest of the group and DI, and then it is communicated to all stakeholders. - -### 1926 Build server -- Instruments are on LTS which is on a 10 year contract, ESU can be a purchased update. -- Both are security updates not quality updates. -- Discussion moved into the fact that keeping a test server on the same architecture was useful. -- Return again when CMS relating to update deploys. -- FA suggested getting an extra machine for the time being, which was agreed. - -### First Line -- Being discussed in many places, no firm decision to be found here today. - -### Server Common -- JH had a different thought, rename server_common to IBEX_helpers, two dependencies group members, for those which need EPICS call ins, and one which doesn't. - -### PR Templates -- Some bits of the PR templates relate to repo specific reminders, but acceptance criteria are used sporadically, should the acceptance criteria be removed from the templates? -- Consensus was `Yes` - -### Location of Emulators -- JH raised the three different locations that the device emulators can exist in - within LEWiS, in the IOC support modules themselves, or in a separate directory again. -- Suggestion is to move them to within LEWiS itself, to make it easier to highlight that success from the team, and present it at various conferences. -- Only potential downside is that we don't always emulate the values that we don't interact with. -- If not tied to the EPICS aspects, then they become more obviously useful to other control system users. -- Some IOCs and similar will use multiple devices, and having the emulators in LEWiS would potentially make that clearer. -- Tests are very individual, but emulators less so. -- Being able to package the emulators with the framework provides a more modern python interface. -- FA mentioned the possibility of packaging the emulators separate so that you don't have to install all the emulators as well. -- Discussion highlighted that we will need to make sure that the versioning and so on is clear. -- *Action*: JH to schedule a technical discussion for this. - -### Sysadmin docs location -- Delay until CMS is in the room. - -### Work Experience Student -- FA Happy for it to be done. -- No one in the room wanted to take the supervisor job on. -- *Action*: Check in with those that are not present. - -### Organisational Diagram -- Not currently appropriate given the structure of the team. - -### Contact Cards -- Make the email bigger, and update the information. -- Provide a QR code that links to the user manual. -- *Action*: KB to try and find the existing template. -- *Action*: Someone update the cards and find a suitable landing page. - -## Mad/Sad/Glad -- Got through cycle -- Glad that SECI is now done with -- Removal of the SECI related items should continue, e.g. SECI2IBEX, the re-organisation of the `mini-insts` etc. may be needed, needs a think and discuss for some aspects -- Sad that LC is moving on to a new role diff --git a/doc/processes/retrospective-notes/Retrospective-Notes-2025.10.30.md b/doc/processes/retrospective-notes/Retrospective-Notes-2025.10.30.md deleted file mode 100644 index 9a4bc4516..000000000 --- a/doc/processes/retrospective-notes/Retrospective-Notes-2025.10.30.md +++ /dev/null @@ -1,59 +0,0 @@ -# 2025-10-30 - -## Sprint 2025-10-30 Retrospective (2025-11-25) - -| Chair | Timekeeper | Note Taker | -|-------|------------|------------| -| GR | CMS | SpC | - -## Items from previous Retrospective -### Support for non-`NDH`/`NDX` -- continuing as is - -### 1926 Build server -- re-imaged and back doing builds - -### Server Common - -### PR Templates -- no longer a consensus - -### Location of Emulators -- still needs to have a technical discussion - -### Sysadmin docs location - -### Work Experience Student -- deadline has passed - -### Contact Cards -- in progress - -## Items from this retrospective: -### Weird Permissions on stage-deleted -- Issue bumped until JH is back - -### Disk Space -- GR to setup a technical discussion to discuss further for anyone interested - -### Internal Facing Docs -- TW to write a ticket to put through to a planning meeting and discuss more then - -### SSH Keys -- Issue bumped to next retrospective - -### Standup Rota -- general consensus of agreement - -### Forwards for support issues -- Wait until there are a few more weeks experience with this -- Issue bumped to next retrospective - -### Standup -- Issue bumped to the end of next sprint after ways of working meeting - -### Maintaining `archivewatcher` -- Issue bumped to next retrospective when JH is here - -## Mad/Sad/Glad -- nothing mentioned diff --git a/doc/searchscorer.js b/doc/searchscorer.js index 11018d7c2..def54f441 100644 --- a/doc/searchscorer.js +++ b/doc/searchscorer.js @@ -6,11 +6,6 @@ var Scorer = { if (docName.includes("instrument_details")) { score -= 100000; } - - // Deprioritize retrospective-notes heavily (but still include them in results) - if (docName.includes("retrospective-notes")) { - score -= 1000000; - } return score }, diff --git a/doc/tools/Shared-utility-scripts.md b/doc/tools/Shared-utility-scripts.md index d7bd6b4f6..2462bb260 100644 --- a/doc/tools/Shared-utility-scripts.md +++ b/doc/tools/Shared-utility-scripts.md @@ -55,7 +55,7 @@ Useful [GitHub Workflows](https://docs.github.com/en/actions/learn-github-action A template repository which can be used when creating a submodule where you would like the parent repository to be updated automatically on push to the main / master branch of the child repository. * https://github.com/ISISComputingGroup/Update_Submodule_Workflow_Action -The repository was created in response to a discussion held in the retrospective [Retrospective notes 2022.09.07](/processes/retrospective-notes/Retrospective-Notes-2022.09.07) to remove the need for a check to scan repositories to ensure submodules have correctly been updated. +The repository was created in response to a discussion held in the retrospective 2022.09.07 to remove the need for a check to scan repositories to ensure submodules have correctly been updated. The repository can be used as a starting point for integration into Jenkins CI/CD.