Author: Christie Koehler

software engineer, geek, yoga practitioner, bike commuter, zen buddhist, queer, vegan, legion of tech board member, osbridge planner, engineer@ShopIgniter

Valerie Aurora and a pattern of problematic behavior

The purpose of this post is to publicly document what I understand regarding the problematic behavior of prominent tech feminist activist and diversity consultant Valerie Aurora. It is not meant to be an unimpeachable accounting but more of a connecting of the dots and a conversation starter. The content here, in its most recent iteration, started as a thread on Twitter.

The timing of this discussion is prompted by two things:

  • The announcement of a book on code of conduct enforcement written by Valerie and Mary Gardiner and distributed under Val’s consultancy, Frameshift.
  • The banning of Valerie from Double Union, a feminist hacker space she co-founded, and her subsequent blog post on the matter (CW: transphobia, TERF).

Folks including Sage Sharp, Jade Ahking, and Liz Fong-Jones have spoken eloquently about why Val’s position on Double Union’s membership policy change is trans-exclusionary, transphobic, and otherwise problematic.

Were this Val’s only misstep, or one among a few over a handful of years, I would not be writing this post. Unfortunately, Val has demonstrated a pattern of problematic behavior towards several people over many years.

At least six people, not including myself, have stated publicly they were subject to or directly witnessed misconduct by Val. Here are some of those accounts:

(There’s one additional account I’m not referencing here until I am able to confirm the person is okay with me linking to their post.)

Other folks have long heard about issues others have encountered while working with Val, including:

Word of Val’s troubling behavior has been making the rounds via the whisper networks for some time. But whisper networks are dangerously exclusive. No one wants to interfere with the work of activists by needlessly airing our dirty laundry. However, I believe we’ve long since passed the tipping point where not talking openly about these concerns is doing more harm than good.

Val’s most transgressive behavior has been directed not at me but at others I know, some well and some less so. It’s taken a while to put together a complete picture of Val’s conduct. When I first started to have misgivings about her behavior, I wasn’t sure who I could talk to about it. She seemed to have such a respected role in the community and I had prior experiences of being shunned for saying “negative” things about others, no matter the context. I thought, if my misgivings were just a matter of differences in personality or strategy, I didn’t want to poison the well, so to speak.

But in the lead up to the Ada Initiative (TAI) hiring a new Executive Director and the subsequent aftermath of Val having that new ED fired and shutting down the organization, more folks started talking with one another. By this point in time I had already stopped directly supporting the work of the Ada Initiative, due in part to financial constraints but also due to significant misgivings about anything Val stewarded. After Val shut TAI down, I stopped recommending anything she worked on. If people asked I’d tell them I didn’t personally feel comfortable working with her because I did not trust her judgement or her approach. Since then, I’ve had the occasional Twitter rant about the poor governance and abuse of power demonstrated by Val’s shutdown of TAI.

The most important details of Val’s misconduct are not mine to share because I did not experience them directly. I will leave it to others to share their stories if and when they feel it is appropriate to do so.

What I can share is what I see as the patterns of problematic behavior I’ve been told about and in some cases directly observed. These include:

Co-opting situations for her own benefit. Taking disproportionate credit for the work of others. An example here is the work many in the Geek Feminism Wiki community did on the Conference Anti-Harassment policy that, once the TAI was founded, Val rebranded as being of TAI origin. She even went so far as to go to folks who had adopted the Citizen Code of Conduct and told them that was actually the work of TAI and to change their attribution. (The Citizen CoC includes text from the original GF wiki text and is attributed as such.) The incident with Violet Blue could be considered an example of her co-opting a situation, among other things.

Being unable to listen to and incorporate valid criticism and change her behavior accordingly. Deflecting and avoiding accountability. The situation with Double Union is a good example of this. So is everything having to do with the end of TAI (see Heidi‘s post, also linked to earlier, for a good summary; the Wikipedia page for TAI also has info and links). I have heard a number of stories of Val responding to criticisms of her behavior by blaming the other person. Want a recent example? Take a look at this not so vague tweet posted right after she started receiving flak for her post about Double Union.

Abuse of power and position. Self-serving governance decisions. Again, see everything having to do with the shut down of TAI. Val orchestrated the release of the qualified executive director selected via a rigorous committee-led process. I know this was not a decision supported by the majority of those in governance positions at TAI by the exodus of folks from the board of directors and advisory board at the time. I don’t know the details of how she dispensed with those who did not support this power grab, but I know from the little others have shared that’s what it was. I believe we need leaders who can tolerate not being in control all of the time, who are team-players and consensus builders. Val has demonstrated the opposite of this time and time again.

Disingenuous communication. Attempting to manipulate others. See the end of the Ada Initiative. The reasons given for the shutdown were not truthful. And still Val managed to orchestrate a good amount of positive press. See her blog posts about being banned from Double Union. There’s loads of other examples in Val’s personal communication with others, some of which has been shared with me.

Non-intersectional and trans-exclusionary approach to feminist activism. See Sage’s and others Twitter thread for examples, linked to earlier.

Threatening and using her social status to isolate folks who raise concerns about her behavior. I have heard about this pattern from a number of folks and it is perhaps the most troubling aspect of all her problematic behavior. I believe it is the primary reason people have gone so long without talking about these issues and also that it has done the most damage to the targeted individuals.

It’s my understanding that Val’s problematic behavior goes back many years, prior even to TAI and to my coming to know her around 2010/2011. I have heard from folks who worked with Val at Sun and have heard rumors about her role in LinuxChix troubles, for example.

My goals in publishing this post are:

  • Informed Decision-making. I want folks to have sufficient background such that they can make an informed decision about working with Val and/or consuming her work product.
  • Harm Reduction and victim support. I want folks who have been subject to Val’s misconduct to know that they aren’t alone, it’s not them, and to have access to a support network.
  • Setting context. I want folks who go to Val for subject-matter expertise regarding diversity & inclusion and governance (code of conduct enforcement) to understand her history with the communities she purportedly serves and the kind of feminist activism she engages in.

Ideally this post would also prompt Val to engage in a genuine accountability process regarding her behavior, but I think that is unlikely and it is not one of my motivations or goals.

What I do not want to have happen as a result of this post:

  • For Val, or anyone associated with these issues for that matter, to be harassed in any way, shape, or form. No dog-piling should occur as a result of this post. I do not wish Val to experience any harm, physical, emotional, or otherwise, for any reason. Note: Discomfort is not the same as harm.
  • For the larger work of the Ada Initiative, Double Union, or any other projects Val has been involved with to be discredited. Many folks have contributed to the work Val has been a part of and I have great respect and appreciation for their contributions.
  • For tech feminists who make genuine attempts at intersectional and trans-inclusionary approaches to be maligned. We should not discount an entire movement due to the misconduct of one person.

Feminist leaders that engage in abuses of power and distortions of the truth raise concerns beyond matters of disagreement over tactics. These “ends justify the means” approaches do active harm. I don’t know the best way to stop abusive behavior by feminist leaders such as Val. I may be doing it the “wrong” way and I’m open to feedback about that. But doing nothing or being super circumspect just isn’t an option for me any longer.

I personally wish Val no ill-will. I just want her to stop hurting folks and to prevent the further institutionalization of her anti-community, trans-exclusive, non-intersectional feminism within technology communities. (See this thread for a good explanation about how this happens and the harm it creates.)

If there’s anything you’d like to share about your experience working with Val, please get in touch. You can email me ck at christi3k dot net, DM me on Twitter @christi3k, or Signal message me (contact me another way to get this number). I’m happy to update this post to share your experience, or just to be a sounding board if you need someone to listen.

10 Years of Open Source Bridge

The following is the text of the keynote I gave at this year’s grand final for Open Source Bridge on 29 June, 2018. See also Audrey’s post Saying goodbye to Open Source Bridge.

Opening

10 years ago planning for the first Open Source Bridge began. 10 years later we are kicking off our 10th and final event, here, together.

10 years is both a very long time and no time at all.

