Hi Bennett, all,
I think this is a very important conversation and one we've had in
various
contexts over the three years I've been involved in Carpentry
workshops in
Africa. Every time this came up, I realised how diverse our outlooks
are on
what a Carpentry workshop constitute and what the branding is suppose
to
represent.
Here in Africa we've been mixing and matching lessons to suit both the
audience and the instructors. Sometimes we didn't have Data Carpentry
instructors (only people who came from Comp Sci and Maths for example
who
related much better/easier to the Software Carpentry material than DC)
and
then we tought Software Carpentry to an audience who needed a Data
Carpentry workshop. It's not optimal, but if we didn't do that, we
wouldn't
have run a workshop at all, so we'd lose out on opportunities for our
instructors to get some teaching experience as well as an opportunity
to
develop capacity amongst our potential learners. Most often though,
when we
taught Software Carpentry, our audience wasn't ready to go from never
having heard about the shell or Python, to doing some of the tasks
described in Bennett's email above, let alone adopt git for version
control. The workshops, for me, have mostly been about creating an
awareness of the:
- existence of these tools (DC or SWC curriculum)
- existence of a community where you could get /give help and could
learn about best practices outside of workshops
- reality that these tools are being used in all(most) disciplines
and
that everyone should learn them (this sometimes come as a shock to
computer
scientists)
- teaching methodology and culture of the Carpentries - open, safe
environment where the instructors believe all participants can
learn some
basic skills to help them use the tools we teach (as opposed to
very often
very irritated instructors who gets annoyed with the slower
learners in
non-carpentry workshops - often the exposure our learners have had
to learn
computing and this is what convinced them in the first place that
they
can't/shouldn't learn to use the tools)
- opportunities through communities like the Carpentries -
instructor
training, other workshops, meeting people at conferences with same
interests and much much more
Our advertisements (example attached) normally say that we will teach
them
a lot more than what we actually get to, but we make sure that they
understand the workshop is just a starting point and that the
materials are
available online for them to work through after the workshop if they
wanted
to. We have seen people coming to more than one workshop where we
teach the
same materials as it builds their confidence and mental model. We also
encourage people to start a study group to continue learning and we've
found that some of the study groups have worked through exactly the
lesson
materials we covered in the workshop from scratch but then over a few
weeks. So, in doing this, although it's not covered in the workshop,
we do
deliver on the promise of the advertisement. We give them everything
(as
presumed by us in any case) they need to learn the skills we advertise
and
we help them to become part of the community. If they take some action
on
their side as well obviously.
We can't teach 30+ people to use tools they've never heard about and
apply
concepts no-one has ever discussed with them (open science,
reproducible
research, publishing of scripts) in 2 days, but we can teach them that
these things exist, that they can learn about it, that there are
people who
want to help them as they learn, and that it is important to venture
into
this new world, preferably not on your own.
We use the pre-course surveys to find out if there are more advanced
learners signed up for the workshops and try to contact them
beforehand to
explain what the workshop will cover and ask if they'd be interested
to act
as helpers.
If the Carpentries are going to become too prescriptive in terms of
what
constitutes a workshop and core concepts, it may really hamper the
proliferation of the Carpentries in contexts like ours. The freedom
we've
had to move at a speed that suits our audience, regardless of whether
we
cover script writing, and the ability to mix and match lessons to suit
our
audience and our available instructors, have been key to the growth
and
impact of the Carpentries on our continent. It has changed my life and
at
least a few other people I know. I hope we can continue to bring these
workshops to more people in the way we've been doing over the past 3
years.
Thanks to everyone for their honest comments on this thread so far.
It's
been amazing to see how many people actually do mix and match and also
to
hear some comments on the various lessons.
It would be interesting to keep track of which lessons are taught how
many
times and in which combinations. I've started to put a dataset
together for
workshops run in Africa since 2013 where I mostly have info on which
lessons have been taught. My personal preference for a mixed audience
for a
first-time workshop at an institution is by far the DC Ecology lesson
without SQL (cognitive overload).
Thanks for listening!
Kind regards,
Anelda
On Mon, Oct 23, 2017 at 2:48 PM, Bennet Fauber <[email protected]>
wrote:
I will address only the last of Marianna's comment (included below):
I
think that the issue of 'branding' boils down to one of 'do the
components
of the workshop meet the criteria for both knowledge transmission and
method of presentation'. Part of the issue I had with the branding
discussion is that the lessons being referred to as the standards are
never
fully taught, so I find it very hard to identify which aspect of the
lessons really conveys the heart and soul of SWC and thus conveys
'the
brand'? I am not sure that there would be full consensus on which
components really are the vital ones.
For example, I take it as a matter of definition that creating
rerunnable
scripts, using DRY, and reproducibility are core components of both
SWC and
DC. So, I experienced a strong sense of disconnect when I was told
that
creating a runnable shell script was optional for the shell lesson,
and it
was covered in only one of the two shell workshops I attended. My
personal
opinion is that if creating a shell script that does more the 'echo
Hello'
is not covered, it should not be an SWC shell lesson, no matter the
source. That's in disagreement with the people who thought it
optional,
and is likely to be in disagreement with others. Discussing that
kind of
disagreement seems vital to the issue to me, if we are not to be
talking
past each other instead of to each other.
Similarly, I also think that a python or R lesson must contain at
least
one example of running a program from the command line. That seems
to me
to be the major justification for including the shell lesson in the
first
place; the command line is useful because you run programs there,
both
shell and others. If the programming language lesson(s) is
completely
disconnected from creating a program that can be run from the command
line,
then a large chunk of the original coherence of the whole of the SWC
program is lost. If R and Git are both run from the GUI, then what
was the
point of including the shell lesson? I ask a similar question/draw a
similar conclusion if one uses Spyder, or for all that only the
iPython
interactive interface, and never shows people how to run the scripts
they
have written from the command line.
That is why I think that the issue of 'core concepts and
competencies' is
central to the issue of branding. If 'creating programs that are
runnable
from the command line in support of reproducible research' is not one
of
the necessary and central components of all the lessons of an SWC
workshop,
then I would like to know that so I do not falsely advertise. That
is the
aspect of SWC that drew me in the first place.
Thanks for bringing that up Marianna, and for your other comments!
Sorry for chiming back in, but I thought it worth clarifying the
connection between branding and content here, in full view.
-- bennet
On Sun, Oct 22, 2017 at 10:30 PM, Marianna Foos
<[email protected]>
wrote:
Obviously full lesson overhaul is a massive undertaking, but
basically, I
agree with Bennet's sentiment that paring down lessons by
establishing a
even-corier-core would be beneficial, both for consistency and time
use,
and possibly for increasing hands-on time. However, I am conflicted
on
whether I think this is the same discussion as the "Meeting criteria
for
brand use" one that was kicked off in the last few days and carried
onto
github.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss
