stories from the Public Lab community
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!
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 )
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 )
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.
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.
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...
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!
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."
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.
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.
Up next: Friendliness, codes of conduct, and first-timers-only. Read more of this series on this page.
Also: do you have ideas or suggestions? We're seeking submissions for this series -- leave a comment or reach out to email@example.com!
Lead Image from YES! Magazine
It seems fitting that the last interview we did in this series was with Yvette Arellano of Texas Environmental Justice Advocacy Services (TEJAS). TEJAS is a Houston based organization. They are a small, but extremely mighty Environmental Justice group. With just five staff, they’re one of the most well known and respected organizations in the field. In their work, TEJAS is “dedicated to providing community members with the tools necessary to create sustainable, environmentally healthy communities by educating individuals on health concerns and implications arising from environmental pollution, empowering individuals with an understanding of applicable environmental laws and regulations and promoting their enforcement, and offering community building skills and resources for effective community action and greater public participation” (http://tejasbarrios.org/about-us/).
This interview was conducted in May, well before the tragic and terrible events of Hurricane Harvey. There is no doubt the events of Hurricane Harvey have stretched this group thin, and strained their many community constituents. TEJAS- Yvette and Deyadira Arellano, Juan, Ana and Bryan Parras, you and your community are in our thoughts. In solidarity.
When it comes to community organizing, anything from individual walking into the office, to funds to help us get the work done. We’re hoping there are young people looking to come in and help us with capacity for things like social media, and keeping the website up to date. We’re also looking for capacity through collaborations with schools, scientists, academics. We’re ultimately hoping to get more information out at a faster pace.
Also funding is a big one right now-- everyone’s crunched under this administration. Before we could count on federal funding, but now our organizations are trying to go after scraps that are left. Bigger organizations can see people laying down funds to support their work because they see what’s happening, but that’s not always the case on the grassroots level.
We just got done working over past year with project with the Union of Concerned Scientists -- it’s a massive network with nothing but capacity. Together we got out the Double Jeopardy in Houston report.
The beginning of year was tough. We checked EJ Screen for missing information and the site went down for a solid week. It was a huge concern. We reached out to USC friends, they called up the ladder to ask why there was so much missing information. We also reached out to our friends in EJ community who gathered together and helped us download information from EJScreen and the Toxics Release Inventory so that we had it.
National Air Toxics Assessment is the most comprehensive source of information on cancerous toxins and amount of cancer on different parts of the country. It comes out once every three years, but it just released information in January regarding results from 2011. We went before NEJAC (The National Envioromntal Justice Advisory Council) and asked the EPA to have a more solid schedule for the data release for NATAData because we need it.
Different databases give us information that help us with our work. The TRI data (The Toxics Release Invintory) is the one that comes out the most frequently- annually. The National Emissions Inventory comes out every three years. Where TRI tracks what’s reported to come out of the stack, the NEI tracks fugitive and stack emissions. If there’s an accident - stuff that’s not supposed to come out NATAData grabs that all and pumps out numbers. ECHO (Enforcement and Compliance History Online) is a solid basis for grassroots groups to know what has been done and help community members. Finally, EJ Screen helps translate this all into graphs, and common language.
They’re technical. EPA has addressed this by telling grassroots groups, or anyone, that there are technical assistance grants to help people. So you have to apply for a grant to get someone to translate it out of the technical jargon - and this is for a public database. It’s unfair.
Just like anybody else - social media, email, news, and conferences. We also get together and share from our communities through regional meetings and phone calls. We also get out and do the old school block walking.
Navigating datasets and databases with older people who aren’t used to it is challenging. Also translating from English to any other language is something that’s a barrier as well.
Yes, 100%. I think working with different organizations from different backgrounds and populations is important. We need to be able to communicate with their groups, and they with ours. We have more experience with these issues when we work together so we need to make a vast network of people to deal with these issues.
Ideally, I would want to be able to piece the puzzle together faster. Pipelines through Illinois are going to connect to Texas and to Louisiana refineries. That’s very similar to so many parts of the country. Across region or nation we have these joint issues. We could work together. We could reach a solution together and create mass momentum across a nation.
I see the space being populated with scientists -- that’s new, we’re not used to scientists and academics opening their eyes and seeing challenges our communities face. Opening that space and really uplifting that message against the administration. We need legitimacy as grassroots organizers. We’re not seen as having the most legitimacy, but when scientists come in and support our message with data it’s really helpful. It’s also really important for young environmental justice organizers to connect with elders. We live in age of technology. If we can’t share those skills, we’ve already lost.
You’ve probably already heard this. Jemez principles of engagement. Environmental Justice principles are about being open and inclusive. Letting people -- community -- speak for themselves. Committing to self-transformation. At the end of day, we’re struggling, and we should be aiming at a joint approach. There is power in numbers.
End of inteview
Thank you Yvette!
It has been a wonderful journey learning from amazing grassroots and environmental justice organizers over the past several months, but that learning doesn’t stop with the end of this series. I’m wondering for those who have read and followed along:
Note on Harvey Recovery: You can support TEJAS in response to Hurricane Harvey by donating to A Just Harvey Recovery Fund here.
Other avenues to share and help on Public Lab:
**This post is part of a series with Grassroots and Environmental Justice Community Organizers. Read more on the series here or follow the blog tag to get updates on new posts.
Lead image from the StarTribune, photo credit Brian Peterson. An uncovered frack-sand stockpile (“Mount Frack”) in downtown Winona, 2013. In the background is the historic Winona County Courthouse. (After large demonstrations and direct action at Winona’s City Hall, the city finally reacted to the citizen’s demands and required the carcinogenic frack sand to be removed.)
The frack sand industry (sometimes spelled frac sand - sometimes considered the industry’s spelling) is one of the lesser known dirty supply lines of the oil and gas industry. “With the massive adoption of hydraulic fracturing and horizontal drilling in the U.S., round silica sand is needed as a ‘proppant,’ a material used to prop open oil and gas-bearing fissures while also allowing gas and oil to escape.” (read more on the history on the Frac Sand wiki). For many years Wisconsin and Minnesota, among other midwest states, have been the victim to the oil and gas industry’s long and vicious assault on natural resources through the frack sand mining industry. Think of the lands where Aldo Leopold wrote the famous Sand County Almanac. These are the beautiful places that have been pillaged. Hills have been flattened, rivers have been silted, farmland have been destroyed, livelihoods have been threatened, and human health impacts have been disregarded.
But out of this chaos and injustice, again we find incredible people who are working together to bring light, and fight back. The interview below is with Jim Gurley, one of many we have to thank for their hard work against the oil and gas industry on the Midwest front.
I split my time between two issues: frack-sand mining, since 2011 with CASM, (Citizens Against Silica Mining) and exploding oil trains, since 2014 with CARS-Midwest, (Citizens Acting for Rail Safety). I’m also active with LSP (Land Stewardship Project). I also plan to help as an organizer with Our Revolution-Minnesota. The groups I’m a part of have not done much fund-raising. We’re all volunteers, except for a staff member or two at LSP. So financial support is not something we have focussed upon.
For rural issues in our county, we lobby for support from our county board of commissioners. The only way we were able to secure a ban in our county on frack sand mining operations (the first and only such ban in the U.S.) was because we spent a lot of time, energy and money (we did fund-raise for that campaign) to get one of our CASM members elected to the board. She won and replaced a pro-sand person, who was a lifelong resident of Winona, and was a TV and radio news anchor with virtually 100% name recognition. Her win was extremely important -- it helped us get the ban (flipped the majority on the board from 3-2 pro-sand to 3-2 against) but also provided the first and only “referendum” of sorts on the frack-sand issue, so we had something tangible to point to when discussing public opposition to the mining. Frack sand is a dangerous carcinogen, so we are interested in low cost monitoring of dust, and ways we can measure particulate matter around the seven frack-sand operations in the city of Winona.
In CARS, we seek and get support from public officials at all levels, and we have networked with other groups who are fighting oil trains throughout country. Those sorts of connections are important. Perhaps the most important support we look for is from local citizens who write Letters to the Editors, come (and sometimes speak) at hearings, attend our meetings, march in direct action, etc. “People power” is our most effective and valuable resource.
Several CARS members attended the Oil Train Response conference in Pittsburgh, and that was very informative and good for networking. The human capital of good researchers in our own groups, as a resource, is key for us. Working with the staffs of senators and congressmen has been somewhat helpful. The Crude Awakening network holds a national conference call every few weeks, and that allows us to get good and timely information about victories and bad things around the country. We need to bolster ourselves and each other and take time to celebrate and integrate the victories that we do have. Connection with others is a reward.
In our frack sand group, some members are not on Facebook, and a few don’t have email. So we use phone calls and emails. Short emails are good, but group email discussions (which can easily devolve into what I call “e-maelstroms”) are challenging. Emailing information prior to meetings allows informed comments at the meeting. In-person contact is paramount.
Someone with expertise willing to visit and address our group is a great way to learn. We’ve also sent a representative to workshops and seminars. One important thing to me — as both a listener and a presenter -- is to be able to clearly hear and understand the person speaking (particularly considering that many volunteers are elderly and hard of hearing). Testing acoustics and microphone ahead of time, and asking at the beginning of the presentation if folks can hear, can make all the difference. It also helps in getting good audio when we are video-recording an event.
New social media platforms are challenging. I and others find Facebook to be useful, but not all of us are on Facebook. We've found language barriers. Reading something that is above our skill level containing technical jargon is difficult; e.g., reading an industry journal is sometimes hard to “translate" into vernacular English in order to report about it to the group. This also happens when working with scientists, or people who have a specific expertise. Articulating scientific ideas in layman's language is a skill and talent that should be cultivated by those who wish their knowledge to be widely understood.
Working with a diverse group of people (geographical, gender, racial, ethnic, education, political party, age, etc.) gives us complementary skill sets and perspectives. We need to have folks who like to make phone calls, others who like to do on-line research, others to write op-eds, etc. Bringing people together from different political backgrounds is challenging, but important and potentially rewarding in the long-term, if we are sincere and honest and open-minded. Having a wider group or network of people who could be resources to each other and develop a broader expertise would be great.
I would like to engage with (and educate) elected officials about environmental issues. They often are well-versed in how to create jobs, but they need to be at the table to learn about environmental issues and the consequences of the job-growth they advocate. It would also be useful to have academic folks there, but so far, few academic leaders at public universities have been willing to help us in a public way due in part to pressure from the state. Last, scientists and activists sharing a space where they could share with each other what they’ve learned could be really useful as well.
Tolerance, patience, and focussed listening are important values. Sometimes people new to activism may be turned off if someone is impatient with them or they don’t feel welcome, so having a welcoming culture is paramount. Follow-through is also key, and it’s healthy for a group to respectively hold members accountable for what they have promised to do. On a mechanical level, ground rules and an outline of shared expectations can help protect these spaces.
In physical shared spaces, welcomers at the door are helpful. Also, we need to be intentional about celebrating our victories, and to avoid getting too intense at meetings. We need to be able to laugh at ourselves and be lighthearted at times. Otherwise, stress and the resulting burnout can hurt our efforts.
End of interview
Thanks again Jim! Hearing about your work is truly inspiring.
**This post is part of a series with Grassroots and Environmental Justice Community Organizers. Read more on the series here or follow the blog tag to get updates on new posts.
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.
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.
With this in mind, I’ll be sharing these every week or so in batches, here and on Instagram and Twitter with the tag
#barnraisingQuestions. And please reach out with your own questions as you draw up your plans for this November 3-5 -- we hope to see you in Cocodrie, Louisiana!
My name is Mirijana Beram and I live in Doddridge County West Virginia, and my question is: how can rural communities fight the Man and win?
One question that I've brought to this year's barnraising is: How can we help the West Virginia community develop more green infrastructure and deal with the contaminants they deal with here, as far as air quality and water quality.
Hi, I'm Laura, and I came here today wanting to know more strategies for how to use aerial photography and drone imagery to chronicle infractions in mountaintop removal and to tell stories.
Hi, everyone! This past week we wrapped up our fourth year of Google Summer of Code (see #gsoc), a Google-funded summer program for students to get paid to work on open source projects. I'll be posting more thoughts as we go, but I first wanted to thank the amazing team we had. We had -- counting mentors, coaches, etc -- 17 people involved in this summer's work. (We're also wrapping up a Rails Girls Summer of Code soon -- many thanks to that team as well!)
From @stella's Email Notification Overhaul:
From @Ashan's Wiki Discussion:
From @mridulnagpal's Map of Projects:
From @ryzokuken's Bot for Publiclab:
From @ccpandhare's Developing Image Sequencer as a Library:
Our mentors were: @david-days, @icarito, @stevie, @liz, and thanks especially to our past GSoC students who were mentors this year, @Ujitha and @ananyo2012! We really could not have had this amount of success without you.
I just wanted to say that, although we've has some amazing summers in the past, this summer was once again our most successful summer yet. I think our continuous refinement of the planning process and how we run our unique Summer of Code process has really grown and allowed us to have:
You can read more of the specific highlights of our projects on the most recent Web Working Group update. But I wanted to share some of the reflections, advice, thoughts, and ideas I've had over the course of this unique summer. I wrote some of this into each of your evals, but without sharing feedback specific to a given student, I wanted to share my notes. Apologies to non-coders if they're very software-oriented, but I think some of these apply to non-coding projects too!
To students who are approaching the end of their projects, an important step is re-assessing what's left, and what they can finish up in the remaining time. But rather than considering any unfinished pieces "missing", it's great to take them as an opportunity to invite others into your projects, by turning them into well-documented issues on your project repositories.
If you offer enough context, you should be able to recruit people to take up the remaining tasks once the summer ends, and whether or not you continue work afterwards, folks will be able to carry your work forward. This may mean writing a first-timers-only issue, for example, to welcome a new coder into the project.
Mentors: I think it's great to encourage students to document their work (and what's left to do) as issues that are up for grabs. It's better for morale to plan ahead for other people to pick up where you left off, and to think about your project living on, than to focus on asking them what they didn't do! And it's better for the project overall anyways!
Ask students to write one new issue per week **for someone else**, which helps them think in terms of how others read their work, and encourages them to break up projects into smaller parts that newcomers can tackle. Good code is modular, not a spaghetti -- and looking at it from the outside is a powerful way to improve your planning and style.
Over the course of your work, you've all become leaders in this community through your work, your collaboration, and your major contribution to the platforms we use at Public Lab. Take a look at this page for some ideas on how you can ensure your projects live on: https://github.com/publiclab/plots2/projects/4
I think asking or even requiring projects to have "onboarding" or "first-timers-only" tasks during the recruitment phase can help improve the overall success of the project and ensure project teams are giving students the support they need early on. This also helps ensure that students have installed everything and gone through the "PR merging" process before they even begin work!
Start your summer by thinking about building a team by inviting others into your work. It's a key skill for any software developer, and it's never too early to think about documentation, or about designing for reuse and for other coders to read your work. As someone who's probably just gotten the project installed and set up, you're also uniquely equipped to guide others through that process! And it's a good habit both for yourself (to break down and articulate problems in writing) and for future coders. Here's a guide to writing issues for newcomers:
Towards the end of the summer, begin to consider how other people (who program) will use your work. Will they understand how to install it? How to adapt it to their own uses? Will they have trouble setting it up, or be confused at how things are named or organized? What can you do to make it easier for others to pick up your work and use it? A good demo? More clear documentation or examples? One great way to know if your work is readable is to ask one another to read it over and provide feedback.
Students love to make giant projects that are all intertwined, and it takes discipline to break things into small, testable parts. But be hard on the students early on -- resist the temptation to just say "code the whole thing up as fast as you can!" since it can really be worth the time to work with them to plan out and break down their work. It's much easier to build on smaller self-contained modules that are clearly tested than to sift through huge amounts of less structured code, whether it's the students themselves doing it or you taking over at the end of the summer. It's also just good coding practice!
Write a planning issue early on, based on your proposal. Take the overall goals and break them into parts small enough that you can merge them (with tests) into the trunk branch one at a time. Before a user-facing feature goes live, you can merge in a whole set of back-end functions which underpin it, and ensure they are all working in production before making the UI that exposes it to the public.
Break things into a checklist with "phases" and really modularize down into distinct steps as much as possible, like in this example:
It's a really great way to visualize your progress over the course of the summer, and a good first step to developing a milestones.
When students want to publish a public-facing interface (a new feature) but you're not sure it's perfect yet, allow them to publish it in a way that's hidden, so you can see how it does "in the wild." For web projects, only enable it if people add a
?beta=true parameter to the URL. For desktop projects, hide it behind a flag, like
--enable features. That way, they can break up the work into smaller parts, and can get feedback from the real community as they refine their work. Just be sure the flags are clearly marked and can be removed by another contributor later.
Do you have more to suggest? I'd love to hear your tips -- leave them below in the comments.