The Changelog: Software Development, Open Source - Automating GitHub with Probot (Interview)

Episode Date: October 6, 2017

We talk with Brandon Keepers and Bex Warner about GitHub's Probot — GitHub Apps to automate and improve your workflows. You can use pre-built apps or easily build and share your own.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Bugsnag. Bugsnag improves the task of troubleshooting errors by making it more enjoyable and less time consuming. For example, when an error occurs, your team can get notified via Slack. You can see diagnostic information on the error.

You can identify the developer who committed the code. And Bugsnag's integration with Trello, Jira, GitHub, and many other collaboration tools makes it easy to assign and track bugs as they're being fixed. We have a special offer for our listeners. Head to bugsnag.com slash changelog. Try out all the features completely free for 60 days. Once again, bugsnag.com slash changelog. From Changelog Media, you're listening to The Changelog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, Editor-in-Chief of

Changelog. On today's show, Jared and I are talking with Brandon Keepers from GitHub and Bex Warner, a recent intern at GitHub, about ProBot, a trainable robot that responds to activity on GitHub. So, Brandon, you've got this thing called ProBot, and you work at GitHub, and we've always been huge fans of what you do there and all the open source work, obviously, at GitHub.

But Probot was recently announced. Can you kind of give us the backstory in terms of your passion around this and how it came to be? So, Probot has kind of come out of this long obsession for me. I've been at GitHub six years, worked on the engineering team on various features. And I spent the last couple of years working closely with the open source community, trying to make sure that GitHub was meeting the needs

of large open source projects, but maintainers that were overburdened. And kind of one of the common themes that kept coming out of a lot of this was that people were asking for or wanting features that weren't necessarily high priority for GitHub. For one reason or another, either they should have been priority and they weren't, or they're features that only a few projects need and isn't necessarily something that's universal to software development. So I've been obsessed with the GitHub API for a long time and built a lot of things over the years. I built this notifications client,

which now Andrew Nesbitt built a way better one called Octabox, but kind of that idea. And so last year, Universe GitHub Apps launched. I think it was called GitHub Integrations then. And as I was talking to people, it came, became pretty clear that like people needed these features and a lot of people had common features, um, uh, common things that they could share with each other. Uh, but they didn't really feel like they were empowered to build them themselves or even that it was something

that they could or should do. Uh, and so this kind of light bulb went off for me talking to people at universe last year of this idea of like a scriptable github or scriptable workflows um you know github has all of these primitives for software development you know it has code it has review it has you know issues in project management um but what it, what it's lacking for a lot of people is this notion of like, when this event happens or when these conditions are met for my team and my needs,

like it should kick off this chain of workflows. And so it went through a bunch of iterations last fall. It started in November. I built this Hack Day demo where it used kind of a custom grammar and you just commit a file in your repo and it'd say on this event when these conditions are met then do this thing.

And that got it pretty far. I worked on that for a few weeks. And then after talking with people and kind of soliciting some feedback online, someone was like actually a jQuery-ish JavaScript style thing where you could, you know, do like dollar sign on this event, and then chain a bunch of actions together. And that took it a little bit farther. And then this last March,

there's one of the folks on the Electron team named Jacob Groundwater reached out to me. And he's like, can I give you some unsolicited advice? Which is always the best. One of the folks on the Electron team named Jacob Groundwater reached out to me. And he's like, can I give you some unsolicited advice? Which is always the best. It's not often unsolicited advice. Always say yes. Jacob is amazing. He's really brilliant.

He said, hey, this seems like a really cool idea, but I feel like you're trying to create an abstraction before you understand, like before you have the other layers figured out. And that was, it helped articulate something I've been feeling. I've been working on this project in my free time for several months. And, you know, I'm like, I feel like the scriptable GitHub is really close, but like, you know, the conditions, like, so when a new pull request is open, if it's a first time contributor, then do this thing. Like those, those like logic gates, I guess, hadn't really been teased out.

And so, like, trying to implement them on this custom grammar was really hard. And so Jacob kind of inspired this, like, reboot, where it's kind of three main components. He's like, you know, start with a bot framework. Like, start with something that's just plain old JavaScript, node modules. People can do whatever else you want. Start to figure out how to make those easy to run easy to deploy

and then as as you're working through that like start to identify the common patterns and start to extract those into a higher level api so in march that kind of kicked off and i basically like in a couple days just like tore out all the code um in fact you can still see the the original code we can like put it in show notes or something um there is now a plug-in for the the current bot framework is the original code um so that was yeah I mean that's kind of the story of how it got to where it is um and then uh this last June um GitHub has every year has this group of interns that come in. And this last June, I randomly get this message from someone named Bex. Actually, Bex, do you want to tell your side of the story?

Yes, please do, Bex. Yeah, sure. So I joined GitHub as an intern, and I was really excited for my time there. And I was on the community and safety team. And going into the internship, I really had no idea what I was going to be working on. And when I got there on the first day, they told me that I was going to be doing some IBM Watson level sort of analysis on toxic comments. And I was like, that sounds pretty cool. I want to prevent toxic comments in open source. And that was a very vague and not totally accurate description of what I ended up doing. But basically, the plan that they had laid out for me

was to create a series of open source GitHub apps that were designed to help open source communities, large open source communities, build and grow and maintain open source contributors, and especially aimed at diversity and inclusion in open source. And since we were building GitHub apps, the obvious platform that being GitHubbers they had heard about was to use ProBot. So I was basically assigned a summer of doing coding working on Probot. What an awesome internship, by the way. I'm thinking back to my college internship, which was at a technology company where I basically spent the summer answering phone calls and helping people upgrade their version of Java. And I'm just,'m just totally jealous right now

how awesome that internship sounds. I think the tagline of the GitHub internship is no coffee runs or something like that. Is that right? That's awesome. So Brandon, you were saying when Bex got involved, that's when Probot went from being your passion project that you were making moves on, but not necessarily

getting too much closer to shipping to here we are a few months hence from the internship and now Probot's out there, at least in a version that you're willing to let everybody participate in. What did VEX bring to the table that you were lacking?

Yes, we sat down, like Vex pinged me and we had a chat and just gave some awesome feedback. I mean, it was things like, hey, I'm trying to do this thing and there's no dots. Or like, what are you doing for testing? Which was a

