Results from our 2024 post workshop survey

2024-08-10T00:00:00+00:00

About this survey</h2>
In early 2024 we sent out a survey to participants of our workshops from 2022 and 2023. We received 129 responses and this blog post summarizes the findings.</p>
You can also browse the survey questions</a> and the Jupyter notebook</a> which generated the plots. We have archived the results on Zenodo</a>.</p>
For each plot we will also provide a summary in text form right below each plot. Further below you can find answers to free-form questions as well as suggestions for improvement which we received from the survey participants.</p>
One thing we did not do with the answers was to try to cross-correlate questions (for instance to correlate feedback with career stage or academic discipline).</p>
We are very grateful for the feedback and suggestions and we will use them to improve our workshops in the future. We also appreciate very valuable input on how to improve survey questions by experts at RISE Research Institutes of Sweden.</p>

How much time have you saved?</h2>
</p>
In your estimate, how much time per month have you saved as a result of attending a CodeRefinery workshop?</p>

No time saved: 20</li>
Minutes: 32</li>
Hours: 59</li>
Days: 17</li> </ul>
Is your code more reusable?</h2>
</p>
After attending the workshop, would you judge your code to be more reusable or not more reusable?</p>

My code is more reusable: 90</li>
My code is not more reusable: 9</li>
Not sure: 30</li> </ul>
Has it become easier to collaborate?</h2>
</p>
After attending the workshop, has it become easier or not for you to collaborate on software development with your colleagues and collaborators?</p>

Collaboration is easier: 91</li>
Collaboration is not easier: 6</li>
Not sure: 32</li> </ul>
Have you introduced your colleagues to new tools and practices?</h2>
</p>
Have you introduced one or more of your colleagues to new tools or practices as a result of the workshop?</p>

I have introduced one or more of my colleagues to new tools or practices: 79</li>
I have not introduced one or more of my colleagues to new tools or practices: 33</li>
Not sure: 16</li> </ul>
How likely are you to recommend?</h2>
</p>
How likely is it that you would recommend CodeRefinery workshop to a friend or colleague?</p>

10: 64</li>
9: 21</li>
8: 24</li>
7: 11</li>
6: 3</li>
5: 1</li>
4: 1</li>
3: 3</li>
0: 1</li> </ul>
Pre-recorded lectures, live online teaching, or in-person teaching?</h2>
</p>
Would you prefer pre-recorded lectures, live online teaching, or in-person teaching?</p>

I would prefer pre-recorded lectures combined with live discussions: 36</li>
I would prefer online teaching (lectures are live): 62</li>
I would prefer in-person teaching: 30</li> </ul>
What would be the ideal format?</h2>
</p>
What would be the ideal format for you?</p>

One week with half days (3 or 4 half-days): 32</li>
One week with full days (3 or 4 full days): 13</li>
Two weeks (6 half-days): 25</li>
Two weeks (6 half-days) but split into two separate logical courses: 24</li>
Lesson series over 6 weeks with one session per week: 17</li>
Lessons are available in a catalogue of videos and can be followed anytime: 18</li> </ul>
Participation style</h2>
</p>
Participation style</p>

Individual learner: 95</li>
Learner in a team: 15</li>
Team leader/ helper (online): 9</li>
Team leader/ helper (in person): 8</li> </ul>
Career stage</h2>
</p>
Career stage</p>

Undergraduate student: 3</li>
Graduate student/ PhD student: 63</li>
Postdoc: 18</li>
Researcher: 19</li>
Professor: 4</li>
Research software engineer/ Scientific programmer: 12</li>
Industry: 4</li>
Other: 6</li> </ul>
Academic discipline</h2>
</p>
Academic discipline</p>

Physical Sciences: 30</li>
Earth and Related Environmental Sciences: 18</li>
Biological Sciences: 13</li>
Chemical Sciences: 11</li>
Computer and Information Sciences: 11</li>
Other Engineering and Technologies: 6</li>
Health Sciences: 5</li>
Psychology: 4</li>
Mathematics: 4</li>
Mechanical Engineering: 3</li>
Civil Engineering: 3</li>
Environmental Engineering: 3</li>
Medical Engineering: 2</li>
Medical Biotechnology: 2</li>
Clinical Medicine: 2</li>
Other Medical and Health Sciences: 2</li>
Other: 2</li>
Other Social Sciences: 2</li>
Chemical Engineering: 1</li>
Electrical Engineering, Electronic Engineering, Information Engineering: 1</li>
Economics and Business: 1</li>
History and Archaeology: 1</li>
Nano-technology: 1</li>
Other Natural Sciences: 1</li> </ul>
Has anything else changed in how you write code for your research after attending the workshop?</h2>

I started doing documentation in Read the Docs and it really makes the difference. Thank you!</p> </li>

Usage of documentation with sphinx to pages planned, not done for now.</p> </li>

I learned to use Git and GitHub.</p> </li>

Optimized coding.</p> </li>

Modularity, smaller functions.</p> </li>

I use Git extensively since attending the workshop.</p> </li>

GitHub, Bash, Python, and others were very useful even if many things I did already know in advance.</p> </li>

Especially code documentation improved a lot as a consequence of the course.</p> </li>

I use Git for myself and it is nice, but I think so much depends on your supervisors, so ... there is little leverage for me to change things.</p> </li>

When I don't know how to do something, I use your lesson material as a reference.</p> </li>

I think I am a lot more confident when writing code now.</p> </li>

I write my code so that it is more easier to read by others.</p> </li>

I write more cleaner code, I think. I have a better understanding of testing routines, though haven't incorporated them yet myself.</p> </li>

Commenting and code structure.</p> </li>

My code is more streamlined and elegant when it comes to reproducibility.</p> </li>

More comments, splitting files in separate notebooks, etc.</p> </li>

Learned to use Git and GitHub better.</p> </li>

I have changed some of my earlier code to be more "modular", that it is easier and quicker to run. At least that. Workshop has also made some changes in how I think about coding, that will probably show in my future work. So, the workshop felt very useful.</p> </li>

Give more emphasis to code structure (architecture) and adopting a consistent way of writing code.</p> </li>

