{"id":118711,"date":"2019-09-06T01:43:59","date_gmt":"2019-09-06T01:43:59","guid":{"rendered":"https:\/\/livablesoftware.com\/?p=118711"},"modified":"2021-12-22T08:42:47","modified_gmt":"2021-12-22T08:42:47","slug":"slack-chatbot-github-repositories","status":"publish","type":"post","link":"https:\/\/livablesoftware.com\/slack-chatbot-github-repositories\/","title":{"rendered":"Talk with your repositories – A Slack chatbot for GitHub"},"content":{"rendered":"

Sustainability of open source<\/a> is a huge problem, especially in a world where all software depends, one way or the other,\u00a0 on open-source software to run. There are many ways to help and thank open-source maintainers<\/a> but, IMHO, the only scalable option to make OSS sustainable is the use of bots<\/a>.<\/p>\n

There is already a fair number of bots to help in software development<\/a> taking care of repetitive tasks, mainly at the code level. And that’s good, but not enough. I think bots can do much more in order to enable maintainers to focus on important tasks. But for that, bots must be able to talk and interact with the community. As an example, we introduce today our first chatbot for GitHub.<\/a><\/p>\n

Build with Xatkit<\/a> (our open-source low-code chatbot development platform), the bot allows you to “talk” with your repositories from Slack. We focus on two relevant scenarios:<\/p>\n

    \n
  1. For maintainers: the chatbot notifies you when a new issue is opened in Slack. You can assign the issue and add labels to it from Slack itself<\/li>\n
  2. For users: You can file a bug report via the chatbot. Slack (or any other input platform<\/a>) is probably more user-friendly than GitHub itself. And even more importantly, the chatbot will make sure you don’t forget any relevant information when filing the report. Otherwise, you and the maintainer will waste plenty of back and forth time collecting all the data needed to reproduce the bug.<\/li>\n<\/ol>\n

    Even if we focus on these use cases as “inspiration”, you can easily build your own chatbots for GitHub. With the predefined Xatkit GitHub platform,<\/a> the sky is the limit. Combine it with the Slack one or the default web interface and start developing GitHub chatbots in no time and with almost no code.<\/p>\nChatbots can be a great tool for open-source maintainers. Let the bots talk to your users, e.g. to make sure they provide all the required info when filing a bug report. <\/a><\/span>Click To Tweet<\/a><\/span>\n

    From GitHub to Slack: receiving and reacting to GitHub notifications<\/h2>\n

    Let’s first see how we can get notified in Slack of things happening in GitHub. In this example, we’ll just look at “New issue” notifications. The bot should be able to:<\/p>\n

      \n
    1. Receive New Issue notifications from GitHub<\/li>\n
    2. Save time to the maintainer by enabling her to assign a label to the issue and a potential developer that could follow-up on it<\/li>\n<\/ol>\n

      In Xatkit, you define the bot behaviour via two different files<\/a>: the intent<\/em> library (that specifies the potential intentions of the user when talking to the chatbot) and the execution<\/em> model (that defines how to react to the user intentions or other events directly received by the bot). All the code for this example is fully available,<\/a> we’ll just show some code excerpts to give you an idea of how the bot works (take a look to the Stargazer Bot<\/a>, that alerts you when somebody starts your project).<\/p>\n

      To process the OpenIssue <\/em>notification and forward it to Slack, we just need to write this piece of code<\/p>\n

      on event Issue_Opened do\r\n\taction SlackPlatform.PostMessage(message : \"An issue has been opened with the title \" + context(issue).get(\"issue->title\"), channel: config(slack.channel))\r\n\tdef issue = action GithubPlatform.GetIssue(user : config(github.repository.username), repository : config(github.repository.name), issueNumber : context(issue).get(\"issue->number\"))\r\n\tsession.store(\"issue\", issue)\r\n<\/pre>\n
      where we get the issue information from the event and post it to Slack (SlackPlatform is part of the predefined Slack platform in Xatkit<\/a>). The issue itself is also stored in the session for further use.<\/p>\n
      Once the maintainer gets the notification, the chatbot starts listening to see if the maintainer expresses any intention to add a label or assign a user to it. These intents definitions will try to match whatever the maintaner writes in Slack to these two potential actions.<\/p>\n
      intent SetLabel {\r\n\trequires context issue\r\n\tinputs {\r\n\t\t\"Set label Label\"\r\n\t\t\"Give label Label\"\r\n\t}\r\n\tcreates context  issue {\r\n\t\tsets parameter issueLabel from fragment Label (entity any)\r\n\t}\r\n}\r\n\r\nintent AssignUser {\r\n\trequires context issue\r\n\tinputs {\r\n\t\t\"Assign user Username\"\r\n\t\t\"Username will take care of it\"\r\n\t}\r\n\tcreates context  issue {\r\n\t\tsets parameter assignedUsername from fragment Username (entity any)\r\n\t}\r\n}\r\n<\/pre>\n
      Note that intents are defined via a set of training sentences. Training sentences try to represent the different ways a maintainer can express that intention (e.g. set label or give label). Thanks to our DialogFlow integration, additional variations will also be recognized: see the following dialog, where I write “Add label” instead of Set or Give.<\/p>\n
      \"\"<\/a><\/p>\n
      After this chat, the new issue gets properly tagged and assigned in the GitHub repo. No need for the maintainer to move out of Slack to do so. The execution actions associated with the intents take care of this.<\/p>\n
      on intent SetLabel do\r\n\taction GithubPlatform.SetLabel(issue : session.get(\"issue\"), label : context(issue).get(\"issueLabel\"))\r\n\taction SlackPlatform.Reply(message : \"Done!\")\r\n<\/pre>\n
      \"GitHub<\/a><\/p>\n
      Filing a bug report from Slack<\/h2>\n
      If you look at any OSS project, the first iterations in any new bug report are basically the maintainer trying to get from the user who submitted the report all the information needed to reproduce it.<\/p>\n
      This is a huge waste of time for both sides. And one that delays significantly the bug fixing since the communication is not synchronous so depending on the respective availability and time zones, it can go on for a few days.<\/p>\n
      I’ll show you how a chatbot can make sure a bug report has all the basic information a maintainer needs. In the example, we assume the project is a WordPress plugin. Typically, to debug a potential error there we always need to know the WP version and the PHP version the website is running. So to illustrate the capabilities of our chatbot approach for GitHub we’ll make sure the chatbot collects this information.<\/p>\n
      We start by defining the intents. Note that some of the intents are only possible after a previous intent has been matched. Some of the intents store conversation data that we’ll be used to open the bug at the end.<\/p>\n
      intent OpenBug {\r\n\tinputs {\r\n\t\t\"The plugin is not working\"\r\n\t\t\"I have a problem with the plugin\"\r\n\t\t\"I'd like to report an error\"\r\n\t\t\"I want to open a bug\"\r\n\t\t\"I want to report a bug\"\r\n\t\t\"There is an error in the plugin\"\r\n\t}\r\n\t\r\n}\r\n\r\nintent DescribeBug follows OpenBug {\r\n\tinputs {\r\n\t\t\"My error is Error\"\r\n\t\t\"The problem is Error\"\r\n\t\t\"I get this error: Error\"\r\n\t\t\"My error is that Error\"\r\n\t\t\"The problem is that Error\"\r\n\t\t\"I get the error Error\"\r\n\t}\r\n\tcreates context bug {\r\n\t\tsets parameter title from fragment Error (entity any)\r\n\t}\r\n}\r\n\r\nintent TellWPVersion follows DescribeBug {\r\n\trequires context bug\r\n\tinputs {\r\n\t\t\"My version number is WPVersion\"\r\n\t\t\"I use number WPVersion\"\r\n\t\t\"It's version WPVersion\"\r\n\t}\r\n\tcreates context bug {\r\n\t\tsets parameter wpversion from fragment WPVersion (entity number)\r\n\t}\r\n}\r\n\r\nintent TellPHPVersion follows TellWPVersion {\r\n\trequires context bug\r\n\tinputs {\r\n\t\t\"My version is PHPVersion\"\r\n\t\t\"I use PHPVersion\"\r\n\t\t\"It's version PHPVersion\"\r\n\t\t\"The server is on php version PHPVersion\"\r\n\t}\r\n\tcreates context bug {\r\n\t\tsets parameter phpversion from fragment PHPVersion (entity number)\r\n\t}\r\n}\r\n<\/pre>\n
      This is an example dialog with this chatbot.<\/p>\n
      \"Chatbot<\/a><\/p>\n
      And once all the error info has been gathered, we just need to put it all together and open an issue with it. As you can see in the following code excerpt, once the last intent has been matched we ask GitHub to create a new issue with the title and body parameters we collected along the way. We end up labeling the new issue as a bug.<\/p>\n
      on intent TellPHPVersion do\r\n\taction SlackPlatform.Reply(message : \"Thanks for your detailed info\")\t\r\n\tdef newissue = action GithubPlatform.OpenIssue(user : \"jcabot\", repository : \"xatkit-tests\", issueTitle : context(bug).get(\"title\") , \r\n\t\t\tissueContent : \"WP version is \" + context(bug).get(\"wpversion\") + \" PHP version is \" + context(bug).get(\"phpversion\") \r\n\t)\r\n\taction GithubPlatform.SetLabel(issue : newissue, label : \"bug\")\r\n<\/pre>\n
      This generates as end result the following issue created from the above dialog.
      \n      \"\"<\/a><\/p>\n
      To sum up, in a few lines of code we’ve been able to create a bidirectional Slack-GitHub chatbot to help open source maintainers. This was just an example but I hope it’s a good enough example to showcase the potential of (chat)bots to significantly improve the sustainability of open-source.<\/p>\n<\/span>","protected":false},"excerpt":{"rendered":"
      Easily create all kinds of chatbots to easily manipulate your GitHub repositories and make sure that your users provide all the required information when filing a bug report. <\/p>\n","protected":false},"author":2,"featured_media":118713,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[14,10],"tags":[48,115,12,116],"_links":{"self":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/posts\/118711"}],"collection":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/comments?post=118711"}],"version-history":[{"count":0,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/posts\/118711\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/media\/118713"}],"wp:attachment":[{"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/media?parent=118711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/categories?post=118711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/livablesoftware.com\/wp-json\/wp\/v2\/tags?post=118711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}