question we kind of wrestled through for a little while because a lot of it, like I've been just throwing a bunch of ideas, like I've been just, you know, throwing a bunch of ideas together and seeing what sticks and, um, not being super diligent about, about testing stuff. Um, and so I just think that like that initial, like partnership, I guess I would call it of like, you know, we started meeting and it was probably at least once a week,

like we would sit down and chat about like, here's the next big hurdle. Um, and it wasn't just, I mean, from the very beginning, like I think after our initial conversation about docs specs, I think you started submitting pull requests to like document some of the things that, that you had already run across.

Um, but I think just having somebody that was like fully immersed in it, understood the value of where it was going and constantly contributing um you know questions and answers uh was just an awesome experience so when you got to that point there with with the lack of docs it's a pet project so to speak a passion project you're not really trying to be you know I guess production worthy so to speak it's sort of like tinkering in a way and a fun tinkering how do you go or what was the process going from that stage there to to getting docs did you sit down Brandon and do it or Bex were you the person that you know took

that to the next level how did docs come from you know that moment there what were the steps to go from no docs to docs so i think that i just want to point out that when i came into this project i didn't really understand that this was sort of brandon's pet passion project i i thought this was like a very big deal and you know i was a little intimidated at first i thought probot was this big well built out thing and over time you know i realized that there was a lot more I could contribute and give back. But I think that the first step was just having more conversations about it. Because at first, when you're just working on something alone, it's a lot harder to kind of figure out what the important things are, what the problems are.

And I think probably the biggest step was when we decided to create a website for it if brandon you want to talk more about that yeah um i mean i think at that point there had been there'd been various forms of documentations just like stuffed in the docs folder on the repo and those were more meant for me and you know the couple other people that were looking at it. And I think the sign of any open source project becoming mature is having a website. I don't know if that's true. I just made that up. It's in there somewhere.

Yeah, it's in there somewhere. I think it does force you, though, to think about how does a project go from being useful to being presentable you know like like there's the part of it's just like here's here's the function that it serves but then you also have to help people understand what that function is and maybe even where it's going and so yeah I think pulling together the site was was a lot of that like we just think through like how do you want to how do we want to present this because because there's also a part of this to me which which maybe we can dive in a little bit more but like this is like step one

and where i think a lot of platforms are going in a few years um you know the idea of of scriptable extensions um and not necessarily like like you know 10 years ago like webhooks was kind of the big innovation and um yeah and then you've had kind of this like app platform thing start to emerge. I think making your platform scriptable is going to be the next. And I think there's even a few steps beyond that. What kind of platforms make sense for that to be to play? Like, obviously you got some, you probably have some ideas, but like where aside from GitHub does something like ProBot work?

I mean, I think you've seen a lot of it already happening. So like Twilio has been launching some really cool stuff in terms of not only making their platform more accessible to coders, but also non-coders. You know, taking like if this, then that type of mentality around controlling like these lower level services. You've seen, well, like Shopify has been doing this for a long time with,

with the way that they allow you to add functionality into your, your stores. Stripe I think has done an awesome job of some of this stuff. But like, I think you're going to start to see any of these software-as-a-service type companies can benefit from this. Because for a lot of these companies,

and I know GitHub experiences this a lot, the challenge isn't necessarily implementing the functionality, but it's actually deploying it. So I can write a little workflow that customizes it with a pull request open and ping this person. But now I have to deploy that to a server somewhere. And for most of us, even with free offerings like Zyte now or Heroku or...

Glitch. Glitch, thank you. That was the one I was trying to think of. Which is amazing, by the way. If you haven't used Glitch, check it out. So even with those, there's still some sort of maintenance overhead. And so I think starting to get to the point

where these scripts are run and hosted by the companies whose platforms you're trying to extend, I think it's going to be a huge opportunity for a lot of these companies. That's not where ProBot is now, though. It seems like, if I understand correctly, you're deploying your own version of it. Or is it run on GitHub? It's a little bit of a mix.

We're basically trying to get to this world where any ProB robot app that you write is just magically running in the cloud. And I think things like Glitch are an amazing example of what can be done there. So what we're doing right now, so it's a bot framework

written in Node and JavaScript. And you can take that, build your own apps, deploy them yourself, and then we're taking a bunch of the ones that we think are incredibly useful and reusable and we're running hosted instances of them so like an example um actually back to you want to talk about like sentiment bot or the welcome bot yeah sure so i was actually just the other day writing up some documentation about that but um yeah so during my internship one of the bots i created was sentiment bot which was the

aforementioned sentiment analysis but um just done through um google's perspective api and basically the bot runs in a way such that if you install it on your repository, it will scan through issue comments and if there's an issue comment that is above a toxicity threshold that whoever owns the repository will set in a configuration file, the bot will comment on it and link to the repository's code of conduct as well as just sort of a retroactive way of trying to get people to reconsider potentially negative circumstances. And so that app is hosted so anyone who wanted to install Sentiment Bot on their repository could just go and click through and get a free version

of it. But it becomes more complicated when people want to install multiple instances of apps or make certain customizations that really make sense for their project. So that's definitely a struggle we've had is making everything, you know, the deployed version work for everyone's specific needs. So the bots that are available on probot.github.io right now that are in the Explorer section there. Those are hosted by GitHub, but if you want to do your own version of those or something like it, you host it yourself. Exactly. I think there's nine apps hosted right now.

Probably by the time this airs, there'll be a few more. There's a couple others that are about ready. And then all of them that are listed on the site are open source, so you can take and get feedback on those projects or stand up your own instance. I do want to dive into the details on both the examples. Those are two great ones,

the sentiment bot and the welcome bot. But there may be some other ones that exist to give people ideas of the types of things that people are building with ProBot or which you can build with ProBot. And then we'd also like to people ideas of the types of things that people are building with Probot or which you can build with Probot. And then we'd also like to talk some of the details of how it works with the events and stuff. But before that, staying big picture for a minute, Beck said something interesting there a few minutes back

when they said that when they first started, they didn't realize it was going to be, you know, Brandon's side project. Um, yeah. Or Brandon's passion project. And then, you know, but,

