OpenHatch wiki

Community Data Science Workshops (Fall 2014)/Reflections

< Community Data Science Workshops (Fall 2014)
Revision as of 03:19, 24 December 2014 by imported>Mako (integrating feedback)

Over three weekends in Fall 2014, a group of volunteers organized the Community Data Science Workshops (Fall 2014) (CDSW) — the first series of four sessions designed to introduce some of the basic tools of programming and analysis of data from online communities to absolute beginners. This version of the CDSW were held between November 7th and 22nd in 2014 at the University of Washington in Seattle.

This page hosts reflections on organization and curriculum and is written for anybody interested in organizing their own CDSW — including the authors!

In general, the mentors and students suggested that the workshops were a huge success. Students suggested that learned an enormous amount and benefited enormously. Mentors were also generally very excited about running similar projects in the future. That said, we all felt there were many ways to improve on the sessions which are detailed below.

If you have any questions or issues, you can contact Benjamin Mako Hill directly or can email the whole group of mentors at cdsw-au2014-mentors@uw.edu.


Structure

The Community Data Science Workshops (Fall 2014) consisted of four sessions:

Our organization and the curriculum for Sessions 0 and 1 were borrowed from the Boston Python Workshop (BPW) although the particular curriculum has diverged quite a bit at this point as we've improved it and tailored it to the learning goals in our sessions. Session 0 was a three hour evening session to install software. The other sessions were all day-long session (10am to 4pm) sessions broken up into the following schedule:

  • Morning, 10am-12:20: A 2 hour lecture
  • Lunch, 12:20-1pm
  • Afternoon, 1pm-3:30pm: Practice working on projects in 3 breakout sessions
  • Wrap-up, 3:30pm-4pm: Wrap-up, next steps, and upcoming opportunities

We had 30 mentors who attended at least one of the sessions and at least 20 mentors at each of the sessions.

We had about 150 participants apply to attend the sessions. We selected on programming skill (to ensure that all attendees were complete beginners), enthusiasm, and randomly to maintain a learner to mentor ratio of between 4 and 5. We admitted 80 participants.

Retention between session and 0 and 1 was nearly 100%. Retention between sessions 1 and 2 and sessions 2 and 3 was probably 75% and similar learning us with perhaps 55-60% retention at the end of session 3.

We collected detailed feedback from users at three points using the following Google forms (these are copies):

We used this feedback to both evaluate what worked well and what did not and to get a sense of what students wanted to learn in the next session and which afternoon sessions they might find interesting.

Morning Lectures

Afternoon Sessions

Session 0: Python Setup

The goal of this session was to get users setup with Python and starting to learn some of the basics. We changed the curriculum enormously to use Continuum's Anaconda instead of Python directly from python.org. The result was staggering. Not a single person reported "many problems with set-up" (i.e., respondants reported either "no problems" or a "few problems.")

Anaconda was key to smoothyness compared to the first workshop series and addressed most of our setup and path issues. That said, we had several major concerns:

  • Anaconda is not free software or open source
  • Anaconda does not support Python 3 which we'd like to move to
  • One studdent had a home directory in Chinese which caused the Anaconda installation to fail at a very late stage. This was eventually fixed by a mentor who changed the path.

Additionally, we moved the Windows curriculum from away from cmd to using Powershell. This was a huge benefit because it meant that ls works and the rest of the curriculum can converge. The only concerns were:

  • Powershell is not installed on Windows XP although not a single student had Windows XP

Changes for next time include:

  • Because it was less successful, we can deemphasize recruiting mentors to the Friday night session.
  • Because Powershell was successful, we're going to try to create a single consolidated set of installation instructions for Windows, Mac OSX, and Linux!
  • We will make it clear to mentors whether participants should self-report they’d completed the steps or whether the mentor should verify that the steps were all taken. In future, email mentors ahead of time to let them know.
  • We need to do a better job of modelling stticky notes during lectures early on.
  • The sticky notes we bought were small and ambiguous color. We should get bright red sticky notes next time.
  • Set up/arrange/select the space to facilitate better circulation of mentors.

