I’m trying to bring the second pilot of the Ascend Project http://ascendproject.org to New Orleans in February and am looking for a space to hold the program. We have a small budget to rent space but would prefer to find a partnership and/or sponsor if possible to help keep costs low.
The program takes 20 adults who are typically marginalized in technology/open source and offers them a 6 week accelerated learning environment where they build technical skills by contributing to open source – specifically, Mozilla. Ascend provides the laptops, breakfast, lunch, transit & childcare reimbursement, and a daily stipend in order to lift many of the barriers to participation.
Our first pilot completed 6 weeks ago in Portland, OR and it was a great success with 18 participants completing the 6 week course and fixing many bugs in a wide range of Mozilla projects. They have now continued on to internships both inside and outside of Mozilla as well as seeking job opportunities in the tech industry.
To do this again, in New Orleans, Ascend needs a space to hold the classes!
Space requirements are simple:
* Room for 25 people to comfortably work on laptops
* Strong & reliable internet connectivity
* Ability to bring in our own food & beverages
Bonus if the space helps network participants with other tech workers, has projector/whiteboards (though we can bring our own in), or video capability.
Please let me know if you have a connection who can help with getting a space booked for this project and if you have any other leads I can look into, I’d love to hear about them.
Ascend had very few ‘rules’ but there was one which was non-negotiable: it’s an in-person program. We didn’t do distance learning, online coursework, or video-based classes. We did bring in a couple of speakers virtually to speak to the room of 20 participants but the opposite was never true.
This was super important in how we were going to build a strong cohort. Don’t get me wrong, I’m a fan of remote work and global contribution as well as with people working from wherever they are. This was a 6 week intensive program though and in order to build the inter-dependent cohort I was hoping to1, it had to be in person at first. Those cruicial early stages where someone is more likely to ‘disappear’ if things were hard, confusing, or if they couldn’t get someone’s attention to ask a question.
It’s been over 5 years since I graduated from my software development program and over 8 years since I started lurking in IRC channels2 and getting to know Mozillians in digital space first. I wouldn’t have stuck with it, or gotten so deeply involved without my coursework with Dave Humphrey though. That was a once a week class, but it meant the world to be in the same room as other people who were learning and struggling with the same or similar problems. It was an all-important thread connecting what I was trying to do in my self-directed time with actual people who could show more caring about me and my ability to participate.
Even as an experienced open source contributor I can jump into IRC channels for projects I’m trying to work on – most recently dd-wrt for my home server setup – and when I ask a question (with lots of evidence for what I’ve already tried and an awareness of what the manual has to say) I get no response, aka: Crickets. There are a host of reasons, and I know more than a beginner might about what those could be: timezones, family comitments, no one with the expertise currently in the channel, and more. None of that matters when you’re new to this type of environment. Silence is interpreted as a big “GO AWAY YOU DON’T BELONG HERE” despite the best intentions of any community.
In person learning is the best way to counter that. Being able to turn to a colleague or a mentor and say what’s happening helps get you both reassurance that it’s not you, but also someone who can help you get unstuck on what to do next. While you wait for a response, check out this other topic we’re studying. Perhaps you can try other methods of communication too, like in a bug or an email.
Over the course of our first pilot I also discovered that removing myself from the primary workroom the Ascend participants were in helped the cohort to rapidly built up strengths in helping each other first3. The workflow looked more like: have a question/problem, ask a cohort member (or several), if you still can’t figure it out ask on IRC, and if then if you’re still stuck find your course leader. This put me at the end of the escalation path4 and meant that people were learning to rely both on in-person communications as well as IRC but more importantly were building up the muscle of “don’t stop asking for help until you get it” which is really where open source becomes such a great space to work in.
Back to my recent dd-wrt experience, I didn’t hear anything back in IRC and I felt I had exhausted the forums & wikis their community provided. I started asking in other IRC channels where tech-minded people hung out (thanks womenwhohack!) and then I tried yet another search with slightly different terms. In the end I found what I needed in a YouTube tutorial. I hope that sufficiently demonstrates that a combination of tactics are what culminate in an ability to be persistent when learning in open source projects.
Never underestimate the importance of removing isolation for new contributors to a project. In person help, even just at first, can be huge.
Because the ultimate goal of Ascend was to give people skills for long-term contribution and participation and a local cohort of support and fellow learners seemed like a good bet for that to be possible once the barrier-removing help of the 6 week intensive was no longer in place. ↩
By the way, I’m such a huge fan of IRC that I wrote the tutorial for it at Mozilla in order to help get more non-engineering folks using it, in my perfect world everyone is in IRC all the time with scrollback options and logging. ↩
Only after the first three weeks when we moved to the more independent work, working on bugs, stage. ↩
Which is awesome because I was always struggling to keep up with the course creation as we were running it, I didn’t realize that teaching 9-5 was asking for disaster and next time we’ll do 10-4 for the participants to give the mentors pre and post prep time. ↩
I believe it was a few years ago, possibly more, when someone (was it Josh Matthews? David Eaves) added a feature to Bugzilla that indicated when a person was “New to Bugzilla”. It was a visual cue next to their username and its purpose was to help others remember that not everyone in the Bugzilla soup is a veteran, accustomed to our jargon, customs, and best practices. This visual cue came in handy three weeks ago when I encouraged 20 new contributors to sign up for Bugzilla. 20 people who have only recently begun their journey towards becoming Mozilla contributors, and open source mavens. In setting them loose upon our bug tracker I’ve observed two things:
ONE: The “New to Bugzilla” flag does not stay up long enough. I’ll file a bug on this and look into how long it currently does stay up, and recommend that if possible we should have it stay up until the following criteria are met:
* The person has made at least 10 comments
* The person has put up at least one attachment
* The person has either reported, resolved, been assigned to, or verified at least one bug
TWO: This one is a little harder – it involves more social engineering. Sometimes people are might be immune to the “New to Bugzilla” cue or overlook it which has resulted in some cases there have been responses to bugs filed by my cohort of Ascenders where the commenter was neither helpful nor forwarding the issue raised. I’ve been fortunate to be in-person with the Ascend folks and can tell them that if this happens they should let me know, but I can’t fight everyone’s fights for them over the long haul. So instead we should build into the system a way to make sure that when someone who is not New to Bugzilla replies immediately after a “New to Bugzilla” user there is a reminder in the comment field – something along the lines of “You’re about to respond to someone who’s new around here so please remember to be helpful”. Off to file the bugs!
Today, post PyCon conference, I spent the entire day immersed in an incredibly dynamic and educational workshop by Software Carpentry “Learn to Teach Programming“. I’m going to do a mix of dumping my notes in a play-by-play fashion with possible sidebars for commenting on what I experienced personally so that I have a record of this to look back on as I move forward with Ascend Project planning and execution.
Meet Your Neighbours
The event started off, as they always do, with a go-round of people introducing themselves in short form. As we started taking turns our teacher, Greg Wilson, asked for the person who just spoke to tap the next person to speak before sitting down. This proved to be our first of many small applications of the science behind learning and how it can play out in real life. While it apparently takes a room of kindergarten children 3 reminders to do this extra step during intros, it took this room of ~25 adults 14 requests before we mostly started doing so without prompting from Greg. By the way, during the intros I learned about Dames Making Games which I can now add to my mental list of awesome women-in-tech groups and if you’re reading this and are in Toronto, check them out!
Teaching Is Performance
It raises your adrenaline, brings out your nervousness, and it’s something you need to work at. A few quick tips from Greg on preparing for your ‘performance’ as teacher: always bring cough drops, and figure out what your ‘tell’ is. Like with poker, everyone has at least on thing they do when they are nervous. I suspect for me its likely that my ‘tell’ is talking fast and/or having trouble not smiling too much (at least in poker, it is). This was our first introduction to how we should be reflective about our teaching – even go so far as to record yourself if you can’t get honest feedback from people around you – so that you can spot these things about your manner and work on adjusting them to ‘perform’ teaching in a more confident and reliable manner.
Improv came up as a way to work on this where you can get feedback on how you perform and also learn to keep other people engaged. I used to do improv when I was an awkward teenager and didn’t feel like I was a superstar at it but I wonder what it could be like now that I have more confidence. I’ll be looking for classes in SF to try it out. What’s there to lose?
Why Don’t We Teach In Teams?
Greg pointed out how teaching, unlike music and comedy, is such a solo activity. Musicians typically build up their experience and skills by playing with others. The best comedians by and large spent a significant amount of time in some sort of comedy troupe before striking out on their own as a stand-up or as major film stars. Teachers though? Often alone in their classrooms and if my partner is an example of the ‘norm’, definitely alone while grading and preparing lessons. This is something worth exploring: what could teaching be like for the teacher if there was team teaching? What could we do with more feedback, more often, and with someone helping us track measurable progress towards our goals as agents inspiring learning? Finland has an excellent system of teacher feedback and peer/mentoring for their educators. Teacher’s college is harder to get into there than medical school (not sure that’s a good thing, but it’s what Greg told us).
Key Points About Teaching & Learning
People have two kinds of memory layers – short and long term – and short term memory (which is what we are working with in classroom environments) can hold ~7 items +/- 2 so really we should aim for 5 in order to teach to our students’ capacity
We have to balance on/off time – we lose some time switching between tasks or concepts in the teaching but working with memory limitations as mentioned above, we must let people take breaks to reset & refresh
Avg person can take in info for about 45 minutes before their attention wanes from exhaustion. For me, this is more like 30 minutes. Hearing this from Greg reminds me that I want to propose that all meetings I’m involved with at work move the default length to 30 minutes and that we have a set of rules for how to deal with ‘overage’. Either email or mailing list post, etherpad, set up a follow-up meeting, or make a proposal and request feedback so that we are not taking an hour because we *have* an hour.
Apparently the military has a lot of research and effective solutions for human performance. Greg mentioned being at a naval academy and the grad students he was lecturing to dropped into doing pushups when a bell sounded on the hour. This sounds like a great practice for anyone trying to learn and be engaged with others – get your blood pumping and change your position. Reminds me to get that automated rest-taking app running on my laptop again and to actually pay attention to it for a while instead of dismissing over and over.
Continuous ‘flow’ – oh that elusive state for programmers. There was some sort of quote about coffee but I missed the first part, the gist was that when we are immersed in something and truly engaged we can override that 45 minute intake limitation from before but if we do more than pause (without switching contexts) we could end up breaking flow and it takes at least 5-10 minutes to get back into it. This is key for people who work in environments full of distractions and interruptions. I’ve been thinking a lot about this one lately as I’d like to work on breaking my very unproductive cycle of checking IRC and email in a loop as though I am event-driven. I need to make times to get into ‘flow’ and do bigger tasks with more focus.
A sidebar of the distraction mention was the fact that, in programming, syntax can be the distraction. That is, errors in. When you get stuck trying to figure out where your semi-colon or indentation is off you break out of ‘flow’. In a language/framework like Scratch this is not possible as the blocks cannot be dragged and dropped into any order that creates errors except in ways that are related to logic and program flow – worth stopping to think about (and keeping you in your engagement ‘flow’)
There are roughly three types of minds out there to work with in teaching: a) Novice b) Competent c) Expert. The Novice doesn’t know what they don’t know so the most important thing to do when trying to teach a Novice is to make sure their mental model of the concept you are teaching is correct. This is to become a lot of the focus in the rest of the day – methods of determining if our concept is getting across correctly. The Expert is such because they have more connections between all the facts they know about the concept/skill and so they can leap from point A to point J in one move where it takes a Competent mind all the dots in between – executed well, but with thought and intention – to complete them. It is *as hard* to get Novices to become Competent as it is to get Experts to see the concept they are trying to teach as a Competent person does. Think about something you might be and Expert at and see if you can tell what steps you assume other people will know.
Another key point about the Expert is the idea of reflection. Being able to reflect on your skill is huge for honing it. An example would be how I went to a hockey skating workshop where they video taped us skating our fastest and when I saw that video, saw how knock-kneed I was and how my internal map that I was using wide leg strokes did not actually look like that in the tape I was a) horrified but also b) it’s a reminder of how far I have to go and how much more work I need to do in order to reach a higher level of expertise, such as that reflected to me by the instructors.
Accepting Feedback and Critique
We spent some time talking about critique. In architecture, art, music, and many other disciplines there is a built-in system for critique. It helps the student to build up their sense of self, to know their strengths and weaknesses. We do not always have this in teaching. In our workshop, Greg had people write down one piece of positive and one negative feedback on two sticky notes (yellow for positive, pink for negative) and he asked us to put them on a piece of paper at the front of the room before we headed out on our first break (just over an hour of instruction had occurred). When we returned we discussed what the anonymous feedback had provided Greg with and what he could actually work on in the moment vs. what was useful for later. He mentioned doing this, and letting it be anonymous, was a great way to build trust with your students. Also we talked about how to get better at accepting feedback, working with it, not letting it paralyze you or derail your lesson.
One of the key takeaways for me here was the idea that the most senior leader/teacher should model this for others. Show that you can hear feedback, both good and negative (hopefully constructive), and be able to move forward without crumbling under the pressure. While I’m nervous about feedback, I will do my best to ‘fake it till I make it’ on this point because it’s definitely more important to correct course and create a better experience for students than to be proud and lose their interest and especially, trust.
Our next major concept was the concept map. This is a way to help yourself understand what you are trying to teach. It’s also a way to check yourself for the 7 items +/- 2 factor. If you have more than 5 main concepts in the concept map, it’s time to evaluate it for what can be put aside for now or what can become the next lesson. The concept map can also be shared with students as a way to make sure everyone is on the same page or at least starting with the same page. Greg recommended handing out a printout of the concept map so that students could doodle and expand it in ways he might not have thought of.
We learned how the concept map should never be used for grading. It’s mostly a tool for the teacher to know if they have managed to get across the mental model well enough for the novice to reflect back a matching map and feel comfortable moving on to the next concept. It’s also a way of preventing the “blank screen” where students can be frozen trying to come up with what to put down (in programming or in writing) and having a scaffolding there in the form of map, or hints, any form of guidance can basically jump start the student and hold their hand until they need less and less of it to self-start, self-direct, and truly *learn* autonomously.
We did an exercise where we drew up concept maps for how to teach a for loop. This was my first time doing a concept map and it was hard. Definitely will take practice and likely some more reading/looking at other concept maps to drive home the concept for myself.
Key points from Greg:
Make your concept map look ‘cheap’ so that people aren’t afraid to give you honest feedback
Write and share maps with each other – try this with your team at work on a project you’re starting – you might see that others have a *very* different sense of what is being attempted
Try not to need things in your concept map that you will “explain later” – if you can’t explain it now you’re going to disrupt the ‘flow’ of maximizing the short term memory limits
Transfer your map into a list of bullet points as it will help you put the most important concepts first
Think of concept mapping like couples dances. You both want to be doing the same dance or there will be a lot of bruised shins
Sticky Notes as Invaluable Teaching Tool
We used sticky notes at several points in this workshop. While we only had two colours today, Greg recommends three colours to be used as follows:
Green: Students can put this up in a visible place when they have completed the exercise currently being done
Yellow: Students can put this up when they have a question. Also this is a great tool for ensuring more participation in the classroom setting. Some people talk more than others, there are definitely certain types of people who take up more space, and the deal with the yellow stickies was: You get two, when you ask a question put one aside. Another question? Put the other aside. Now you have no more questions until EVERYONE in the class has used at least one of their yellow stickies.
Red: Students can pop this up in a visible place when they need help on something. This is great for two reasons: 1) the student can keep *trying* instead of worrying about holding a hand up and waiting for eye contact with a teacher and 2) the student can request help without drawing too much attention to themselves. This is great for classes with people who might have learned it’s best not to speak up, ask questions, or draw attention to themselves out of fear and/or shame.
Know Your End Goal
This probably shouldn’t have *blown my mind* but it did. It’s so obvious yet I’ve never once designed curriculum with this approach. You can bet that’s all changed now. Here’s the key point:
DESIGN YOUR LESSON BY WRITING THE ‘EXAM’ FIRST
Ya. It’s maybe obvious. You want to make sure the students leave knowing what you intended to teach them? Well, figure out how you’re going to measure that success *first*, then build your lesson up to that. “They understand the for loop” is not enough. Be specific. Have a multiple choice question that tests the output of a for loop and gives 3 plausible answers and one right answer. Use this to check if you are teaching well – their failure to choose the right question is your failure to teach the concept correctly. This doesn’t have to be for actual grading (unless you want to grade yourself). Think of this like Test Driven Development for curriculum. Teach to the goal. You will develop lessons faster and more efficiently. Your learners will appreciate it. They can tell when they are learning vs. having a lecturer do a brain dump on them that goes nowhere in particular. Backwards design works. Greg’s book plug related to this section: “Seeing Like a State“
Another tip? Create one or more user profiles for your lesson. In our workshop we created Dawn: 15 year old girl who is good at science and math, learning programming in a one-day workshop. Then we did an exercise in crafting a question that would confirm if we had successfully taught how functions work to her.
We learned about Allison Elliott Tew‘s work and about “Concept Inventory” which is a way to use common mistakes in mental modeling to create multiple choice questions where the incorrect answers can help you understand *how* someone has misunderstood the concept you are trying to teach. Multiple choice is great because it’s quick to get you an assessment (teacher grading time).
Related to multiple-choice as test of understanding is Peer Instruction. This is a method that uses a multiple choice question in a really interesting, and engaging fashion.
Developed by Eric Mazur in the 1990’s this method expects students to have done some pre-work on the material before coming to class so that the entirety of the lesson can be used to compare and correct conceptual maps and understanding of the material. It goes like this (at least Greg’s interpretation – it differs in Wikipedia as to how Eric designed it):
Provide a multiple choice question based on the pre-work content. Ensure 3 plausible answers and one correct
Students select and *commit* to an answer (there is not yet software for this, though there are clickers) – you can also ask people to hold up the number of fingers for their choice and have classroom helpers count
If everyone picks the right answer you can move on but otherwise you ask people to talk in groups with their neighbours to examine each other’s choices and what the correct answer might be and why. This is great for having people explain their mental model/map
Vote again and have students commit to the answer
Instruction reveals the answer as well as perhaps a single sentence explaining why
Groups discuss again, this time they can explore their understanding with the correct answer alongside people who, likely, had the correct model
This teaching technique was proven in 1989 but is still widely unused (esp. in MOOCs). Greg told us that he can usually do about 10 of these types of questions in a 1 hour class. We did an example of one in the workshop to test out the method and it was a lively exercise. This was also an opportunity for Greg to help us notice how noise in the room helps a teacher determine when a good time is to check in, continue the lesson, or make sure people aren’t stuck. Active, engaged learning is boisterous and noticeably relaxed. Quiet can mean focus, and then as people complete the exercise you can hear some discussions start up as those who are done talk with each other about the exercise. I look forward to getting a bit of expertise at this level of listening and was impressed by Greg’s skills in classroom energy level reading.
F*ck It, I’m Outta Here
I have several more pages of notes but it’s getting late and this is a long post. There’s one more part of the workshop that I’d like to write about: The moment when you decided you didn’t want to learn something anymore.
This is a really great piece of advice for teachers. Greg started by saying that he used to ask students what motivated them to learn, what great experience in learning they had so he could tap into that motivation as a teacher. Now? He asks people what DE-motivated them. You get a lot out of people this way. Ask someone (or think of your own experiences): “What was something you were curious about, working on, getting into, and what happened that made you say ‘f*ck it’ and drop it? If you could go back in time what would you change?”.
For my example I spoke about returning to gym class at 12 years of age after recovering for many months from a very physically traumatic incident where I was hit by a car while on my bike (15 bones broken, 6 months in a wheelchair). Being immobilized *and* being a pre-teen caused me to put on a fair amount of weight and I was no longer very physically active or able. I also had yet-to-be-diagnosed asthma. Not only did I have to endure a gym class where those with natural talents were help up while the rest of us were discarded but I also continued to fail tremendously at getting more than a “Participation” certificate(! Every other result got a very nice badge) for the Canada Fitness Test.
My “F*ck it” moment was when I got so frustrated with never getting a badge that I stole someone’s gold badge when no one was watching. I also ended up eschewing all sports and athletic pursuits for many years if there was any hint of tryouts or actual talent needed. Years later, at 29, I taught myself how to run by using a couch-to-10K program that did repetitions of running and walking in order to build up endurance. Not only did I succeed at that but I learned to *love* running and feeling healthier in my body. If I could go back in time I would become a Physical Education teacher and make sure every kid in my class knew that it’s not about natural talent at anything. It’s about setting achievable goals for yourself and comparing your results against your OWN RESULTS. Never mind some test, and other kids. We’re all very different but no one should be denied a sense of accomplishment. It’s what keeps you coming back to learn & build on what you’ve learned.
Now Go Read More: Keep Learning How to Teach
It was an amazing day. I have more notes to transcribe for myself but I think I’ve managed to capture the major concepts I learned today that will all be invaluable in my work on Ascend and beyond. Greg is an experienced, passionate, driven teacher and his enthusiasm for *knowing* what works in education is contagious. I want to be a better scientist and educator too. The Software Carpentry movement is picking up momentum. Look for workshops, blog posts, and opportunities to participate in a town near you. See their site for up to date information and also check out their materials page for additional resources. I’ve got a few new books to read on the plane home tomorrow.
Last year I approached Debbie Cohen, our C-level People person, and made a proposal. With all these Hacker School/Dev Boot Camp/Hackbright accelerator programs popping up, I had an idea to create an open source version and specifically target participants who come from underemployed, LGBTQ, Latin@, and African American populations – aka: people who are terribly underrepresented in tech but also very much more so in Open Source. The idea was that instead of people paying to come learn to become developers in the capitalist, Startup-focused, feeding-frenzy the Silicon Valley promotes we could instead seed other towns, other communities with open source and create an in-depth technical contribution training program that more mirrored the experience I had with Dave Humphrey at Seneca College. Imagine my surprise when Debbie clearly, and without hesitation said to me “Great idea! Do it!”. I’ve been building up to something that is more sizeable through running local events, hack meetups, participating in community building in several ways so I saw this proposal as the next step for me, as an organizer. This time I’m going to do something that is bigger than what I could do alone. I will have Christie Koehler working with me as well as several community building team members in advising and mentoring roles.
The populations I want us to reach out to have resulted in certain adjustments to the typical setup of those for-profit accelerators which I see as being key to the potential success of our cohorts. Attendees in the Ascend Project will benefit from taking this course in the following ways, which are intended to remove many barriers to participation in Open Source:
a $50 per day honorarium will be provided to encourage regular attendance and help ensure participants can afford to focus on being present to learn & develop
laptops will be provided to use during the course and upon completion, graduates will get to keep theirs
food (breakfast and lunch) will be provided every day
where needed, childcare stipends are available to participants who need additional care in order to put in the time this course will request of them
transit passes for the whole 6 weeks
The purpose here is to not only acknowledge that we know we’re missing people in our open source communities but that we’re willing to put our money and time where our mouths are to go and explicitly invite people who like to solve problems to come and see what it is like to get to just focus on learning, developing, fixing a bug, getting hooked, being a part of a bigger community with a mission for global good. I see this as a solid way to counter the manner in which many of these populations are pushed away from participation in computer science and open source contributions.
We can’t expect every person who might be a strong, longtime, and impactful contributor to Open Source to find us based on passion alone. That leaves all the systemic issues in society to decide for us who gets here. If we can remove some barriers and provide an environment where participants in a program get a chance to feel confident, trusted, strong, and *wanted* then we can see how that might blossom their abilities to learn and contribute to an open source project that has a ton of pathways for potential input and impact.
The project is currently still in the kickoff phase so this is the first public post. Mostly I’m braindumping, trying to work backwards from September when the course will start, and getting my head around who will do what so we get everything ready in time. I’ve got a budget for the first pilot, which will take place in Portland, OR in the Fall of 2014, and it’s almost approved. Next up I will be designing the curriculum while Christie works on partnerships locally in preparation for our call for applications. We’ll be doing our best to reach far outside the typical degrees of separation to get word out and to attract applicants. I’ll be in Portland next week to meet with local orgs and gather information on where we can promote the project.
The first session, as a pilot, will have certain ‘training wheels’ on it. Mozilla has a great space in Portland. Portland has a wonderfully large open source community I fully expect to tap into for networking and partnerships. We’ll be using this first pilot as a way to test the participant selection process and the curriculum itself. I really want to be setting people up for success. This is measured by committing at least one patch to production code (in any area of Firefox) before the end of the course. Our first course will focus on Mozmill automated testing because we can get our participants to that level of success with independently-written JS tests for several of the Firefox products.
Following Portland we’ll be reviewing, updating, improving, and then taking the next pilot to New Orleans in January of 2015 where we can test “what happens if we don’t have an office, a large community already in place?” with our tightened up selection process and curriculum. The two pilots should give us lots to go on for how to scale up an initiative like this going forward and hopefully it can become something that happens more frequently, with more teachers, and in many more places (like in some of our Firefox OS launch markets).
That’s the gist for now. I’ll be posting more frequently as we hit milestones in the project and also am happy to take people up on offers to review curriculum.
Dare 2B Digital is an annual South Bay conference that brings 300 young women ages 12-16 together to encourage them to consider STEM fields in college by coming together for a full day of inspiring talks and workshops showcasing women’s work and relevance in technology. For the past three conferences I have signed Mozilla up as a sponsor and created a workshop that is run 3 times that day and reaches about 80-100 attendees. Last year I created kits for participants to learn about soft circuit hacking and lighting up felt foxes, the year before I taughtUniversal Subtitles and Popcorn before it was even a 1.0 product yet. I’m always trying to keep our workshops current and, if possible, on the bleeding edge of whatever Mozilla is working on. The participants get a taste of one exciting aspect of what is happening RIGHT NOW in open technology.
In the past year I’ve been really inspired by Mozilla’s outreach around web literacy and at the same time there’s been all this work done around our upcoming Firefox OS for mobile devices that will allow apps to be built entirely of the web and installed/sold/shared outside of the silo-structures such as Apple’s App Store and Google Play. At MozCamp Asia in November of 2012 I watched the Mozilla Taiwan reps showcase a fairly simple card matching game they had made of browser icons and they turned it into a Firefox OS installable app in only a couple of hours. All of these snippets and ideas led to my proposed workshop for the girls being about hacking their own version of the browser-pairs game and installing/playing it on a Firefox OS device.
Now this was all before the Firefox OS phones even existed, and it was also before I went away on a 3 week vacation to Vietnam over the holidays. I mentioned it to my co-worker Margaret before leaving and she said she’d be up for working on it with me but when I returned from vacation I lost about a week just on jetlag & minor flu-like symptoms then another on my birthday and having my family in from out of town. Next thing I knew it was February 1st, the workshop was on February 9th, and I had NOTHING ready and there was no public Firefox OS device yet, either.
So I called up Ruth who organizes the conference and tried to beg off this year. Would it be so bad if Mozilla didn’t do a workshop this one time? Thankfully Ruth very calmly returned my panicked email with a phone call and asked me what I needed to get this workshop on track. What did I need? Mostly just to buck up and finish what I started, me with my big mouth. The pieces were all out there. I had code (thank you Mozilla Taiwan!), Chris Heilmann had recently posted some inspiring slides about HTML5 and mobile for Firefox OS App Days, and Hackasaurus has plenty of youth-focused resources.
Hastily, I organized a couple of lunch time meetings during the week leading up to the workshop with Margaret and we hashed out who would do what. We made an exciting discovery in our first meeting, which was that we could host the game from a github page and this meant every girl in the workshop could hack on her own customizations of the game in github’s web interface code editor and see their changes reflected on a mobile device immediately. No need to deal with the minutia of web hosting, no server-side code, and minimal development setup – the freshly imaged laptops we borrowed from Mozilla IT would be good to go in minutes!
I drove to Redwood City on the day of the conference with: 20 laptops, 15 Firefox OS test driver devices (thanks to my co-workers who let me borrow their phones!), and some slides about why hacking HTML5 is the future of mobile apps. One thing we realized as we were setting up was that there would be some delay between when the participants created their GitHub accounts and when they would see their github pages live with our demo code. We ended up front-loading that and having them start right away as they arrived at the top of each time slot then going into the presentation after they had forked the repo which had the gh-pages branch set to default. We later learned (through Margaret’s chatting with GitHub support) that it was likely the delay could be caused by not having edited anything yet on the gh-pages branch so in later workshops we had the girls follow along with Margaret and change the <title> of their index.html and commit the change.
The presentation portion was about 10-15 minutes and started out with asking the girls to shout out what comes to mind when I say the word “HACK”. Answers included “death row” and things along the lines of breaking or sneaking into someone’s computer, mostly things associated with dark or criminal activities. A few did mention things like ‘nerd’ or ‘creative’ too. When I showed them my examples for the talk we had a brief discussion about not asking for permission, being curious, creative, and taking ownership. After that we talked about Apple/iPhone and Google/Android. Most of the girls had one or the other we explored how non-interchangeable they are, how much it might cost to be a developer for one or the other, the need to play by someone else’s rules in order to get your ideas out there. My favourite part of this talk is repeating over and over how using open web technologies and the web itself is all about NOT ASKING PERMISSION. You put your stuff up, tell people where it is, and they can go use it. It can (and should) be that easy.
After the talking was done the young women had about 45 minutes to hack on their github sandboxes and test out making customizations to their matching game. We modeled it after Mozilla’s Thimble project which uses comments in the code to explain various areas of the code and gives ideas on what to change. Our take was to suggest they try (in increasing levels of difficulty):
changing the background color/images (of the page, game box, card backs)
changing the images on the cards when flipped
change the music (few got to this part in the allotted time)
We saved 15 minutes at the end to do demos of what people did to their code and to come up and tell us what they did to achieve their end results. Some of the customizations led to a newly themed game like pigs, magic, twilight, book covers, and other things the designers liked. A few girls went further and took snapshots of themselves on the laptop camera and used their own action shots in the match game, one girl had her own laptop and drawing tablet so she drew her own card faces and intro screen background, and another girl removed the card backs to make it look like the game box was all black – when I started to click during her demo and cards flipped I was surprised since I had thought the game was broken but she laughed and said it was on purpose. It’s hilarious to me that she made a simple match game into a much harder challenge by hiding the discover-ability of the game.
All in all the three workshops went smoothly, everyone got to do some hacking and see their results during the time we had allotted, and all the girls left with a new github account and code they can keep hacking and learning on over time. During the course of the workshop we went around helping and answering questions and taught them about commit history, rolling back changes, and also using “Inspect Element” to figure out where to look in the code to make changes. I should mention that at the beginning of every workshop I asked “Who here has touched HTML/CSS before?” and there were never more than half the hands in the room raised. This comes up every year in the workshops I run. Some girls are getting this knowledge from parents, friends, self-teaching, and now things like CoderDojo (as one participant bragged) but there’s no indication that any of them are learning this in school where they spend a majority of their time. The thought that some girls are being left behind on this is sad to me, and I want to do all I can to help change that. Every single one of these young women left our workshop with a new spark in their eyes having now had first-hand experience with the power of creating web apps that can run on ANY WEB-ENABLED DEVICE. It was powerful to see.
So, what’s next? I think this workshop should become another Webmaker and/or Hackasaurus project that can be taught anywhere, to anyone who wants to have a first-time experience with mobile app development. We’re 80% of the way there, I’d say what’s left to do is:
* Spend a bit more time, if you have it on basic HTML/CSS editing, using Inspect Element, and having cheat sheets printed up for participants.
* Have options for what to do next – getting off of github pages and hosting your own app, possibly with some server-side code.
It won’t take much to turn this into something more generic and useful for introducing people to the power of Firefox OS and HTML5 app creation and I look forward to continuing to develop this sort of material whenever I can. Thanks to the Desktop Support staff who prepped laptops for the conference, SF co-workers who lent their phones, and most of all to my coworkers who lent their time and their expertise: Margaret, Larissa, and Amy*. Without all of you this would not have gone smoothly and because of you it was the best day of 2013 so far.
* At lunch we had a little Q&A with the 30 or so girls from the first workshop. They got to ask all of us questions about what we do and how we got there. The four of us had such different paths & connections to technology. I love that we got to show these young women a variety of ways to engage with tech and to be in open source.
This past weekend I led another soft circuits 101 workshop as a Mozilla Rep at a women’s music festival near SF called Fabulosa. I had one hour to teach people really basic electricity, circuits, and how to ‘hack’ their clothes/sculptures/lives with a 3V battery and some LEDs.
The reason I love to do this workshop is because I find it gives participants a physical representation of the hacker spirit Mozilla aims to embody for the web. Learning soft circuits is just the tip of the iceberg and I always stress that the web has much more info for them to continue exploring, learning, being curious about how to create and modify technology in their lives. In one hour, I just show them how to make light.
This workshop was smaller than the ~80 girls who came through at Dare 2B Digital. The festival setting meant there were more conflicts of interest so I had 6 participants instead of the 20-25 I had planned for. The 6 participants were all very enthusiastic though, and we started off with a go-around to hear why people were interested in learning soft circuitry. One person was hoping to learn how to light up her clay sculptures, another wanted to make art for Burning Man, and a few had costume ideas in mind.
I spent the first 10-15 minutes explaining electricity, how a circuit works, and what kind of circuit they would be creating with their 3V batteries and LEDs – their circuits would be made using conductive thread sewn into felt (or some other material if they brought it). With only 40 minutes left, we got to work – everyone started in on their first circuit.
While we were casually chatting during the building time, one woman said “I thought ‘hack’ was a bad word” (I had written a large “HACK” on the whiteboard to inspire). I’m so glad she brought this up and we had a chance to discuss the very reason for workshops like these, and for Mozilla. I explained to her that while it might once have been a vilified term, it has now been largely reclaimed as people work to make sure that they have full ownership of the things they buy, or make. Encouraging people to open their minds up to the potential of hacking their lives – whether on the web or in the physical world – always feels great. I was happy that even in this small gathering, we got to discuss this very key issue for technology going into the future, and that there are now 6 new hackers in the world.
Last Thursday night about 8 women arrived at Noisebridge to learn how to contribute to Wikipedia. Several things led to this gathering:
An article in the New York Times back in October drew attention to the lack of women contributors to the Wikipedia knowledge base and that got me thinking.
Having organized other spontaneous “women get together and learn stuff” events I figured I could take the same approach to Wikipedia contributing, get some women together to create accounts, generate content, learn how to stop vandalism and see what would stick.
Recent participation in activism around the Occupy Wall Street movement also inspired me to try and reach out to communities I am in who are not as technical, to encourage people to come first with knowledge and interest in topics Wikipedia could benefit from and let the tech come second.
A month ago Elsa and I were talking casually about all the the above mentioned things and we decided to just go for it and pick a date, throw it up on the Noisebridge (local SF hackerspace) calendar, and see what we could make happen.
We took over a small makeshift classroom space at the back of Noisebridge. It had one lamp as the primary source of light because the fluorescent holders above were missing their tubes. A man was near the back working on a dress for fashion school, several other hackers were up front working on their various projects. Noisebridge was a wonderful place to have this event. It feels like anything is possible in a space like that.
I was happy with the turn out – we had a mix of artists, educators, and tech workers. Also as a bonus one of the attendees, my coworker Boriss, was a seasoned Wikipedia contributor who was able to really detail the ins and outs of the different levels of participation. I can’t stress enough how amazing it was to have her and her knowledge there because there are lots of misconceptions about Wikipedia (I definitely had some) and her first-hand knowledge was inspiring to me.
So the beginning of the meetup went well enough, and as you might expect. We introduced ourselves, talked about why we had come to the event and what we were hoping to get out of it. We started in on learning how to set up an account if one didn’t already exist and we looked at discussion/history/edit and other basic navigations of Wikipedia space. There were a lot of questions about what belongs in Wikipedia, neutral tone, citations. The conversations were lively and I found them quite enjoyable.
Here’s what I didn’t expect: Getting folks interested and excited about Wikipedia becomes REALLY HARD in practice. Unlike learning Python where the participants can hammer out some code on their own computers in minutes and feel accomplished, there is a lot more complexity to Wikipedia. There is a lot of confusion about their UI, their purpose, who can do what and when. Very quickly it seemed that the women who had come to the event feared adding anything new to the knowledge base and they were also incredibly intimidated by the UI of the site. It wasn’t even clear enough how one would create a new article when none existed.
From this event I learned a lot about organizing and about the intentions of future events like this and I did a little braindumping while we were meeting so I could remember to list them later in this very post.
Things that would help newcomers:
Having a “new to wikipedia” moniker next to their nickname for the first N activities on the site (we have this on our Mozilla bugzilla) so that hopefully older and wiser participants would be extra nice to them
Find a way to make some of the simpler tasks that help Wikipedia (typos, reverting vandalism, categorizing articles) into a game that a new arrival could play that would start easy and then move more toward the real-life workflow of working on Wikipedia – as a way to warm them to the UI
Encourage newcomer to write a straight-up article and have a place for these things to be dumped for inpection/linkage/categorization and otherwise Wikipedia-fying the knowledge dump. My partner is an English professor and can certainly write good content for Wikipedia but everything about the site is intimidating. There should be a page where she could copy/paste or upload a document of her article and then let people who know wiki syntax and the other requirements an article needs come along and finish it up
Make it way easier to find the “adopt a user” program that I hear exists but no one would know to find that from the Wikipedia home page
I will continue to organize these events, perhaps once a month. More reports as they happen.