but I guess what that made me start thinking is there's this, I don't know, hazy relationship that I see from the outside with companies and people, open source. And so you have Brandon working on this in his, in part, you know, spare time, but it's very much a GitHub thing. And the way you're talking, Brandon, with regards to like in the future, it would make sense if GitHub was, you know, first party hosting certain things. And it seems like

it could be a valuable business endeavor for the company. And I would just love to have you speak on where all that stands and how you feel about it and what it's like to have a side project that's also kind of a company project. Yeah. This has been a big part of my life this summer, I guess. I mean, obviously, I think that this is a direction that GitHub should look at going it's still to be determined I think if this fits in

with everything that GitHub is doing I mean either way it'll be an open source project that exists and is part of the ecosystem and I mean one of the great things about GitHub is and a lot of companies now is their willingness to allow employees to kind of explore these ideas in open source. Like GitHub explicitly has this balanced employee IP agreement, it's called. And I actually talked to our legal team

in the last few weeks just around, you know, if this does become like a future product thing, like, is there any conflicts in this? And this, the guy I talked to said, this is exactly the kind of thing that they're hoping to encourage. You know, if you, you should,

companies should be encouraging their employees to kind of dabble at the edge of what might be an interesting product area. And if something comes of it, great. Like I'm, I'm still employed by GitHub and like this can become an important part of the company's future and if not like that's okay

like it's been a fun project and I think a lot of people will still benefit from it yeah I mean the short answer to that is I would love to see it become something official and still to be determined. I think the interesting thing about a company like

GitHub is that once you and you've been there for a while too Brandon so I think the interesting thing about a company like GitHub is that once you, and you've been there for a while too, Brandon. So, I mean, once you get to a place like you are as a company, it's pretty easy to start, you know, very similar to Amazon, you know, how they have their main business, but then they also have AWS. And then all these other slivers of, you know, Amazon things, but they're very much standalone businesses. I can see how, maybe not so much how easy

it is, but like Marketplace, for example, or Slash Jobs, you get your job where you get lots of different slivers of GitHub that isn't exactly GitHub's core mission. However, it does lead to the core mission, which is advancing the open source mission. Yeah, and I think an important part of Marketplace, sorry, I think an important part mission, which is, you know, advancing the open source mission. Yeah. Yeah. And I think an important part of marketplace, sorry, I think an important part of the marketplace is that, you know, it kind of encourages this open source ecosystem we're talking about. And I think that to an extent, ProBot isn't really sort of limiting that in the sense

that, you know, when you talk about Amazon, some of those products, you know, have competitors outside of Amazon. But what we're trying to do here is more of just a platform for GitHub apps that really anyone could become part of the ecosystem as opposed to closing people out from it or making it a GitHub-only thing. It's certainly focused on making GitHub smarter, I guess, for the individuals using it, but it's certainly focused on making GitHub smarter, I guess, for the,

the individuals using it, but it's, it's open to anybody to contribute, whether it's using the featured apps or sharing your app or, you know, having the, the, you know,

the, I guess the, the flexibility to write your own and deploy your own. It's still the same pro bot. I think like just looking at GitHub's product strategy, I guess, if you will. GitHub is a tool that has become literally the hub of software development. But we're under no

impression that GitHub will be the only tool that you can use. Every software team is going to bring their own chat service or bring their own CI or have their own internal tools that they've developed over the years that they want to use that should work alongside GitHub. And what I think, like, what I get really excited about with ProBot and one of the reasons it's kind of been this, like, passion of mine is this idea that, like, this could be something that starts to glue github to those other things um you know it doesn't

matter if you're using slack or or hip chat or um you know if you're using travis or circle or jenkins like uh like what's the connective tissue between all of those tools, especially as more of our tools move into the cloud? I think it's important that those connecting pieces are open and accessible to anyone to use and to modify. So when we talk about side projects, I always think of things like, I don't know, generative art or your own programming language or, you know, things that are like either art driven or curiosity. But this is even though we I guess my point is we don't make light of it because it was a side or a passion project.

Very much. This is a proof of concept that you are very interested in seeing exist. And so, you know, you spent your spare cycles working on it. Do you have, is there added pressure when you're building something that doesn't just represent Brandon, but also represents everybody who associates themselves with GitHub, the company, or no big deal? I mean, that's a great question. I think it depends.

There's been moments in past where there's, there is a lot of pressure to get something right the first time. Um, and I think like any company struggles with this, I think around like large product launches, um, you know, or like,

like if we roll out a feature, there's, I don't know, 5 million, 10 million developers using it right away. You know, or how are the 25 million-ish developers on GitHub at the moment? So, like, there is a pressure in that sense

to, like, if you're going to roll out something at a large scale, like, you better be kind of sure that it's right. And our product teams have a lot of really good ways of arriving at that. And, you know almost everything that we ship is iterative and like we start to roll it out to select groups and stuff

like that but so i think there is that sense in anything that's like kind of core i guess to the business um something like this and maybe since this was a side project and a passion project i haven't felt so much of the pressure in terms of like what will people think of this with regard to github i think the bigger pressure has been like i've kind of bought into this vision of where it's going and if it if it doesn't work out like that's a been a pretty big bet for me personally um and i mean i. I'm more than happy to be wrong, but I don't want to be, I guess, if that makes sense. It sounds like you have a lot invested in this.

It's a big bet. He's putting his time into it. He's putting his name on it. This is where he thinks things are heading. He hopes so. That's tough to put yourself out there like that and i just like i think for github itself i mean like so pressure to bring up like dear github but like um for me a lot of that is came out of that moment

of like people were asking github for things that like the engineering team couldn't necessarily deliver um and that's nobody's fault like. We just have a very large audience, and that's a good problem to have. But that doesn't mean that we can't enable people to start building those things themselves. In fact, I think the community would be better off if we got to a place where, as a community, we were starting to actually build features for each other.

A large open- source project like Kubernetes knows a lot more about the pains of managing a large open source project than, you know, someone working on some product feature at GitHub or any company. And so I kind of want us to get to the point where some of these communities that are like pushing the edge of where software is are the ones that are thinking about, you know what, if I build this little bot or build this little feature, it's a tool that I can share. I mean, this is kind of like open source at its heart, right?