When mentors can circulate easily things are better for mentees.

  • We are going to try writing installation instructions that do not rely on Anaconda so people have a fully open source option.
  • Once again, not a single person outside of mentors ran GNU/Linux. We should strongly consider how much effort we want to put into maintaining this part of the curriculum.
  • We should move to Python 3 to try to address lingering unicode issues. We should try to do this for the next session.

We had many new mentors this round. One general concern was the relative lack of mentor training, especially before the first sessions. We felt that we should:

  • Arrange a mentors meeting (perhaps a day or two before to over material) and maybe at a bar or other social environment.
  • Send out details instructions and emails to mentors, or create pages in this wiki with detail on how to do this better.
  • Perhaps meet 15-20 minutes early to get to know each other and over things
  • Create some easier way to distinguish mentors from students (e.g., t-shirts, buttons, etc).
  • Explicitly encourage mentors to reach out to students and ask them how things are going.
  • Talk to mentors about much should you help? (e.g., some but be careful not to just give away the answer, to focus too much on elegance or technical correctness and be careful not to overwhelm the learners).

Session 1: Introduction to Python

Morning lecture

Afternoon sessions

Baby names is good project because it feel data-science-y. Baby Names does everything that Word Play does but it has the stink of science about it. Next time, let’s have two small rooms doing the exact same thing. Wordplay is kind of boring.


Session 2: Learning APIs

The goal of this session was to describe what web APIs were, how they worked (making HTTP requests and receiving data back), how to understand JSON Data, and how to use common web APIs from Wikipedia and Twitter.

Morning lecture

The morning lecture was given by Frances Hocutt and it was was well received — if delivered too slowly for a significant minority of attendees. Unsurprisingly, the example of PlaceKitten as an API was an enormous hit: informative and cute.

Frances used excellent slides which are shared on the wiki page and which we will reuse. Since many people felt the lecture was on the slower side, we want to use this time to introduce function definition up front. Then, functions can be reinforced in the week 2 workshops.

Afternoon sessions

There were three parallel afternoon sessions on Twitter, Wikipedia API and SQL. We plan to do some version of all three sessions next round:

Twitter:

  • Once again, the session too many people and we should consider splitting it if we have mentors who are comfortable splitting it.
  • Next time, we should be careful to make sure that the advance notice asks everybody to download the project zip file ahead of time. If we're going to do this in class, we should set up a short URL of some sort to help streamline the process without heading to the wiki things.
  • A bunch of people found the Twitter session too fast.
  • TweePy is not well documented.

Wikipedia workshop:

  • The teacher explained things very clearly. That was frustrating for those who didn’t need it, but super great for people that wanted/needed a lot of explanation.
  • Graduated challenges in a workhshop that go from less challenging to more and more challenging helps with the fact there is a range of learning levels.

SQL workshop:

  • Generally was very successfuly Seemed to work really well and did a good job of giving people an overview of a data science and a way to hook themselves in to it.
  • Next session, also do a workshop that closes the loop between SQL and Python.
  • Can we host an open SQL database somewhere?

Session 3: Data Analysis and Visualization

Afternoon of Session 3:

The spreadsheets session. People were modifying the code to build their own dataset and did their own visualizations. At least a few people. That was cool!

The MatPlotLib session. Most people in the session were deeply lost. The mentors who taught it were not at any of the other sessions and therefore didn’t go in with a good sense of where the mentees were at. Several people left and went to other room. In future, ensure mentor success by having them loop in better to where the mentees are at. Consider next time, encouraging new mentors do a practice session with some friendly folks before they let loose. Also, next session, consider using SeaBorn instead of MatPlotLib.


Morning Lecture

The goal of the lecture was to walk people through the actual mess of making a code.

Afternoon sessions

General Feedback

  • We should try to schedule the workshop not as close to the end of the quarter. The beginning or middle of the quarter should be better for UW students.



Budget

Unprocessed

Maintanence errors on the wiki. There was a need for several on-the-fly corrections of the instructions and files on the wiki during the workshop.


