Artisanal Contributors

Part 1: Start In Person

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.


  1. 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. 
  2. 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. 
  3. Only after the first three weeks when we moved to the more independent work, working on bugs, stage. 
  4. 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. 

Take on the harder problem, Google

This just in:

Girls love to make bracelets, right?
Girls love to make bracelets, right?

Google, who recently announced their very disappointing statistics for diversity within their company are trying to remedy that with a $50 million dollar initiative targeting the usual suspects:  Girls.

This is not just me pointing fingers at Google.  I am actively working to create a program that targets adults and supports them getting deeply involved in tech without blinders to the realities of that environment as it stands now.

They have $50M to put into this? Great.  They should, however, have enough brains in their organization to KNOW that ‘fixing’ the issues of lack of women in tech is demonstrably not done by just getting to more girls. Loss of women in tech happens with drop offs during CS courses & majors in college and then also out in the tech workforce because it’s a toxic and imbalanced place for them to spend their time and energy.

All this money thrown at adorable girls, creating projects for them will not help if they are being set up just to go into that existing environment. While we should do outreach and attempt to build educational parity for girls (but more importantly kids of color, kids living in poverty) so that there is exposure and understanding of the technology the REAL problem to solve is how to get adult women (and other underrepresented people) re-trained, supported and encouraged to take on roles in technology NOW.

While we’re at it, stop acting like only a CS degree is what makes someone a valuable asset on tech (pro-tip: many people working in tech came to it via liberal arts degrees). Make the current adult tech world a welcoming place for everyone – then you can send in the next generation and so on without losing them in the leaky pipeline a few years in.

Ascend Project Kickoff

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.

Applicants will go through several steps before we whittle down to our final 20.  There will be an expectation that they can complete the highest level of a free, online Javascript course and the Mozilla PDX office will hold drop ins with computers available to help applicants have the time to do this with the right equipment and a mentor or two nearby.  Following that stage, we’ll ask for an essay or video that briefly describes a ‘hard’ problem the person had to solve, if they were successful what worked and if not what didn’t.  Staying away from specific, alienating technology language seems key here. We need problem solvers and self-starters, not people who know syntax (yet).  That group will then be the pool from which the final participants will be selected from, with specific ratio targets for populations that I mentioned earlier.

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.