[Events] Boston Python workshop: Volunteer wrap-up meeting

[Asheesh Laroia]

Hey all,

We had a wrap-up meeting for volunteers who worked on the Boston Pytthon 
workshop for women and their friends.

Here is what happened at the volunteer wrap-up meeting. These are my 
written-up version of notes I took. Anyone who was there, please add 
things or editorialize as you see fit.

EDITOR'S NOTE

If you are thinking about running a similar workshop, please read these 
through! Ask us questions on-list.

PHASES

This converation took place in phases:

* Discuss signup process
* Discuss laptop prep
* Discuss the teaching on Saturday
* Discuss the projects on Saturday
* Discuss our advice to other, similar workshops

SIGNUP PROCESS

* Jessica: We could maybe offer child care, or help people find child care 
services.

* Asheesh: Yes! I wanted to offer it ourselves, but forgot to. Railsbridge 
does child care.

* Asheesh: The Minnesotans pointed out that if we call it "children's 
activities", then there are probably fewer hurdles in terms of liability.

* Deb: We might be interested in setting an age bar: the children should 
be old enough to go the bathroom themselves.

* Jessica: Using Meetup.com was nice because it handled the 
process of informing people that they were on and off the wait 
list.

* Jessica: In the future, if it still an event that spans two days, we 
should set the Meetup page to be for the earlier of the two days. That 
way, people really know to come on the first day (forus, that was Friday).

* Ned was a little bit bothered by the fact that

* Adam pointed out that many co-workers asked him if they would be 
belittled for having no prior knowledge. He explained the situation to 
them, that they would not be, but by the time he did that, the event was 
full.

* Deb points out that the text on the page should clearly say, "We really 
are welcoming of every skill-level," and that it's not going to be a 
jargon-stooped thing.

* We should be explicitly welcoming to trans women. Next time we write 
the meetup page, we can figure out exactly what that should look like.

DISCUSSING FRIDAY LAPTOP PREP

* Jessica: The self-directed instructions generally worked pretty well. 
People, especially Windows users, didn't retain the information on how to 
e.g. run Python. To fix that, we should:
** Add Python to the Windows path
** Make there be an extremely explicit checklist of the laptop prep goals

* Ned: We could tell poeple to use a worksheet where they fill in some 
blanks. That could increase information retention, plus then they have the 
notes in their own words.

* As for timing, people rolled in across the whole time period.

* Most people did show up.

* 1 or 2 or 3 people did the laptop setup on their own, at home.

* During the laptop setup, students edited the wiki and fixed the 
instructions. Some students did this by themselves; others did 
this when asked to. That was super useful.

* We needed to create virtualenvs for some people, but the instructions 
didn't say how to do that.

* One person arrived without working wifi. We should probably maybe say 
that wifi is required.

* Adam has a theory that some people's work Windows laptops won't give 
them enough administrator privileges to install things. We didn't see that 
problem this, but we might in the future.

* The wiki should warn you about the big scary "OMG YOU ARE DOING 
SOMETHING AS ADMINISTRATOR" warning that you get sometimes on Windows. 
That way people know not to be too shocked.

* Internet Explorer 6 doesn't work with Alwaysdata.com. We should make a 
note of that.

* It was good that Windows users ended up with an editor that wasn't 
Notepad, since Notepad is a terrible text editor.

* Asheesh has a feedback email from an attendee named Jenny, and should 
forward it to the Events list. We should ask for more feedback from 
attendees.

* Everyone agrees that IDLE mostly sucks, especially on Windows, where 
Adam says it is very crashy.

* Some people had old versions of things like Python (and Django); we 
should specify the versions we'll use on the wiki, and make sure to let 
people know how to find out what version they have.

* Volunteers on Friday night stayed later than we asked them to. Deb 
points out that we should tell the volunteers realistic time ranges ahead 
of time, so they can plan their lives around the commitment we're making, 
and also possibly limit the time range we do setup. (The core idea is to 
make sure we don't spring extra time requirements on our volunteers 
without telling them.)

* The space worked out well for Friday night. We needed power strips, but 
we managed okay without them.

SATURDAY MORNING: LECTURE

* We started late, in large part because a fair number of people needed 
more help with laptop setup.

* Jess suggests we allocate more time in the schedule to do lecture.

* Asheesh suggests _Learn Python the Hard Way_ by Zed Shaw: 
http://learnpythonthehardway.org/index  and thinks that using it 
worksheet-style, rather than doing more lecture, would be valuable.

* Others point out that we should probably ask attendees what they think 
-- would it be better to have more lecture, or a worksheet-style 
introduction to programming?

* People asked good questions, and Jessica gave good answers!

* Deb: Sometimes the answer was, "We'll get to that later." If attendees 
could see a clear table of contents for the intro programming lecture, 
that would have helped.

* Adam: A glossary of terms would be nice, so that people don't have 
to be scared-off by jargon if they run into us using it.

* Deb: We can give them the glossary on Friday, as a paper handout.

* Adam: A glossary is good because it is very rare that people declare 
their ignorance in terms.