Think back to 2008. George W Bush was President. The primaries had concluded but Barack Obama had not yet received his nomination. Most open source projects hosted their code on Sourceforge or Google Code or a self-hosted solution. GitHub was just a few months old and most projects used Subversion anyway. Hardly anyone was talking about codes of conduct or how to fund or sustain our open source work. Both the Open Source Initiative and Mozilla had just turned 10. Microsoft was the sworn enemy of free and open source software. Nodejs was not yet a thing. The term “DevOps” was not yet part of our vernacular. RMS and ESR were the most well-known role models for our movement.

2008 is significant for me personally because it was my first full year in Portland, having moved here the previous Fall.

Portland Tech History

2005

To understand the origins of Open Source Bridge it’s helpful to understand what the Portland tech community looked like in the few years leading up to it. And here I must thank Audrey for the details I am about to share, for she has a good memory and a keen ability to connect and contextualize events with their larger meaning.

In 2005 Portland was still recovering from the post-9/11 recession, lagging behind other parts of the country. Community tech was represented by the Linux user group folks and Free Geek, which itself was an outgrowth of a local environmental and community building movement. Corporate tech was represented by the SAO, Software Association of Oregon (now known as the Technology Association of Oregon). There was also a wiki community growing out of the Portland Pattern Wiki lead by the inventor of the wiki, Ward Cunningham. It was during this time that Portland started to establish a reputation as an affordable Silicon Valley satellite.

2006-2007

In 2006, when Audrey started attending user group meetings and a year before I moved to Portland, there was no BarCamp Portland. No Legion of Tech, no Calagator, no IgnitePortland, no Open Source Bridge. CubeSpace hadn’t opened yet nor any of the dozens of co-working spaces we have now.

What did we have? Monthly meetings of groups like PDXPHP, Portland Ruby Brigade (PDX.rb), Portland Perl Mongers (PDX.pm), often at Free Geek (which started in 2000) or a local pub. There was the cross-technology groups like Portland Web Innovators. You learned about these events by running into someone who knew they existed. Finding groups and events at the time was mostly word of mouth. We had OSCON, an annual open source conference organized by O’Reilly media happening every July at the Oregon Convention Center. Various tech companies called Portland home or had offices here, some still in the process of recovery from the dot.com bust.

As OSCON approached, the conference chairs reached out to local contacts about doing some sort of community programming at the event. The previous year, PDX.rb had scheduled a “FOSCON” event one night of the conference, to provide a free way for local user group members to experience some of the Ruby content at the conference. Also, the Portland wiki community had just held an unconference called RecentChangesCamp, and there was interest in having some kind of open space at OSCON as a result.

While that discussion continued, PDX.rb members decided to go ahead with a FOSCON 2. It was a packed evening event at Free Geek with free pizza and several Ruby presentations. Meanwhile, the open space at OSCON idea turned into OSCAMP, a free unconference that ran during the day alongside the main event. A large sign on one wall, at the event asked people to contact Raven Zachary if they were interested in working on a Portland BarCamp.

Raven had just moved from Austin, and he liked the BarCamps he was involved with there enough to try starting one in his new home. This led to connecting with Dawn Foster, who had also been to the Austin BarCamp and offered to be a co-organizer for one here. Not enough people signed up to help plan in time for the intended date in August, so they decided to build up interest with a series of monthly meetups instead.

After an initial meetup at the Ram’s Head, Jive Software offered space to host these meetings, and this event helped form a core of the “Portland tech community” in the late aughts and early 2010s. Each meetup included a round of introductions: people would say their name and what they worked on, and often add details about whether they were new to town or looking for work. Quickly this became a mechanism to help people find jobs, which led to more people spreading the word about this being a great resource for anyone who had just moved here or needed to connect up with local employers.

By the following winter, enough momentum had gathered, and several people, including Audrey, stepped up to organize a BarCamp to happen May 2007. CubeSpace, a new coworking space stepped up to offer to host the event. It went well, with roughly 300 people attending throughout the weekend.

In June 2007, CubeSpace started offering free meeting space to local user groups, building on the good experience they’d had with BarCamp. Several groups moved in after some discussion, and the space quickly became a go-to resource for members of the open source community looking to hold meetings and events.

In the course of producing the first BarCamp, and Ignite Portland that fall, it became clear that there were limits to what an event without a legal or financial entity could do. There was no real way to handle money–we had sponsors pay directly for food and drink since we didn’t have a bank account. Dawn and Raven started talking about what to do to make the next events they ran work better, and along with Dawn’s partner Todd, came up with the idea to start Legion of Tech, a nonprofit.

At the end of 2007 the three of them invited several people to become the organization’s founding board: Audrey, Josh Bancroft (who helped set up that first Ignite), Justin Kistner (part of the social media/marketing community), Selena Deckelmann (also heavily involved in user groups, like Audrey), Adam Duvander (one of the PDX Web Innovators founders), and Paul Biggs (who worked with Dawn at Jive).

Also in 2007, Rick Turoczy started Silicon Florist, a blog about Portland startups, community events, and other highlights from the local tech scene. This created a central point for discussions about what we were doing or wanted to work on next, something that contributed further to the sense of cohesion in the growing tech community.

It was around this time, in Fall of 2007, that I moved to Portland. I went to my first user group the same month I arrived, an early Code ‘n’ Splode hosted at CubeSpace. Here I met Selena and Gabrielle Roth who were running the group. I also met Randal Schwartz who was inexplicably at this meeting for women in tech. I remember this not because I knew who he was at the time but because he gave me a hard time when I said I was a PHP programmer, something which Selena and Gabrielle made a point to tell me after the meeting was not okay and would not happen again.

By this time it had became clear to Audrey that the community needed more tools for organizing what was going on. In response to conversations at BarCamp and user group meetings, she set up a PDXGroups wiki and a Google Calendar to track everything that was happening, and enlisted several people who had expressed interest in organizing this information to help out. This worked for a little while, but over the course of the year they started to see the gaps in the plan: getting people to add their group to the wiki was relatively easy, but the calendar required manual authorization of each and every maintainer’s account. Keeping an up-to-date event calendar proved to be time-consuming and unwieldy.

2008

As Legion of Tech plugged away at organizing community-wide events in 2008, the range of activities continued to grow. CubeSpace offering free meeting space contributed to a burst of user group activity. Sam Keen started a pair of events called the Winter and Summer Coders’ socials to give user groups a way to connect with each other twice a year. It was all getting pretty intense.

In January 2008 Audrey sent out a call to action to do something about the “event calendar problem”, emailing all of the community members she could remember having discussed it with so far. She set up a mailing list. After a couple of weeks of discussion they had our first meeting. Incidentally, still very new to Portland, I joined the mailing list thinking it was the tech calendar, rather than a project to make a calendar. I was very confused by the postings at first.

That initial meetup is the day they started working on Calagator. They continued to meet every two weeks from January through July, took a break in August, and came back for semi-regular code sprints until spring 2009, when two things happened: several of us became involved in a new open source conference, Open Source Bridge, that needed its own software, and CubeSpace, our wonderful hosts, went out of business.

Unconferences proliferated in Portland throughout 2008. In addition to BarCamp, we had a WordCamp for WordPress users and developers, and a WhereCamp for geography geeks [8]. We were also having a lot of conversations about the side project problem: the tendency for Portlanders to have all of these fabulous technology projects outside their day jobs. Eva and David at CubeSpace suggested a Side Project to Startup Camp for people who might want to turn those side projects into businesses.

During this time I started becoming more involved in the community by regularly attending user groups and helping out with Legion of Tech events including BarCamp and Ignite.

Not long before that Side Project to Startup Camp was scheduled to happen, OSCON announced it would not be returning to Portland in 2009, cutting a hole in Portland’s connection to the wider open source world.

Selena seized on this as an opportunity to do something she’d wanted for a while: Start a new conference that would skip all the parts most developers didn’t care about, and be a fun, grassroots way for people to learn and connect. A conference by us and for us in a way a corp conference could not be. She had a wishlist she thought a community conference could do. Diversity. Ideas that became open source citizenship.

At Side Project to Startup, she held a session to discuss the possibilities, and by the end of the day Audrey had signed on to lead it with her.

Running a conference turned out to be a lot of work, even compared to the unconferences and other events they’d both been involved with so far. Selena and Audrey quit the Legion of Tech board at the end of 2008 to focus on getting Open Source Bridge off the ground.

2009