So I want to see us start to get to that with all of the other products that we use, not just tools and libraries that we run on our local machine. Coming up after the break, we talk with Brandon and Bex about more of ProBot apps, bots, whatever you want to call them. We want to know how they interact with the GitHub marketplace, how it's built into GitHub apps, what the vision of ProBot is, what it might look like in two or three years and it might even be cool if probot lived inside github instead of a self-hosted kind of thing you got running around

so we talk about all those details after this. is a continuous integration and delivery platform that helps software teams rapidly release code with confidence by automating the build, test, and deployment process. They recently launched version 2.0 of their platform with a focus on providing faster build times thanks to advanced caching strategies and flexible resource allocation. Super fast build cycles ensure quality code by using SSH access and local builds to quickly troubleshoot and remediate. Flexibility to run CI and CD without limits. There's no pausing work while environments update. And language inclusivity frees up your team to use any toolchain or framework

because CircleCI supports every language that runs on Linux. And finally, control workflows. Let your team run build, test, deploy stages as individual jobs, which lets you fully customize your development process. There's a ton more to learn about Circle CI, so head to circleci.com slash changelawpodcast. Once again, circleci.com slash changelawpodcast to learn more. So Brandon, you said that the form of robot, what it exists as today, began to solidify for you when you had some help from your friend, but also when you started some help from your friend,

but also when you started thinking about the use cases that you were trying to solve for. We like to hear some of the use cases out there. We hear a little bit about Sentiment Bot and was it Welcome Bot? But surely there's more than just that. So tell us some of the things that ProBot can do today, and then we'll get into maybe what Probot can do in the future. Yeah, sounds good. I still brought the first app that really took off was the Stale app. And what it does is it just sweeps your repository for stale issues and pull requests.

This is kind of a problem that plagues every open source project where you either open up a bunch of issues of things you want to do eventually or the community starts to come in and make feature requests. And most of those things are great ideas and probably things that could and should be done given infinite resources, but the reality is just that they're not going to get done. And I've actually, over time,

started to notice this happening within GitHub as well. A lot of our projects are going to be used to issues and pull requests to manage them. And I started to feel completely overburdened by all of the unfinished work that was in front of us. And so there was the Jekyll project. Jekyll is the thing that powers GitHub pages. It had an app that would, if there was no activity on a project,

would just ping it and say, hey, it looks like there hasn't been any recent activity on this. If there's no more activity in like a week, I'm going to close this issue. And so that was kind of one of the first ones where I was like, oh man, this is awesome. Like every project should have this. So we built Stale. It's now used by,

I don't actually have an account in front of me, I would guess 150 to 200 organizations on GitHub. Last time I looked, it commented on like 6,500 issues, 6,500 public issues, because you can also use these

on private repositories as well. And yeah, it just helps, it helps you keep your project in shape and, and, uh, make it so that everything that's open is either actionable or things that you intend to,

um, to keep open and keep on the radar of the team. I think that's really helpful. Like in this, there's a weird social dynamic when you have a certain issue that just goes unworked on for long enough where it's like, you know, this should really be closed, but I feel weird closing it explicitly because that's mean or rude or something. And so it's like we can shove off these hard things onto robots

and just be like, well, it just passed the threshold and it's stale now. And so I guess that's what has to happen. It's a freeinging it frees you up to not feel sorry this is the conflict i'm sure right yeah because you can't really get mad at a robot well you can but it doesn't help right i mean they're not going to argue back right yeah unless you program a little silly yeah you would feel a little silly exactly which is like that actually sorry i was gonna say that might lead us later on to where we saw your best practices

for robots we might dive into that at the end if we have time but I was actually just going to bring that up related to getting mad at a robot I mean so actually is that alright if we go into that real quick yeah let's do it just real quick based on stale because I think that's really relevant

so yeah one of the one of the kind of notions behind most of these apps that i that we've been working on is you should build it in a way that it acts as a normal human would um to a degree so like stale we want it to not do something that a maintainer wouldn't be willing to do um and and it should be practicing you know empathy so thinking about So thinking about how's the community going to receive this. So the stale bot will come in and say, hey, if there's no more activity, I'm going to close this. But it does

give people a chance to voice their interest and say, actually, I do really care about this. I want to make it happen. So I think that's really important. It's important for the entire bot ecosystem and app ecosystem to think about as our lives become kind become surrounded by robots. I think it's going to get to the point where we're just overwhelmed and we're around all these dumb robots that don't care about us as humans.

But as long as the designers of those robots are remembering that there's humans on the other side of that. I think that we can design good interactions. There's also that uncanny valley of when a robot almost sounds human, but then it's almost like, I mean Siri a lot of times, or the Google equivalent, will be, it's like more annoying because it's so close to being sentient, but it's not. Exactly. Way too often I give Sirii more credit than well i say she or he you know depending on what voice you choose but you know it's like no sir i did not

mean that and it's just like i forgot you're a robot you don't have you don't even care what i'm saying to you yeah you know it's you get to that point it's like well and you and uh back to what you said you kind of feel stupid because you're talking to a robot and they actually don't really care and in based on the last message they don't understand either that reminds me do you guys know know what siri uh calls me my nickname adam you know this i told you this one uh it calls me how do you say toilet in Spanish? And the reason it says that is because right when they added some Siri features, I pulled it out and I was going to test it.

And I said, hey, Siri, how do you say toilet in Spanish? And then she responds and says, oops, I actually just triggered her. Shut up, Siri. Sorry. So then Siri responded and she goes, okay, I'll call you. How do you say toilet in Spanish? And I said,

I said, yes you will. And so she's been calling me that ever since. Were you with me when that happened? Yeah, I was riding in your car. That's right. I was like, that feels really familiar.

I mean, I knew that, but I didn't. It was like two and a half years ago and she still calls me that to this day. That is so funny. Even inside mail, when it comes a new email in, it'll be like, from Brandon Keepers to, how do you say toilet in Spanish? Anyways. The uncanny valley, for sure.

For sure. Yeah. I mean, I have a lot of feels about the bot ecosystem that's emerging. One of my strongly held beliefs at the moment is that like, I don't converse with bots. Like I want, I want bots that either know what I want or that I can command. Like I don't want to have to have a conversation with a robot knowing that