* It would have been better to have a bigger space for lecture. The day 
before lecture, we can sanity-check the room and see if we need to change 
it by e.g. rearranging it.

* Deb: The tone of the lecture was friendly. It was generally 
well-organized and people did mostly successfully type along with what 
was going on.

* We created a special hand sign indicating, 'I want private help,' and 
while nobody used it, they did generally ask for help, which indicated 
that the feeling was reasonably comfortable.

* The pacing was good until the very end, when it got a little more 
hectic. This was in part due to starting late, but also largely because 
Jessica didn't know at what time pizza was arriving, and she really wanted 
to get to a particular part of the curriculum.

* We should ask people about dietary restrictions as a question on the 
Meetup.com signup form. That way, we can order the pizza more ahead of 
time, and then it will arrive on time.

* Adam: It was important that we had a woman giving the lecture.

FEEDBACK ON PROJECTS: WEB APP

* Asheesh: Many people, though fewer than half, got through the web app. 
There were some git-related issues toward the end of the tutorial; those 
can be fixed by play-testing the full tutorial.

* Adam: The web app doesn't focus on Python, even though you sat through a 
3-hour lecture on Python.

* Deb: The project doesn't have enough experimenting -- too much 
cut-and-paste, which maybe means less retention.

* Asheesh: People liked SQLite Manager.
** Deb: This was useful, because many people have a passing familiarity 
with databases.

* Adam: Maybe we should make it a local web app?

* Christine Spang: People didn't understand why the code was distributed 
across several different sites/machines/services (i.e., local + github + 
alwaysdata).

* Deb: A roadmap would have helped.

* Adam: In the project, it's hard to tell what's important: Git? Django?

* Asheesh: We could restructure the project so that you make the web app 
locally, and then ask you, "Do you want to now set up the app on the web? 
Or do you want to expand on it locally?" That would give people the chance 
to choose the thing that they find most personally compelling.

* Jessica: We could change the project curriculum so that people rotate 
between "modules", which would be small-form projects where you do 
something applied and concrete with Python.
** Ned: We could look for examples of things to do from the Python 
Cookbook.
** Deb: One downside to the web app the way it is *now* is that you never 
get the feeling of finishing anything, unless you get all the way to the 
end. If we used modules as concrete sub-steps of the web app, then you 
could feel good about finishing parts.

COLORWALL PROJECT

* If Jess would have to re-run the colorwall project, she would have 
''exercises'' for people to try. The way it was, it was too open-ended. 
Jessica would actually prefer to use smaller, more-concrete projects, as 
discussed above, as modules.

* People spent a long time trying to understand how colors work in HSV 
space.

MORE THOUGHTS ON THE WEB APP PROJECT

* Adam said something but I couldn't record it fast enough in my notes. 
Maybe it was that the model-view-controller paradigm is not necessarily 
obvious for new programmers, so it should be explained.

* Jessica: Future clones of the workshop need to make time to do two 
extra lectures, if they do the web app project:
** "How web servers serve pages in response to web requests"
** "Explain Model View Controller, and urls.py"

* Deb: The web app project tutorial gets very incoherent toward the end. 
(More specifically, it stops being as specific, so you have to just start 
guessing what file to edit. Editor's note: Solid play-testing can fix this 
if we pay attention to increasing the specific-ness of the web app 
project.)

* Deb: It would be really nice to start with an existing web app, and have 
people modify it.
** You can control the background of the web page, or change the behavior 
in the code.
** Editing existing code can be emphasized, because it is an extremely 
useful skill for actual programmers. It teaches confidence and also that 
it's okay to not totally understand something as you edit it.

* Ned: really liked the different *flavors* of the different projects. It 
let people choose what they preferred.

* Deb: liked how, once she picked the web app project, it was like saying, 
"Give me the big bowl," and then she felt committed to stick it out.
** Deb would have appreciated more "finish lines" within the web app 
project.

REGARDING MODULES

We had a discussion as to what "modules" meant. There were two different 
ways people understood them:

* Jessica's original meaning was that people would rotate people at some 
time marker, so they would be sure to go through all of the modules.

* Ned imagined that it would be okay to have stragglers stay in one module 
so they could finish it.

* So long as the modules are designed to only take a small part of the 
time allocated to them, we figured that time-forced rotation can work.

REGARDING FUTURE WORKSHOPS

Advice for others, to run a successful workshop:

* You need staff: 6 students per teacher.

* You need people with Windows experience.

* You need women instructors.

* You need a high-quality list of "next steps" for people to look at after 
the workshop, and that list needs to be online before the workshop even 
happens.

NEXT STEPS

* Asheesh: can organize a hackathon night, so that people get time to 
practice what they've learned.

* Asheesh: can send an email to all attendees requesting feedback.

* We should make a nice, solid prose write-up of the problems we had, and 
our successes. Asheesh said he would take lead on this, and get 
collaborative writing going on a PiratePad.

THAT'S IT.

-- Asheesh.

-- 
Q:	Why do mountain climbers rope themselves together?
A:	To prevent the sensible ones from going home.