Audrey spent the first half of 2009 writing, writing, writing. Descriptions of the conference, of the types of content we were looking for, of what we meant when we said it was a conference for open source citizens.

“We’re planning a conference that will connect developers across projects, across languages, across backgrounds to learn from each other. We want people to experience something beyond “how to use tool X” or “why databases keel over when you do Y” (even though those topics are important, making up our tools and trade, and will be a central part of the conference content). We’d like to share what open source means to us, what it offers, where we struggle, and why we do this day in and day out, even when we’re not paid for it.

In order to do that, it seemed important to bridge the kinds of roles we have in open source, user/contributor/owner/institution, getting down to something more fundamental. What else are people who interact in this multi-directional way? Perhaps we’re citizens. Not residents—we do more than live here. We are, like citizens of a country, engaged in the practice of an interlocking set of rights and responsibilities.”

Selena reached out to everyone she knew throughout the open source world to get people to attend, submit talks, and sponsor. Igal Koshevoy and Reid Beels, who both worked on Calagator, spent many late nights getting OpenConferenceWare, our proposal and session-planning software, finished up in time for the conference deadlines. Several other community members (Rick Turoczy, Adam Duvander, Kelly Guimont, Jake Kuramoto) joined the planning team to work on sponsorship, marketing, and logistics.

I joined the team 6 or so weeks before the conference and took up organizing the volunteers. I also gave two talks that year.

Open Source Bridge year one, held at the Oregon Convention Center, was exhausting and fabulous and a success.

Three Phrases of OS Bridge

Looking back over the ten year history of the conference, there were 3 distinct phases.

Phase 1: 2008-2011

The first includes years 1 through 3 and was really about getting the basics down, establishing infrastructure including a stable business entity and venue host. It was during these years that we figured out how to do all the things that would make us last 10 years.

In fact, year 2 of the conference almost didn’t happen. Audrey was burnt out and had stepped away and although Selena stayed involved one more year, it was clear she was ready to pass the torch. We chose a venue that was expensive and unaccustomed to working with a scrappy group of tech folks with little money and comparatively weird ways of doing things. You want to park a housetruck in our courtyard? And the next day you want to add a donut truck? No, you can’t attach WiFI access points to our statues. Oh, and by the way, those 20 cases of Yerba Mate you were gifted can’t come into the venue.

With the original Open Source Bridge foundation having been shut down, we used an out of state fiscal sponsor who provided us with banking services but little else. We pulled off the conference but it was a struggle and many folks who helped that year did not return.

By this time I felt heavily invested in the community and what we were building. I found our eventual home here at the Eliot Center just days after signing the contract with the art museum and I very much wanted to see what we could do with the conference center in this space, in partnership with First Unitarian. So, I stepped up to chair the conference to ensure there would be a year three.

2010 was a busy year for me not just because of Open Source Bridge.

Early that year I joined the board of Legion of Tech, the organization that had been formed to support BarCamp Portland, IgnitePortland, and other activities. In the Fall of 2009 Legion of Tech revealed that one of its board members had been discovered to have embezzled about $30k from the organization. That I chose to join the board after this occured and ended up being the one to lead most of the cleanup shows you just how much love and energy I had for the community then. I still have as much love but oh what I wouldn’t give to have that energy again! The way I have to manage my time and energy now, approaching my 40s is so different from when I was approaching my 30s.

While the embezzlement issue was resolved, as much as such a thing can be, by the end of 2010, relations between the community and Legion of Tech were poor. People didn’t trust us, rightly so, and it was hard to fundraise. I felt we couldn’t carry out our mission, and the work that I wanted to do, effectively within the structures and history of that organization.

At the same time, the deadline was approaching to open registration and pay deposits for Open Source Bridge and we needed an organization and a bank account in order to do that. So, I approached Audrey and Reid about starting a new organization, the Stumptown Syndicate. The idea was that we would take all the lessons learned from organizing over the last couple of years, and through the missteps of Legion of Tech and do it the right way this time. We’d create a fiscally responsible, long-term home for all these community organizing and events projects we were involved in. Legion of Tech wasn’t defunct yet — but I felt it was likely headed that way and if we did things right the Syndicate would be able to take on its programs if and when that happened. Audrey and Reid were on board and we incorporated the Syndicate in December 2010 which enabled us to pay the deposit for our first year at the Eliot Center and open registration for year three.

Phase 2: 2011-2014

Thus began the second phase of Open Source Bridge, years 3 through 6, from 2011 to 2014. Looking back these feel like peak years for the conference. We had the Syndicate and were building upon a solid foundations. We really knew how to organize a 4-day multi-track conference. Companies were interested in sponsoring us and did so readily. We saw lots of communities come together and click at our conference. The Geek Feminism, AdaCamp, Wikimedia, Mozilla, and IndieWeb communities. We grew into our new home here at the Eliot Center and into our new partnership with First Unitarian Church. We experimented with different aspects of the conference, removing what didn’t work and a trying new things to find out what did. We improved diversity, inclusion, and accessibility. This is the period where I think Open Source Bridge became known as a queer social justice kind of tech conference. Then and to this day this makes me immensely happy and proud.

I’m going to pause here in 2013 for a moment to talk about year 5 a bit. Not only is the 5th an anniversary of most things a significant milestone, but it was also a very bad year for a lot of us. Personally I was dealing with chronic illness and significant elder care and drama. As a team we were faced with the death of an integral team member.

Igal died in early April, 10 weeks before Open Source Bridge was scheduled to begin. Contracts had been signed. Tickets had been sold. We had to notify speakers and publish our schedule.

We had no choice but to move forward. To make the conference happen. To help settle the affairs of our friend. To navigate our grief. And, most of us had day jobs and families to attend to as well.

We managed to keep the conference more or less on schedule. Open Source Bridge year 5 happened. It went as well as it ever had. We had a big party at the Oregon Museum of Science and Industry where we celebrated our 5th anniversary and we celebrated Igal.

I’ve tried to figure out exactly how we kept everything moving.I don’t have a clear answer. It appears we just did by doing what we always did — plan the conference. I looked through the archives for our email planning list. The messages don’t look substantially different from any other year. We cancelled exactly one planning meeting, the week of Igal’s death.

I think we were able to do this because we had a lot going for us, relatively speaking. It was year five of the event, not year one or even two. We weren’t in a significant transition year in terms of team members. And our core team was and is really dedicated.

We also were supported by the Portland tech community at large.

While we planned our conference, we also organized a celebration of life for Igal. This is how I learned that it turns out a lot of the skills you use to organize tech events also apply to memorials. As they often did with so many of our events, the Portland tech community came together to help. The folks who we’d been convening with for years at barcamps, user groups, and other events pitched in here and there, in small and big ways to help make Igal’s celebration happen.

I mention this in some detail because for me it was a turning point. It made me realize that part of what drives my connection to the community and the work I do for it is my hunger for fellowship. For coming together in the good times as well as the bad times and supporting each other, being with each other, learning from each other.

Phase 3: 2015-2018

The third and final phase, 2015 to now, was a winding down from this peak. To say we lost momentum is true but doesn’t tell the whole story. By this time things in open source and the tech community, both local and wider, were really different.

We had more tech companies with funding trying to higher technologists. We had more and more people moving to Portland. By this time numerous code schools had expanded participation in the tech community. More and more user groups sprung up to meet the needs and interests of these newer, different audiences.

Also by this time I think we can say open source had become fully assimilated into business. Adoption was no longer the goal. That had been achieved. We were starting to that access and even ownership of the code is not where the true financial leverage lay but rather in data and services and algorithms.

And, by this time GitHub had come to define open source participation. It’s hard to understate the impact this has had on open source.

If something is on GitHub in a public repo it’s open source. At the same time that more and more open source participation is happening in walled gardens. Shift away from wikis to google docs. From IRC to Slack. Open source has become a very literal definition and retains very few of the cultural aspects a lot of us were interested in previously. Open source doesn’t mean there is open collaboration. I experienced this very directly in my four years at Mozilla. There were near constant arguments between the different “generations” of open source folks about how to do it the right way.