it's a robot. So like I like that my robot vacuum just every day vacuums the floor at 9am because at one point i told it like 9 a.m is the time that is ideal to vacuum the floor i like that like my nest thermostat you know adjust the temperature based on my behavior in the past and like i don't have i shouldn't have to talk to it um so yeah there's this fine line between like bots practicing empathy and like going too far to to them pretending to be human. It'll be interesting to see where that goes in the next six to 12 months.

We'll add your list of best practices to the show notes. The top level categories are empathy, autonomy, and configuration. So anybody out there building a bot, check out these best practices. And if you have best practices of your own, I don't know, PR, or maybe we should have a thing that is beyond just ProBot, but in general I think best practices for building bots would be a cool thing for anybody to have access to. So back to use case a little bit. We've got stale, we've talked about sentiment,

and welcome bot. What are some other things that people will build with ProBot? Yeah, I'm going to talk about DCO for a bit because I think DCO is kind of a cool niche use case. So I think that back when Probot was in some of its early days, some of the Linux Foundation people who are really into using the developer certificate of origin approached Probot and were like, can you build us a bot that will essentially check for a sign off on every single commit and so dco is a bot that does that pretty simply and i think it's a really interesting use case just because of you we have recently been running into a lot of stuff talking about

how you handle errors and what to do when a commit sign off doesn doesn't have the DCO sign-off. Like, what should we do in that case? How do we correctly communicate with a user that you don't have the sign-off and to basically say, you know, here's how you can fix it and add your sign-off if you agree with the developer certificate of origin. And it's, you know, it's a really simple bot. I think that going back to best practices a little bit, bots commenting on things can get really, really tedious really quickly. I, for a while, was running several of the bots I built all on one repository, and having three comments in a row from three different

bots just doesn't help anything. And honestly, it can be really annoying, which is not really what you want your bot to be. So DCO is only a status check, similar to like a CI check. And I think bots like that that just solve a really simple task are some of the really coolest ones that we've built. So it's almost like the bots are to some degree reacting based on some sort of action or event, as we'll hear about in this bit, but then potentially even trying to have a conversation to some degree, like stepping on each other's toes, basically.

Wasn't there somebody who had two bots that were in an infinite loop at some point on a GitHub thread? I can't recall the details of that, but I remember thinking there was an infinite loop somewhere where one bot was doing one thing and the other was undoing it or replying to it and they just kept going back and forth until I don't know, can GitHub segfault? Can the whole website segfault?

Yeah, at some point the bots reach trigger abuse mechanisms. I've seen a few threads like that. There's been some really clever ones actually where they'll use bots to playfully interact in the pull request, which is fun.

Most of the apps you have listed here though seem to be focused around scripting a better issues user experience or some sort of communication pattern back to the humans involved, since we're talking about bots and humans basically you know the humans involved in a repository or project is that kind of where most of the you know current featured apps are or is that where you see them playing the best fit where's the state of that it's probably more of a reflection of like where our heads have been at um just trying to think through think through how do you demonstrate that you can add features on top of GitHub.

And some of them are what I would consider rather core features. So there's an app for configuring GitHub settings via pull requests. So you just commit a config YAML to your repo, and you can change the project name, you can change the topics, you can change whether it's public or private. So you can have, you know, like open sourcing a repo is now a pull request.

You can change the collaborators, you can configure the labels. So just kind of trying to get people thinking in this idea of, you know, even something like that, which seems, you know, it's like, oh, we're going to have full requests on repos, on repo settings. Like that would have to be a core GitHub feature. But really it's not like the API pretty much allows you to do anything you can

do from the web UI. So starting to demonstrate some of those features. There's also a few bots of just, or I'm trying to not say bots, a few apps. Why did you want to say bots? It is... We had a great branding decision in 2017 in which we transitioned from saying plugins to saying apps all the time. And we also decided to not say bots at that time i think your bot is to build apps

but it's a bot i know it's unfortunately named naming is hard um i think i mean so the bot part of it is just there's a lot of craze about bots like as soon as any like you know the like technosphere gets excited about something um i'm always kind of naturally skeptical um and so for me i think i mean bots i think are really important will continue to be important but they're currently in like one of those hype cycles and i want to make sure that uh as as we come out of that hype cycle that this doesn't die with that um because i think there's more to it than just bots. It's more about building applications and utilities that extend the tools and platforms that we use.

Right. And apps have already been through their hype cycle and back in 2008, they're not. Yeah, now it's just practical. We're over it, yeah. I think the other part of it is kind of going back to that uncanny valley idea. There's a really great talk, actually actually by a woman named Kate Compton called The Poetics of Bots.

And Kate's actually speaking at GitHub Universe, actually platform day, which is the day before GitHub Universe about this. And her, I probably won't be able to summarize it very well, but she looks at like Plato's ideas of poetics, which is like theater and the way that we present stories to each other. And she compares that to like, what is a bot? Well, a bot is an algorithm with eyes. So it's not just like the, the functionality of the application, but it's the way that we experience it in the same way that it's the way that we experienced theater. Um, so I, so I love that, which you'd think I would be tempted to call it bots, but I, there's also this fine line between like, like a lot of

these things actually aren't intended to be bots. They're intended to just be algorithms or software. Kind of going back to my idea of like, I don't want to converse with a robot. I want a robot to just do the thing that I need done with as minimal interaction for me as possible. So between the hype cycle and that notion of like, I think a bot does have a personality and some of these things don't.

And there's an important distinction there. There's an aspect of scale there. And I want you to tell me if I'm keen into it or if I'm being misled. But with a bot, and even with a lot of the existing apps that you guys have with Stale, with Welcome, with Sentiment Bot, uh-oh, it's an app called Bot. I mean, it's bot. These things all are

the Unix philosophy, one thing well. They're very small in scope of what they try to accomplish. But then when you go to GitHub Marketplace where apps exist and you have CircleCI and all these other things that are business-level integrations with GitHub, is ProBot always going to live in the small Unix philosophy of like scripting GitHub? Or is it also supposed to scale up because, and you're building apps with ProBot that you can maybe build a business on? Which one is it?