I have gotten better at using functions in code, previously it was much more script-esque. I have referred several junior colleagues to your workshops as well (and they've also found them valuable).</p> </li>

I try to be tidier but it is hard.</p> </li>

Started using Git.</p> </li>

I have improved my reusability and documentation of my codes.</p> </li>

I thank my past self for writing such clear codes now.</p> </li>

Considering the latest workshop, the most important topic for me is the "How to document your research software". After the workshop, I have used "GitHub Pages" and "GitHub Actions" for the main documentation of the project that I am currently working on.</p> </li>

I document my code more thoroughly.</p> </li>

I didn't know how to use git version control before. Now I find it so useful!</p> </li>

Better documentation + Easier to test.</p> </li>

I have started writing more modular code and I use git more diligently, too.</p> </li>

I use Git in much more sophisticated way and enjoy it!</p> </li>

I think more on the potential reader of my code and make it more comprehensible.</p> </li>

It is hard to tell, since I took CodeRefinery in the beginning in my PhD. I think the focus on tests and test-driven development has had a good impact on my coding.</p> </li>

The most important outcome I got from CodeRefinery was learning version control.</p> </li>

I am way more careful to commit regularly to my repositories and keep track of changes better.</p> </li>

No. But I am mainly an experimental scientist. Coding isn't a big part of my work.</p> </li>

I use Git more consistently and I learned that making my code more easily understandable does not in fact cost me as much more time as it saves. I have known that I have room to grow for a long time, but would like to mention that just the fact that I finally made time for the workshop and I focused on developing my coding for a few days helped as well.</p> </li>

I try to write more functions to reuse code for multiple purposes. Furthermore, I've started using virtual engines.</p> </li>

Haven't coded a lot since then so hard to say.</p> </li>

I write self explanatory commit messages.</p> </li>

I back up in git repositories almost all my code.</p> </li>

I try to document my code as I am writing it.</p> </li>

I am just starting to apply the information from "HPC Best Practices." From previous workshops, it has been a useful reference point to discuss collaborative workflow with colleagues.</p> </li>

My code was always a mess that was meant to be solely my personal playground. The workshop definitely changed my mindset about it - now I think in the process of what is the best way to write the code (and comment it) so it can be used by other people without any (or at least, big) difficulties. I don't use Git actively at the moment, but it was great to receive the necessary toolkit for efficiently working with it. I think I will definitely need it at some point!</p> </li>

I've been trying to use Git for all of my projects.</p> </li>

A lot has changed on the way how I run code and test it. I attended code refinery while I was still new to programming so it was difficult to put into use the learning from code refinery. Now that I actually do coding for my research, I expect to make the most of the workshop.</p> </li>

I am using Snakemake now. Right now I think it might not speed up my work because I am still learning, but I think the benefits will come over time.</p> </li>

Making my codes easier to share, comment them and version control.</p> </li>

It maybe not directly related to the code itself but I've learned a lot of new what is always very beneficial in this area.</p> </li>

Slightly. I was aware of much already in the course.</p> </li>

I don't have a lot of versions of my code anymore. I have my codes in a Git repository that can be shared with my publications.</p> </li>

I can write code more compactly and with high performance.</p> </li>

I tend to write more functions with documentation and test units.</p> </li>

More testing and better documentation.</p> </li>

I try to create new Git branch for every new line of development to always have a working version of the code.</p> </li>

I haven't been writing a lot of code since the workshop so I haven't really had a chance to put everything into practice, but I'm trying to create a project environment for each project and I have been documenting my working process in RMarkdown notebooks. The notebooks have been really helpful for my research process.</p> </li>

I am trying to keep good practices in mind. I am trying to use proper workflows (raise issue ==> create branch ==> deploy fix ==> push ==> merge request), etc.</p> </li>

Not after this workshop just when I tried it in my own projects.</p> </li>

I use more arrays, which speeds up my work a lot.</p> </li>

I try to use GitHub now. try to do at least some version control.</p> </li>

Better commenting.</p> </li>

It has been easier to get to know other's code projects because I have learned some of the conventions eg. in naming.</p> </li>

Now I use Git for managing the code folders.</p> </li>

I tried to follow the rules to make it more reusable.</p> </li>

I am more organised thanks to the use of Git.</p> </li>

No.</p> </li>

More focus on version control and testing.</p> </li>

My code is still so bad that I haven't benefited from it yet. But I am definitely going to integrate it. Actually, thanks for asking, I will just get a few words of advice from my colleague on how best to apply what I learned at your workshop! :)</p> </li>

Made life easier when I work with git tool.</p> </li>

For me trying to write more readable and reusable code is taking a bit more time at the moment, but that is because I do not write code very much so I take a lot of time planning the code and the parts and how they are most fluently glued together. So I expect it to become easier and take less time with practice.</p> </li>

I'm actively trying to use Git, and back-up my projects (code, useful articles) in my personal GitHub. I try to update it and, though I've not done so yet, I intend to use tags to keep track of milestones along the project.</p> </li>

I started using Git on all my projects.</p> </li>

I started using renv to track which version of packages I am using.</p> </li>

Forcing myself to write function description prior to actually writing the function.</p> </li>

Creating all code under Git control.</p> </li>

Trying more modular approaches.</p> </li>

I think my code now is modular. The way I organize my repositories reflects it too.</p> </li> </ul>
What topic(s) should we add to our workshops?</h2>
[Answers like "None", "Nothing", "Everything was on point", etc., are not shown in the results below.]</p>

More advanced topics on GitLab.</p> </li>

Hands-on with setting up, training and running AI-models.</p> </li>

Java APIs.</p> </li>

Java for beginners.</p> </li>

Automation with Azure.</p> </li>

OOP with Python.</p> </li>

Xarray and/or similar useful libraries</p> </li>

Some stuff related to Quantum Computing could be quite interesting. Also some more "technical computer skills" (how its works by inside, compilations..) could be interesting.</p> </li>

It would be good if in the workshop you also showed how to connect GIT to a private repository on GitHub and later how to synchronize such a connection with VS Code or RStudio.</p> </li>

I have not managed, unfortunately, to make git a regular part of my workflow. For that, I find that a short revision few weeks after the course would be useful.</p> </li>

Linting/debugging and maybe more time for testing.</p> </li>

Besa training.</p> </li>

Matlab training.</p> </li>

Python training.</p> </li>

Visualisation with Python, Matplotlib of gridded data (thinking about maps, projections). And also setting up figures with multiple plots. Smart ways to get reusable code for creating figures.</p> </li>

Processing of non-linear timestamp data; Combination of float, string, object data in the same data analysis.</p> </li>

The actual pieces of code shown were minimal and went quite fast whereas there was a lot of discussion in very general analogy level which wasn't so helpful.</p> </li>

Could mention VSCode's version control instead of just using the terminal.</p> </li>

Git (always useful).</p> </li>

Python: managing problem with installation packages.</p> </li>

Python: debug (within some environment: Spyder (?).</p> </li>

How to use Google Colab.</p> </li>

Maybe: Docker / code ocean ...</p> </li>

Maybe more on organizing "analysis script" type projects - at least where I am this is a more common than developing software packages.</p> </li>

I think the program was good, but the Git part was most useful.</p> </li>

I think the current topics are very good. I felt like the course was a nice introduction to all the topics, even for the length of it it felt a bit crowded, so I think it is good as it is.</p> </li>

VS Code and GitHub Copilot or using AI for coding.</p> </li>

I know that GitLab Pages and GitLab CI have similar workflows but you might also consider creating some examples for those alternatives as well.</p> </li>

Maybe something about reproducibility (like Docker containers etc.) or code publications beyond Zenodo.</p> </li>

A small note on how to correctly version-control Jupyter notebooks would be useful.</p> </li>

It would have been nice to spend a couple of minutes on GitHub Desktop (not all of us are Terminal fans).</p> </li>

Build systems: For example Make or CMake.</p> </li>

HPC: What are supercomputers and how to use them. What are GPUs, how to program and use them.</p> </li>

Object Orient Programming (for Python).</p> </li>

Use of AI tools for coding.</p> </li>

Perhaps package building for Python? Or a practical example of Docker application? But this is more for a subsequent workshop, I would not remove anything from the workshop as I attended it.</p> </li>

Go further on how to browse some else's code.</p> </li>

Further on recovery options of erroneous commits.</p> </li>

A bit on debugging.</p> </li>

More than additional topics, interactive/exercise segments should be added after topics to reinforce learning. This was more the case in earlier workshops than the day 1 HPC best practices workshop.</p> </li>

In terms of content covered, although challenging, more concrete examples on how to find the right amount of memory and CPUs to allocate a job would be incredibly valuable.</p> </li>

For the general CodeRefinery workshop, I think a "putting it all together" unit, including hands-on exercises, would be incredibly helpful, and almost essential, to see the extent of a baseline application of the knowledge included.</p> </li>

Since Visual Studio code is quite popular editor it would be good to teach running Jupyter notebooks in Visual Studio Code.</p> </li>

The courses are very complete, perhaps something about dataset sharing.</p> </li>

ML maybe =)</p> </li>

Something about docker maybe? It's used more and more in my experience.</p> </li>

Perhaps a couple of more advances focused workshops of advances git to save time and make it easier to manage code and collaborating.</p> </li>

Code for publishing.</p> </li>

PEP 8 style.</p> </li>

Maybe for more advanced courses: Object based coding.</p> </li>

Functionalizing a code.</p> </li>

I think it is just right. Adding more may be too overwhelming for a beginner.</p> </li>

Testing.</p> </li>

Refactoring.</p> </li>

Management in general (partly done already).</p> </li>

I would have liked to spend more time on reproducible environments.</p> </li>

Difficult to know. I recently would have benefited from knowing more about (c)cmake, but this becomes very specific. Git is likely the one thing that has most general applicability from your education suite.</p> </li>

More focus on writing statistical code (as opposed to software).</p> </li>

The topics look fine the overall organization of the workshop was a limiting factor. There were too many participants and it got chaotic due to the limited number of teachers. Maybe CodeRefinery should focus on quality rather than on quantity, for instance deliver courses with reduced number of participants on-line. Also, CodeRefinery can coordinate with universities where local instructors could teach the courses locally.</p> </li>

Conda environments.</p> </li>

Using pycharm for some code development and version control.</p> </li>

More testing and how to switch from chaotic version control to a good one. Now there is only from scratch, but it would be helpful to go over from midpoint.</p> </li>

How to use Chatgpt to assist coding.</p> </li>

Using a IDE for Python programming: Notebook & Git/Github integration, debugging, etc.</p> </li>

Docker or containerization in general.</p> </li>

How about software design for research? How to write reusable and maintainable code when you don't know today what you need tomorrow, or when students, who may have been sole authors, move on.</p> </li>

More examples of Pull requests, forks and upstream repositories or local repositories.</p> </li>

More advanced topics on git collaboration.</p> </li>

Since I work with R I would have liked to get more R specific information. But I can see how it can be difficult to add specific info if everyone uses a different language.</p> </li>

Conda vs mamba, module management?</p> </li>

Code architecture and data repository architecture and management.</p> </li> </ul>
What topic(s) should we remove?</h2>
[Answers like "None", "Nothing", "Everything was on point", "All the topics are relevant", etc., are not shown in the results below.]</p>

The course is very good as it is ... However, The 6 half days over 2 consecutive weeks is not very convenient for some people here ... However, I understand the difficulty to bring together online helpers and instructors. You are doing a good job ! Keep going !</p> </li>

Reproducible research and social coding are a little vague for my taste. So if you need more time, I'd skip them.</p> </li>

Jupyter</p> </li>

The Open Science workshop day has a lot of potential, but there is too little time with too few interactions with too many topics to make a difference. The exercises are not very engaging and you did not go deep enough in the aspects you try to cover.</p> </li>

Jupyter notebook, because Python is too slow.</p> </li>

I attended the workshop about Git and was surprised that also other topics were covered. Maybe have shorter, more focused courses instead of the current format.</p> </li>

In the first workshop I attended, the general code refinery workshop, I did not get enough of a grasp on Snakemake, and other tools I understood well mainly because of prior experience. I think this was a wonderful workshop that I have repeatedly recommended to my colleagues, but I think more time should be given to fully try out and cement each tool introduced. I would roughly add 50-100% more time to the course and spend all the added time on more live exercise walk-through and coaching while people work on exercises individually. I would not remove any topics.</p> </li>

I found the basic Git introduction to be rather tedious, so I lost my focus and motivation. This made it difficult to prioritize attending the final parts of the workshop over other duties, so I eventually opted out completely.</p> </li>

I would much prefer an approach were participants are assumed to be at a somewhat competent level from the get-go. Preparation material could be provided ahead of time for the beginners.</p> </li>

Maybe automated testing and modular coding to put that in a separate workshop about improving coding practices.</p> </li>

Documentation was a lot of things in a very short time. I say just choose one of the documentation options to explain.</p> </li>

None of them. Or split the topic of collaborative programming (Day 1 to 3) and documentation (Day 4 to 6) to two separate courses.</p> </li>

I don't think anything should be removed...maybe a second workshop that goes into more depth on reproducibility?</p> </li>

How about you ask registrants to pick their three/five/x favorite topics from a list upon registration, and you select the N most popular ones? Perhaps makes it more difficult to prepare, and perhaps makes it more difficult for participants to commit, but since participation (at least online) is a relatively low commitment, maybe it is okay anyway?</p> </li>

Maybe a small practice session for some of the presenters - a few of the presenters could improve their communication skills. I know it is a small thing, but just adding 10-20% humor or more energy into a presentation can really significantly affect the learning output for students.</p> </li>

For me personally the Jupyter notebooks session was less helpful. But that doesn't mean it should necessarily be removed.</p> </li> </ul>
Other feedback</h2>

Let me highlight it here: your format is great! The features I liked in particular:</p>

HackMD and very high quality feedback there</li>
type-along sessions</li>
dialogue between the two teachers as a format of the lecture. Many thanks for your effort!</li> </ul> </li>

It was great that I could watch the few sessions that O unfortunately couldn't attend on video.</p> </li>

Thanks a lot for organizing these super useful workshops and for promoting/creating a environment very relaxed and inclusive learning environment.</p> </li> </ul>

Lessons learned from phase 2 of the project

2021-11-20T00:00:00+00:00

The motivation for this document was to collect lessons learned from phase 2 of our project, both for our own future work but also for other future projects who may find our experiences useful. We have chosen to collect the lessons learned in bullet-point format and not in prose.</p>

Below we list experiences and also unsolved challenges from workshop organization, lesson development, meeting minutes and decision tracking, Carpentries membership, communication, data management, stakeholder- and community engagement, and infrastructure hosting.</p>

Workshop/event organization</h3>

Metrics</h4>

When we started teaching in 2016, we only worried about the teaching and not about measuring how many participants from which country and from which discipline and career stage. However, we were asked to report about metrics again and again, on short notice. At some point we started reporting this in detail (https://coderefinery.org/about/statistics/</a>) which really simplified reporting.</li> </ul>
Survey</h4>

Survey should be designed considering analysis and presentation of results, as well as and what to focus on (what we want to show off).</li>
When survey platform needs to be migrated to another, consider the structure of the questions and answers to avoid tedious post-processing. Over the past few years we have moved between platforms and also kept adapting questions which made the analysis non-trivial.</li>
How to get a better and precise overview of "actual" participants:

Both pre-/post-workshop surveys are opt-in, and they should be. In principle, sign-up form should collect only very necessary information for those to be able to participate in the workshop, and thus it may not be optimal to collect learner-profile type of information via sign-up form (at least not as mandatory fields), except for cases where we need to apply priority criteria or treating participants differently (e.g. team participation, grouping according to background so that they can work on different exercises etc.)</li>
Pre-workshop survey: so far submitted by anyone voluntarily upon sign-up. Not necessarily all the submitters are participating in the workshop, neither all the actual participants submitted the pre-workshop survey. It might be an idea to ask them to submit upon acceptance to increase accuracy to some extent.</li>
Post-workshop survey:

It needs a scheduled reminder to the organizer side have consistency in the time between the workshop and the survey timing, as the survey aims to see the long-term effect of the workshop.</li>
There is inevitable risks that the survey invitation cannot reach the email address registered after a half year or such, and of course we cannot expect very high response rate, either.</li>
Another limitation that we need to think of could be that the chances could be higher for those who had positive impression would submit the post-workshop survey than those who had negative impression, which will naturally yield biased results.</li> </ul> </li> </ul> </li> </ul>
Capacity and workshop format</h4>

How to afford as many as possible learners while keeping good learner experiences or even improving them.</li>
How we carried out online workshops in 2020-2021:

Standard 3-full day CR workshop was transformed into 6-half day format, typically Tuesday-Thursday over 2 consecutive weeks.</li>
Helper/Exercise lead onboarding sessions as well as installation help drop-in sessions were held typically a week before the 1st week.</li>
All the exercises were done in breakout room with a group of regular members.</li>
We recruited exercise leads and accepted 5-6 individual learners per exercise lead plus team registration including their own exercise lead.</li>
We used priority criteria based on countries and/or institution's characteristics.</li>
Problems/challenges we experienced:

Withdrawals on short notices and no-shows</li>
Much hassles by the coordinators</li>
Feedback showing both positive and negative experiences with regular members/exercise leads</li> </ul> </li> </ul> </li>
What is the optimal format of help provision and exercises:

Should the group members be fixed or more ad-hoc or even hop-in-and-out?</li>
Is one regular exercise lead always needed per group? One disadvantage of not-having regular exercise lead is that it takes time to call help, explaining situation etc., which eats up exercise time.</li>
"Webinar (stream)-by default" with an option for joining in zoom-meeting room for extra help may work better (ref. Python for SciComp 2021</a>)?</li>
Post-workshop Q&A session time/day would be useful?</li>
We have considered for the future to offer optional exercise walk-through sessions. These could be interesting not only for learners but recording of these sessions could also help future exercise leads.</li> </ul> </li> </ul>
Communication with participants</h4>

Indico's email function worked well to send information about the workshop to participants/signers.</li>
We experienced few cases of typo in email address, thus we could not reach registrants.</li>
Online collaborative notebook (HackMD and similar) worked well for Q&A during the lectures.</li> </ul>
Certificates</h4>

Should CR issue any certificate at all? Certificates became participation certificates and possibly we should delegate certification to participating organizations.</li>
"TU Delft PhD candidates can obtain 2 GS credits (Research skills) when attending and actively participating in the workshop (complete assistance)"</a> - It may be better that each institute would have one responsible for approval of students' (or similar) active participation in any of the CR workshops as part of the study etc rather than CR takes responsibility on their participation by checking their records in Zoom etc.</li>
(Relevant to Legal questions</a>) Issuing certificates may have some problems with data management including personal information.</li> </ul>
Planning</h4>

Long term scheduling with fixed twice-per-year schedule is probably better than juggling many calendars and trying to find a time slot 1 month in advance.</li>
Planning relevant workshops/events before and after the CR big workshops will be also helpful. They include for example Software Carpentry, Python for SciComp, Hackathon, etc.</li> </ul>
Lesson development</h3>

Only happened before workshops. This was very efficient but introduced stress.</li>
It probably requires a calendar event to dedicate time for this.</li>
"software installation and setup"

This is not lesson itself, but this also needs to be updated along the lesson development and improvement as well as along the changes implemented in different software programs, packages and platforms to use (e.g. GitHub).</li>
The procedures need validations given diverse scenarios.</li>
Introduction of step-wise procedures with prepared Conda environment worked well, we had considerably fewer visits to installation-help sessions (no statistics, though, it is staff's impression).</li> </ul> </li>
Compared to the cases where one sends PR with all the team members assigned as reviewers, lesson improvement works better when done in a pair; one takes revision work, while the other does a thorough review. Often assigning all the team members as reviewers make the responsibility unclear and ends up with the PM (or in a better case, a few regularly active members) reviews and merges.</li>
It is important to make the contribution criteria clear for making lesson citable:

“creator”(author): significant contributions</li>
“contributor”/Editor: reviewing/approving contributions</li>
“contributor”/Other: smaller contributions</li> </ul> </li>
Ref: https://hackmd.io/@coderefinery/citable-lessons</li>
In view of marketing as well as convincing funders, it would be worth collecting information about where the lesson materials are used. It will be an idea to have a form to submit where it can ask the following questions:

Institution/Organization etc.</li>
Type of event and link to the event page:

Workshop</li>
Credited course</li>
Non-credited course</li>
Other type (specify)</li> </ul> </li>
Which lessons were used

Only CR lessons (which ones)</li>
CR lessons (which ones) as well as other lesson materials (what materials?)</li>
part of CR lessons (where of it)</li> </ul> </li> </ul> </li> </ul>
The Carpentries</h3>
Membership and use of its benefits</h4>

Membership tier: Platinum, 3 years (2018 Nov. 1 - 2021 Nov. 1)</li>
After discount for providing the regional coordinator (RC) position (2019 Nov. 1 - 2021 Nov. 1), we paid 5,000 USD annually for the last two years.</li>
Use of instructor seats and Centrally-Organized Workshops (COW):</li> </ul>
year</th> used seats</th> badged instructors</th> COW</th></tr></thead>

2018-2019</td> 13</td> 8</td> -</td></tr>
2019-2020</td> 12</td> 8</td> 3</td></tr>
2020-2021</td> 10</td> 6</td> 1</td></tr> </tbody></table>

For each membership year, NeIC had 15 priority seats for the instructor training and 6 COWs without fee.</li>
Regarding the membership year 2020-2021; 3 trainees who took the instructor training are planning to finish the rest of the checkout procedures within this year. 1 of them remains as pending in the Carpentries database at the time of 26th Oct.</li>
RC did follow-up check-ins for the trainees who attended a training event. Regarding 2019-2020, 4 trainees from the same institute failed check-out (1 of them could not complete the participation in the training event due to absence more than an hour) despite repetitive check-ins. 1 trainees in 2020-2021 became unreachable after the training event.</li> </ul>
Relationship with the Carpentries and recognition of CR in the Carpentries community</h4>

CodeRefinery had sessions at CarpentryCon 2018 in Dublin (short-talk), CarpentryConnect 2019 in Manchester (lightning-talk) and CarpentryCon2020@Home (lightning-talk, panel-session), links found at https://coderefinery.org/about/reports/#presentations</li>
CodeRefinery submitted 2 blog posts in the Carpentries blog:

Lessons Learned from Running Code Refinery's First Online Workshop</a></li>
Report from the Mega-Coderefinery workshop</a></li> </ul> </li>
CodeRefinery's Zulip chat is introduced as a Carpentries local community space for Nordics and Baltics.</a></li>
Attended at membership executive council meetings (2020 by RA, 2021 by NT).</li>
In 2021, CodeRefinery hosted a workshop on Introduction to Conda for (Data) Scientists</a> as a part of the Carpentries pilot program to improve the lesson material in the incubator program to further level</a>.</li>
Carpentries Executive Director provided a support letter upon the application for the sustainability phase.</li>
CodeRefinery has re-licensed their lesson material from CC-BY-SA to CC-BY based on a suggestion by the Carpentries.</li> </ul>
Regional Coordinator (RC)</h4>

During the period where the RC role was given as a part of tasks by a CodeRefinery project staff, the RC had an administrative role within the Carpentries on both COWs and SOWs in the relevant region. In total, appointed RC carried out administrative works on 35 workshops</strong>. In addition, she recorded 28 past SOWs hosted by University of Oslo, which were eligible to be recorded in the Carpentries database but had not been registered.</li>
RC initiated the following:
Nordic region mailing list at topic-box (managed by the Carpentries)</a>,</li>
"Nordic and Baltic Get Together" session at CarpentryCon 2020 @home</a>, and</li>
monthly community calls</a>.</li> </ul> </li>
RC explained and guided about the NeIC's membership benefit and the Carpentries workshops, as well as bridging new individuals to the region to the local community upon requests.</li>
Upon the expiration of the NeIC's membership, RC in Nordic region is also discontinued.</li> </ul>
Dissemination of opportunities to use the NeIC's membership benefit</h4>

Dissemination of opportunities were done via CR and NeIC website, CR Zulip chat, CR newsletter, at relevant workshops, CR twitter, etc.</li>
In addition, presentations at conferences etc. (for example at "Seminar for bibliotekenes nettverk for ph.d.-støtte" (In Norway)) were also used to disseminate opportunities.</li> </ul>
Uptake of the membership benefits</h4>

Benefits were generally underused, especially COW opportunities. This was partially due to the pandemic and that requests for online COW were not accepted for the first several months after the pandemic hit. Also, the difficulty in planning in-person workshops may have also influenced here as well.</li>
Instructor training's three check-out procedures seem a bit high barrier for some people. Follow-up by RC seemed to have helped to some extent, for example, reminding them to apply for extension of the due date to complete the check-out, offering opportunity to join in Nordic community call as a part of check-out processes, and some advices on contribution works (e.g., translation of terms in Glosario).</li>
Provision of teaching/learning opportunities in Carpentries SOWs/COWs initiated by CR might have been helping;

to disseminate the usefulness of the Carpentries workshops, as well as</li>
to provide a "safe" place for newly-badged instructors to try teaching.</li>
NB: There was a plan to attempt this idea by a SOW for 2021, and several newly badged instructors showed interest in teaching there. But then there was a request for a new COW, and those new instructors had a chance to teach there.</li> </ul> </li>
The Carpentries is also changing along time:

Membership price model and the price itself had been stable for a couple of years, but will be changed within 2021.</li>
RC role is to be changed in the process of re-designing community development program</a>. RC will no longer have responsibility for administrative works on workshops in the responsible region. This is also explained as due to a concern around GDPR raised by the major sponsor of the Carpentries (Community Initiatives</a>). The discount offer of having an RC is to be discontinued.</li>
The Carpentries will have online workshops as their standard option to offer in near future; it is so far only as pilot.</li> </ul> </li> </ul>
Meeting minutes and decision tracking</h3>

One rolling meeting minutes document is probably better than one document per meeting to track tasks and decisions. Creating new documents for each meeting risks that action points get lost or forgotten.</li> </ul>
Time reporting and vacation planning</h3>

In the project we have early on chosen to not report hours to the project management to build trust (only report hours to the local management).</li>
But in hind sight the project manager should have had a closer overview over reported hours earlier, not with a delay of months between work done, work reported to local management, work invoiced to NeIC, and NeIC management informing the project manager about hours invoiced.</li>
There has been work imbalance among the team: the contribution and buy-in was not the uniform among all participating countries/organizations (taking into account different FTE shares).</li>
In hindsight, it would have been better to offer more 1-1 discussions between project manager and staff.</li>
Over time there has been significant staff fluctuation which is normal but every time it takes time to know the routines and grow mutual trust and to get up to speed with the tools and processes.</li>
It reduces confusion to share a vacation plan: not only for the project manager but for the entire staff.</li> </ul>
Issue/task tracking</h3>

The process of having a centralized task tracking was found to be difficult to implement in a decentralized team where everyone has other 'primary' projects.</li>
Over the first two project terms we have tried different tools: Trello, GitHub project board, GitHub issues, HackMD, but it seems no tool replaces 1-1 discussions and more personalized task planning and one or few persons keeping the overview and re-prioritizing from time to time.</li>
However, having one HackMD document that collects all tasks that we chose to work on and keeping this document across bi-weekly calls has been found useful.</li> </ul>
Support line/ request tracker</h3>

We got roughly 200-300 tickets/year.</li>
We have started with email to project manager but that got too much, then we moved to ZenDesk but we had to pay for each agent and it felt expensive for the very few emails we got per week.</li>
SNIC has kindly provided us with the RequestTracker service which we appreciate but the barrier to authenticate using SSL certificates was too high for a cross-border project and for few staff members it took weeks or months to get access.</li>
Most tickets arrive around workshops.</li>
Most non-workshop tickets were to unblock GitLab accounts.</li> </ul>
Communication within the community and the project</h3>

We have started within NeIC Slack.</li>
We have a major problem, because we don't want to (or are unsure how to) keep lists of contacts/interested people (personal data), so we don't have a way to reach out to a broad audience.</li>
Although we have accumulated a large dataset of contact information, we had to delete this information and could not use it to announce other events since we never asked registrants whether they would prefer being informed about related events.</li>
We are unsure however, whether the problem with outreach is lack of tools or lack of processes.</li>
One way out is to move communication to the public space which we have done when moving from Slack to Zulip.</li>
Internally Zulip chat has been good for the project.</li>
In addition, we have managed to engage many helpers and volunteers for each workshop.</li>
When contracted staff are working on different percentages and remotely, it is important to have clear overview of who is working on what and when, otherwise it may give the feeling of unfairness. Frequent short meetings in "Standup"-format (or even writing asynchronously on Zulip or GitHub project etc.) may help all having a better overview and enable us to regularly follow up each other.</li>
Minimizing the toolset has been found beneficial since everybody already has a set of tools to interact with in other projects and these tools often do not overlap or inter-operate.</li> </ul>
Data management</h3>

Google Drive has served us well in the first years.</li>
However, this storage was connected to a personal account.</li>
Over time we used GitHub more and more.</li>
HackMD was used a lot in the last 2 years of the project, both for workshops and notes and meetings.</li>
We have never defined who owns the data and this created a bit of work for the project management towards the end of the project phase.</li>
We should have created a data management plan.</li>
Relevant to some points written in Legal questions</a>.</li> </ul>
Community engagement</h3>

There was a constant stream of people interested in becoming more involved.</li>
We have activated some, but as 'communication' says above, some potential was left unrealized.</li>
Growing a community requires also promoting newcomers and mentoring.</li>
Mentoring also requires volunteer mentors.</li>
With more mentoring and more follow-up we could have had engaged more people and more organizations.</li>
How to give proper credits to the volunteer effort given to the community; do we need different "levels" as well as types (e.g. lesson contributions or exercise leads) of contributions? Ref. Supporting community champions and running champions programs</a></li>
How to keep the community engagement up and running without "burn-out" is a constant challenge.</li> </ul>
Stakeholder engagement</h3>

Steering group seems to have become less engaged over time.</li>
At the beginning of the project the SG actively influenced and gave ideas and input and suggestions.</li>
Over time the steering group meetings and communication grew more and more passive and turned into a reporting channel.</li>
The project had only 3 short meetings with the reference group formed by national training coordinators. This was somehow beneficial to connect to national newsletters.</li> </ul>
Infrastructure hosting (GitLab service)</h3>

Both the steering group and also the project staff became less interested in this over time.</li>
Although the GitLab service turned out successful, it became more and more disconnected and disengaged and ended up a two-person effort (one person maintaining service, another person answering tickets).</li> </ul>
Legal questions</h3>

The project was lacking support in GDPR-related questions

We felt a bit left alone with questions about data privacy and storage and collaboration. For example: how long can we keep participants' data to issue certificates? Should we keep information of the certificates issued? If so, how long, who and where eventually will keep them in case the project ends?</li>
The employer organizations, preferably their lawyers should be consulted, especially in terms of making a project's privacy policy and choice of common cloud-based platforms that are inevitable to use. As an example, UiO lawyers have raised concern about using work email address for making user account of any cost-free cloud service (including GitHub) so that users don't set the same password as the one used at the work. In addition, it was not encouraged to use any cloud-service based in the US to store any personal data (even not sensitive ones) for work-related purpose given the risk that GDPR is not followed due to its server existence outside of the EU (especially in US)</a> (Ref. Recommendations by European Data Protection Board</a>)</li>
Given its characteristics, NeIC should provide both necessary legal support on the issues relevant to GDPR and common cloud-based platforms that staff across boarder securely use. Common support email and a platform where more than one project staff can answer inquiries regardless of their affiliation is essential (see also section about "Support line/ request tracker").</li>
CodeRefinery is (and has become) a very much community-driven project rather than one where only fixed staff work with written contract through the employer. Such project may have been rare, but there might be more of this type in future. Clear legal guideline for involvement of voluntary staff is needed. In this sense, working contract or collaboration agreements including data processor agreement may not be sufficient and it will need a very clear guideline about who should be able to have access to any personal information of the third parties including sign-up information to workshops, for example.</li> </ul> </li>
"Rights to work results" vs. Open Science

Ref: a page about "Rights to work results" at University of Oslo</a></li>
General clarification is needed here so that everyone won't be in trouble later.</li>
It should be also better explained and clarified in terms of the choice of platform for collaborative works in this regard so that staff/volunteers etc. can feel safe in using the chosen (cloud-based) platforms, including GitHub, YouTube, Twitch, HackMD, Tinyletter etc.</li> </ul> </li>
We also lacked support in questions about how to start an own organization/ spin-off.</li> </ul>

Bi-weekly Community Calls started

2021-09-01T00:00:00+00:00

CodeRefinery is now shifting towards a new phase with community-based collaboration. We are aiming to continue offering the workshops, community space, and develop lesson materials together with those who are interested in.</p>
For this to be successful, CodeRefinery started bi-weekly community calls from the 9th August. Calls are open to anyone interested in joining in the community from any point of view; teaching, learning, hosting, contributing to lessons, you name it. Join in the calls, get informed and influence the community's way forward!</p>
So far, we informed and discussed among others;</p>

CodeRefinery project: current status and future,</li>
How to improve outreach and publicity,</li>
Importance of possibility to provide ECTS,</li>
How CodeRefinery should give credits to contributions by volunteers,</li>
Mentorship program for exercise leads after the workshop,</li>
How to "order" workshops</li> </ul>
For more details of each call, please visit the archive of the minutes</a></p>
The next call is on the 6th September 12:00-13:00 CEST with a theme of "CodeRefinery way forward", where we will be discussing the community organization model. For the connection details and agenda, please follow the Community Call HackMD</a>.</p>
We all look forward to seeing you at community calls and Zulip</a> :)</p>

Community discussion in Nordic and Baltic countries

2020-11-13T00:00:00+00:00

This blogpost is based on the notes made on Carpentries Community Discussion Etherpad</a> on the 30th Oct. 2020.</p>
Summary</h2>
The Carpentries say "never touch learners keyboard". Should instructors rigidly follow this advice in online workshops or should we be more flexible in order to overcome the challenges of teaching online?</em></p>
On October 30th 2020, a Carpentries community discussion was held with discussion focused on Nordic and Baltic countries. The host was Annika Rockenberger (Carpentries instructor trainer). Including the host and the co-host, totally 15 participants joined: 6 from Norway, 3 from Sweden, 3 from Finland, 2 from Denmark, and 1 from Bangladesh (Thanks for joining, all!). A complete list of the participants can be found below</a>.</p>*
First, experiences from 2 online workshops were shared. The theme above was raised as a part of the discussion. The active discussion left little time for other topics, but we had a positive and creative suggestion for further collaboration and community building for Nordic and Baltic region: There was a suggestion for running a joint workshop on AR technology and the idea to create a mapping of expertise in the region to facilitate cross-border collaboration.</p>
There are ongoing initiatives to develop Nordic community further. Among other things, information about the Nordic Research Software Engineer initiative</a> and its first online get-together event on 30th Nov. - 2nd Dec.</a> was announced.</p>
Workshop debriefing</h2>
Experiences from two recently held online Carpentries workshops were shared and discussed:</p>
Sweden, Stockholm -- Mix and Match (SQL, OpenRefine, Python programming and plotting)</h3>
A self-organized workshop by KTH, Stockholm University, and Karolinska Institute</a></p>

(Lina, instructor of this workshop) Felt it was hard to teach online, as she was unsure if it reached to the audience. But it went fine.</li>
(Radovan) (In his experiences from teaching online workshops in CodeRefinery</a>) Jumping into breakout rooms to see how the participants did in exercise sessions helped a lot. Also being able to ask/answer questions asynchronously via HackMD hopefully lowers barrier to ask (does not delay others).</li>
(Annika) Even being able to see helpers' faces would help despite having all the learners camera off. Also, when breakout room size is small, it is easier to get impression of the learners.</li> </ul>
Norway, Bodø -- DC social science</h3>
A centrally-organized workshop at Bodø University</a></p>

(Lars, instructor of this workshop) Breakout rooms helped as it enhanced dialog. One of the key issues in the Carpentries. Remote control function worked well. The other instructor used this function to help a learner in the main room. It took some time to build trust.</li>
(Anne) "Taking over learner's keyboard on an in-person workshop should never happen", the Carpentries says! But this concept could be too rigid. This should be given back as feedback to the Carpentries.</li>
(Lina) Depending on the context?</li>
(Annika) Communicating the principles and the important parts for not leaving participants behind in critical situation would be the essential thing to consider when taking over keyboard or not.</li>
(Joakim) Important thing is not give pressure on instructors.</li>
(Lina) Letting learners take over instructor's screen would be interesting.</li>
(Lars) Polls for ice-breakers as well. Easy to rush through, but important not to, especially when you cannot see faces as feedback.</li>
(Radovan) Hopefully useful tips for online teaching learned from CodeRefinery workshops: https://coderefinery.github.io/manuals/</li> </ul>
Community building, collaboration, and ongoing initiatives in the Nordic and Baltic region</h2>

(Tobias) Is planning to run a workshop on AR "Let's build an augmented reality web app!" based on a full-day workshop given at the research bazaar at the University of Oslo</a> earlier this year:

goal: making 3D holiday greeting card using HTML and JavaScript: https://arworkshop.teebusch.repl.co/card1.html</li>
The lesson material is all there: https://repl.it/@Teebusch/arworkshop</li> </ul> </li>
(Joakim) Suggestion of a repository of Carpentries Nordic/Baltic community members with specialities and skills</li>
(Annika) Google Sheets for this?</li>
(Anne) EOSC Nordic claims to be a knowledge-hub</li>
(Radovan) Is also working on mapping.</li> </ul>
Announcements</h3>

Nordic RSE (research software engineers) online get-together (Nov 30 - Dec 2): https://nordic-rse.org/events/2020-online-get-together/ (everybody welcome to attend and submit proposals or ideas)</li>
Local-nordic Carpentries mailing list: https://carpentries.topicbox.com/groups/local-nordic</li>
CodeRefinery workshop in November 17-19, 24-26 (registration closed): https://coderefinery.github.io/2020-11-17-online/ (looking for helpers: great way to learn)</li> </ul>
Participant list</h2>

Annika Rockenberger (host, Norway, Oslo)</li>
Naoe Tatara (co-host, Norway, Oslo)</li>
Kerstin Lenk (Finland, Tampere)</li>
Lars Kjær (Denmark, Copenhagen)</li>
Tobias Busch (Norway, Oslo)</li>
Lina Andrén (Sweden, Stockholm)</li>
Mohamed Abdelhalim (Norway, Oslo)</li>
Annajiat Alim Rasel (Bangladesh, Dhaka)</li>
Joakim Philipson (Sweden, Stockholm)</li>
Thomas Arildsen (Denmark, Aarborg)</li>
Radovan Bast(Norway, Tromsø)</li>
Samantha Wittke (Finland, Helsinki)</li>
Olav Vahtras (Sweden, Stockholm)</li>
Anne Fouilloux(Norway, Oslo)</li>
Richard Darst (Finland, Helsinki)</li> </ol>
Thank you for all the contributions!</p>

Making lessons citable and giving credits for contributors

2020-10-02T00:00:00+00:00

CodeRefinery is organizing a half day online "open house" dedicated to collaboratively working on making CodeRefinery lessons citable as well as giving credits for contributors! Here, contributors are not only those who developed lesson materials, but also lesson mainteners.</p>
Anyone interested is welcome to contribute to discussion on how to realize these in practice!</p>
We will collect notes in a shared document</a>. Please note that this document will be archived in our Open House event repository</a>.</p>
We first meet online at 9:00 am (CEST) / 10:00 am (EEST) via video (connection link will be shared in our shared document</a>. If we decide on working individually during the day, we will coordinate the work through our Zulip chat</a> with possibilities to further discuss via video if necessary.</p>
We conclude the day around 12:00 pm (UTC+1).</p>

git-pr: painless small pull requests

2020-09-29T00:00:00+00:00

git-pr: painless small pull requests</h1>
In CodeRefinery, we teach the benefit of small changes via pull requests in order to have better collaboration and review. But, when the changes get small enough, the time it takes to run the commands and open the pull requests begins to get annoying. I looked around for other tools that could make this faster, but wasn't quite satisfied with anything. So, I slowly started making something that evolved into git-pr, https://github.com/NordicHPC/git-pr</a>.</p>
Let's talk about how it works.</p>
Making a change</h2>
First, git-pr will help you to make the new feature branch. `git pr branch $branch_name</code> willcreate a new feature branch off of the upstreamdefault branch and check it out for you. You might want to git fetch</code> first. Make your commits off of this branch.</p>`
`One trick I use is to write the first commit's message like I would write the pull request description. I decided it's usually not worth writing a separate description for the pull request itself. Perhaps there is some advantage to including the PR message in the git history itself, too.</p>`
`Then, to push the pull request, I use git pr open</code>. This will push the current branch, and open a pull request on both Github and Gitlab. It will pop up an editor pre-seeded with the commit's message for you to further edit. Once you save and close, the pull request is made.</p>`
`One thing that git-pr will do is figure out the upstream and your local copy by yourself. Default upstream goes in priority order upstream</code>→origin</code>, Default personal fork goes in the order local</code>→origin</code>→upstream</code>, so no matter if you first clone the upstream, or your own fork, you can always add the other with only one command and have it auto-detected with no renaming.</p>`
`git pr prune</code> will remove all merged branches both locally and on the remote (possibly dangerous!).</p>`
`Various git pr fetch</code> commands will fetch pull requests into a local pr/NNN</code> branch.</p>`
`There are various other small useful things, with it, but this is the main part.</p>`
`These are only</em> shorthands for things you can easily do with other git commands, but they save you time. It gets me closer to the ideal of making many small pull requests.</p>`
`About git-pr</h2>`You can find it at https://github.com/NordicHPC/git-pr</a> - it is a single shell script to copy to your path.</p> It's beta-quality software: it is used by me and a few others all the time, but there will almost certainly be issues as others start using it. Send issues and PRs!</p> It supports both Github and Gitlab, though Gitlab support is less well tested.</p> There is a lot of prior art on different pieces here, there isn't much in git-pr that is completely new - In particular, the GitHub command line interface has come out since then and has some overlap. You can see other options in the git-pr README.</p>
Writing newsletter articles and blog posts 2020-08-24T00:00:00+00:00 CodeRefinery is organizing a one day online "open house" dedicated to collaboratively writing up blog posts which have been in the pipeline for some time and which will be published in the next CodeRefinery newsletter.</p> Tentative list of articles:</p> Future mega-CR</li> Update on citable lessons and credit/visibility for instructor and helpers</li> Update on sustainability efforts?</li> Manuals : how they can be used for your lessons</li> git-pr</li> </ul> Anyone who would like to contribute to these articles or suggests new topics is welcome to join!</p> We will collect notes in a shared document</a>. Please note that this document will be archived in our Open House event repository</a>.</p> We first meet online at 9:00 am (CEST) / 10:00 am (EEST) via video (connection link will be shared in our shared document</a> and then work on the instructor training material. During the day, we will coordinate the work through our Zulip chat</a> with possibilities to further discuss via video if necessary.</p> We conclude the day around 4:00 pm (UTC+1) by writing a short /summary in our shared document</a>.</p> Report from the Mega-Coderefinery workshop 2020-07-31T00:00:00+00:00 In May/June 2020, CodeRefinery ran a large online workshop with about 100 learners in attendance. We overcame the challenges with some clever strategies, and we feel the learning outcomes were similar to that of in-person workshops of around 30-40 participants.</p> After that workshop, some of the same staff held an even larger "High-performance computing (HPC) Kickstart" workshop (180 learners, more than four universities). This provided another perspective and reinforced some of the lessons learned during the large online CodeRefinery workshop.</p> Running a 100-person workshop seems like an intimidating goal, but with the right vision and techniques it turned out to be quite smooth. Instead of expecting direct instructor interaction with every learner, we had to accept that everyone could be both a helper and learner and create a hierarchical support structure.</p> Online is not simply a temporary substitute for in-person. Mega-online is not simply a way to reach more people because we don't have instructors. This concept fundamentally takes us closer to the promise of technology for teaching: being able to reach everyone regardless of location and physical limitations.</p> Executive summary</h2> Yes, we scale to 100 people pretty well, but you do need a good vision about how to do it.</li> We maintained good learning outcomes with our adjusted strategies.</li> Helpers are essential and need to be trained. Helpers serve as a first-level of support, and instructors/expert helpers serve as a second. Helpers need training in breakout room management and a walk-through/training in the group exercises.</li> Encourage the social aspect by asking for people to register as part of teams and keep the teams together. Teams can even bring their own helper - or even helpers (learners in previous CodeRefinery) can bring their own learners to spread their knowledge to their colleagues.</li> You need to put in extra effort to ensure things run smoothly and make sure that everyone is prepared - anticipate all problems.</li> Roles of staff should be carefully explained and ideally not overlapping, to reduce the cognitive load.</li> </ul> Mega-CodeRefinery</h2> Webpage</a></p> Finnish HPC Kickstart</h2> Webpage</a></p> Organization</h2> Pre-workshop install help times: Emphasis on getting ready and making sure things are installed and configured.</li> We "required" everyone to attend one pre-workshop installation time, even if they thought they had already done it (in this case, we quickly verified the instllation). In practice, we didn't check this requirement and only 25-50% of people came, but it still make the workshop more smooth.</li> The installation verification time occurred right after the "helper introduction meeting", so helpers would stay and help people verify their installation.</li> </ul> </li> Installation instructions consist not just of installation, but also verification instructions. In particular, verifying of the git configuration, since if there are any issues, it very quickly derails things.</li> </ul> </li> We created installation and verification videos for the most critical part, git youtube playlist</a>: One on verifying an installation (make repo, run it)</li> One for most common problems you might see and how to fix</li> One for advanced topics (ssh keys)</li> </ul> </li> Start the meeting 20-30 minutes before, request joining 10 minutes early (on time is late). Have some sort of icebreakers/discussion/program to fill that 10 minutes to keep people interested.</li> We kept the Zoom meeting room open for 30 min to 1 hour after the scheduled lessons are over on that day. This enabled continuation of exercises in re-opening breakout rooms.</li> Some participants could receive individual help by a helper or an expert helper.</li> In the main room, we did debriefing among instructors and helpers so that we could reflect on the day after.</li> </ul> </li> The larger the audience gets, the more diverse it is. This causes more load on helpers and more effort for organizers to prepare.</li> It also makes it harder to please everyone.</li> But on average, we felt that the outcome was about as expected.</li> </ul> </li> To scale to this cognitive load, carefully assign roles (roles explained below): Zoom host, focuses on chat, breakout rooms, registration, etc.</li> HackMD master</li> Expert helpers (special ops)</li> Instructors</li> Helpers</li> It is best if these roles don't overlap, because they require different types of focus. Zoom host and HackMD master are easiest to combine. Then, instructor and expert helpers.</li> </ul> </li> </ul> Recommendations</h3> Place a large emphasis on getting ready for the workshop.</li> Have multiple ways for learners to verify their installation.</li> "Require" attendance in pre-workshop installation verification times. Invite helpers there to get involved and practice basic helping.</li> </ul> Teams</h2> Our recruitment/sign-up strategy was twofold.</p> Open call for helpers and sign-up for individual learners.</li> “Bring your own breakout room”: We allowed learners to register as teams</strong>, where each team brought its own helper.</li> </ol> Open call for helpers and sign-up for individual learners.</h3> First we had a general call for helpers to assign a breakout room with individual learners.</li> Our plan was to allocate one helper for 5 learnes accepted approx. (the number of helpers) 5 of individual leraner sign-ups.</li> We tried to sort these learners by university/country/field, but didn't put too much effort into this.</li> Helpers and learners were told which team they will be in before the workshop (personalized email with breakout room number).</li> In general, we tried to keep consistency in member composition in a breakout room throughout the whole workshop; with the same learnes and the same helper, as much as possible. For a long workshop like this one (6 half-days), getting to know each other seemed to result in more interaction by the end.</li> Random assignments might work better in a smaller workshop, where you are likely to see the same people you know. That isn't the case in a large workshop, so consistent breakout rooms are more worth it.</li> It took a session or two for people to get comfortable with their room, but once they did it went well.</li> </ul> </li> </ul> "Bring your own breakout room"</h3> To further improve things, imagine if a whole group wants to get trained? They can register and bring their own helper, who could be an advanced group member.</li> Research shows that multiple adopters in an organization greatly increases uptake of new tools (Graf-Vlachy, L., Buhtz, K. & König, 2018</a>). Encourage people to come with friends or groupmates.</li> How it worked: This is implemented as a "Team name" option when registering.</li> They are put in their own breakout room together.</li> </ul> </li> Advantages: Scalability</strong>: Because they bring their own helper, we can scale to essentially as many learners as we want.This mechanism allowed us to reach far more people than we could normally, and allowed anyone who could find their own helper to attend. So, our workshop size became SUM(number of people in a team; number of teams) + (number of helpers)6: every teamless helper directly allowed five other learners to attend.</li> Team building</strong>: Because these learners have a pre-existing social connection, they are able to keep a sense of community and help each other much better than you might expect from a course of this size.</li> Possibility to use familiar examples</strong>: We have observed that some team breakout rooms were discussing examples close to their research domain which would otherwise have been difficult to do in a "random" group room or the main room.</li> </ul> </li> The concept of teams could be extended to in-person workshops, too. Not necessarily pre-assigned, but cleverly organize tables, expect the group to stay together all days.</li> One could give the teams names and so on, to increase team spirit.</li> </ul> </li> </ul> Recommendations</h3> Accept a "team name" as part of registration. These people will be put into the same breakout rooms. Worst case, it isn't used.</li> Keep people in the same breakout room for the entire workshop - if there is risk that people will not get used to interacting with their group.</li> </ul> Breakout rooms management</h2> Assign names depending on breakout room and role. Here, n</code> is the breakout room number: (n) First Last</code> - learner</li> (n,H) First Last</code> - helper</li> the above help you to easily assign to the correct breakout rooms, and becomes fairly easy with the Zoom interface. When there are more than 10 teams, it is recommended to use '01', '02', .. as it makes it even easier to organize them into breakout rooms manually.(Otherwise participant list sorts (10), not (2), right after (1))</li> (CR) First Last</code> for instructors and expert helpers (here "CR" stood for CodeRefinery staff).</li> </ul> </li> Initial breakout room assignments serves as a guideline, rooms are constantly adjusted as needed but we try to keep teams together.</li> Preferably, one breakout room should have minimum 4 learners.</li> When people register as a team together, keep them together unless explicitly asked. For others, do what you need, but realize that the social aspect becomes important.</li> Some people don't join with the right Zoom name. Other co-hosts can browse the registration list and manually rename participants who didn't name themselves correctly.</li> Then, the Zoom host only has to worry about assigning them into the right rooms, and not looking up everyone on the lists.</li> </ul> </li> Our registration system, Indico, made this management much easier than it could have been. After registration closed, we added a "Room" field to the registration data.</li> Then, we went through and manually assigned each person to an appropriate room number. We have to make sure that each room has one helper and an appropriate number of learners.</li> We could send personalized messages to each person with the Indico mail merge function</li> The majority of people did manage to name themselves correctly.</li> </ul> </li> </ul> Recommendations</h3> Consistent naming of participants (and an order that sorts properly) makes managing breakout rooms reasonable.</li> Consider how your registration system can send personalized emails to each person.</li> </ul> Helper training</h2> Regular helpers:</p> Have a helper call the previous week. Actually, have two so that everyone can make it to at least one.</li> Helper training: General</a></li> Breakout rooms</a></li> </ul> </li> Focus on training for managing time and keeping a flow going. This is described in our document.</li> Helpers do not need to be experts in everything. They should be able to know what "correct" looks like, see obvious problems, and then call for help from an expert when something will take more than a minute to resolve.</li> </ul> </li> Helper training is focused on: Motivation of learners and teaching psychology.</li> How to help: don't do it for them, etc.</li> Keeping the flow going, encourage everyone to speak up and share.</li> Knowing when and how to call for an expert helper to come to the room.</li> </ul> </li> </ul> Special expert helpers:</p> There are also "special expert helpers" (we need a new name), who are experts in the material and problems that may come up. Most are instructors or could soon become instructors (though really they need to be expert debuggers). Basically many of our free instructors would hang around to serve as special experts.</li> Special experts aren't assigned to any particular breakout room. Instead, they are able to go to any room that needs more help.</li> While no room is calling them, they swap between rooms: they join a room, wait a bit (30-60s) and watch if it's going ok, before moving to another room. This way, the instructors can always be aware of the pulse of the breakout rooms, pro-actively help, and also provide more mentorship to the helpers.</li> One idea was to have expert helpers begin joining breakout rooms only after 1/3rd of the breakout session is over. This ensures that helpers get a chance to do their thing. This needs some thought.</li> </ul> </li> Special experts provide valuable feedback to the instructor on the progress of all learners. They should bring up some of the most important issues they have seen in the main room.</li> Special experts also serve as backup helpers and can take over or permanently join a room if a helper is unprepared.</li> The instructor is also encouraged to pop into some breakout rooms to see how things are going. This may be enough in small workshops.</li> Special experts should be Zoom co-hosts. They are then able to go into any breakout room they want (the mechanics of this is not</em> obvious, see our helper training info for more).</li> Special experts are different than the Zoom host and hackmd master. These jobs require different types of concentration. Helpers and expert helpers need to carefully follow what the instructor is saying, Zoom host/hackmd master follow learner questions, and up-next instructors think about what they are about to do.</li> </ul> Recommendations</h3> Hierarchical helpers allows you to extend to a greater size.</li> You need to put thought into how helpers work and prepare them well. We should develop a special, quick training for them.</li> Special expert helpers connect the instructor (occupied with teaching) to the pulse of the breakout rooms and serve as helper mentors.</li> </ul> Lesson adjustment</h2> Make the exercise sessions as long as possible, group things together. There is a significant overhead to each breakout session, becoming adjusted, figure out just what it is you are supposed to do.</li> </ul> </li> Type-along is hard, given limited screen space to both watch and do.</li> In the end, the main room was more for lectures and watch an example, then we flipped to breakout rooms to do most of the hands-on work. We still need to think about this more.</li> With hierarchical helpers and more people in general, make sure that each exercise and hands-on session is as self-contained as possible. A person familiar with the tools should be able to read the exercise and figure out what the objective is and what the steps are - not having to pay attention to something said 5 minutes ago, and not having a surprise twist that somehow had to be accommodated at the beginning of the exercise.</li> </ul> </li> </ul> Recommendations</h3> Consider limits of online formats and how difficult it is to do interactive work.</li> </ul> Exercises and breakout sessions</h2> Very clearly say what the goal is, what the duration is (duration and</em> time it ends), etc. for each lesson</li> Write the basic info in hackmd for each exercise: link to it, what you are expected to do, how long it is and clock time when it ends e.g. "we expect you to finish 1-3, 4-5 are optional. 20 minutes, ending at xx:45".</li> When participants are in two time zones, it is extra important to use this format of not specifying hour.</li> </ul> </li> This is exactly the case of "if it's even a little bit slow to you, then it takes ages for a learner to understand".</li> </ul> Recommendations</h3> Have lots of "meta-talk" about what you are doing, what expectations are, etc.</li> </ul> HackMD</h2> HackMD serves as a side channel to answer questions, so that the main flow is not disrupted. Learners keep it open and always watch and ask questions at the bottom.</li> </ul> </li> One person serves as the "HackMD master" who follows it, answers, and most importantly keeps it organized and adds in meta-information about what the course does. We've found that it's best if there is one person dedicated to this without any other distractions (but of course many others help, too).</li> </ul> </li> Be careful about answering questions in too much depth, more than is needed. If you do, text becomes overwhelming and people can't follow. Be strategic: if an answer isn't needed for following the course, say so (and if you want, come back and answer later). Answer the minimum to let someone follow the course, and inspire people to research themselves later. Several short bullet points progressively going into more depth makes for fast reading but also more inspiration. For example this point, it's a bit long and intimidating to read, which makes you lose the flow of whatever else you are watching, isn't it? Imagine if every bullet point was like this.</li> HackMD starts failing with a lot of people We saw the limits at 50-100 people. If most people leave it in view mode, it gets a little bit better.</li> If there isn't much text in it, it's better (~10k characters is low).</li> When the document grew too long: we moved some of the text from previous episodes to a side-HackMD and linked to it.</li> The failure mode was usually not being able to edit.</li> In theory, there are no strict limits. With short documents, even 100 or more people could use it. Perhaps this is determined by length of edit history.</li> We even saw Google Docs fail with 50 simultaneous editors during an icebreaker (and our icebreakers with hackmd seemed to work with ~50).</li> </ul> </li> Always have people ask questions and comment at the bottom. There is not a "questions section" and "lesson section", always write at the bottom.</li> Add headings when you get to a new lesson/page/exercise/topic. Questions go at the bottom, sorted by what you were talking about at the time.</li> </ul> </li> Suggested heading arrangements (but hackmd master does whatever makes sense): #</code> for page title</li> ##</code> for each lesson</li> ###</code> for each episode</li> ####</code> for each exercise, group discussion, etc. (if it needs to be smaller than ###</code>.)</li> </ul> </li> Make participants aware that we plan to publish questions and answers later as workshop outcomes. After the workshop we add questions and answers from the HackMD document to the workshop page.</li> We go through these to make sure that we don't publish names or any sensitive information or any information that would violate our Code of Conduct.</li> But even though we take the effort of checking the questions and answers we recommend to point out to learners and helpers to only use the form [name=Myname]</code> if they prefer to indicate their name in the notes to simplify discussions during the workshop. Before publishing the notes, we remove all of the [name=Myname]</code>. In other words write in a style and recommend everybody to write in a style which allows us to publish these notes without hurting anybody's privacy.</li> For a large workshop, even sharing the notes among other learners might be too much, and will naturally limit who else you can share the live notes link with. Consider if you really want to ask anyone to put real names in there.</li> </ul> </li> </ul> Zoom</h2> Have a dedicated host, who focuses on breakout rooms and registration related matters.</li> Use a client, not the web browser - though web browser is minimally OK.</li> Assigning leareners to breakout rooms takes a long time, but luckily Zoom can make it easy enough: The "pre-assign breakout rooms" seems to only work within one organization, thus was useless to us</li> When people name themselves according to the (n) Firstname Lastname</code> system, people sort properly and it becomes very fast to assign hundreds of people to their rooms.</li> </ul> </li> Ask participants to edit profile beforehand and log into zoom when they join in the meeting room. This shows the name properly upon entry and thus the zoom host can confirm that the name is found in the registration list. This is important when you approve entry to the meeting room from the waiting room.</li> Enabling or disabling waiting room is another discussion: For the host, it can be a lot of work verifying people against a registration list. Plus, we experienced some problems that waiting room interfered breakout room entry (see the point at the bottom of this section). With a private link, waiting room didn't seem to be that important.</li> </ul> </li> Prepare another communication channel dedicated to staff (like expert helpers and those who could help with HackMD editing), in our case we used a dedicated topic in CodeRefinery Zulip channel</a>. Zoom chat is sometimes tricky, as it allows communication with either all to the same room (in the main room or breakout room, wherever you are, and as a host to all in waiting room) or to an individual.</li> HackMD can also be used to discuss among staff, of course always at the very bottom.</li> </ul> </li> If someone uses a different computer for Zoom than for doing the exercises, they can join twice, one of those times for sharing their screen (second one also be web browser client).</li> We saw some interesting Zoom problems: We experienced in the first couple of days that after assigning a participant into one of the breakout rooms, and then that participant leaves from the meeting room (not only breakout room), and tries to join in the meeting room again with waiting room enabled, then that participant was kicked out from the meeting room.</li> We don't still understand the mechanism behind, but once we disabled the waiting room function (right before opening breakout rooms until they are closed), it went totally fine.</li> Even after opening breakout rooms, people can join in the meeting room, and the host could assign the new people into one of the breakout rooms.</li> </ul> </li> </ul> Recommendations</h3> Managing breakout rooms isn't too hard, but do practice.</li> </ul> Streaming</h2> Once you reach 100 people in a lesson, you start wondering: why can we not reach everyone in the world at once? The technology is there, it's a question of if it matches our vision.</p> We are worried about trolls in our Zoom meetings, but that is because the Zoom mechanics is many-to-many, while for a public meeting you need a one-to-many mechanic where learners can't interact with each other. Streaming provides this mechanic, at a loss of interactivity. In principle, it can co-exist with breakout rooms.</p> </li> What's the point of streaming?</p> We did streaming in parallel to the interactive workshop. That way, anyone who couldn't register could also follow along. They wouldn't get the full experience, but could at least do something.</li> We encouraged people to watch streams in groups (ideally with their own helper) so that they can get the social aspect and help each other anyway.</li> We can imagine a fully federated system: There is one small Zoom meeting with instructors doing the teaching. All</em> learners join via other Zoom meetings. Each other Zoom meeting watches the stream together, and manages their own breakout rooms. Each other zoom meeting can communicate to the central one as needed to adjust the pace, for example chat and hackmd. HackMD helps here.</li> </ul> </li> Stream as an overflow</p> We had far more people register than we could accommodate, even after getting as many helpers as we could, we could feel good at least offering everyone who could not make it a chance to attend via the stream</li> We emphasized that the experience would not be the same, and they should try to come to another workshop later.</li> The stream can also be good for lurkers and passive attendees, who can't go through the effort of attending but would like to follow along.</li> </ul> </li> Interacting with stream viewers</p> We got questions and comments on the stream chat.</li> We also provided a separate streaming HackMD to ask questions. With our volume, we just as well could have given them the primary hackmd (and did when someone asked, but we were worried about trolls)</li> Stream viewers seemed pretty happy with what they were getting.</li> </ul> </li> Risks of streaming</p> When the main room is streamed, people are more cautious about saying things. But once we get to 100 participants, the main room is quiet anyway, so we don't lose too much.</li> Risk of the stream going off-track from what learners need. You need a good support system of expert helpers and feedback tools to keep this working, if it was a stream-only workshop.</li> Risk of learner audio or video being broadcast. Zoom provides tools ("spotlight video") to prevent this, but it doesn't work all the time.</li> Extra effort needed. The marginal cost isn't that great in the end, once you know how it works.</li> </ul> </li> Zoom can send a video feed to a streaming service, which re-broadcasts to the whole world</p> This has to be enabled under your account, then can be configured for a particular meeting.</li> "Custom streaming server" seems to be able to broadcast to anything. In particular, we used Twitch</a> to do our streaming.</li> </ul> </li> Keeping learner's videos out of the stream</p> Privacy of learners is the first prerequisite to streaming.</li> We said: if you speak in the main room, it may be streamed and recorded. Your video should never be. We thought this was fair, since most main room questions go through hackmd anyway.</li> Breakout rooms never recorded or streamed (though some groups asked if they could be recorded).</li> Zoom "Spotlight video" means that only</em> that person should go out into the stream. The zoom host must not</em> be in the gallery view.</li> This bugs</em> sometimes and everyone ends up in the stream is gallery view. This is extremely frustrating and we didn't find a cause or solution. Workaround: someone should always share their screen.</li> In practice this wasn't a big issue, since in the main room video was off most of the time. We reminded participants to turn off videos when they are back from breakout room sessions.</li> We really need to investigate this more.</li> </ul> </li> </ul> </li> What to do with the stream while the breakout rooms are going on?</p> At first, during the breakout sessions in the main room, we spent a lot of time trying to fix problem with people who couldn't be assigned to breakout rooms. This seems to have been a waste of time</li> Then, we decided to not spend time on Zoom problems, and instead use the main room to do the exercises as a demo. This was mainly for the stream viewers, but also could be useful to the people who couldn't join breakout rooms. In the future, it could also serve a different type of learning style.</li> </ul> </li> </ul> Recommendations</h3> Consider the place of the workshop in the larger world. Once you go big, streaming is not too hard and lets you reach even more people.</li> If you do streaming, clearly announce it from the very start, with the privacy deal (e.g. "video not broadcast, voice may be"). It is much harder to add this later.</li> </ul> Recording</h2> Once you do streaming, it is a smaller step to recording and posting the videos. Who is benefited by the recordings? Perhaps not brand new learners, but the learners who were in the workshop can review them again later.</li> </ul> </li> If recordings require post-processing, they will almost never get done. Plan for one-short recording as much as you can: find a way to keep learners out of the recording so you can go and directly publish it with the minimum effort afterwards.</li> </ul> </li> A surprising number of learners have asked for the videos after the workshop. While the videos may not be as useful to someone learning the material from scratch, they are probably very useful to an existing learner who wants to review something they already saw, teach others, etc.</li> When we can't provide them quickly, their usefulness is much reduced.</li> </ul> </li> </ul> Recommendations</h3> Clearly announce the recording privacy statement when first registering.</li> Try to make the recording as one-shot as possible, with minimal post-processing needed. Plan for who will do this and when already before the workshop.</li> </ul> CodeRefinery tools in action: NordicHPC 2020-04-27T00:00:00+00:00 You've been to a CodeRefinery workshop, and wonder how these tools are actually used? The NordicHPC github organization, which we've mentioned before, provides a lot of demonstrations on using github and working collaboratively. It's an example of people who have a common interest and form a community by using common tools.</p> Yet at the same time, not everything is perfect. Rather than try to make everything perfect, they make things good enough, licensed, and shareable, and improve it as a need comes - possibly, when someone else has a need and time to improve it.</p> Within the organization, you can find many examples of using git</a> (everything), pull-request based workflows</a> (e.g. sonar, git-pr, slurm2sql), automated testing</a> (e.g. .travis.yml in sonar, envkernel, nbscript, slurm2sql), modular code development</a> (e.g. ), open licensing</a> (e.g. everything).</p> Below you see some examples of NordicHPC tools. Some tools are useful to anyone, but some may be more interesting to cluster administrators.</p> nbscrpt</a> is an attempt to provide the familiar script interface to Jupyter notebooks.</li> sonar</a> and sonar-web</a> provide a way to watch what is actually running on clusters.</li> git-pr</a> saves you keystrokes when making pull requests, though perhaps cli.github.com</a> takes its place.</li> slurm2sql</a> imports the HPC Slurm job history to a sqlite3 database. It can be useful, even individually, to get and analyze data about your jobs.</li> envkernel</a> is a Jupyter extension which lets you run your kernels in different environments, such as Docker, Singularity, and virtual/conda environments more easily.</li> </ul> Do you have a nice tool that needs a home? You know what to do...</p> Announcing the first Nordic-RSE conference 2020-04-24T00:00:00+00:00 A couple of years ago, several CodeRefinery members and their friends</a> started discussing how a Nordic network of Research Software Engineers (RSEs) could be established, and soon thereafter the Nordic-RSE initiative</a> was launched. The idea was to follow in the footsteps of very successful such initiatives in other countries, most notably in the UK</a>, the Netherlands</a> and Germany</a>. For the past two years we have been taking the first steps in this direction. A survey was conducted</a> to learn about the environment for people in RSE-related roles. Information on groups and people</a> working in Nordic universities who identify as RSEs is being collected, and local campaigns have been launched within several universities for the creation of new RSE groups. To further grow the emerging Nordic community of RSEs, we are now happy to announce that the first Nordic-RSE conference</a>, Nordic-RSE2020, will take place in Stockholm between 1st and 2nd December 2020</strong>!</p> About the conference</h3> At Nordic-RSE2020, we will bring together those that develop software for research purposes and contribute to building the RSE community. The program is not set in stone but we will have invited talks, lightning talks, poster sessions and workshops on best practices for creating research software and other popular RSE related topics. We expect a large contribution from Nordic RSEs, but will also invite international RSEs that can help our Nordic community take shape.</p> The emphasis of the conference will be on learning from each other in a supportive and relaxed atmosphere. The choice of conference venue for Nordic-RSE2020, the THS student union building at KTH campus in Stockholm, reflects our hopes: it has lots of spaces for casual conversations and is equipped with fast internet and all the facilities required for a successful conference.</p> Who should attend?</h3> Our aim is to reflect the diverse and emerging community of RSEs by seeking input from all levels of experience and across a variety of domains, genders, and ethnicities.</p> We welcome participation from:</p> Researchers at any career stage who develop software for research purposes;</li> Software developers working in a research context, whatever their job title or field;</li> Those interested in advancing the understanding of how best to use existing research software (e.g. with respect to scalability, performance and/or reproducibility);</li> People from any organization providing tools, platforms or services that benefit research software;</li> Anyone with a stake in research software (funders, publishers, decision makers, etc).</li> </ul> We especially encourage first-time presenters and can offer mentoring and other support with preparing your contribution.</p> Getting involved</h3> In order to make this a successful conference, we will need help from volunteers to ensure that all the logistics and practicalities work smoothly. What's in it for you? All conference helpers get a free conference ticket! Please get in touch with the organizing committee ([email protected]) if you would like to help or if you have any questions on how to get involved with Nordic-RSE2020.</p> We will also need sponsors to cover costs, keep the conference fee as low as possible and to be able to offer travel grants to younger participants. We have already received generous offers for sponsorship from the Swedish e-Science Research Centre (SeRC)</a>, the Swedish National Infrastructure for Computing (SNIC)</a> and the Swedish e-science collaboration (eSSENCE)</a>. By supporting us, our sponsors are helping to raise awareness of the importance of developing RSE career path in the Nordics.</p> Inviting new sponsors</h3> Nordic-RSE2020 is the first networking and community-building event of Nordic-RSE. We will meet to network, to learn about best software practices, reproducible research and open science, and to further develop communication and project management skills required by RSEs.</p> RSEs are the connection between technology and research. If you want to get a message directly to those who facilitate research with technology, you want to sponsor this conference. Our attendees often shape decisions about tools, contracts and approaches to research software and computing – either directly or through their role in advising, training and collaborating with researchers. In addition to the chance to raise awareness of how your products or services are relevant to modern research, sponsors will get mentions, visibility, and depending on the sponsor package chosen, conference tickets and contributed workshops, posters or short talks. For information on sponsorship see our webpage [removed] or [email protected]">get in touch</a>.</p> CodeRefinery workshops moving online 2020-04-24T00:00:00+00:00 After cancelling all our planned in-person workshops this spring due to the ongoing pandemic, we decided to make the best of the situation and start focusing our efforts on developing an online workshop training programme. We wanted to start small while learning the mechanics of online teaching, so we began by offering an online workshop covering only the Git-intro</a> lesson to a group of around 25 participants on April 7-8. Neither teaching nor attending online workshops offers quite the same experience as attending in-person events, but we were pleasantly surprised about how well the workshop went and it definitely gave a boost to our ambitions to move more of our traditional workshops online. Online workshops will also provide a means for us to scale up</em> and reach a larger audience than possible with in-person workshops.</p> We learned many important lessons in this first experiment and we tried to summarize them all in a previous article</a>. We hope that these notes can be of help to others who are going online with some of their teaching.</p> New notify-me form</h3> We expect to be delivering many more online workshops also after covid-19 restrictions are lifted and life starts returning to normal. We realized that this means that our old notify-me form has become obsolete - it is no longer enough to only indicate the city in which you want to attend a workshop. So we created a new more fine-grained notify-me form</a> where people can sign up for updates about upcoming online and/or in-person workshops and also indicate which lessons they are most interested in. If you want to be informed of upcoming workshops, please sign up.</p> Join an online workshops as a helper</h3> The new notify-me form now also has an option to indicate that you are interested in participating as a helper or instructor. Instructors always need help and this is even more relevant for our online workshops. Helpers assist learners in overcoming technical problems and work through challenges or questions they may have. Ideally, we need at least one helper per breakout room (4-5 learners). Helpers don't have to be familiar with all the lesson material - experience with even just one lesson/tool/approach is sufficient.</p> Have you already particated in one or more workshops, and now want to help us in spreading better software development practices to the world? Register as helper</strong> for upcoming online or in-person workshops in our new notify-me form</a>. Remember also that there is no better way to consolidate new knowledge than teaching it to others!</p> Bring your own breakout room/helper</h3> With online courses over video we could in principle aim at reaching a larger scale than in-person workshops which are limited by room-size and being visible and audible, but also by the number of helpers. In online workshops the presence of helpers is no less important to make sure that each breakout room has a helper to answer questions during exercise sessions. We are considering to offer participants the possibility to "bring their own breakout room" to the workshop. This way they can collaborate on exercises with colleagues they already know, if they prefer so. More importantly, they can assign one person who is more experienced in the toolset presented to take the role as helper. Participating as helper not only means "giving" but is also a great learning experience: both in the tools and in solving problems and supporting and teaching other learners.</p> Upcoming online workshops</h3> We plan to arrange two full online CodeRefinery workshops covering all our material before the summer. The format will be to split the workshop content over six half-days spread over two weeks.</p> In May we will do our first full CodeRefinery workshop, starting on a Tuesday, and ending on a Thursday the week after. Drawing on the experience from this first full workshop, the plan is to deliver a second online workshop in June.</p> Sign up for the notify-me form</a> if you want to receive an email as soon as registration opens for these workshoops!</p> Rebase vs merge 2020-04-24T00:00:00+00:00 During a CodeRefinery workshop you might have heard an instructor say that you can merge or alternatively rebase, like merge and rebase are two equivalent operations. Clearly, they are not, but should we treat the operations equally?</p> Let us take a closer look at rebase and merge, how they differ and in which situations they are an advantage to use.</p> Rebase</h3> Rebase gives you the opportunity to move the base of a branch to a new base. Here we have two branches, master</code> and feature_A</code>.</p> </p> We can rebase the feature_A</code> branch to the last commit in master</code>:</p> git</span> checkout feature_A</span></span> git</span> rebase master</span></span></code></pre> The result will look like this.</p> </p> Checking out master</code> again, we can merge feature_A</code> with master</code>. The merge will by default be a fast-forward. We end up with a linear history, which many find attractive as it is easy to follow. The disadvantage is that we rewrite the history as the commit hashes changes.</p> </p> Merge</h3> If we don’t use rebase, but just merge feature_A</code> with master</code>, we get an merge commit, a new commit pointing to the previous last commit in master</code> and the previous last commit in feature_A</code>.</p> </p> If we only do merges, we show the true story of the repository, how the code came to be. As the repository grows with new branches, maybe more contributors, following the history can become very challenging. The git graph can look like the tracks of a large railway station, where it can be hard to find the ancestors of a feature.</p> Mixing rebase and merge</h3> Instead of sticking to either rebase or merge, we could use both operations, but establish principles for when we will use merge and under which conditions we use rebase:</p> When we merge a semantic unit to master</code>, we use merge.</li> When patch features, or do general corrections, we use rebase.</li> </ul> How will this look?</p> Merge revisited</h4> Let us say we have created a new function or class, something that belongs together - a semantic unit we call feature_B</code>. The base of feature_B</code> is the last commit in master</code>.</p> </p> If we do a merge, git will by default do a fast-forward merge. Following our newly stated policy, we want this merge to be a merge commit. Consequently, we add the option --no-ff to the merge command:</p> git</span> checkout master</span></span> git</span> merge feature_B</span> --no-ff</span></span></code></pre> Alternatively, we can configure git to default do merge commits, by setting the configuration to not do fast-forward by default. Here as a global setting, spanning all our projects:</p> git</span> config</span> --global</span> branch.master.mergeoptions</span> --no-ff</span></span></code></pre> The result will be like this, where the feature is clearly visible in a feature path, presumably with well written commit messages explaining what has been added in this path of work.</p> </p> Rebase revisited</h4> Now we take the case where we checkout a branch from C1 to do some corrections. While we were doing the corrections, at least before we were able to complete the corrections, master</code> moved to M1 as in the picture above. A merge commit will add unnecessary complexity to the story of our project. We are not adding a new semantic unit, just fixing things that got wrong in the first phase. That we started to fix things from C1 is not necessarily a important information to keep for the project.</p> </p> Following our second principle, we rebase the fix_typos branch to M1. Then we do a merge, but this time as fast-forward. If we have configured merge for not doing fast forward when possible, as the configuration statement above, we need to add the --ff-only argument:</p> git</span> checkout fix_types</span></span> git</span> rebase master</span></span> git</span> checkout master</span></span> git</span> merge fix_typos</span> --ff-only</span></span></code></pre> The git graph will now look like this:</p> </p> Rebase vs merge revisited</h3> Rebase and merge serve two different purposes. We can use this to our advantage to create a clear story, a more readable git log (It is important to create a story, remember?). By using the above principles as guidance, we will become more conscious of where these operations will serve us or add more clutter. For instance, we might conclude that rebasing semantic branches, but insisting on a merge commit, is perfectly fine, because it is where the feature (the semantic entity) enters the master</code> branch which is important, not where the development first started. Features will clearly stand out as a visible pattern in a git repository following such a practice.</p> [1] Getting Solid at Merge vs Rebase</a></p> Research Software Hour 2020-04-24T00:00:00+00:00 CodeRefinery is a project that holds workshops, but computing is an experience. As much as we teach in workshops, it's not enough: these workshops are hands-on, but still can't show our whole daily thought process. They also aren't the right format for everyone and can't reach enough people at once. In order to extend our reach, we are trying a streaming web show Research Software Hour</a> that combines the spirit of CodeRefinery with real-life examples from our daily work - and hopefully, some entertainment, too. We hope watchers experience the spirit of research software and computing</em>.</p> We knew that there had to be a way to reach more people, so considered streaming and decided to do it together: it's more fun and more engaging for the audience, we can discuss, ask each other questions, show each other new tools we discovered, learn from each other, hopefully teach the audience some. We will certainly be learning a lot from the audience, too.</p> We wish to show why we enjoy research software and computing and how you can, too. This is an interactive show, and a big part is answering your questions. We encourage you to submit your own codes and scripts and repositories which we can constructively review on stream. You'll get positive ideas and everyone will benefit.</strong> We are not experts in everything and will also show you the errors we make and how we get through them and also critically review our own codes.</p> We are starting this as a two-person project (Richard Darst from Aalto University, Finland, and Radovan Bast from UiT the Arctic University of Norway, both working as part of the CodeRefinery project). This is an open source production - anyone can help us develop Research Software Hour, too. There are many different ways to contribute, from streaming to developing material to community building. Join us with questions, answers, ideas, code!</p> Read more at the website</a> and join us each Tuesday at 20:30 CEST on Twitch.</p> Work on blog posts 2020-04-24T00:00:00+00:00 CodeRefinery is organizing a one day online "open house" dedicated to collaboratively writing up blog posts which have been in the pipeline for some time and which will be published in the next CodeRefinery newsletter.</p> Tentative list of articles:</p> Online lessons, what we're working on, how we'll be delivering online workshops</li> Merge vs rebase</li> Nordic-RSE conference</li> NordicHPC tools</li> </ul> Anyone who would like to contribute to these articles or suggests new topics is welcome to join!</p> We will collect notes in a shared document</a>. Please note that this document will be archived in our Open House event repository</a>.</p> We first meet online at 9:00 am (UTC+1) via video (connection link will be shared in our shared document</a> and then work on the instructor training material. During the day, we will coordinate the work through our Zulip chat</a> with possibilities to further discuss via video if necessary.</p> We conclude the day around 4:00 pm (UTC+1) by writing a short /summary in our shared document</a>.</p> Lessons learned from running our first online workshop 2020-04-14T00:00:00+00:00 April 7-8, 2020, we gave our first online workshop on introduction to Git</a> (2 x 3 hours) with 22 participants and we plan to deliver many more such workshops on a number of topics based on our lessons</a>.</p> The workshop went well. Online feels slower, but has a different set of advantages (we discussed later whether we actually covered significantly less than during an in-person workshop and we were not sure the pace was actually slower).</p> Here we wish to share with the community our lessons learned: What worked well and what we need and plan to improve. We use bullet point format for brevity.</p> It's maybe obvious but aiming for less material at a calm pace is better than trying to cover all material too fast. During the online workshop we will manage to traverse less material than in-person and it's good to prepare for that. For 1 hour session, plan for 30 minutes. The rest will be questions, issues, and breaks.</p> Breaks and ice-breaker</h3> 5 minute breaks were too short, better 10 minutes or longer, at least once an hour.</li> We have started with a demonstration of the tools (Zoom and HackMD) and this was probably time well spent (thanks to Greg Wilson's excellent presentation</a> and references therein).</li> The HackMD ice-breaker was for each participant to write their name, operating system, experience with Git, and optionally what they are working on. We found it useful to pre-fill the HackMD section with the participants' initials to avoid that all cursors start from the same place and everybody hesitates to write something.</li> We should have included a "ice-breaker" break-out room session where persons can talk about something informally considering that the first time participants possibly ever experience a breakout room is in the first exercise (they may not know how breakout rooms work, they need to find the exercise in the material, they don't know anybody). We want people to feel comfortable and to ask questions.</li> </ul> Solving technical issues</h3> Online, the initial problems can end up derailing the whole day's schedule, and take longer to get resolved. Compensate by ensuring they are set up in advance, which is also easier to do online.</p> On day 1 we spent some time debugging tech issues and for the next event we plan to create a 5-10 minute video "setting up and configuring Git" and ask all participants to show up at a session one day before the workshop to demonstrate that all is set up to not lose any time during the actual workshop.</li> For solving technical problems we found it useful to move the participant into a breakout room with a helper where the participant can share screen and this way we could solve problems without disrupting the main flow too much. However, if one has previously created groups for group work, the only way to send helper-instructor pair to room is to delete all the existing rooms or un-assign all participants. It's not possible to launch just a single room out of several existing rooms.</li> We think that when pre-making the rooms, you have to create some empty spares for this.</li> </ul> </li> </ul> Helpers</h3> Without limitations on distance, we can involve more helpers. With more use of breakout rooms, they have a more clear job and it could be a great opportunity to pay forward but also learn more for someone who finished CodeRefinery a little while ago.</p> To keep a high quality of the workshop each group should have one helper/instructor. But this places limits on scalability - we can't have too many participants and must maintain a 1:5 helper:participant ratio.</li> Helpers were important for our breakout room systems to work. They don't have to be the absolute experts: primary instructors can rotate between breakout rooms and help with hard questions, also having typically more experience with the material and exercise goals.</li> Helpers can be recruited from previous online workshops, and perhaps that could even be a requirement: "price of workshop is to attend a later workshop as helper" (not a direct lesson learned from this workshop).</li> </ul> Breakout sessions</h3> Breakout rooms are pretty good, but as a host, the Zoom mechanics take some getting used to. We found an interesting semi-flipped classroom mechanic.</p> Fewer longer (15 min) breakout sessions were better than many short ones (5-10 min).</li> This also means that we should group some exercises and not have them spread out every 10 minutes.</li> On day 1 we tried to group participants according to operating systems but we got better feedback and it felt better after grouping participants either randomly or even better according to experience.</li> Groups with 4-5 persons seem to work well, with one helper.</li> In breakout rooms encourage participants to share their screen and other participants to comment but also make sure that it's not only one participant sharing all the time at every group session.</li> Some exercises can be done in driver-navigator mode, where one participant who shares screen types in the commands and other participants in the room discuss and recommend what to type.</li> Some people just wanted to work alone, that's OK too.</li> Method 1: group work</strong> Most teaching done in main room (this is important for the most important and delicate topics).</li> Participants are in breakout rooms, working independently, sharing screen/asking for help when they need to.</li> </ul> </li> Method 2: flipped classroom</strong> ("flipped classroom" isn't quite the right term though) Initial motivation in the main room.</li> Switch to breakout rooms early to go through the type-along exercises.</li> This only works when things are clear enough that people can't get too lost.</li> () One learner shares screen, others follow along discussing, asking question, and typing along themselves. Emphasize "it's easiest to share the screen since you don't have to do the thinking".</li> () Instructor flips between the rooms every 1-2 minutes answering hard questions and following progress.</li> Join the end for a wrap-up where best questions are discussed.</li> Helpers and instructors should write down the most important questions to discuss afterwards.</li> </ul> </li> In reality, use the best of both depending on your specific lesson, especially the asterisk () points! Encourage the instructor to cycle through breakout rooms to watch discussions and help out.</li> Many interesting questions were asked in breakout rooms but we did not write them down, they could have been interesting for everybody. They should be written down and discussed as a follow-up in method (2).</li> </ul> </li> Host can lose host rights sometimes. Host should not enter breakout rooms, at least if they are not the original host because then hostship is transferred to original host.</li> In our case the person who created the meeting room transferred hostship to another instructor who then organized the breakout room but we experienced a technical glitch and hostship fell back to the first person and we lost the room assignments and for a minute or two the room creator did not even notice this (was busy helping out a participant). This means that ideally the person who is the main host should also create the meeting room, if possible.</li> Richard: at least when I was main host in another meeting, I could join a breakout room and not lose host. I think. Needs more testing.</li> </ul> </li> Co-hosts seem to be able to jump between rooms freely after</em> first joining the room they were originally assigned to (i.e. can't select any group from the main room).</li> At one point, Zoom dropped the whole meeting and everyone re-joined (automatically). Pre-assembled breakout rooms got lost, which was annoying.</li> </ul> HackMD</h3> HackMD was a vital resource</strong>, but you should have someone dedicated to watching it and keeping it organized.</p> We were impressed how well it worked, holding up with 25 persons editing without noticeable lag.</li> If a question was too advanced or we had no time to answer it, we encouraged to write the question in HackMD (or wrote it ourselves there) so that it could be answered later.</li> Asking and replying question in HackMD worked well. It worked so well that even in physical workshops we should use HackMD for questions that helpers can answer!</li> It gives the possibility to answer at different levels of complexity in successive bullets, so that each participant can read until satisfied with the answer.</li> Students can come back after the course and find better researched answers, if the in-course answer is unsatisfactory.</li> Make sure that the HackMD contents, without any identifying information, can be made public after the course.</li> Instead of asking questions in a particular section of the HackMD and searching and scrolling it was better to ask questions always at the current bottom</em> of the document. Add new section headings as you start new sections.</li> Some questions on HackMD were a bit off topic (but still very good questions) and some answers probably looked confusing so some questions can be postponed for after the video call and answered later.</li> Participants should be asked to give feedback after each day at the end of the HackMD. One positive experience, one thing to improve, as usual.</li> </ul> Chat</h3> The chat window in the Zoom client is useful because it can provide multiple ways to get information for different learning styles. However, it is not threaded and you have to keep it from getting out of hand. Better for detailed questions to go into HackMD.</p> It helped to direct most questions and answers to HackMD and only short administrative questions via chat. Participants should not be asked to watch both the chat and the document.</li> The chat can be used for formative assessment questions where participants are asked to vote for correct answers in a multiple-choice question.</li> Practical announcements/instructions should be provided both written and spoken, to reduce chance they are missed.</li> The recommended signals (raise hand, \hand, red/yellow "sticky" notes) should not only be communicated at the beginning but also written somewhere and easily findable.</li> </ul> Organization</h3> Online, there are more things to think about, but also more ways to communicate (they go together). To compensate, have enough people and clear roles about who does what.</p> We used a private chat as back-channel to coordinate among instructors and helpers. We kept the chat private to not reveal any personal information we may need to share but we noticed later that most/all of what we talked about could have been and should have been</em> public (though not necessarily to students, but just for reasons of cognitive load). We never needed names and the only sensitive information were room connection details.</li> On day 1 we failed/forgot to assign clear roles to ourselves; we were all a bit overwhelmed with the chat, plus the HackMD, plus answering questions on the microphone, plus some of us preparing and giving the lectures. Next time we will try:</li> Roles during main lectures: Host person in charge of overall schedule, timekeeping, breakout rooms and Zoom chat/participant reactions, clearing feedback, balancing answering questions, moderating, etc.</li> Instructor and upcoming instructors (they can't at the same time prepare their material, follow questions, and do one of the other jobs). One of our instructors managed to do both: teach and manage breakout rooms, so it is possible, but easier if somebody else takes the charge.</li> One person watching and formatting the HackMD (but more persons might be needed if there are many questions).</li> Backup expert helpers for problems that require intensive debugging (at least needed at the beginning).</li> </ul> </li> Roles during breakouts (this is more flexible): Host in main room watching stuff.</li> One helper per room leading.</li> Lesson instructor hopping from room to room answering advanced questions and also probing the general mood.</li> </ul> </li> Host makes all instructors and helpers co-hosts so that they can move between rooms.</li> </ul> Screencasting</h3> The requirements and recommendations are roughly like in-person.</p> Showing history of commands via tmux or similar, coupled with displaying the last commands typed</a> really helps.</li> Gray/dark background terminal looked better than light background terminal.</li> </ul> How to make this more scalable?</h3> This time we did not plan to record or stream but we nevertheless asked the participants in a pre-workshop survey: 2/20 preferred not to have the workshop streamed, 1/20 didn't want it recorded.</li> The workshop was great, but we should think more about how to reach more people. A small workshop where we can individually interact with everyone is amazing, but the promise of digital technology is that we can reach everyone in the world. How can we get the best of both? Can we also do something for everyone else who can't attend but might want to watch later? This is something to think about.</li> How can we make this more scalable? This workshop was quite labor-intensive. You could probably do it with two instructors (instructor + HackMD watcher) + 1 zoom expert (host + general helper) + a lot of semi-experienced helpers (1:5 ratio) + a few debuggers to help with tech support the first hour (not overlapping with instructor or HackMD watcher).</li> Imagine if we had main room recorded (or even streamed), but breakout rooms not. People can still ask and interact with privacy in the small rooms - and we take these comments/issues back to the main room. Other people following along later can do the exercises at their own pace, and hear the intros/conclusions in the main rooms, and it might feel a bit like a small class.</li> </ul> Work on instructor training material 2020-03-24T00:00:00+00:00 CodeRefinery is organizing a one day online "open house" dedicated to work together on revising and improving our instructor training material</a>. Issues are filed here</a>, notes from the first workshop can be in the shared document</a>, and we are taking what each of us wants to work on. Input for the further improvement are also very welcome.</p> Anyone who would like to contribute to the instructor training material, or learn how to contribute to any CodeRefinery lesson in general, is welcome!</p> We will collect nodes in a shared document</a>. Please note that this document will be archived in our Open House event repository</a>.</p> We first meet online at 9:00 am (UTC+1) via video (connection link will be shared in our shared document</a> and then work on the instructor training material. During the day, we will coordinate the work through our Zulip chat</a> with possibilities to further discuss via video if necessary.</p> We conclude the day around 4:00 pm (UTC+1) by writing a short blog/summary in our shared document</a>.</p> Preparing for online teaching 2020-03-20T00:00:00+00:00 We will meet on video</a> (9:00 am, UTC+1) and chat</a> and discuss techniques, solutions, and tricks for online teaching and collect our notes in a shared document</a>.</p> Anyone who would like to contribute or learn is most welcome!</p> We will conclude the day around 4:00 pm (UTC+1) by writing a short blog/summary in our shared document</a>.</p> Collaborative work on the website 2020-02-11T00:00:00+00:00 Welcome to the second CodeRefinery Open House!</h3> Following up on our successful first CodeRefinery Open House, we will have our second online Open house!</p> The idea behind this event is to work together on revising and improving coderefinery.org</a>. Issues are filed</a> and we are taking what each of us wants to work on. Input for the further improvement are very welcome!</p> Anyone who would like to contribute, or learn how to contribute to coderefinery.org</a> is very welcome to join.</p> We will collect nodes in a shared document</a>. Please note that this document will be archived in our Open House event repository</a>.</p> We first meet online at 9:00 am (UTC+1) via video (connection link will be shared in our shared document</a>) and then work on CodeRefinery training material. During the day, we will coordinate the work through our Zulip chat</a> with possibilities to further discuss via video if necessary.</p> We conclude the day around 4:00pm (UTC+1) by writing a short blog/summary in our shared document</a>.</p> Collaborative work on the training material 2019-12-13T00:00:00+00:00 Welcome to the first CodeRefinery Open House!</h3> The idea behind this event is to bring together people who are interesting in contributing to the CodeRefinery training material</a>.</p> Anyone who would like to contribute, learn how to contribute to the CodeRefinery training material is very welcome to join.</p> We will collect nodes in a shared document</a>. Please note that this document will be archived in our Open House event repository</a>.</p> We first meet online at 9:00 am (UTC+1) via video (connection link will be shared in our shared document</a>) and then work on CodeRefinery training material. During the day, we will coordinate the work through our Zulip chat</a> with possibilities to further discuss via video if necessary.</p> We conclude the day around 4:00pm (UTC+1) by writing a short blog/summary in our shared document</a>.</p>

CodeRefinery

Upcoming and recent workshops and events

Advanced git / git masterclass materials and topic collection

List of material we know about</h2> Advanced Git in Carpentries incubator (pre-alpha)</strong> Rendered webpage</a></li> GitHub repo (see issues for items in dev)</a></li> </ul> </li> </ul> Other Carpentries incubator projects on intermediate and advanced Git</strong></p>

Other resources on teaching git</h3> A list of other resources that can be helpful when learning about or teaching git:</p>

Changing history</h3> How to modify an open pull request/ merge request - responding to code review with changes (rebase, squash, edit commits)</p>

Combining changes</h3> More advanced merge situations</li> Cherry-picking to apply change from a single commit (as alternatives to merge)</li> Comparing rebasing with merging and understanding when to prefer one or the other</li>

Organizing projects</h3> Suggestion: this topic belongs on a 'RSE/Data Manager track' of git training, separate from a 'researcher/user track' that focuses more on daily usage, recipes etc - 'history' & 'recovering' sections.</em></p>

Outlook</h2> In this Open House session, we looked back: we shared experiences and links to already existing materials. We also preliminary identified topics of interest to the community based on previous experiences.</p>

CodeRefinery Open House - advanced git / git masterclass

CodeRefinery - Celebrating eight years

CodeRefinery train the trainer workshop

Bring your own classroom to a CodeRefinery workshop

Results from our 2024 post workshop survey

About this survey</h2> In early 2024 we sent out a survey to participants of our workshops from 2022 and 2023. We received 129 responses and this blog post summarizes the findings.</p>

Citation Information for Open Source Lessons

What information should be captured in a CFF for a lesson?</h2> Based on previous experience and discussions at various conferences and events, we have developed the following list of information that should be captured in the CFF of an open source lesson.</p>

Summary of business and financing models -planning session Tromsø 2024

Summary of business and financing models -planning session Tromsø 2024</h1>

Why should your organization support CodeRefinery and how?

Observe</h3> If you are curious about how these workshops work, you can always send observers: a CodeRefinery workshop is a special event, let your teachers observe how we do things and maybe we can learn a thing or two from each other.</p>

User Community</h3> If you are a part of a specific user community or a project, you can benefit similarly by supporting CodeRefinery.</p>

In-person meeting summary: Community

In-person meeting summary: Onboarding

Roles</h2> We currently have a few different roles a community member fits into:</p>

Where to find information</h2> We discussed what information potential future community members should get from the website and what should be made available later:</p>

Drafting a governance structure for 2025 and beyond

Structure and responsibilities</h2>

Working methods</h2>

Code of conduct</h3> We take our code of conduct</a> as starting point but suggest to adapt it to the governance structure and decision making process.</p>

Conflict resolution</h3> Questions to be worked out:</p> What to do if there is conflict within leadership?</li> Conflict within community?</li> Conflict between leadership and community?</li>

Community meetings, communication, and reporting mechanisms</h3> This needs to be worked out. Data sharing policy needs to be worked out.</p>

Amendments to the governance document</h3> Board can change based on majority vote.</p>

Periodic review and evaluation</h3> How often do we review the governance document?</li>

Discussion points during the in-person meeting in February 2024</h2> Mission, vision, guiding principles: what is missing?</li>

We have completely changed our Git lessons. Hopefully to the better.

The Modular Code Developement Lesson

Conclusion</h2> We had a hard time of finding a way to make it more engaging, in a way that everyone could follow along. The conclusion was to add tabs for R, Matlab, Julias in the "instructor guide".</p>

CodeRefinery Social Media Strategy

Introduction</h2> We looked at our social media strategy and discussed to improve it to engage our audience and cultivate our brand presence during our in-person meeting in Tromsø (26 Feb-1 Mar, 2024).</p>

Discussion</h2> Why do we need a social media strategy?</h3> We need a good social media strategy to:</p>

What information should be captured in a CFF for a lesson?</h2>
Based on previous experience and discussions at various conferences and events, we have developed the following list of information that should be captured in the CFF of an open source lesson.</p>

Observe</h3>
If you are curious about how these workshops work, you can always send observers: a CodeRefinery workshop is a special event, let your teachers observe how we do things and maybe we can learn a thing or two from each other.</p>

Code of conduct</h3>
We take our code of conduct</a> as starting point but suggest to adapt it to the governance structure and decision making process.</p>

Community meetings, communication, and reporting mechanisms</h3>
This needs to be worked out. Data sharing policy needs to be worked out.</p>

Amendments to the governance document</h3>
Board can change based on majority vote.</p>

Conclusion</h2>
We had a hard time of finding a way to make it more engaging, in a way that everyone could follow along. The conclusion was to add tabs for R, Matlab, Julias in the "instructor guide".</p>

Introduction</h2>
We looked at our social media strategy and discussed to improve it to engage our audience and cultivate our brand presence during our in-person meeting in Tromsø (26 Feb-1 Mar, 2024).</p>
We have already documented CodeRefinery outreach and marketing plan. Link here</a>.</p>