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

[Jessica McKellar]

Thanks for writing these up, Asheesh!

I have a bit of a speech for the people who are planning workshops
like this one, so let me start with that. For context, I was one of
the organizers for the Boston Python Workshop, was the lecturer, wrote
the ColorWall, and helped attendees with both projects on Saturday:

This first Boston Python Workshop was an experiment. It was a
phenomenal learning experience for us, and we have a lot of ideas for
how to make the workshop better and plan to run a revised event based
on what we learned. I was thus surprised to hear after PyCon that
people were planning to re-run an approximation of the original event;
it wasn't the intention of the organizers for the workshop as it
existed in the first run to be replicated, in particular because we
haven't converged on excellent project choices / implementations for
this event structure yet.

So, for people who are scheduling similar workshops with plans to use
the web app or ColorWall instructions from the Boston workshop: I
strongly encourage you to look at those projects and see if they are
really the best choices for your event. My opinion is that you will
have better results with smaller, more focused projects.

I do plan on getting people together soon to work on short (~1 hour)
modules as candidates for the next Boston Python Workshop, and I'll
keep this list in the loop on progress on that front.

And that's my speech. Feel free to send me mail or ping me on IRC
(jesstess on freenode) if you have questions or want me to elaborate
on something. The bottom line is that it is awesome that people are
excited about running these kinds of workshops, and my goal is not to
apply stop energy to excited people, but to encourage and facilitate
successful events as much as I can.

===

Fleshing out some of Asheesh's bullet points:

- "* Ned was a little bit bothered by the fact that ". I think this
line ends with "someone jumped the waiting list and showed up on
Friday/Saturday".

- "* Jess suggests we allocate more time in the schedule to do
lecture." We talked about a couple of ways to do this. One is to make
the lecture 3 or so hours on Saturday instead of 2, at the expense of
project time. Another is to add a small component to Friday that is
somewhat self-directed and might help reinforce the setup concepts
people had trouble forgetting (eg. "these are how numbers and print
statements work"). Another is to restructure the event as a 2-day
event on a Saturday and Sunday, so that we have more time.

-Jessica

On Mon, Mar 21, 2011 at 2:00 PM, Asheesh Laroia <asheesh at asheesh.org> wrote:
> 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.
> _______________________________________________
> Events mailing list
> Events at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/events
>