That's a good question. So from the beginning, Bex mentioned that we originally called them plugins. And it's actually designed so that any of these apps can all be run from the same instance, the same deployment. We can talk more about how it's built, but it's all Node.

And so if you want to combine multiple of these together, you just declare dependencies on each of those packages, and then it will start up and run all of them in one instance. Now it's kind of intentional starting to look at how some of these large open source projects were designing their automation. You look at a project like Kubernetes that I mentioned earlier, they have a ton of really awesome tools built around their GitHub project,

but they're all these monoliths that are tied to Kubernetes workflow. And so the idea was, let's try and pull all of these individual pieces of functionality out so that we can deploy them and they're useful on their own. But then if somebody has custom needs, or if it's an enterprise that wants to run something on their own. But then if somebody has custom needs or if it's an enterprise that wants to run something on their own infrastructure, they can pull all these together

and not have to reinvent the wheel. I think to more directly answer your question, I think the answer is actually, I don't know. I think I like building small things because they're easier. Bex and I have had this back and forth a lot I think I like building small things because they're easier. You know, like, as, like, Bex and I have kind of had this back and forth a lot where, like, we have all these really tiny apps,

which is really nice because, like, every single one is this, like, new fresh start. But then, like, you start to see the patterns in all of them as well, which I think is kind of helpful for influencing future design. So we'll see. On that note, since this is a framework for building GitHub apps, and GitHub apps is essentially, if I'm wrong,

but if the marketplace is built on this GitHub apps idea, right? Yep. Okay, so if that's the case then, so you then have this passion project you've been lifting up, Brandon, and now Bex is involved and others are involved and it's become more and more legit, so to speak. It's no longer this side thing that doesn't have a name or a face or visibility, so to speak. Right. A website, documentation, all the things we've talked about. It seems to me that the worlds are colliding, so to speak. You're giving people the ability to create what is in Marketplace,

but Marketplace has its own strings attached, which is like if it's a for-profit kind of thing, you have revenue share, you've got sort of some edge cases that you may not be personally able to answer now, but that at some point, ProBot may graduate to be something renamed or altogether different, but with similar roots where you're coming from. So the way I see this is that there's the set of features that GitHub decides to build into the product on one side. And then you have on the other end of the spectrum,

if you think about it that way there's marketplace apps which are things that are profitable products that have enough value that you can go and resell them and build a business around them and I think in the middle there's this massive gap of features that are useful to developers but that aren't profitable for someone to start a business on and aren't interesting for github to build

and so i think that's the sweet spot for prova i mean like you know if somebody wants to try and build a business on closing stale issues like best of luck but like those are those are just the type of things that like you know we shouldn't have to deal with. As developers, we shouldn't have to deal with the overhead of these little lacks of automation in our lives every day. But some of these things just aren't profitable. And so the way I've thought about it and tried to explain it to other people is my hope is that this fills in that gap in the middle. So developers get the best experience, you get first-class features from GitHub,

great apps from marketplace partners, and everything in the middle, the community can build themselves and share. Inevitably, I think it is going to force marketplace people to keep going up the stack and try and find things that are higher value. And this is kind of just, I think the story of like human progress where it's, you know, we're constantly solving one problem that used to be profitable and then

now it becomes commoditized and you have to go on and solve the next problem. So I think it will have that effect, but I think in the end developers win. I mean, we, we get better tools. And I think even people building businesses, you're going on and building more interesting businesses that are harder to replicate, which I think puts you in a better position. Let's talk about the technical nitty-gritty a little bit. You mentioned Node, but just thinking from the perspective of,

okay, I would like to script my GitHub. How can I use ProBot? What are the events that are exposed? How do I program against it? We know it's going to be some JavaScript or anything that compiles to JavaScript, I suppose. But tell us how it all works. So basically, what you need to do is you need to go on GitHub itself and set up a GitHub app. And from there, you get a few things. You get an app ID and a private key. And then you can start running a Probot server from there. And that's kind of your connection to GitHub.

Through there, you can also set up permissions, basically. And so the core of Probot is listening on GitHub webhooks. And GitHub webhooks are basically anytime you do an action on GitHub, anytime a pull request is opened, you open a new issue, you close an issue, all of those different things count as a webhook. And so we can listen on those different webhooks and then take actions based off of them. So you set up a GitHub app, you choose your permissions, say you want to do something every time a new issue is opened. So you choose the issue event and you give the app that permission. And then in your local dev

environment, you can, you know, paste the very simple ProBot code. I think there's some on the front page of the website documenting. You just basically have a robot act on issues.opened. And from there, you'll get the context of what's known as the payload, which is basically the webhook event that has just occurred. And GitHub's API is pretty intense. So you'll get a lot of information about that issue that's been opened. And then based off of that, you can do anything with the content. And we have a built-in GitHub API client through the Node GitHub library. And from there, you can basically take any action on GitHub. You can add labels, close the pull request, assign people, etc. And pretty much do anything from there with the code. Sounds so easy. Anything to add, Brandon? No, Beck's covered it.

I mean, it basically tries to abstract all the details about building an app that are not unique to the app that you're trying to build. So you listen for the events, you have an authenticated GitHub client, and then you can start making use of any of the APIs available on GitHub. Yeah. So it probably would be exhaustive to go through all of the events and stuff,

but maybe if there's, and of course, you know, there's documentation now, so go read that. But is there anything that's glaringly missing? Like, oh, I want to build this, but, you know, you guys have already thought of that, and you can't do it because of reason X, Y, I want to build this, but you guys have already thought of that and you can't do it because of reason X, Y, or Z. Up until recently, the pull request reviewer API was unavailable to GitHub apps.

But I think as of potentially soon, most of that will no longer be an issue. Right, Brandon? Yep, I believe so. To kind of expand on that the so github apps was one of the first major features that was launched as a like preview feature um so launched last year at universe um and kind of the idea was like you know get it out in front of people so that you can start using it building on it um keep iterating on it. So the result of that is actually that there's still some things that are in progress.

One of that being some APIs still aren't set up to work with the apps, but hopefully the platform team is working really hard on that. And so hopefully that won't be the case soon. Every API should be available. That's available now. Yeah. Cool. So next up, let's talk about use cases that don't exist.