Portland tech continues to grow but there remains a big disconnect between companies and the community. While writing this I found myself wondering, whatever happened to the diversity pledge all those companies signed? It’s my experience that companies are happy to pay for beer and scholarship tickets but won’t fund our work in general except in very small amounts. Not interested in being partners just in colonizing the space. If they sponsor at anything more than a pittance they want too much and they don’t defer to your expertise of what your community needs and wants. We stopped allowing sponsors to throw parties after the year a sponsor threw one that featured excessive drinking after which they and several other speakers were nearly too hungover to give their talks. Most folks organizing the conference couldn’t get explicit support from their employers for doing so, and as such most of the work has been done after hours or covertly during the day.

What I’m saying is that not only did it become harder and harder to continue putting in the second shift work the conference needed but it also became harder and harder to fundraise for Open Source Bridge the more and more mature it became. We were never great at fundraising but money was more available in middle period. By the time we got better at asking for money sponsor attention was elsewhere. It’s hard to raise money for a generalist event, particularly one that is no longer shiny and new. It’s even harder to raise money from corporations for one with a social justice bent that always prioritizes the needs of its constituents over sponsors.

This fatigue and difficulty fundraising affected all of the events we were doing. The last BarCamp Portland was in 2013. WhereCamp PDX 2015. IgnitePortland 2016.

On the positive side of things, in these later years we started to notice new groups building their own things based on same core values that we were trying to express. I think this is a good thing. It is a part of how movements are built and sustained.

By 2015 burn out was really starting to set in for me. I was no longer interested in hands-on event planning or running. In part this was due to the amount of crap you have to deal with as an organizer. Harassment from GamerGaters. Being dragged into vindictive lawsuits. Working with the health department when you have a salmonella outbreak at your event. People being mad at you for enforcing your code of conduct. The endless drudgery and paperwork of keeping a non-profit, even a tiny one such as the Syndicate, in operation. I was frustrated at not being able to implement the things we wanted to do with the Syndicate in our spare time while trying to have a life and with a full-time job. I was starting to realize the deep limitations of the non-profit, volunteer model.

I stepped down from co-chair role for 2016 conference and new co-chairs, Shawna Scott and Thursday Bram, stepped up and did a great job running the conference. I concluded my second full 3-year Syndicate board term at the end of 2016, leaving several new board members in place to lead things forward.

Shifting focus, shifting needs

Burn out was not the only reason I stepped away. Simple put, I could no longer do so much work for free. I also wanted to build community and experience fellowship in a way that looked less like my day job. I was wanting more social justice / activist / radical & resilient community building. The AMC conference in Detroit had become a great source of inspiration for me. The projects happening in Detroit that I learned about through the conference are more like what I want to be a part of here. They are decades ahead of where we are in terms of community organizing. This is borne in large part out of necessity and I am not sure the conditions exist yet in Portland for this kind of thing to occur. Much less interested in the politics of free and open source software at least in terms of adoption. Open source “won.” It’s everywhere. It’s become nearly synonymous with tech itself. I’m also at a point in my career where I’m maintaining more than I am building. I’ll spend my evening going to a user group if I need to for work, but no longer for fun or to socialize. I need that time for other things.

“Citizenship” as a word and a concept feels increasingly difficult to navigate. Were we starting the conference today perhaps we find a different term for the belonging, membership, and bidirectional rights and responsibilities we envision as integral to participating in open source. Perhaps had we not been mostly (all?) US-born folks with white privilege we would have picked a different term at the beginning. I don’t know. What I do know is that the questions and goals that concern me now are different from the ones of ten years ago. And I suspect the same is true for a lot of you. The stakes feel very different too.

Where do we go from here?

What I would like us to do together today during the unconference, before we celebrate this evening, is explore the concerns most pressing to us and to start figuring out what’s next.

  • How do we fund the tech that we need?
  • How do we continue the technology communities we need?
  • How do we connect with the people around us, technical and non-technical?
  • What do we want to be doing in 10 years? What do we need to be doing now to get there?
  • What would it mean for technology to change the world for good?

Accomplishments

Before I wrap up and hand things over to Kronda, I want to call attention to some things that we have accomplished together over these last 10 years of Open Source Bridge.

  • We put on 10 amazing conferences
  • Adapted and evolved the conference in response to the community
    • We added an extra day of scheduled talks but kept the unconference
    • We eliminated the expo hall and put that energy into making the hacker lounge awesome
    • Quiet room
    • Affordability
    • Diversity & inclusion
    • Food
    • Yoga! And other mind-body activities such as Geek Choir.
    • T-shirts for All
  • Open Source Citizenship Award
  • We were at the forefront of code of conduct adoption and enforcement.
  • The kinds of conversations we facilitate: cross tech, cross community, cross organization, infrastructure focus, social justice, humane tech.
  • We gave a lot of folks their first keynote opportunity and we paid them.
  • We gave a lot of folks their first speaking opportunity and provided a place for them to speak about things other conferences were not interested in.
  • We built a fiscally responsible, ethical organization, the Stumptown Syndicate.
  • We established and maintain a great relationship with our venue hosts First Unitarian.
  • We brought people together and helped enable them to build things they hadn’t been able to elsewhere.
  • We supported people through life transitions and career development.
  • We helped building connections among people who had common interests and values but hadn’t yet found each other in other spaces.

Together we created an amazing body of work that will continue to influence others. We should all be proud of this.

Acknowledgements

Thank you Audrey and Selena for starting this thing that became a huge, defining part of my life for the last decade. Thank you Reid for co-chairing the conference with me for 5 years and for being willing to start the Syndicate with me and Audrey. Thank you Shawna and Thursday for keeping the conference going after I stepped down. Thank you Holli Nicknair and all the Eliot Center staff for being amazing hosts and partners these last 8 years. Thank you to my beloved wife Sherri who not only brought yoga to every year of the conference but also set the standard for grassroots catering and logistics. Thank you Kirsten for running registration year after year with astonishing efficiency and for setting up the Syndicate’s books the right way during your time as Treasurer. Thank you Igal for everything that you did for the community while you were with us and for being my friend. I miss you. We all do.

Thank you to everyone who has been a part of Open Source Bridge over the last 10 years. And I do mean everyone. Speakers, volunteers, core team organizers, attendees, those of you who convinced your company to sponsor us. All of you, no matter how small your role may have seemed, it was essential and integral. It’s been an honor and a treasure to have shared this journey with you. I will miss inhabiting this space with you all for a week every June but I’m also excited for what we will do next together.

Thank you.

My theory: Patreon doesn’t want to be a money services business

tldr: Patreon is changing their fee structure, in part, because the batching of pledge payments from one patron to multiple creators and the use of Patreon balance to pay pledges without processing an external payment requires “holding funds in a balance that can then be redistributed” and makes them look like a money transmitter money services business, which makes them subject to additional regulation.

Also, if you want to follow my stream of consciousness thoughts on this, see this twitter thread.

Updated 9-Dec-2017 9:35 PST: Fixed a few typos.

Updated 11-Dec-2017 10:00 PST: At least one person has indicated Patreon might be using Stripe Connect and that would obviate any concerns with Patreon being a money services business. Sure, they could be using Stripe Connect. As far as I know that hasn’t been confirmed by anyone (let me know if you know otherwise). For the MSB issue to be of no concern, Patreon would also have to be using the equivalent service for PayPal transactions and they would have to be operating in compliance with both of those services. 

Patreon, a crowd-funding platform focused on serving creators of online content such as web comics, digital artists, writers, musicians, podcasters, etc., announced a new fee structure this week.

Many who use the service, creators (those who make content) and patrons (those who support creators with financial contributions) alike, are very upset about the new fee structure. Search Twitter for “Patreon” and you’ll see the feedback is overwhelmingly negative. It’s particularly so from creators who are supported by many small ($1-5) pledges as well as the patrons who support them with these pledges.

The reason for this stems from the specific changes, which I’ll review briefly.

Patreon’s current fee structure

According to their documentation, Patreon’s current fee structure is as follows:

  1. 5% platform fee: Patreon takes a 5% of each pledge from the creator’s share after the pledge payment is successfully processed. The fee for a $1 pledge is $0.05. For a $5 pledge it’s $0.25.
  2. Payment processing fees (variable): Patreon takes a variable amount from the creator’s share to cover payment processing fees incurred from processing pledge payments. More on this in a moment.
  3. Payout fees: Patreon collects a fee anytime creators move money from their Patreon balance to their bank or PayPal account. For US customers, the fee is $0.25 for every transfer done via Stripe and for PayPal it’s $0.25 or 1% of the amount transferred capped at $20 USD per deposit. Non-US customers have different rates (see the documentation for those).
  4. Value-added tax (VAT): If the patron is subject to VAT, then Patreon collects the appropriate amount from the patron and does all the required paperwork. See this post to read more about how Patreon handles VAT.

