Feedback on the course from 26-11-24

[phillybroadbent]

1. Overall, good practical advice probably what 80% of RSEs etc really need to know.
2. Intro was really useful for me personally, I hadn't seen the "Reproducible Research" stuff before - this is kind of what I was personally after from the course, so objective for me was achieved.
3. I really liked Challenge on scoring / scaling a piece of software on a scale of 1-5. Metrication like this is really useful as it not just marks the software but also provides guidance to where SW can be improved. General principle that Monitoring is a prerequisite for Managing. As a suggestion, maybe draw Radar Plots of the 4D FAIR Axes? (Not an original thought, lots of similar Monitoring/Managing frameworks to this).
4. Definition of FAIR in the course does not align with the original FAIR4RS principles paper (I read the paper yesterday as prep) - I can go into detail, but generally FAIR4RS in the paper seems to be predominantly about Configuration Management rather than whole SDLC.
5. The choice of tools to use is somewhat arbitrary, but likely to be fairly normal for 80% RSEs (i.e. Git and Python). But what I mean by that is for example using Git. Why control source? Why not control binaries? Or more generally Software Bill Of Materials (SBOM)? Same applies to things like to Python venvs, why not Vagrant/Ansible or one of another 1000 ways to make environments reproducible. Just one of many many many possible toolchains.
6. Course material gets into things like coding standards and testing which don't appear to be covered by the original FAIR4RS principles at all. For me, I feel that this identifies weaknesses in FAIR4RS rather than weaknesses in the course.
7. Does this course overlap with standard intermediate carpentries courses? Is FAIR really worth a whole course to itself since most of the tools stuff is SW Eng 101. Could the first half a day just be incorporated in another course?
   Final thought...
   Having listened to this course, read the FAIR4RS original paper and attended the FAIR4RS workshop yesterday, I still don't understand what problem FAIR4RS is trying to solve. That is, "Why FAIR4RS?" Why pick on only certain elements of SDLC / SWEng techniques and not others? Why copy but not extend FAIR4DATA? I could argue that the Engineering Community has known how to do most of FAIR4RS since the 1950s, and the SW Engineering Community has known since the 1980s and this is just the RSE Community reinventing the wheel using RSE speak. I think there is a lot to be learned from looking at more general well established Engineering and Software Engineering practices and principles.