Q: How to handle when mentees want to refer back to the workshop material that they experienced?

A: Create and archive template for the page they are looking at during the workshop. Each project can be its own namespace as opposed to having event-specific pages.

Mentors should post the code generated in the break-outs. Encourage them to capture the code.


General observation about mentoring: Being a mentor is kind of hard, especially being a good mentor. Some steps were skipped in helping mentors that were in place last time.

It was hard to tell who was a mentor and who wasn’t.

Improvement: Help the mentors to be visually identifiable. E.g. Paper them head to foot in sticky notes.

Questions about mentorship: How to help the mentors to mentor well?

Suggestion for mentors: Walk around to every single person. Ask, “How are you doing? What are you working on? Show me what you’re doing.”

How much do you help somebody?

Should there be a page of guidelines for mentors?

Where is uniformity needed in mentor style and where do we want to encourage diverse approaches?

Let’s have a mentors workshop! At a bar! With BEER! and PIZZA!

The pizza party, er, mentor workshop could cover: norms, best practices, goals. Planning, etc.


Should only fully open source tools be selected for workshops? A: Our job is not to extoll the virtues of open source. Our job is to help mentees solve their data problem. “We are teaching you how to do things with data that help you achieve your goal.” However, open source tools are desirable.


Student demographics. This time there was more gender balance in both students and mentors.

2/3 of mentees were from UW. Included students from random places including someone who works for the city of Seattle.Many random Wikipedians were there. It's cool that people who are not doing research but are part of online communities were in the mix with the researchers.

We had 16 students from HCDE were there, but also a bunch of mentors. They were good mentors.

Demographics of Applicants. Several people applied who are already good at programming. Why do they apply? Maybe they want more exposure to data science?


Desired applicants. The constraint on scaling the workshop is the number of mentors. Every mentor means that the workshop can accommodate four more mentees.

Is it good to have mentees who have some programming skills along with those who don’t have any? Or is it a better use of the seats to only take those with no programming background?

Who are the priorities? Get more of the newbies and invest more in them?

Improving Retention: Anecdotally, there is a sense that those who are dropping are those who had more trouble but didn’t struggle visibly.

Q: Would it help with retention if we show people what will happen in the following weeks?

A: Several mentors say “yes.” We’re doing that, but let’s do more of it.

Pair programming for those who want it might be helpful. Working in groups is another possibility.


Mining research interests/goals. Could we help match up people with similar interests?


How can we support self-directed projects?

Can we give mentees more guidance to support their project interests? It’s easier to do that if people are pre-clustered.

Bring up people’s ideas at the end.

The size of the breakout workshops varied and that means different degrees of engagement were feasible.


The BIG feedback from the first series of workshops: Bring people back together more often. Bringing people together in the end was effective this time. We need a go between for each session to remind people to reconvene. An emcee.

Flow of the workshops Q: What degree of dependencies should there be between workshops?

Feedback on lectures. About half found Frances’s lecture either too fast or too slow and about half found the lecture to be just right.

Getting other people to do some of the lectures. Diversity is desired. Mako does not want to be the only one.


Selecting workshops for next time. Do we need more break-out sessions? OR do we need to break out best of the break-out sessions? Two mentors thumb wrestle.

Wrestler one: Smaller groups of the same break-out session might be good.

Precanned sessions make it easier for new mentors to feel confident and be successful.

Wrestler two: Diversity of projects inspires people to do the kinds of things that people can do with this new knowledge. 


What else can encourage generative-ness? Giving mentees generative moments within sessions and lectures might be empowering. Perhaps, calling out mentees who are doing generative things.

Basic statistical analysis in Python would be a fun thing to teach (says Mako) and at least ten mentees would be enthusiastic about it.

Some people love R some people don’t. The world goes round.


Q: How can we strengthen the relationship between the lectures and the break-outs?