Now, back to the way Patreon has been processing pledge payments and assessing the fees associated with that.

There are two fee structures for pledge payments depending on whether the payment processor is Stripe or PayPal:

  • Stripe charges 1.9% + $0.30 per transaction.
  • PayPal charges 5% + $0.05 per transaction.

So, a $1 pledge payment processed via Stripe would have a fee of $0.32 ($.019 rounded up to $0.02 + $0.30) and a $15 pledge payment would have a fee of $0.59 ($.285 rounded up to $0.29 + $0.30).

And for PayPal, a $1 pledge payment would have a fee of $0.10 ($.05 + $0.05) and a $15 pledge payment would have a fee of $0.80 ($.75 + $0.05).

You can see that under both these fee structures the lower the dollar amount of the pledge, the greater effective percentage (of the pledge) the fee is, with PayPal being the better deal for very small pledges like $1.

The payment processing rates imposed by Patreon are rather standard across the industry. Processing very small payments is relatively expensive pretty much no matter who use use. Though, some platform are able to negotiate better rates for micro-payments, depending on their circumstances.

Ah, but, Patreon has been offsetting the true cost of these micro-payments through batching. Currently, until the new pricing policy goes into effect later this month, patrons supporting multiple creators are currently being charged once for all of their pledges, regardless of how many creators those pledges go to. Because they are charged once, a payment processing fee is assessed just once rather than per pledge.

So, a patron supporting 10 creators with a $1 pledge each is charged $10 at once and the associated payment processing fee is $0.49 for Stripe ($0.19 + $0.30) and $0.55 for PayPal ($0.50 + $0.05). That payment processing fee is then split among those 10 creators, with each of them being assessed $0.049 each for Stripe and $0.055 for PayPal (or perhaps $0.05 and $0.06, I don’t know what rounding rules Patreon has been applying). After Patreon takes their 5% platform fee, each creator would realize $0.89 or $0.90 of that $1 pledge in their Patreon balance.

There is one exception to this batching under the current fee structure, and that is for creators who have the charge-up-front (CUF) feature available to them and enabled. With charge-up-front, the patron is charged their pledge amount right when the make the pledge and a payment processing fee is assess on that lone payment. After the initial CUF payment, the patron is charged on the first of the month, with all their pledges to creators batched and processed as one payment.

Patreon’s new fee structure

Patreon’s new fee structure, according to their announcement and documentation, only makes changes to the way fees are assessed on pledge payment processing (#2 from the list above). But the changes are rather significant, particularly for those patrons and creators related through low-dollar pledges.

Here’s what’s changing about the way pledge payment processing fees are assessed:

  1. There is now one fee structure for payments processed via Stripe or PayPal and it’s 2.9% + $0.35.
  2. The patron not the creator will be assessed the payment processing fee.
  3. Pledge payments are no longer batched. They will be processed individually, each incurring a separate processing fee.
  4. You can no longer use your Patreon balance to make pledge payments to avoid the per-pledge processing fee.

(That last item #4 is not made clear in any of Patreon’s announcements, but it’s been confirmed by Patreon staff. Update 8-Dec-17 16:02 PST: I just noticed the Patreon rep said this is “likely” which isn’t the same as definite, but nevertheless I think it will come to pass.)

There are two main reasons so many folks are upset about this new fee structure: a) It gives creators no option to absorb the cost of the payment processing, which many of them would prefer to do, and b) it makes low-dollar pledges much more expensive compared to the old fee structure.

How much more expensive? If you’re a patron supporting supporting 10 creators with a $1 pledge each you will now be charged $0.38 for each of those 10 pledges, bringing  your total monthly spend to $13.80. This is a 31-32% increase from the old fee structure where your monthly spend would have been $10.48 for Stripe and $10.55 for PayPal.

(Patrons subject to VAT will incur an even highly monthly cost.)

Creators, on the other hand, will realize $0.95 of each of those $1 pledges in their Patreon balances because now only the Patreon platform fee of 5% will be taken from their share.

Why did they do it?

The main reasons Patreon gives for the change in their announcement is to provide creators with a predictable, stable monthly income, and to allow creators to take home as much of their earnings as possible.

In order to do this, they explain, they need to move from processing pledges on a fixed, 1st of the month, monthly schedule, to processing payments still monthly, but on the anniversary of when the pledge was first made.

Here are the two diagrams they provided to illustrate this:

Okay, I can follow Patreon’s thinking here. But there is an issue I think they are specifically not speaking to here.

Implied in Patreon’s reasoning and in the diagrams above is a move away from the concept of stored value, of an internal Patreon ledger than can be used to redistribute money amongst patrons and creators.

At this point you’re probably asking, “Christie, what are you talking about, isn’t the whole point of Patreon to “redistribute money” from patrons to creators?” Well, yes, it is. But the phrases stored value and redistribute money have specific meaning and consequences in the financial regulatory world. Business engaging in certain kinds of activities are considered Money Services Businesses (MSBs) and are subject to additional laws and regulations. PayPal and Stripe are money services business. Kickstarter and IndieGoGo are not. In the United States, MSBs are required to register with the Dept of the Treasury and are overseen by the Financial Crimes Enforcement Network (FinCEN). One type of MSB is a money transmitter and I believe this is specifically what Patreon is trying to avoid having to be classified as (and therefore subject to additional cost and regulation).

Here I’m going to stop and express my gratitude and appreciation for the folks at Gratipay. Without their commitment to transparency and communication about how their business work(s/ed) I likely would not know any of what I’m about to explain. Thank you!

As soon as I realized that Patreon’s changes included unbatching payments, I recalled the issue Gratipay encountered when they were shopping for a new payment processor. They had trouble finding a payment processor that would work with them under their existing business model because they looked too much like a money transmitter:

The crux of the problem is the stored value: holding funds in a balance that can then be redistributed, in our opinion, qualifies as money transmission, which we cannot support.

Gratipay wrote extensively about this issue, so if you’re curious to learn more, start with this blog post and follow the links from there.

In the case of Patreon, both batching of pledge payments from one patron to multiple creators and the use of your Patreon balance to pay pledges without processing an external payment requires “holding funds in a balance that can then be redistributed.”

So, that’s what I think is going on here. Now, I’m not an expert in this area and I’m not familiar enough with the regulations regarding financial businesses to assert my theory with 100% confidence, so take what I say with a grain of salt. (If you are knowledgeable in this area and have insight you’re willing to share, please get in touch!) But this explanation makes more sense to me than most others I’ve heard. And, it’s quite common for venture-backed startups to operate in a regulatory grey-area (intentionally or not) in order to build an audience and then get to a point where they either need to change the regulations (what Uber is trying to do) or come in line with them. It’s the latter point I think Patreon has come to.

What Patreon should have done

I think Patreon probably made the right call for their business with regard to the move away from stored value via the unbatching of pledge payments. I can’t say for certain if they made the right decision to put the burden of the additional payment processing on patrons and to deprioritize patron-creator relationships built upon small pledges. That’s their call, unfortunately. (See this post for details indicating it was very much a deliberate choice to prioritize larger pledges and lucrative creators.)

Could they have negotiated with their payment processors to offer a better rate for small transactions? Maybe. Kickstarter offers 5% + $0.05 for pledges $10 or less. But then again, Kickstarter doesn’t offer PayPal and Patreon does. That kind of rate negotiation may not be possible without an exclusive arrangement or other circumstances that don’t apply to Patreon.

You could argue that Patreon’s true mistake was in subsidizing the true cost of micro-payments with a business model they couldn’t (or were unwilling) to sustain in the long-term. People flocked to Patreon because no one else was offering this model and it turns out there’s a reason for that.

