Transcript
This whole conference is about avoiding thinking about the elections for me, so I won't give you that pressure for this. My name is Nick O'Neill. I've been working as a software engineer in Francisco for roughly 15 years. I started working on a lot of UI stuff, and the thread that sort of weaves through everything that I've done is that I want to work on user experiences that give people a more intuitive view of something that they can't do or they don't know how to do, based off of something new.
Originally, it was like early Web 2.0. and people were finally getting into the idea that web pages weren't just static things. They're things, they're applications that we can really interact with. I was a JavaScript engineer for a long time. And then, we started holding these pieces of metal and glass in our hands, which is a totally different experience than navigating a web page and using a mouse. So I dealt with a lot of UI for this stuff. And I ended up leading some mobile teams, and then, sort of stumbled into this role as a political tech non-profit founder.
But before I get into that too much, I'm going to give you a short prelude on voting. I hope everyone got a chance to vote today, if you're a local, or vote early maybe, if you're from out of town. And people tell me that the way to connect with your audience is to translate things into a language they understand. So we're going to translate voting into high availability consensus algorithms. Why voting is important? This may be a bit of a stretch, so you got to bear with me just a little bit.
We've got this cluster of servers and each one is monitoring the health of its neighbors. We're making sure it's available, its performance is fine, that sort of stuff. And unfortunately, a couple of our servers are misbehaving. They're being bad, they're causing a bit of a problem. And neighboring machines, next to them, are watching this and keeping track. We are in luck, though, because we have a controller. It makes sure to only route traffic to the good machines and remove the bad ones from the pool. And it periodically checks in with the servers to make sure it knows how the neighbors are doing.
Unfortunately, the way we designed our system is not really optimal. Remember, this is about voting, so keep that in mind. No one has to respond if they don't have any changes to report. These two servers in blue here, they're thinking that the other servers were acting up before, but now, they're sort of fine, so we don't really have to report anything. Now, after a while, they don't really report anything for a while, the controller sort of gets bored. It's like, "Hey, no one's talking to me about these servers. They must be fine. They're not contributing, I'm not going to ask them about it anymore."
Eventually, the bad machines starts acting up again, and there's no one to report because no one's being asked about these bad machines. Now, this is a really bad system. You obviously wouldn't design this sort of thing. You wouldn't trust it to keep your network highly available. And to make changes to the system, we have to always be reporting and we have to know that the machines that are there can be taken out of the pool. It's the same thing with voting; you can see the parallels. Candidates look at the demographics for people who have voted, and they craft their policy around these kinds of people.
So even if the person you wanted is going to get elected anyway and you feel like it's not important to vote, these candidates are going to look and see who voted and say, "The policy that I'm going to craft is the demographic of people that are going to vote for me." "Not just the people that are going to be part of my party, but the demographic of people who are going to vote and actually turn out." So that's why voting and reelection is important. Thank you for coming to my TED Talk about voting as high availability systems, and let's get back to the real presentation.
5 Calls
I'm an engineer. I'm working on normal, non-political things. And 2016 happens. Totally not political stuff until 2016. And I realized, so any part of politics, especially politics of how people stay engaged in what is going on in the system, have really, really terrible experiences associated with them. Whenever we are trying to understand what's going on between elections, it's difficult for people to maintain that engagement for long periods of time, because there's a lot of insider knowledge that goes into how you should communicate with your representatives, and what they want to hear about, and what the best way to talk to them is. Post-2016 election, I called some friends who worked in politics and I said, "Listen, what's the best bang for my buck here? What's the effort that we can put in, that anybody can put in, and get the most impact out of it?"
Now, in politics, in constituent contact, there's a big range here. All the way down, at one end of the spectrum, you've got basically signing a petition. You're going online. You're clicking on something. It's adding your name to a list. Very low effort, but also very little impact. These things just get delivered in giant stacks to constituent offices, and it makes an impact in the sense that it does get delivered, but there's not a whole lot that comes out of it because the representative knows that this is a very, very low effort thing for someone to do.
All the way on the other side of the spectrum is actually visiting a representative in a political office. So you're making the time to travel to whatever it is, DC or Sacramento. You're making the effort to set up a meeting with someone who's representing you, talking about something very specific, that's very specific to your life and how their policy should change based off of your personal experience. Totally other end of the spectrum, super high effort, and super high impact too. So I asked my friends, "What's the good middle ground? What's the thing that everybody can do that is both relatively low effort, but also relatively high impact?" And the thing they told me, of course, was getting on the phone and calling your representative. It had to be calling because everybody loves to get on the phone and talk to someone that they don't know.
So we turned that feedback into five calls, which was a challenge, it was, "How can we take this thing that nobody likes to do, which is calling people that they don't know and being part of a process that they're not familiar with, and how do we make that really, really easy?" And so, that's what we did. I'll walk you through the steps of what we do. This is sort of step one. We track upcoming legislation and news items, we research the issues, the ones that are interesting from a progressive perspective because that's the perspective that we take, and then, we update this list with the top items, every week, and take them off as they become irrelevant. We use technology like browser location, IP geolocation, and we can roughly get a sense of who your representatives are automatically. But if not, there's a manual field where you can enter in your address to get an exact match. And then, we use a combination of databases, APIs, crowdsourced information, to get your phone numbers not only for your representatives in their DC offices, but also their local offices. Sometimes when traffic is really high, calling your office in DC and you can't get through, it's much easier to call a local office. And anyone who's a national representative will have both a DC office and at least one office back in their home district.
Finally, we write up all of our research into this short description. And that's the key here, that it's a short description. We give you a little example script as well. The script is not so much about telling people what opinions to have, but it's about guiding them in what the process is going to be like. It's a relatively short conversation, no one's going to challenge you on what to say or what your opinion is, and you don't have to figure out what to say on the fly. So all of this information is about giving someone confidence to get on the phone and make a call for that first time.
How Did We Do?
We've been doing this since 2017 and, thanks to the generous support of our members and volunteers, we've been able to do it really successfully for the last two years. We've made almost full two and a half million calls to Congress through the platform, we've had more than 100 volunteers come through and participate in both the technical side and the politics and writing side, and we're able to deliver this through three separate platforms, in a different way, to get people that information however they like to get it.
And what I like to say about it is that it's not just keeping up on the news, it's about staying involved in elections between elections. So if you don't stay up on what's going on, how your representative is representing you between the elections, then you're not really going to know how to vote at the end of those four or two years or however long you vote. We help people do that.
Open Source as a Software Team
"And that's very fascinating," you say, "but this is a software architecture conference. And how is that relevant?" Well, it turns out that we sort of have everything you need to make a little software company inside of our open source project. We have to figure out how to hire people and how to keep them involved. We have to coordinate across all of these different types of projects, mobile and back-end and all these different things. And of course we have great stories of failing under load, which every software team must have. And this is all very familiar to normal software teams, except for the fact that we do it on an incredibly minimal budget and nobody actually gets paid.
I don't get to talk about the specifics of the stack very often because I'm usually at conferences where people want to talk about, "Oh, what are the contact rates for this politician?" and, "How does it work?" and all this very specific political stuff. I'm going to take this opportunity, while I have it, to talk about our software stack, which I never get to do. It's very simple. We have this single RDS mySQL server that communicates with a custom Go back-end, talks to a Google Civic API, and Twilio over normal APIs. And then, all of that is fed out through the same APIs to three platforms: our web platform, which is React and TypeScript, an Android app that's written in Java, and an iOS app that's written in Swift.
Now what is the most interesting thing about this software stack? Probably that it's really boring, right? It's the most vanilla thing that you could possibly put together. And that's really intentional from our perspective. We have this interesting opportunity to build a software stack that's really boring and inclusive to other people because people are purpose-driven when they want to come and participate in our project. They're not tech-driven. So we've got this big pool of volunteers. If you know the basics for any of these platforms, you can come in and help out. The other idea, the hypothesis that it is boring, and that equals simple, and that equals more reliable. I'm not sure if that's generally applicable but, for us, it seems to have panned out. We really don't have an engineer that's on staff 24/7 to make sure things don't go down. And so far, we haven't really needed it. I'm just going to keep looking at my watch though.
Lessons from Volunteers
But let's talk about the lessons we've learned from volunteers. We've had a lot of volunteers come into the project and work on various parts of the project, both from the research and politics side to the tech side, across all of the different platforms. We've learned a lot about what it takes to get new folks started on the platform, and also, what it takes to get people coming back. Mostly, we do this on GitHub, so thank you. Our process for volunteers is very simple. We keep track of the specifics of what needs to go into each platform on GitHub Issues. We have a project for each of our individual platforms, and sometimes volunteers find their way in just through GitHub, and they pick out an issue and they say, "I want to work on this issue." And that's great. That's how they get started.
Other people email us and say, "Hey, I'm coming in to work on this issue," or, "I'm coming in to work on this platform. How can I get started?" Having the issues and products split up amongst all the different projects that we have is really helpful to help us direct people once they come in and say, "Hey, I know Java. How can I help out? How best can I be used because I really love the mission of your product and I want to help out?" And I can say, "Oh, great. Well, here's the Android project and you can look through the issues there and pick out something that really works for you," or, "Here's the next thing we want to work on for Android. It's all written in Java, it should be right up your alley."
It does make for a little bit more management on our side because, across all of these projects, GitHub, even in the same organization, isn't super great at synchronizing all of those things. And a lot of that stuff is synchronized for us. If we release a new thing on the API, we want to support it across all of our platforms, and making sure all of those things are on all of the projects and are reflected for everyone who comes in to see what the current state of the world is. What we're working on next is a bit of a manual task, but I think it makes the volunteers' jobs significantly easier when they come in for the first time. So that's why we do that.
We're really lowering the bar for people who come in for the first time and want to get involved. I have worked on some other open source projects, some which have a significant amount of stars on GitHub, way more than we have on 5 Calls. But 5 Calls is the one that gets the most attention from new volunteers. I think it's partially because we've been really good at lowering the bar for new volunteers. You have to assume, for each person that takes the effort to find an email and ask about a project and say, "What can I work on?" there's probably two or three that came in and didn't want to go through the hassle of talking to someone over email. I know it doesn't sound like much, but we're programmers. Introverts here. Give me a little bit of a break.
So there's this huge cognitive load that goes into deciding what you want to do and getting started on a new project. Making it easier for folks to understand the current state of your project and what should be happening next, it removes some of that extra effort that people need to make. Right? There's also the benefit of being a value-driven organization, in this sense, because there are external factors driving that decision. It's not just you want to participate in this tech, you want to do something because it's providing value for other people and you want to be a part of that.
The basic rules here that we've stuck to are have a readme with goals, what the project is all about, expectations for what you should expect as a volunteer, how you should flow through the whole system, and then, what the values are for the project. What is the expected use case for your code when you come into it? We'll talk about this a little bit more later. Second thing, labeled starter tasks, are super key for people. They just want to come in and get started on something. A starter task is a very, very little thing that they can do with very, very low effort. And it just gets them in the door and helps them get started.
The third thing is good getting started guides for all of these projects. I get so many emails from people who say, "This is great. I just got started on this project. I got it building. What can I do next?" So they've already cloned their repository. They've downloaded it. They've whatever, opened Xcode, hit Build, and it just worked for them. Right? They got started or they followed the instructions to get started. So do you think that person would've emailed me and said, "Hey, what can I do?" if they had downloaded the project and it was just a blank slate and there was nothing for them to figure out how to work on it? Probably not. They probably would've been like, "Oh, this doesn't work for me. I'm going to go away."
3 Types of Volunteers
Once they're in, you have basically three different types of volunteers, roughly. Being able to recognize which type of volunteer this is, is pretty critical to figuring out how you handle them through the early part of the process. Now, I'm going to generalize a bit here because people are truly a mix of all things, but it really helps to be able to place people into these certain buckets when they're getting started, before you get to know them a little bit better and figure out what their strengths and weaknesses are.
First type of person: very, very experienced to open source type. Lots of work in open source libraries. Generally, they're coming in and they want to do something technical that they know what they want to do. For example, when we started out and launched the site, we didn't have SSL on the website. And a friend of mine came in and said, "Hey, I want to set up SSL for you. This is really easy. I'm going to get it done in an hour." I said, "Great, let's do it." And he absolutely had done it in an hour, set us up with Let's Encrypt. It automatically renews. I don't have to think about it. And he doesn't have a ton of time for the project but he set it up. He got it done because he knew exactly what he wanted to do. And that was it.
The one thing you have to be worried about with these types of contributors is that they tend to suggest, "Let's just use this one thing that I wrote that nobody else uses.” And that can be a little tricky because, now, you're stuck supporting something that's a weird niche thing that nobody else uses. You want people to have ownership in your project, the part of the project that they are responsible for. They also don't really respond well to you asking them, "Hey, can you come back and work on this other thing that's my idea and not your idea?" A mixed bag there but you might be able to get a code review from them, here and there. But that's about as far as they go.
Now these really solid coders who just love the mission are my favorite types of volunteers. Because they're really great coders, they love what you're doing, they love the mission of what you're doing, but they don't always know what thing to work on next. They don't know about what politics is. They don't know how to make the best impact. So they're going to come in and they're going to ask you, "What should I do?" And if you give these folks a bit of ownership over what they're working on, then they're great at being long-time contributors and they'll come back over and over again and help you out with your projects.
Planning ahead for these folks is really great. This is an open source volunteer project so I don't know if something is going to get done next week or next month. But these are the kinds of volunteers who show up on a Friday and say, "Hey, it's going to rain all weekend. What can I do?" And if you don't have a project ready for them, to give them, to say, "Hey, this is the next thing on the roadmap for the iOS app," they're going to be like, "Oh, I'm going to go do something else." But if you do have something for them, if you can say, "Hey, this is the next thing," whatever, they've got time this weekend. They're going to work on it. They're going to give you whatever it is, 16 hours on a thing because they love what you do. And that's huge. That's a huge amount of work that you can get out of somebody, especially if they're as solid as some of these people are.
So again, with ownership, give them a little bit of ownership. We were super lucky to get people for our iOS and Android apps that are awesome about owning everything that goes on there. Especially for Android, which I don't know a lot about at all, so I can't really help with Android. If it needs something new, I'm sort of reliant on these people who come in and own this part of the code. And iOS is a little bit different because I have a little bit of experience there, but same thing, the team has been incredible in terms of handling code reviews, trying to make time here and there, or figuring out who on the team has time when something comes up and needs to get done.
Third type is fresh coders who just want to learn something. Now, this is a little bit more difficult. It's hard to turn them away because, again, they love what you do and they really want to help. But the experience makes it a little bit hard. They are going to need some more hand-holding. They're going to need a lot of code review. And that largely depends on how much time you have to manage them in the project. They can be great candidates for work down the line. They do tend to stick around for a longer period of time. Maybe it's because they feel like you've given them the chance on something. But they're a great candidate to start with starter issues, and say, "Hey, take this out. Let's see how much effort it takes you and let's see how much effort it takes us to work through this."
It’s about Time
This review of volunteers could basically apply to any software team. Except for the fact that we're not paying anyone any money and the trade-off here is, obviously, their time. So best practices here are basically get really light, low touch. Not commitments to like when they're going to finish something, but commitments to when they're going to work on it. Just say, "Hey, you said you're going to do this. Are you going to work on it this evening or are you going to work on it this weekend?” It's not a question of when you're going to finish it. It's just when is the next time you're going to have time to put into this?
Of course anybody can flake on you. Don't be surprised when some of the volunteers who come in and say they're going to do something, and then, suddenly drop off the Earth. Life happens and open source contributions are definitely one of the first things to go. It's not an insult for you, or anyone, or your project, or anything like that. And all types of contributors will flake on you, I guarantee it, for lots of reasons or no reason whatsoever. If they've done a lot of work that's not complete, it's possible that you can salvage it. But frequently, it's hard to have code in your code base that has zero owners. If it's simple, sure, maybe someone else can take it over and figure it out. If it's more complex, it's harder to have someone who came in, did some work, and then try to find someone else who wants to then own that code and finish it up.
When in doubt, use my favorite check-in emoji. Don't be afraid to check in with someone just because they're a volunteer. They said they wanted to do something for you, it's not a bad thing for you to check in. I was definitely hesitant to check in with people early on in this process for me. I don't know if I was concerned about people getting angry at me or whatever, but it really grew on me and no one has really given me any shit about it. It's the ping-pong emoji, you get it? Because you're pinging somebody. Tough joke, tough joke.
So what we're doing? We're lowering the bar to entry for volunteers, we're getting super light commitments from them about when they're going to work on things, and we're just going to check in often with them. It's easy. All of this falls under the umbrella of communicating effectively on what the current state is and what needs to be done. An open source project with volunteers is like a remote team whose only communication source is GitHub Issues and employees who may never show up again. So if you can communicate effectively with that team, you can basically communicate effectively with a real team who have employees that actually show up. Most days.
Work by Your Values
The other part of value-based projects is something that we've been really forced to do, but other projects I think will pick up a lot on this in the future. In our case, our political values were pretty plain to see for a lot of our contributors, but we did a lot of talking initially about what was the acceptable use case if someone took the code that we had out there and used it wanting to build their own version of 5 Calls essentially. When I started working on 5 Calls with some friends, we started building this as open source because it was so much easier to collaborate with everybody. That was our primary driver for it being open source. One of the initial concerns we had was we did not want, what I would consider, the other team being able to take what we've done and replicate it very easily. It's sort of at odds with open source. You want to be able to put it out there and have people collaborate with what you're doing. But, at the same time, you don't want your work going towards a cause you don't believe in, or specifically, believe against.
To be clear, plenty of use cases came up that were very compatible. Seattle DSA did a great restyle of a lot of early 5 Calls work and put it on their website. And it worked great. A couple of other organizations outside of the U.S. inquired about how they could take what we worked on and adapt it for other APIs where there were different representatives coming in, that sort of thing. Of course this sort of turned out to be moot for us because the secret to 5 Calls is not that we have a great tech stack. It's the fact that the content is continually updated and people can come to us, any day of the week, and say, "What should I call in right now?" We do the research for what legislation is coming up, even as early as committees, we figure out who's the most impactful to call on it, and even if that person isn't your direct representative. And then, we write the content for the site and we make sure it comes off the site if it's no longer timely. And that's the bulk of the time spent on the whole project. It's not even the tech stuff. It's just the content. It's just keeping track of what's going on in politics.
We haven't actually had anyone challenge us on this yet but I think it was worthwhile for us to talk about it. We ended up talking about it really early with a lot of our volunteers, that we wanted to be open source just for the collaboration aspects, not because we think every project that's open source needs to be bipartisan. And did this prevent some volunteers from working on our project? I'd say it probably did. I can't point to anything specifically, but it's entirely likely that someone looked at our project and said, "No, that's not for me." But along the same lines, I think that there are probably a lot of people who looked at our values and said, "This is something that I really do want to work on because they have specific values." I think it was probably net positive for us.
So have your strong opinion about what your software should or should not be used for but, at the same time, communicate it clearly with the volunteers who are working on your project. I'd even go one step further and say if you don't have an opinion on what your software should and should not be used for, then you should have one. Figure it out and then communicate it to your volunteers after that. Software is going to continue to eat the world. And we're going to see more and more of it co-opted for tasks that lots of us don't agree with and is not even close to a gray area.
We've seen high profile cases, like this fight inside Microsoft, to limit how it serves cloud software to immigration and customs enforcement. That's still going on internally. And then Google, where employees protested and resigned because of their project to review and analyze drone footage through AI. They eventually dropped that, so that was successful work from inside Google. Now, these are extreme cases but I don't think it's all that hard to find cases that are open source software that unintentionally creates actual harm. Most sites that peddle actually factually incorrect news are run on WordPress. This is people using open source software to make money off of your grandma by manipulating grandma to clicking on clickbait on Facebook. I'm not super comfortable with software I've used being used in that capacity. And if you run an open source project, I think you should seriously consider the implications of something like that happening.
For those of you, in the audience, who contribute to open source or even write software that's owned by another company, I want you to ask yourself, "Do you know what the values are of the people that you're writing software for? Do you know what the line will be for what they should and should not use their software for?” You probably should. For maintainers, do your volunteers know, do your contributors know what your values are? Do you even have values? Do you know what your values are? Maybe it's time to have that discussion with your team or just decide it yourself.
We Know Our Values, Now What?
To be very clear, once we decide on what our values are, there's a lot more work that goes into what we're going to do about it. And I am not a lawyer, but I suspect that the licenses people prefer to use for open source software because of their permissiveness, would give you probably zero legal control over how someone else wanted to use it in a way that you strongly disagree with. So licenses say a lot of things, like no warranty, no limitations. But this last one is the thing that concerns me the most. Without a sense of responsibility for our craft as software architects, we're just pawns for someone else's proxy war, both in the case of being a cog in this larger machine, big company who can't really see what your code is doing, but also in the sense of you being an open source contributor in something that seems technically interesting, but then, can be used in unintentional ways to harm other people.
At 5 Calls, we sort of fell backwards into having to decide where we stand very early. I think we have a lot of work to do on what we can actually do about it. But for now, the least you can do is ask your maintainer what their values are or, if you're a contributor, or if you're a maintainer rather, communicate your values to your contributors.
So, in review. Projects that are rooted in values have their own ways to motivate volunteers to show up. You don't necessarily have to have hot, new tech stuff to get people to come in and contribute. Maybe you should be using more boring technology choices to have more inclusive software. It doesn't have to be all of your choices that have to be boring, but it should probably be some. Make it easy for your volunteers to take that first step into the project, starter issues, getting started guides. Even just a clear description of why your software is important is a really good step.
And finally, if you've got values, communicate them. If you don't, find some values. This is a differentiator that will probably bring people to your work. Saying, "This can be used for anyone for any purpose," is absolutely a value set that you can have, but make sure that's understood by your contributors. It should not just be a side effect of the license you chose.
Thanks again for being here on election day. I hope you're able to vote on wherever you traveled from or here. And a shout out to the many volunteers who have worked on 5 Calls, over the last two years. They've made it an incredible success and something I never even imagined. We're of course always looking for folks to help out technically and on the politics side, so please, get in touch if that's something you're interested in. And if you're interested in more about building value-driven projects, I hear the closing Keynote tomorrow is along the same lines, and also, incredibly amazing. So please go to that. I think we have some time for questions.
Questions & Answers
Participant 1: You said that you haven't run into the issue of the other side, using your software. Why do you think that is? Is it that they don't know this exists or they're just lazy?
O’Neil: Oh no. I think lazy is one way to put it, but I think the other side is it's a group effort. You need to have people who are both experts in running open source software and also being interested in what's happening politically, and being able to distill that information into something that's easily digestible by people. It's a lot more effort than just downloading some code and clicking Run. I think that's the biggest contributor, more than just laziness.
Participant 2: You mentioned it's really important for maintainers to communicate their values to potential contributors or core contributors. In your experience, what have been really great ways or avenues and mediums to communicate those values?
O’Neil: I think we need a code of conduct-like thing for values. It needs to be a thing that you start a project and you say, "Here's my code of conduct. Here's my code of values. Here are the things that this could be used for and here are the things that this will not be used for." Again, this is sort of easy for us because you go to 5 Calls, you know exactly what we do and the positions we take on things. So it's been relatively easy for us to communicate that to people. But I honestly think that there needs to be more forethought that goes into it for any open source project.
Moderator: Are you getting ideas for things we can work on?
Participant 2: Yes.
O’Neil: I saw a lot of nodding here too, so it's good.
Participant 3: The thing about the license, I think, it's been in the news recently about folks trying to create licenses that have restrictions on them. And obviously, that goes against the OSI definition. And I'm curious, if I understood correctly, was the stance that you all took that, “Yes, the permissive license might allow things that go against our values, but the benefit of the permissive license outweighs that risk”? Is that the position you took? And do you have thoughts about attempts to make licenses that have restrictions?
O’Neil: I don't know. If I had to start over, I would need to do a lot more deep thinking about what the license actually was because we started it with a very permissive license. There's a reason for the permissive license as well. Not just that we wanted to collaborate, but because people at places like Microsoft and Google can basically get carte blanche to work on open source projects in their free time, given that there are very, very permissive licenses. And there are a bunch of people who wanted to contribute from those places. And we were like, "Absolutely. We'll do that."
At this point, knowing what I know, I would definitely think more about what kind of license that was and look into these new types of licenses that, potentially, can provide some … I don't know. Is a legal defense the one that we want to take? I don't have an answer for that. I don't think it's terribly useful for us because we have a lot of other angles for ways that we can defend against it. The 5 Calls brand is a lot of what brings people back. And obviously, they can't use that. So there's no one going to be taking that from us. And if they spin up a site, we've very much lucked out in terms of getting people into the site, when there was a lot of anger on the progressive side about this sort of thing. And that brought us our initial set of users. And it'd be really hard to replicate that just on a whim.
Participant 4: I'm curious about, in the day-to-day of making 5 Calls work, I guess if you could put in different buckets, like financial side, dealing with the software, dealing with the content, how do you split up your time amongst all those different tasks?
O’Neil: I am very lucky in that my partner, Rebecca, deals with all of the content stuff. And there are six or eight volunteers who each break out sections that they're interested in. One woman is super interested in health care. She works in the health care industry, and she's just on top of every legislation that's related to health care. I don't need to worry about it, which is fantastic. So I can mostly focus on product and code stuff. What are the volunteers doing? What's up next for them? Where do we want to go with the product? What's the next thing we want to build that we'd have to spread out across all of these certain platforms? Because, as much as I love having a web and an iOS and an Android app, it's a lot of extra work.
We definitely didn't start it that way. It was just people who were like, "Hey, I want to build this for you," and we were like, "Look it up, the API. Let's go with it." And now, it's like we sort of deploy our new stuff on the web and test it out and see if people like it. And then, if people like it, then we're like, "Okay, we'll make some issues on the iOS and Android projects and we'll see if people are interested in picking those up."
Participant 5: You mentioned the fresh coders who wanted to learn something. Have you ever had to break up with someone who never got to the software standards that you wanted to, reject them altogether?
O’Neil: Not outright. There were definitely …
Participant 5: Did you ghost them?
O’Neil: Would I ghost them? I don't know if I want to answer that. What is the best way to break up with a volunteer that doesn't produce code to the standards? There have been a lot of people who- I don't think we’re at the point where we want to accept code from someone that is a quality that we don't agree with. Once you reach a point where you're like, "This is like the fifth review we've gone through," I mean we're still going to be providing feedback because that's the thing that you should do. And at that point, I think, it becomes such a burden on someone else to do that work, that maybe they realize that they need to improve a little bit or take a class or figure something out before they come back and do it. But we've never actually had to say, "No, you can no longer contribute because your code is not good enough," whatever that is. One more question up here.
Participant 6: So is there any reason this wouldn't translate to another company with a little work? Is the main issue keeping track of the politics, or are there some issues with getting those contacts sorted out?
O’Neil: No. I mean with a little bit of work, you can definitely pull in … I imagine, I haven't looked into contacts from how to get, essentially, phone numbers of representatives based off of geolocation or an address. I'm sure that that exists in lots of other places that people are interested in. And hooking that up to the rest of the API would be pretty straightforward. It's just a lot of extra work to keep track of the politics. And so, someone else would have to have a team in wherever that kept track of that and updated a site along that sort of thing.
One thing we do want to do is expand towards more local politics because state legislatures are a huge thing that makes all sorts of huge decisions about stuff that goes on in your state and they don't get a lot of calls from their constituents. And so, you can drive a significantly smaller number of calls to them and make a significantly larger impact. And that's even double at the city level.
See more presentations with transcripts