And maybe y'all could just throw out some ideas. You probably had more than we have in terms of thinking about a thing, but not actually building the app for reasons. But we have some apps that exist. Are there apps that, I mean, there obviously are apps that don't exist, but what are some things that you've thought of that you just haven't had time to build yet or you'd love

for somebody to be inspired and go build a ProBot app? So there's a couple apps that are in progress. Hopefully, actually, well, a couple of them will be available by the time this publishes, but some of them of them will be available by the time this publishes, but some of them I think will be long-term.

One of them that should be available is a reminders app. One of my frequent problems with GitHub issues or just work in general is somebody will ask me about something and it's like, oh yeah, well, I had this and this going on, but I'll come back to it next week. And I don't have a great system for for doing reminders like i've tried to do lists and task lists and using reminders apps all over the place um but one of the things that i've figured out works for me with with everything in life is i store information about that thing in the place where i'm going to

act on it so like i keep you know keep book recommendations as a wish list in amazon because that's where i'm going to buy them. Or I keep movie recommendations in an app on my phone that I buy movies through. And so I want, for reminders, I want those in GitHub. So we're building, basically introducing a couple new concepts with ProBot. You have slash commands. So I can reply to your issue say hey yeah you know i'm in amsterdam this week but i'll take a look at it next week and then just

below that slash remind me next week to you know do whatever um so that'll be that should be launched here pretty soon um there's the linter uh bex you want to talk about that? You've probably worked on that more than I have at this point. Yeah, so linter is my current little pet ProBot app I'm trying to get working. But basically, the goal of that one is to, whenever you push up a commit that's using, right now it's just implemented for JavaScript because that's what ProBot's in, so it's easiest.

And then it would automatically push up a follow-up commit linting your code for you for any linting things you might have missed. And so basically just taking the hassle out of having to read through a CI log telling you if you don't have a semicolon like 20 lines down. Brandon, when you were saying what you said about

the slash commands and things like that, it kind of made me feel like since you said this is designed to help you add features and whatnot to GitHub, it almost made me feel like the reminders idea could be similar to how a browser extension will recognize that you're on an XYZ site. For example, Hacker News where it'll say buffer this or do something somewhere else where it actually adds interface. So the sidebar you might have, rather than just a slash command, you might actually have a brand new piece of interface because you have this app installed and the interface, maybe it's a standard way GitHub has interface. So I'm thinking you can maybe add things to the sidebar or add metadata to issues or just different things, like add things to GitHub that aren't GitHub and maybe store that data somewhere.

I'm not even sure how, but this seems to open the door to allow you to kind of make it up your own. Is that kind of what you're thinking? Metadata. Yeah, that's what I was thinking. Yeah, I mean, that's kind of actually one of our goals and experimenting with this is trying to figure out how to push the platform. I mean, the idea that adding UI to GitHub is not new. I mean, a lot of integrators and stuff have been asking for that.

And it's something that a lot of people on the platform team are really interested in. I think it's just a matter of figuring out what are those patterns. Personally, what I would love to see is if I install an integration or an app that offers CI, there should be a rebuild button on the side of the page. Or if I install an app, if I install Heroku or the AWS app, there should be a deploy button. We're trying to,

we're trying to like tease out some of those patterns. And a lot of these, again, are things that like the platform team has been thinking about for a long time. There's some, we're just really hard problems. And so I think what we're trying to do is figure out how can we standardize at least the concepts behind them.

So like another example of this is that DCO app that Bex mentioned. We've been trying to figure out how to surface errors to users in a way that's helpful. Cause like DCO, like if you don't do it right, you have to rewrite all of your commits. And the status checks are really great in GitHub, except that they don't give you a spot to actually then like help users resolve those errors. You know, like if your CI fails,

you click through to the link and then circle. Or your CI system has the error log. And so it's really interesting to think about how can we bring those back into GitHub? And so, yeah, we're just experimenting with a lot of those patterns, storing metadata on issues, slash commands, displaying the results of checks like COCI or VCO. This is very much in the skunkworks slash.

It's out there. It's available. However, it's early in its days. So a lot of innovation, a lot of change could be potentially expected because you're sort of in this, how should it work? How could it work? What does the community really want? What does the community really need? And even down to, you know, how is it hosted? Because you've got one, which is, you know, hosted apps that you do just in a.github directory inside of your repository, or the opposite, which is hosting you know externally heroku get glitch you know however um it seems like you're still in the very it's it's it's a cake being baked

state it's not it's not ready for it's ready for usage but maybe not full-on consumption yeah um i think like one of the things we've been trying to do with all that, though, is recognize some of the, at least the abstractions early on and pull those out so that the apps aren't having to. So actually, I think the config one would be a good example. Can you talk about that, Bex? Yeah, so one thing that was one of the original goals of ProBot was to not have to use any outside data storage. So most third party integrators like Travis, any CI service have their own website, and you go to their own website. And that's where you kind of view all the data that they're trying to give you. But with Probot, we don't none of the apps at this moment have their own website. So basically, we just wanted to be able to build apps that were purely dependent on your GitHub repo. So that's why we came up with the idea of

having configuration in.github files, so that all of the basically history of your GitHub app lives within GitHub. So it's kind of purely using GitHub as its platform. And recently, we've been having a lot of conversations about the best ways to store configurations that aren't annoying for people, because we've had people want to install GitHub apps at an organizational level. If you have 100 repositories in your organization and you want the same stale settings to act on them, it's kind of we're not really in a space right now where you can easily set that up for all 100 repos without having a configuration file in every repository and we haven't really seen a lot of good patterns for apps that are acting upon it without having

some sort of you know third party actor doing it for them so it's right now you're not sure how to do it at a corporate level across an organization, but you can do it now at project levels. Yeah, there are definitely ways to accomplish it for an organization. It's just maybe not as easy as it could be. Right. An elegant solution that allows you to easily

manage it. That makes sense. I have an app idea. Share it, Jared. Let's share it. Okay. Bear with me. It's called Changelog Promoter Bot. And it watches

every repository on all of github.com issues. And anytime somebody references a changelog, it just chimes in