That’s why I think, given how banks and credit card associations work, it will be hard for folks to find an alternative to Patreon that offers the exact same features to brought them to the platform. Drip, a competing platform from Kickstarter currently in private beta, might be able to offer a better rate on micro-payments, especially since Kickstarter does. But if you were relying on the availability of PayPal, Drip isn’t going to work for you without compromise.

Further reading

My friend and colleague Audrey wrote her own take on Patreon, more from the point of view of creator. Check it out and let me know if you’ve come across other points of view you appreciated and I’ll update the post with them.

Join me in Supporting the Recompiler for Year 3

My good friend and colleague Audrey Eschright runs indie publishing company Recompiler Media, which produces the feminist tech zine Recompiler and a companion podcast of the same name that I co-host.  It also publishes important books such as the Responsible Communication Style Guide, edited by Thursday Bram.

Right now, Audrey is running a Kickstarter campaign to fund Year 3 of the Recompiler. If you’re able, please contribute what you can to this awesome effort. There are some fantastic backer rewards. If you select the “Community Builder” package, you’ll get a copy of the Responsible Communication Style Guide, the 1st edition of Community Event Planning, along with updates as we complete chapters of the 2nd edition.

That’s right! We’re doing a 2nd edition of Community Event Planning, our guide on how to organize community-focused tech events and if you support the Kickstarter you’ll get a copy of the new and current editions. I’m thrilled for the opportunity to share even more of what we’ve learned about organizing community through events, including first-person accounts from organizers of all kinds of events. The new edition will include sections on selecting the best talks and activities for your event, budgeting (with examples!), logistics, inclusion, and building your team.

To celebrate the Recompiler and all its great content (and to inspire you to join the Kickstarter), we’re doing our first telethon! It’s this weekend, Saturday, 11 November from 10am-4pm PST. I don’t have the links to the livestream quite yet, but will update this post soon with all the relevant details. Stay tuned! One of the things we’ll be doing during the telethon is answering your questions so submit them here.

Please tune in on Saturday and join me in supporting the Recompiler for Year 3!

Using Zapier and OmniFocus to stay on top of meetings

(If you like this post, you might also like Using Zapier to import GitHub issues into OmniFocus.)

I use OmniFocus for personal task-tracking and Zapier to automate work when possible.

One way I use these two tools in combination is to automatically create tasks when a new event is created on my work calendars.

The two tasks look like this:

  • Meeting Prep: Call with Robert Smith, with a due date the day before the meeting is schedule.
  • Call with Robert Smith, with a due date the date the meeting is scheduled.

In OmniFocus this looks something like:

The reasons I create two tasks in OmniFocus is because I use a few applescripts to generate daily and weekly task reports and forecasts and I like to have a record of my meetings as well as the prep work I do for them in those reports.

What you need to setup this integration:

Optional tools include Hazel or Lingon to automate the running of the ParseInbox applescript.

Before I continue, thank you to Joe Buhling for sharing his collection of OmniFocus scripts!

Part 1: Create Zap

Step 1: Google Calendar app, New Event trigger

First, select the Google Calendar app and the New Event trigger:

Next you’ll need to configure the connection to your Google account (if you haven’t already):

Then you’ll select the specific calendar from which to retrieve new events:

That’s it for this step. Don’t forget to test the step before moving on to be sure you can retrieve an event.

Step 2: Formatter app, Date/Time trigger

In this step, we’ll take the start date of the meeting and subtract one day to get the due date for our Meeting Prep task.

Select the Formatter by Zapier app and the Date/Time trigger:

Next, you’ll set the following fields:

  • Transform: Add/Subtract Time
  • Input: Step 1 Event Begins (Pretty)
  • Expression: -1 day
  • To Format: Use a Custom Value (advanced)
  • Custom Value for To Format: MMM D, YYYY

(The script I’m using to parse OmniFocus Inbox items doesn’t handle date formats with times well which is why in this step we’re also formatting the date as MMM D, YYYY.)

 

Continue and be sure to test the step before moving on to the next one. The output should look something like:

Jun 8, 2017

Step 3: Formatter app, Date/Time trigger

This step is similar to Step 2 except that we aren’t going to modify the date, just format it so it works with the script we’ll use to parse our OmniFocus Inbox.

Select the Formatter by Zapier app and the Date/Time trigger as before. This time you’ll select Format as the Transform value:

  • Transform: Format
  • Input: Step 1 Event Begins (Pretty)
  • To Format: Use a Custom Value (advanced)
  • Custom Value for To Format: MMM D, YYYY

Continue and be sure to test the step before moving on to the next one. The output should look something like:

Jun 8, 2017

Step 4: OmniFocus app, Create Task action

In this step we’ll create the first of our two tasks, this one for Meeting Prep.

First, select the OmniFocus app:

Select OmniFocus app for Step 4.
Select OmniFocus app for Step 4.

Now select the Create Task action for the OmniFocus app:

Select create task action for OmniFocus app.
Select create task action for OmniFocus app.

Next you’ll need to connect your OmniFocus account if you haven’t already and select which connection you’d like to use.

Next, set up the create task action. You’ll configure only the Title field as such:

--Meeting Prep: Step 1 Summary @Meeting Prep ::Project name #Step 2 Start Datetime Pretty //Step 1 HTML Link

Let’s break this down:

  • The -- sets the name of the task.
  • The @ sets the context.
  • The:: sets the the name of the project.
  • The# sets the due date.
  • The// sets the text of the note.

Two notes:

  • The name of the project is fuzzy matched against flatted name of folders and projects, so you don’t need to use a colon between folder and project name.
  • With the applescript I’m using to parse OmniFocus’ Inbox, I had trouble with dates including time, so this is why I simplify the due date format in Step 2 and 3 of the Zap.

For details on the syntax used for parsing the inbox, see this post.

Here’s what the the task looks like in Zapier:

As always, test the action before proceeding to make sure everything looks right before continuing on. You test should look something like this:

Step 5: OmniFocus app, Create Task action

In this step we’ll create the second of our two tasks, this one for the meeting itself.

As in Step 4, select the OmniFocus app and Create Task action.

The Title field for this Create Task action is slight different as is the due date:

--Step 1 Summary @Meetings ::Project name #Step 3 Start Datetime Pretty //Step 1 HTML Link

Here’s what it looks like in Zapier:

Next, test the action before proceeding to make sure everything looks right before continuing on. Your output should look something like this:

Part 2: Parsing tasks in OmniFocus’ Inbox

Step 1: Manually run the ParseInbox script

For this part, if you haven’t already, you’ll want to grab a copy of the AutoParser scripts from either the original author or myself.

The repositories linked to above contain a collection of applescripts for use with OmniFocus. (Thank you Joe Buhling for putting these together!)

There are two main options for running the script manually.

Option 1: You can run any of the scripts from the command line with the osascript command:

/usr/bin/osascript "/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript"

Option 2: If you don’t want to use the command line to run scripts, you can copy the ParseInbox.applescript into OmniFocus’ scripts folder. To find out where this is, go to Help > Open Scripts Folder in OmniFocus and it will open a new finder window at that location. Once you do this, you’ll see Script: ParseInbox as an option in the View > Customize Toolbar… window. Drag this icon to your toolbar for ease of use.

When you run the ParseInbox script, it will transform the Inbox task Zapier created that looks like this:

--install certbot @GitHub ::sustainbility index project kick off #06/08/17 //https://github.com/numfocus/collab-infrastructure/issues/30

Into the task install certbot, belonging to the project Project Kick Off in the folder Sustainability Index. The task will now have a due date of 6/8/2017, and note text that includes a link back to the original GitHub issue:

Task in OmniFocus after it has been parsed from Inbox.
Task in OmniFocus after it has been parsed from Inbox.

If at this point you realize that your Zap isn’t quite configured correctly or exactly how you want it, you can go back and adjust it. And, if you get tired of waiting for OmniFocus to sync with the server to retrieve the new task, just remember you can copy and paste the test output from Step 4 of your Zap.

Step 2 (optional): Automatically running ParseInbox

This step is totally optional and you can skip it if you’re happy manually running the script when you want to parse Inbox items.

However, if you don’t want to have to remember to do this, or if you want OmniFocus to be able to process Inbox items while you’re out and about, then you’ll want to automate it.

There are a few options for doing this. They all require your computer be on, but OmniFocus doesn’t have to be open (the script will open it if closed).

