Changes requested in handover

[Iain-S]

This is a placeholder for now

---

Changes requested following on from the 2022-01-11 handover meeting/demo:

• document/publicise different approaches considered/tried (e.g. the scalability issue encountered with the "editions" approach) either via a ticket (e.g. Turing Way/REG collaboration on UX/UI project update the-turing-way/the-turing-way#2071) or a blog post of some kind.
  • scalability issues of Plan A
  • interaction with the TW community whilst trying out Plan A
  • potential workarounds (different branch per pathway, speed up build with multi-processing, etc.)
• we could we open an issue with sphinx or jupyter-book to summarise the changes they would need to make in order for Plan A to be scalable (make rebuild after small changes to toc quicker)
• summarise scalability issues with current solution (e.g. do we want to be able to expand/collapse tags at the top of each page in case e.g. there are 30 pathways)
• merging with TW repo
  • would be nice to keep commit history of pathways package
  • should we keep pathways in its own repo and install it via a git line in the TW's requirements.txt?

[malvikasharan]

Some notes on what can be improved or worked on in the future:

• Showing categories (rather than all profiles in the landing page) when the profile number increases
• Adding description in the landing page of all profile (making it attractive)
• All tags appear on the top for profiles that have been curated, so it will be helpful to have only the original profile (where the user clicked) on the top, and rest could be hidden to avoid confusions

[malvikasharan]

Need to capture tested but unused solutions in The Turing Way issue, cross post that to Jupyter GitHub and have that published as a blog on Jupyter (all contributors from the project as collaborator)

Action: Should capture all solution on this repo to make sure they have sufficient info for why we did not choose them

[malvikasharan]

Q from KW: Should this package be a separate repo so others can use it, or should it directly live in The Turing Way

• Option 1: It can live in The Turing Way, but we can make sure that the current TTW specific info are not hard coded
• Option 2: Make it more reusable by having it as a separate package, add it to the requirement.txt, have TTW specific config in the Turing Way (and allow other projects who want to reuse to create their own config)

[malvikasharan]

Reflections on REG+TTW collaboration:

• it took a lot of time to figure out how JupyterBook is involved
• Also clarifying that involvement from Sphinx is minimal (used for card design) - so staying clear of that is better!
• Enjoyed the process of getting to the outcome (not only interested in goals) <3
• Being able to talk about what was challenging - why it was challenging felt supportive
• Made the test repo public in the mid-way, but what could be useful to get folks involved from TTW from the start
  • Having the activity and discussion on TTW repo demonstrate open collaboration. It's important for us to be transparent, hope that more people get involved and support, it is possible that they don't but it's the part of the open source collaboration. There is an infrastructure aspect where we get more people see what is happening.
  • We could have active conversation on issue on TTW even if we work on a separate fork or repo. We can also use Slack channel for conversations we having in close.
• With collanboration with TTW team, we want to people to take away some open ways of working.