and says, I'm sorry, did you mean the changelog and awesome podcast about open source? Or did you mean the actual changelog of this project? And it just linksimes in and says, I'm sorry, did you mean the changelog and awesome podcast about open source? Or did you mean the actual changelog of this project? And it just links to our website.

I have a feeling that will get marked as spam. That's funny. Yeah, the spam bots are very aggressive. I actually, on my testing bot, got it marked as spam within my first three days of my internship at GitHub. Oh, wow. It was quite scary.

Achievement unlocked. Wow. We're very close to bot slash app spam. Oh, yes. A problem we do not want on GitHub. I mean, it's hard not to keep up with notifications, let alone spam. Spammers. No spam.

No spam. What's some ways that people can get involved? Is it to build apps? Is it to get involved with the framework itself? What are ways that people who are excited about ProBot and this possibility of scripting GitHub to our liking, what's the best way that the Hackett community can help out this project?

Yes, if you check out the website, probot.github.io, there's basically three main ways right now. So one, just start using some of the apps, like give feedback on the ones that are already hosted. And then we link to all the other ones on GitHub that have been written

so far. Just go try them, hack them, figure out what makes sense and what works for you and what doesn't um and then yeah the second thing is like start to dive into to playing around with it it's really easy to to get started with the hello world example um you can run it on glitch so it's free hosting you can edit it live right in the browser um and then you know the third third way is just getting involved with the community.

There's been a really fun community around this project, kind of starting with Vax, but then several of GitHub's interns this summer got really involved. So, like, Jason at Co. on GitHub, England B. Oh, I started naming people now. I'm going to forget a bunch of people.

But yeah, the community is starting to take off. We do lots of trout slapping in the Slack room. Is that a phrase that's familiar to you guys? I was lost. Trout slapping. Are you a bear?

Yeah, something like that. I don't even know how it started. We were... We also have, continuing our plug for ourselves, a weekly office hours that we just host. It's basically a video conference that anyone can join, ask

questions, get help. During that video conference someone was talking about some product on slack called slap and you know being curious i googled it and the first result was this slack app that just had a slash trout command and it would just slap people with trout like fish trout and so we built one for our own slack channel so that we could trout slap each other i think it's a term of endearment it's basically it seems like it i want to be yeah i noticed that the you're you're contributing documents pretty thorough too in terms of like adding apps and you know in terms of next steps.

You know, someone might be saying, you know, how do I add an app or how do I host my own app? So you're contributing documentation has some pretty good information there in terms of like adding your app to the website, you know, adding a new file in the slash apps directory, all that good stuff. So that's a pretty, pretty neat little thing to be able to add that. Is there any is what can somebody expect in terms of protocol after they do that? Like, is it a pull request? And obviously we get opened up, but like, what's the process of like criteria, so to speak of, of accepting or even the kind of apps you're looking to accept? Yeah.

So I actually outlined most of that document and basically the goal was, the number one concern is that it's just not like an existing app and it is its own app and it actually does something on GitHub. It accomplishes some tasks through the UI. And that's basically it for listing an app. We will basically list any app that, you know, does something and to the best of our knowledge, you know, isn't stolen or copyrighted in any way. But for hosted apps, we have a few more strict requirements. We'd like to see some basically minimal documentation for how you can get set up. Usually it's just a screenshot of the bot in action is enough or if there's any configuration needed, what that is going to look like. We also want the apps that we host, obviously, to be open source.

And then a couple of other just general maintenance things, like we want it to have a license, we want them to have code of conducts, and someone willing to maintain them. But it's a pretty simple process. Either me or Brandon would probably reply to anyone who opened a pill request pretty quickly. So is it possible that you would have an app that you have here, but then also host yourself? I mean, it seems like adding your app is one thing, but then hosting your own app is potentially another. Will you have sort of like two directories?

Like one is the featured that are on there, the nine now, plus the more that are coming, and then potentially a list of hosted apps that are sort of like best of, so to speak, or just like from the community? Yeah, I think the ones that are listed now are all hosted. We're still undecided. Like if we want to, like kind of in the back of my mind, I've always had like we'll feature the ones

that are like one-click install. And then if there's other ones, anything else where where you have to run yourself it kind of requires a little more digging but that's also like that's a hard like chicken and egg problem for some of these apps that are trying to get traction so i think we'll probably you know just exercise a little bit of editorial around you know like there's a couple apps uh there's one that does duplicate issue detection as an example obviously open a new issue and it will um search for other issues that look like that and then comment and be like hey like were you looking for this other one um something like that to me seems really really useful and that i would love to just see have a version out there um but it had it

basically just needs a little bit more work to improve the algorithm um so i was gonna say what's nice too is that you're actually linking up repository directories like the work in progress, for example, is Internet Slow is from Gregor and seems to be

not a GitHub-er, from Hoodie. But the person or persons or community that are involved in that repository or that app get some credit, so to speak, when they get their app listed. Credit where credit's due, right? Yep. And we've also talked about adding more community content style features, adding better ways to give credit to people who are contributing to apps, but maybe not the main creator. We were also considering talking about adding, you know, a blog and featuring a different app every month

and just having sort of community content once, you know, as ProBot hopefully grows to basically be able to give people credit where credit is due. Yeah. Well, very cool. Well, Bex and Brandon, thank you so much for taking your time. And, you know, obviously the promise to care about the community. I think this is certainly something that the GitHub and larger open source community will really appreciate because you're putting a lot of power back into the user's hands and and being able to do things that obviously they weren't able to do before and to Greenfield.

So hopefully this stays in place and becomes something that people use quite a lot. And thank you so much for joining us. You guys are awesome. Thanks for having us. Yeah. Thanks for tuning in to The Change Love this week. If you enjoyed this show, share it with a friend or two.

Rate us on Apple Podcasts. And thanks to our sponsors, Bugsnag and CircleCI. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. We host everything we do on Linode cloud servers. Head to linode.com slash changelog. Check them out. Support this show. That's how we pay the bills. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. It's edited by Jonathan Youngblood. And the awesome music you hear

when we play these shows is produced by the mysterious Breakmaster Cylinder. You can find more shows just like this at changelog.com or by subscribing wherever you get your podcasts. Thanks for listening. Thank you.