Option 1 is to use Hazel to run the script when your OmniFocus has been updated. Joe explains how to configure this option on his blog here. I had mixed results with this method. The script seemed to run sometime and not others. YMMV.

Option 2 is to schedule the script using launchd (macOS’s version of cron). This involves editing plist files, which I hate doing, so I bought Lingon X to make this easy.

Here’s what my settings for Lingon look like:

Lingon settings for scheduling ParseInbox script.
Lingon settings for scheduling ParseInbox script.

And the plist generated by Lingon looks like this:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EnvironmentVariables</key>
	<dict>
		<key>PATH</key>
		<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/sbin</string>
	</dict>
	<key>Label</key>
	<string>of.autoparser</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/bin/osascript</string>
		<string>/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript</string>
	</array>
	<key>StartInterval</key>
	<integer>300</integer>
</dict>
</plist>

Using Zapier to import GitHub issues into OmniFocus

I use OmniFocus for personal task-tracking and Zapier to automate work when possible.  I also coordinate open source work on GitHub. Recently I was wondering if there was a way to make OmniFocus automatically import any GitHub issue assigned to me. It turns out there is!

What you need:

Optional tools include Hazel or Lingon to automate the running of the ParseInbox applescript.

Before I continue, thank you to Joe Buhling for sharing his collection of OmniFocus scripts!

Part One: Create zap on Zapier

If you haven’t already, enable OmniSync and create a Mail Drop email address. You’ll also need a GitHub account and there should be a newly created issue assigned to you.

To get started, while logged into Zapier, click MAKE A ZAP! button.

Step 1: GitHub app, new issue trigger

Select GitHub as the trigger app:

Screen capture of selecting "GitHub" as trigger app.
Select “GitHub” as trigger app.

Next, select New Issue as the GitHub trigger:

Screen capture of selecting "new issue" as GitHub trigger.
Select “new issue” as GitHub trigger.

Next, set up the GitHub new issue trigger according to your preferences:

Screen capture of setting up GitHub issue trigger according to your preferences.
Set up GitHub issue trigger according to your preferences.

In my Zap, I’ve selected Only issues assigned to you and for the time being, I’ve limited it to a single GitHub organization. What you select is up to you.

Next, test this step to ensure it is retrieving the data from GitHub that you expect it to. Before you run the test, Zapier will remind you to have a recently created issue that matches your trigger options:

Screen capture of testing your GitHub new issue trigger.
Test your GitHub new issue trigger.

Once everything looks good, save the step.

Next, you’ll create a formatter step to format any dates attached to GitHub issues via their assigned milestones.

Step 2: Formatter app, date/time action

The app you’ll select for this 2nd step is Formatter by Zapier:

Screen capture of selecting step 2 app as Formatter by Zapier
Step 2 app is Formatter by Zapier.

The action you’ll use for Formatter is Date / Time:

Screen capture of using the date action for app Formatter.
Use the date action for app Formatter.

Next, set up the Date / Time action. You’ll want to set the following fields accordingly:

  • Transform: Format
  • Input: Step 1 Milestone Due On
  • To Format: MM/DD/YY
Screen capture of configuring date transform.
Configure date transform action.

Now test the action to ensure the result is as you expect. You’ll see something like:

Test results for date formatter action.
Test results for date formatter action.

Once everything looks good, save the step.

Step 3: Code by Zapier app, run Python action

In this step, I’m using Python code to map GitHub repository names to OmniFocus folders and GitHub milestones to OmniFocus projects within those folders. If you have a different organizational scheme, you’ll want to modify the code in this step accordingly.

First, select the Code by Zapier app:

For Step 3, select the Code by Zapier app.
For Step 3, select the Code by Zapier app.

Next, select Run Python as the Code by Zapier action:

Select Run Python as Code by Zapier action.
Select Run Python as Code by Zapier action.

(You could also select Run Javascript and re-write the Python code below in Javascript.)

Next, configure the Input Data for use with our custom python code. You’ll want to set the following:

  • repo: Step 1: Repository Name
  • milestone: Step 1: Milestone Title

The names of the fields on the left doesn’t really matter, but it must match the key names we’ll use in our Python code.

Configure input data for custom python code.
Configure input data for custom python code.

Next, you’ll enter the following Python code into the Code field:

# want to set the project as
# repo milestone
# or just repo if no milestone

output = {'project' : input_data.get('repo').replace("-", " ")}

if input_data.get('milestone'):
    repo = input_data.get('repo')
    milestone = input_data.get('milestone')
    project = repo.replace("-", " ") + ' ' + milestone.replace("-", " ")
    output = {'project' : project}

If the issue being processed by Zapier has a milestone, this code sets project to Repository name milestone name, replacing any hyphens with spaces. Otherwise, it sets project to simply Repository name, also replacing any hyphens with spaces.

This works for me because I organize NumFOCUS projects in GitHub like this:

  • [repository] my-project
    • [milestone] milestone 1
    • [milestone] milestone 2

And in OmniFocus, I organize projects like this:

  • [folder] My Project
    • [project] Milestone 1
    • [project] Milestone 2

If you structure your projects differently, you’ll need to update the Python code above accordingly.

When you’re ready, test the Python code and check to see that it creates the expected output:

Results of testing custom Python code.
Results of testing custom Python code.

When everything looks good, save this step and continue on to creating the 4th and final step.

Step 4: OmniFocus app, create task action

In this last step you’ll configure the OmniFocus app to create an OmniFocus task with information from the retrieved GitHub issue.

First, select the OmniFocus app:

Select OmniFocus app for Step 4.
Select OmniFocus app for Step 4.

Now select the Create Task action for the OmniFocus app:

Select create task action for OmniFocus app.
Select create task action for OmniFocus app.

Next you’ll need to connect your OmniFocus account if you haven’t already and select which connection you’d like to use.

Next, set up the create task action. You’ll configure only the Title field as such:

--Step 1 Title @GitHub ::Step 3 Project #Step 2 Output //Step 1 Html Url

Let’s break this down:

  • The -- sets the name of the task.
  • The @ sets the context.
  • The:: sets the the name of the project.
  • The# sets the due date.
  • The// sets the text of the note.

Two notes:

  • The name of the project is fuzzy matched against flatted name of folders and projects, so you don’t need to use a colon between folder and project name.
  • With the applescript I’m using to parse OmniFocus’ Inbox, I had trouble with dates including time, so this is why I simplify the due date format in Step 2 of the Zap.
  • If you wanted to dynamically set the name of the context based on some attribute of the GitHub issue (e.g. label), you could do that by modifying the Run Python action in Step 3.

For details on the syntax used for parsing the inbox, see this post.

Here’s what the the task looks like in Zapier:

Configure create task omnifocus action.
Configure create task OmniFocus action.

As always, test the action before proceeding to make sure everything looks right:

Test create task OmniFocus action.
Test create task OmniFocus action.

If this looks good, click Create & Continue to create the task. Once you do this, flip over to OmniFocus and wait for the task to appear in your Inbox. It’ll look something like this:

New task in OmniFocus Inbox.
New task in OmniFocus Inbox.

Now you’re ready to setup the script to parse that monster-looking task out of your OmniFocus Inbox and into the right spot!

Part 2: Parsing tasks in OmniFocus’ Inbox

Step 1: Manually run the ParseInbox script

For this part, if you haven’t already, you’ll want to grab a copy of the AutoParser scripts from either the original author or myself.

The repositories linked to above contain a collection of applescripts for use with OmniFocus. (Thank you Joe Buhling for putting these together!)

There are two main options for running the script manually.

Option 1: You can run any of the scripts from the command line with the osascript command:

/usr/bin/osascript "/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript"

Option 2: If you don’t want to use the command line to run scripts, you can copy the ParseInbox.applescript into OmniFocus’ scripts folder. To find out where this is, go to Help > Open Scripts Folder in OmniFocus and it will open a new finder window at that location. Once you do this, you’ll see Script: ParseInbox as an option in the View > Customize Toolbar… window. Drag this icon to your toolbar for ease of use.

When you run the ParseInbox script, it will transform the Inbox task Zapier created that looks like this:

--install certbot @GitHub ::sustainbility index project kick off #06/08/17 //https://github.com/numfocus/collab-infrastructure/issues/30

