deploy: 76a6a40

.buildinfo

@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 2c513b0805f5f2845220e7a669544077
+tags: d77d1c0d9ca2f4c8421862c7c5a0d620

_sources/CodeRefinery_intro.md.txt

@@ -0,0 +1,98 @@
+# About the CodeRefinery project and CodeRefinery workshops in general
+
+```{keypoints}
+- Teaches intermediate-level software development tool lessons
+- Training network for other lessons, too
+- Publicly-funded discrete projects (3 projects actually) transitioning towards an open community project
+- We have online material, teaching, and exercise sessions
+- We want more people to work with us, and to work with more people
+```
+
+CodeRefinery is a
+[Nordic e-Infrastructure Collaboration (NeIC)](https://neic.no/)
+project that has started in October 2016 and is
+funded until February 2025.
+
+The funding from 2022-2025 is designed to keep this project active
+beyond 2025 by forming a support network and building a community of
+instructors and contributors.
+
+```{discussion} History
+
+The CodeRefinery project idea grew out of two [SeSE](http://sese.nu) courses given at KTH Stockholm in 2014 and 2016.
+The project proposal itself was submitted to NeIC in 2015, accepted in 2015, and started in 2016.
+
+We have started by porting own lessons to the Carpentries teaching style and
+format, and collaboratively and iteratively grew and improved the material to
+its present form.
+```
+
+
+## Main goals
+
+- Develop and maintain **training material on software best practices** for researchers that already write code. Our material addresses all academic disciplines and tries to be as programming language-independent as possible.
+- Provide a [code repository hosting service](https://coderefinery.org/repository/) that is open and free for all researchers based in universities and research institutes from Nordic countries.
+- Provide **training opportunities** in the Nordics using (Carpentries and) CodeRefinery training materials.
+- Articulate and implement the CodeRefinery **sustainability plan**.
+
+
+## Impact
+
+We collect feedback and survey results to measure our impact.
+
+3-24 months after attending a workshop, past participants are asked to complete a short post-workshop survey.
+The survey questions aim to establish what impact CodeRefinery workshops have on how past participants develop
+research software.
+
+[Pre- and post-workshop survey results](https://coderefinery.org/about/impact/)
+
+- Overall quality of research software has improved: more reusable, modular, reproducible and documented.
+- Collaboration on research software development has become easier
+- Past participants share their new knowledge with colleagues
+- Usage of several tools is improved, and new tools are adopted
+
+[Free-form answers](https://coderefinery.org/#what-do-our-participants-say-after-attending-a-workshop)
+also suggest that workshops are having the intended effects on how people develop code. A common theme is:
+
+> *I wish I had known this stuff already as a grad student 10+ years ago...*
+
+We would love to get suggestions on how we can better quantify our impact. This
+would make it easier for us to convince institutions to partner with us and
+also open up funding opportunities.
+
+## Target audience
+
+### Carpentries audience
+
+The Carpentries aims to teach computational **competence** to learners through an applied approach, avoiding the theoretical and general in favor of the practical and specific.
+
+**Mostly, learners do not need to have any prior experience in programming.**  One major goal of a Carpentry workshop is to raise awareness on the tools researchers can learn/use to speed up their research.
+
+By showing learners how to solve specific problems with specific tools and providing hands-on practice, learners develops confidence for future learning.
+
+> ## Novices
+> We often qualify Carpentry learners as **novices**: they do not know what they need to learn yet. A typical example is the usage of version control: the Carpentry `git` lesson aims to give a
+> very high level conceptual overview of Git but it does not explain how it can be used in research projects.
+{: .callout}
+
+
+### CodeRefinery audience
+
+In that sense, CodeRefinery workshops differ from Carpentry workshops as we assume our audience already writes code and scripts and we aim at teaching them **best software practices**. 
+
+Our learners usually do not have a good overview of **best software practices** but are aware of the need to learn them. Very often, they know the tools (Git, Jupyter, etc.) we are teaching 
+but have difficulties to make the best use of them in their software development workflow.
+
+Whenever we can, we direct learners that do not have sufficient coding experience to Carpentries workshops.
+
+> ## Competent practitioners
+> We often qualify CodeRefinery learners as **competent practitioners** because they already have an understanding of their needs.
+{: .callout}
+
+> ## Best software practices for whom?
+> It can be useful to ask the question: *best software practices for whom*?
+> CodeRefinery teaches *best software practices* derived from producing and
+> shipping software. These practices are also very good for sharing software,
+> though our audience will probably not need to embrace *all* aspects of
+> software engineering.
+{: .callout}

_sources/co-teaching.md.txt

@@ -0,0 +1,54 @@
+(co-teaching)=
+
+# Co-teaching
+
+:::{objectives}
+- Get to know the principle of co-teaching: How we do it and how you can too.
+:::
+
+:::{instructor-note}
+- Teaching: ? min
+- Exercises: ? min
+:::
+
+Why teach together?
+-------------------
+
+It has been said **a lot**, especially in areas such as code development or scientific research, about the value of collaboration.
+Yet still today, the effort of teaching is made alone far too often: a person decides to share their knowledge (or gets assigned a study module) and starts building the actual teaching material basically from scratch.
+It seems much more logical, in the age of FAIR science and open knowledge, to release, develop, iterate, and maintain teaching material -- including the contact sessions -- **collaboratively** as well.
+
+Ways to teach together
+----------------------
+
+* Develop materials together - avoid duplication.
+* Present the materials together ("proper" co-teaching, see [Team teaching section](https://coderefinery.github.io/manuals/team-teaching/) on the CR manual).
+* Use helpers extensively to tackle specific tasks commonly arising in online teaching process.
+* Involve your learners too, e.g. using collaborative document (such as HackMD) for parallel and mass answers.
+
+Advantages
+----------
+
+* If you need to teach anyway, combined efforts take up less time.
+* More engaging to the audience, taking some of the (sometimes daunting) expectation to "speak up" off of the students.
+* Easier on-boarding of new instructors -- one of them can be learning at the same time, either subtleties of the material or the teaching itself.
+* [Swiss-cheese](https://en.wikipedia.org/wiki/Swiss_cheese_model) principle: two "imperfect" teachers are __much__ easier to find and complement each other than the extensively-prepared, absolute expert.
+
+Challenges
+----------
+
+* Additional effort needed of teacher and/or helper coordination -- including syncing up their schedules!
+* Materials might need to be (hopefully slightly) tuned to a specific target audience.
+* Using simultaneous-teaching strategies is a learned skill, not identical to the classical lecturing.
+* Online tools (HackMD, type-alongs) can potentially overload learners and teachers alike, if not used with care.
+
+:::{exercise}
+(What's better here -- practical exercise or discussion?)
+:::
+
+(TODO: Here goes the rest of the episode sections and text)
+
+
+:::{keypoints}
+- Here we summarize keypoints.
+:::