# The Public Lab Blog

stories from the Public Lab community

# What questions will you bring to the Barnraising? (Part II)

by warren | 10 months ago | 0 | 3

The Barnraising starts tomorrow morning! We're all super excited.

At the past two Barnraisings, in Morgantown, West Virginia ( #west-virginia ) and in Cocodrie in November 2016, I was able to interview and video folks who came, and ask them what questions they brought with them. This post is a continuation of my last, featuring Barnraising attendees -- and we're about to start this year's Annual Barnraising in Cocodrie!

Last time, I mentioned why I like this format:

I like asking this question because many people come with a specific need in mind, hoping to find someone from the diverse Public Lab community that may be able to help, and some come with knowledge, skills, and capacity -- and I'd wager that most people come with both of these! But finding ways to exchange knowledge, and support one another, is one of the keys to making an event like this work.

We've been sharing these with the tag #barnraisingQuestion on Twitter and Instagram. Please reach out with your own questions as you arrivein Louisiana today!

### Leslie Birch

Hey, I'm Leslie Birch, I came from Philadelphia, and I was really excited to come to this particular regional barnraising because I'm interested in the problem of fracking that's going on because it obviously affects Pennsylvania as well as West Virginia. My big question is: is it true that they're using radioactive isotopes as tracers in the process of fracking? I'm still waiting to get that answer, but I'm excited about discovering it. I'm also wanting to figure out how I can use art and my knowledge technology and hardware to better communicate the problems that are going on in these ( @zengirl2 )

### Matej Vakula

Hey, I'm Matej Vakula and I came here from Brooklyn -- I'm originally from Slovakia. I came here with a question of how to build infrastructures for sharing knowledge, and for knowledge production -- how to produce knowledge. ( @matej )

...

### Ryan Covington

I'm Ryan Covington, from Washington DC. And the one thing I wanted to get out of the barnraising was to figure out how myself and the organization I work for, Skytruth, a small technology and conservation organization in West Virginia, can more broadly distribute our expertise, and satellite imagery and digital mapping to Appalachian communities and advocates that need it.

...

west-virginia cocodrie barnraising blog

# Software outreach: a blog series

by warren | 10 months ago | 0 | 3

Since early 2016, Public Lab has worked to make our open source software projects more welcoming and inclusive; to grow our software contributor community in diversity and size. This series collects some of those strategies and initiatives.

I've written a bit before about software outreach at Public Lab, but I'm interested in taking a broad overall look at the specific strategies we've developed, borrowed, and built on since around April 2016, when we started this initiative. This will be a series, and I'll be collecting resources on this page. (Above: GitHub profile icons of some of our contributors)

What's this series for? A set of experimental new strategies and patterns for outreach have emerged over the past 2-3 years which are rapidly changing the landscape for newcomer engagement. I'm excited because they hold promise for more welcoming (and technically superior!) project growth which also support more diverse and equitable communities.

### Starting point

We started out pretty "stuck," like many open source projects. From 2010-2016, we had only 16 contributors, total, 6 of whom were part of our Google Summer of Code programs (today we have over 100; we're still a small project, but growing fast). Our code was byzantine -- not because we were terrible coders, but because we were all busy, and we put new feature development before all else. Documentation, code cleanliness, install process, and even updating to the latest versions of our dependencies, all fell by the wayside as we made pragmatic decisions -- after all, I was the only consistent long-term developer, and I had something like 1/3 or 1/4 time devoted to this.

Our first foray into better onboarding was led by @justinmanley, one of our earliest and best GSoC contributors, who wrote this excellent post on how to reform and improve our code and outreach strategy. He did a huge amount to rework our code and systems to set us on the right track. With his help, we were ready for the next step...

### SpinachCon

Three events led to our completely changing our direction. First, SpinachCon (in 2016), hosted by Shauna Gordon-McKeon and Deb Nicholson, was a great -- and humbling -- opportunity to try to get our code to be installable by newcomers. We'd estimated 30-60 minutes, after much work (even worse, in the past our GSoC students had sometimes taken more than a day to get dependencies installed!). We found several people who couldn't install our code at all over a couple hours. We spent a lot of time after that to get the install process down below 15 minutes, with an install video and a standard install environment in a free VM service, Cloud9, and things have improved a huge amount since then. Without this initial step, none of the following strategies would have worked!

### First-timers-only

Second, in the spring of 2016 I attended a fantastic set of talks at BostonJS, which highlighted both the need for a wider conception of who contributes (including issue creators, commenters, etc) and, from Gregor Martynus of the Hoodie project, a whole new framework for thinking about building a contributor community. Click the link above to read more, and I'll be writing more about this soon, but I learned about the First-Timers-Only "movement", and really loved Gregor's attitude of "rolling out the red carpet for new contributors."

### Diversity and project growth

It really seemed to me that Hoodie might even be more interested in recruiting and welcoming newcomers than in actually writing code! I was game -- writing a first-timers-only issue usually takes longer than solving the issue yourself. It's aimed at inviting someone new into the project, using a small but substantive issue to be solved as your initial point of collaboration, and as the start of a conversation and a relationship.

But I was wrong about one thing; as I learned in the coming months as we adopted this approach, a focus on first-timers really is an investment in the long-term growth of a community, both in size and diversity. It's a commitment to supporting people to take their first steps, but it recognizes that it takes work to do so, and that this work is totally worth it.

And in my mind, it emphasizes equity and diversity as core values, not only because they match our personal values, but because we recognize that they are fundamental to improving our work and ourselves. At the recent Google Summer of Code Mentor Summit, one thing I really appreciated hearing from a few people was that diversity was important to the success and growth of their project -- to incorporate new ideas and perspectives, and to be shaped -- transformed -- by them. It's a relief to hear people acknowledge that they're not just looking for someone to type out some code, but some insight, some human qualities, that they can't achieve without diversity.

### Transformation

So, before we start diving into the actual strategies in subsequent posts, I'll say that one thing I've learned is that doing good software outreach means acknowledging that your own work must change. Not only in shifting from direct coding work to organizing and cultural work, but also in transforming your own coding style and even your project architecture (see Modularity, in an upcoming post) to make it easier for others to enter into your work and work with you. Good outreach will make you a better coder!

So thanks to everyone who's helped make this journey possible! I'm sure I'll be naming a lot of amazing people and projects as this series develops.