Into the task install certbot, belonging to the project Project Kick Off in the folder Sustainability Index. The task will now have a due date of 6/8/2017, and note text that includes a link back to the original GitHub issue:

Task in OmniFocus after it has been parsed from Inbox.
Task in OmniFocus after it has been parsed from Inbox.

If at this point you realize that your Zap isn’t quite configured correctly or exactly how you want it, you can go back and adjust it. And, if you get tired of waiting for OmniFocus to sync with the server to retrieve the new task, just remember you can copy and paste the test output from Step 4 of your Zap.

Step 2 (optional): Automatically running ParseInbox

This step is totally optional and you can skip it if you’re happy manually running the script when you want to parse Inbox items.

However, if you don’t want to have to remember to do this, or if you want OmniFocus to be able to process Inbox items while you’re out and about, then you’ll want to automate it.

There are a few options for doing this. They all require your computer be on, but OmniFocus doesn’t have to be open (the script will open it if closed).

Option 1 is to use Hazel to run the script when your OmniFocus has been updated. Joe explains how to configure this option on his blog here. I had mixed results with this method. The script seemed to run sometime and not others. YMMV.

Option 2 is to schedule the script using launchd (macOS’s version of cron). This involves editing plist files, which I hate doing, so I bought Lingon X to make this easy.

Here’s what my settings for Lingon look like:

Lingon settings for scheduling ParseInbox script.
Lingon settings for scheduling ParseInbox script.

And the plist generated by Lingon looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EnvironmentVariables</key>
	<dict>
		<key>PATH</key>
		<string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/sbin</string>
	</dict>
	<key>Label</key>
	<string>of.autoparser</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/bin/osascript</string>
		<string>/Users/christie/Bin/OFScripts/Auto-Parser/ParseInbox.applescript</string>
	</array>
	<key>StartInterval</key>
	<integer>300</integer>
</dict>
</plist>

 

How could GitHub announce an all-male conference line up the same week it shares results from an OSS demographics survey with 3% women?

(Post adapted from this twitter thread.)

This week, GitHub released results from a survey it did regarding the “attitudes, experiences, and backgrounds of those who use, build, and maintain open source software.” Of 5,500 responses from 3,800 open source repositories, only 3% of responses were from women.

Also this week, GitHub announced an all-male speaker roster for its upcoming ElectronConf and then promptly postponed due to negative feedback about the line up. The original roster is no longer available, replaced for the time-being with the following message:

“We published a list of speakers that does not reflect the standards to which we hold ourselves. We will be postponing this event until we can deliver a more diverse slate of speakers.”

It also appears the twitter account for the conference (@electronconf) has been switched to private.

How could this happen? How could an organization that appears to be working so hard to improve with regard to diversity and inclusion let such an embarrassing and totally preventable thing happen? Easily. Leadership isn’t truly committed to enacting change.

How can I say this without having any insider knowledge? Because I’ve seen it happen at other organizations. And I’ve studied organizational change and have learned it’s very difficult. It requires leadership be entirely committed to change and act accordingly.

I think we’ve all noticed how many diversity-minded folks GitHub has hired over the last two years or so. While I’m always happy when colleagues and acquaintances receive an exciting career opportunity, it makes me a bit nervous when an organization known to be problematic makes a bunch of hires like GitHub did. One way to quiet your critics, after all, is to hire them! And there’s a ripple benefit to this, too. Other people watching think, “Oh, GitHub hired so-and-so, maybe they can finally get their act together now.” Plus you don’t want to make someone you care about feel like shit by criticizing their employer and possibly their work, so you temper what you say.

Unfortunately simply hiring prominent diversity folks doesn’t actually solve systemic organizational issues. Those skilled in diversity & inclusion can help plan and guide improvements, but leadership has to do the hard emotional labor. And so, unless leadership is committed to change, if you come aboard to work on D&I or any other kind of major change, you are very unlikely to succeed. You might be able to make small improvements here and there, and even release some great product features. But wholesale organization change? No.

(A really good resource for learning more about this, particularly how you can make the most of being an individual contributor, is Who Really Matters: Core Group Theory and I wrote about it here.)

I know this from experience because I’ve been that senior hire at a prominent OSS company who hasn’t been allowed to do anything of real impact.

After nearly four years of one frustrating thing after another, what finally got me to quit Mozilla was this: In a planning meeting for the developer conference (View Source) that I was tasked with producing, the team organizing logistics, in response to me saying I was assembling an accessibility guide for them to follow, said something like “we don’t need an accessibility guide because we’re reasonable people.” This from the same team that had not a single accessibility-related item on their venue selection checklist. No one else present at the meeting, including my manager, said anything. Except for me, of course. I was livid. Having finally realized I would never get passed the hubris Mozilla engenders across its entire organization, I quit a few hours later.

I mention this because I think it speaks to how an organization like GitHub could so publicly and embarrassingly fail on diversity & inclusion and not realize it until it’s pointed out by external folks. Many people think that addressing the systemic issues required for improving diversity & inclusion is about being a good or reasonable person. It is absolutely not. It is about committing to change. To listening and learning, far outside of your comfort zone and doing that over and over again. It’s about bringing in subject-matter experts when needed and supporting them appropriately. It’s about identifying and getting rid of the people in your organization who obstruct change, even if they are ‘nice’ or even (especially) someone you personally like.

Lastly, I want to say: Don’t give GitHub any accolades for “admitting” it’s mistake and postponing ElectronConf. Postponing an annual event that’s six weeks away from happening is a major kind of fail. It jerks everybody around. GitHub selecting and announcing an all-male speaker line-up is not a coincidence or an accident. Diversity and inclusion, like security and UX, is not something you think about at the end of the product development process. Rather, it has to be a priority and an integral part of the conference planning process from the beginning. Whatever led to GitHub publishing the line up they did relates to systemic issues present throughout the development and planning of their conference. Any response that fails to speak to those issues and how they will be addressed rings hollow.

Support indie tech feminist Recompiler magazine + podcast

On Saturday, Recompiler Media, which publishes a print and online magazine as well as a podcast (hosted by me) turned two years old. Yay!

Audrey reports about year two accomplishments:

I’m very proud to be producing a podcast component of the magazine. We’ve shared interviews with amazing, thoughtful technologists such as Meli Lewis, Amelia Abreu, Helga Hansen, Sumana Harihareswara, Thursday Bram, and Heidi Waterhouse. We’ve talked about what happens when your toaster has a DNS bug, we’ve shared all kinds of creepy fun tech news, and we’ve figured out how to hop the internet.

But it’s tough because the Recompiler currently doesn’t generate enough revenue to pay me, so I do it for free, on the side, as a “passion project.”

Audrey provides more details in her post about where we’re struggling:

This is not a sustainable level of subscriptions, sales, and reader support. The way things are right now, we won’t be able to continue publishing The Recompiler into year three.

We know we have a lot of enthusiastic readers, and many of you contribute what you can. Here’s what we need:

  • If you forgot to renew your subscription, please do that! I send out reminders but there is a limited amount of time I can spend on admin tasks and still keep the articles coming.
  • If you’ve been meaning to subscribe: this is the time. We have print and digital options, and we can do invoicing or bundles for schools, libraries, and offices. Email us to discuss.
  • If you have the means to make a recurring contribution or sponsor an issue, this makes a huge difference in our ability to keep things running smoothly.
  • Finally, if you haven’t ordered a copy of the book yet, it will be out soon and it’s a great resource.

We need to bring in about $3000 by the end of the month in order to publish Issue 7 (security) on schedule.

Audrey has pledged the following: for every $500 in new subscriptions, renewals, monthly pledges, and sponsorships, she’ll find something fun to post on our Twitter account.

For my part, I am pledging:

  • For every $500 raised, I’ll record a dramatic reading of a tongue-twister for the podcast. (We’re up to $1588 as I type this, so I’m on the hook for three already. Can you help me it four? Five?)
  • If we exceed the $3k goal by 50% or more, I’ll figure out how to do the readings LIVE.
  • If you pledge $100 or more, I will read any short message of your choosing on the podcast (within reason, subject to our code of conduct).

Thanks for reading this far, and all your enthusiasm and support. We wouldn’t be able to do this without you!