The ethnographers get the last word: Some observations about the culture of mentoring from a first time mentor: There are some distinct values that came through strongly. There is a clear vision of empowerment through programming. The degree of inclusivity is impressive. The culture of feedback, iteration, and reflection was really surprising such as the amount of effort that goes into improving the materials and the teaching. As is the way that other organizations are able to (and are) using the materials. The way that this is building the community. For example, how mentees are organizing their own meet-ups (though that could be encouraged even more).

The pragmatism of what is taught demonstrates a clear value. It would be helpful to make sure that all mentors are clear that part of what is expected of them they give pragmatic coaching. That is they should lead mentees to something that works rather than telling them what an expert would do.

Mako's Raw Notes

rooms:

maybe get the oodegard room architecture of the space has quickly become the limiting factor

checkout - not everybody loves the checkout, maybe there's a way we can make it more fun?

communiate the whole setup process to the mentors ahead of time

-> maybe stream line the process

-> finding the directory continues to be hard


we moved the curriculum from cmd to powershell

- windows xp is broke now. make sure you ahve a person with xp skills on hand

not a single person in our session had ip

we can move away from 3 separate installations in the setup information.

- everybody can use zip instead of a zip/tar.gz both


maybe we can consoldiate the wiki pages into a singel page which will be much eaiser to instlla nd keep updated in the future

generally, lets stop copying and pasting new stuff into the wiki. we when archive the old version, we can create links to teh old version of the wiki pages (intstall the templates from english wikipedia)

get rid of pages that are event specific


  • demorgraphics

people come in: departments? maybe build a table?

  • org suggestions

let people joiun int he later session

making letting peopel skpi #1 could be usefuil

-> maybe we can accept people after words

-> alternatively, we can try to accetp more newsiebes and improve retention

mixed feelings




ways to improve and retain people

-> layout what we're going to do int he next sessions

go to show why are learning things up front

focus on broad research questions

pair programming? 

encouraging people to work iun teams or with other on problems they suggest

next time maybe mine the registration for a list of research questions

note:

next time make it explicit that folks can work in grousp

tip: introduce mentors to everybody very clearly

introductions would have been good but are hard to do

  • sesion 1

bring folks back together to go over things

- post examples of code used in teh lectures

- create code base

- turn on loggin gin the concsol and post it after the lecture

mentor workshop:

- get people together before encourage people to get involved maybe bar meetup

- track diversity of people along more dimensions

- the sql workshops was well received although slight mixed in terms of feedback

more breakout session next time colorwall was gone and nobody missed it

  • babynames

- try to integrate more year - huge success - may split rooms into two baby names


list questions up front and let folks choose what to work on and what to bring back together

generally:

- note places to bring folks back together

  • session 3

generally:

showcase what students ahve accomplished and places people can change things and do things differently

e.g., the fergeson thing with the exmaple from ha=rry party

strong connection between the lecture and the introduction

-> more connections and takeaways to emphasize the session more clearly

how to tap mentors on topics more effectively

wordplay

- kinda borning

next time

- public healtha nd epi data session

end of semseter was too late. maybe have it early next year

twitter:


- have people do the setup ahead of time

-> that was clear ahead of time and it happened in the beginnginf of class. either fix the instruction and make sure that everybody is doing the same thing

speed was an issue

the opaqueness of tweepy was a problem.. option to creat ea version of tweppty that just gives you json

or miku or michael for details onhow to do that

dharma might be able to do this.


sql session:

- maybe split this into two session next time

- merge in some more python this time

  1. 1 intro into sql
  1. 2 using pythong o tgra data and bring python and pandas

wikipedia

- too slow

we can do it faster

lecture

  • stress defining functions more and earlier.. maybe in the first project and certain in session #2 so we can use it in the afternoon projects and tweepy


session 3:

show and tell at the end was very effectively

we need a designated mc who can go =between rooms

bring people up to the

matplot lib

- maybe replace it with seaborn? - tommy will teach it

ideomatic ptyhon

talk to chris to try to fix those things

Retrieved from "https://wiki.openhatch.org/wiki/Community_Data_Science_Workshops_(Fall_2014)/Reflections?oldid=15670"