An Easy, Homegrown, GitHub Issue Management System for Your Developer Outreach Efforts

Do you need to know what issues devs are having with your API or platform in near to real or real time?

Does your team have a platform, API, BaaS or other solution that calls for community developer involvement and developer outreach/evangelism through GitHub? 

Do you need to be responsive to developers that file issues about your product in your Github repo?

If you answered “Yes” to any of the above then this GitHub Issue response system tutorial is for you!

This tutorial will take you through the steps to set-up a multi-layered way to manage incoming Issues via GitHub.  Multi-layed GitHub-driven Issue alerting accelerates the break/fix process and eliminates bottlenecks by getting information into multiple points in the Agile cycle. The system outlined here makes your Agile team as responsive as possible to every incoming GitHub Issue for a given repository.

This system puts developer feedback instantly to work for your team by getting critical feedback into your Agile workflow in all the right places: during planning via a Pivotal Tracker new Story and text message, during testing via a new Zendesk Ticket and post-release via a Ducksboard heads up display.

This type of multi-layed response let’s developers know that you are listening actively and it gets valuable developer feedback into the hands of multiple members of your team quickly so that it can be acted upon quickly and iteratively, the way Agile was designed to.

This tutorial uses the following: a GitHub repository, Zapier, Ducksboard, Zendesk and Pivotal Tracker.

You can choose to use the whole system or just the parts you love, it’s up to you. GitHub and Zapier are the only items that are definitely required for this tut and for the most part they are both free.

Follow the steps and at the end of the tutorial you will have a system that takes an incoming Issue from a GitHub repo and then:

  • files a new Support ticket to your Zendesk account
  • sends a text message to a set of phone numbers like your PM or developer evangelist
  • files a new Bug in your Pivotal Tracker to be triaged (if you use Agile)
  • makes a post to a Ducksboard heads up display wallboard

Step 1

Turn on Issue Tracking for the GitHub repo that your open-source code or SDK reference material resides in. Turn on Issue Tracking by going to your repo and then go to Settings -> Features -> check the box to allow Issues.

After enabling the Issues feature the Issues option will appear for all users as a top level tab next to Pull Requests and Wiki.

Step 2

Let’s get the part working that opens your Zendesk ticket, files a Pivotal Tracker Bug and sends a text message (aka SMS) to some mobile numbers.

Set-up an account (it’s free) at Zapier.

Have your GitHub, Pivotal Tracker and Zendesk account pages open and handy so that you can grab authentication details.

Set-up an account with the SMS folks at, make a new campaign while you are there, name it anything you’ll remember, pick a keyword it can be anything, check off the “MO” box under the Keyword field. Keep the user/pass handy.

Now for the fun part!

Create a new ‘Zap’ on Zapier by finding GitHub in the services marketplace and dragging the GitHub icon into the box on the left. Click the New Issue trigger from the GitHub trigger choices.

Find the Zendesk icon and drag that into the box on the right, select Create Ticket as the action.


Click Create This Zap. The page will set-up forms to collect your auth details for the GitHub side and then the Zendesk side.

In Section 2 drag in the fields from the left that you’d like to populate the new Ticket with.

Scroll all the way to the bottom (don’t worry about Filters or Tests right now) and click Enable.

You’ll land on your dashboard page and see the new Zap live under the Live Zaps table.

Click Create New Zap and run through the same process again but this time use GitHub New Issue on the left and drag Pivotal Tracker over onto the right. Choose New Story for the Pivotal Tracker action.

Enter the auth info for your Pivotal Tracker account. Scroll down drag in the fields from the left that you’d like to populate the new story with and Enable the Zap.

Now the last Zap!

Click Create a New Zap. Drag GitHub to the left as with the previous two, drag Mobyt SMS onto the right. Choose New SMS as the action.


Drag the Mobyt SMS icon into the right side of the Zap and select New SMS as the Action.

Add your authentication info for Mobyt.

Decide what fields you need the people getting the text message really need to see. I normally use the Title and Body.

From the dropdown on the Mobyt side, select the keyword that you set up earlier, it should be the only one there at this point.

In the Recipient field enter the mobile phone number that should get a text message when a new Issue is filed.

Just enter one to get this going, you can add more later once you know it’s working the way you want it to.


Select the Campaign and Keyword that you set up when you opened the Mobyt account. It will be the only option in the list.

Head over to GitHub and file a new Issue in your repo.

Open up your Dashboard on Zapier. All of your services should be Live, not Paused.

Click the gear to open up the menu for each service.

Click Run for each service.

Zapier Run

Click the Run icon to run your new Zap and test it.

After running each service you should see a new Ticket filed over in Zendesk, a new Story filed in Pivotal Tracker and a new text message arrive on your mobile phone.

This next step will allow you and your team to see all of your GitHub Issues in real-time on your heads up display. 

Ducksboard is a versatile real-time dashboard visualization web page that can be displayed on a monitor, a TV or you can link to your Ducksboard page from your Intranet, site or Wiki.

Here is an example of a sample Ducksboard that is displaying recent issues from GitHub, a list of a repo’s followers and some info from Pivotal tracker.

Ducksboard Example

This example is a Ducksboard that shows GitHub Issues, Followers and Pivotal Tracker actions for a given repository.

To use GitHub with a Ducksboard just head to Ducksboard and create an account, there are plenty of free and trial options.

Click the + sign on your first board and scroll around to find the GitHub widget.

Pick the GitHub Issues group then select GitHub Issues, One Column/Two Rows.

After authenticating click Choose Content from the tabs on the left.

Add your GitHub username and the name of the repo where you turned on Issue Tracking.

Save the preferences for that widget and presto, your Ducksboard will begin loading the issues from the repo.

You can add other widgets to the Ducksboard and then share the link with folks on the team who need it or add it to a wall board on a TV etc.


We just created a new Ticket in Zendesk, a new Story in Pivotal Tracker, a text message and a heads up display all from a single new Issue filed on GitHub!

Author: Carol Glennon

Intro to Agile for Engineers (Agile for EE)

This article is an overview of agile development basics, including common terms and processes, used during the agile development process. The overview will help engineers understand the agile elements and stages and have a basic understanding of how the agile process identifies and then delivers a work product.
This is an important overview for engineers that want to understand and communicate effectively with their software counterparts in teams that are employing agile processes such as in partner groups or customer teams.

Agile is set of development methods and recommended processes that strive to deliver higher-quality, ‘shippable’ products through iterative and incremental cycles.
Agile development emphasizes on-going evaluation of features to be built, constant streams of feedback, daily interaction, cross-functional teams and self-selection of work items.
The Agile Manifesto, written in 2001 by agile method pioneers, outlines the importance individuals, interactions, working software, collaboration with customers and responsiveness are to the methodology.

The Agile Manifesto reads, in its entirety, as follows:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”*

*Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
This declaration may be freely copied in any form, but only in its entirety through this notice.


Agile development benefits from working, ‘shippable’, product at the end of each iteration. The work product at the end of each iteration has undergone continuous testing and feature iteration and is ready for production use. Product owners and stakeholders are able to build upon working pieces from each iteration and quickly prioritize features for the next iteration without delay.
A total understanding of the work at hand and constant communication with development, stakeholders, product owners and quality assurance provides cost-savings as expensive delays and testing mishaps are avoided.

Agile Cycle

The agile life-cycle begins with stakeholders and product owners determining what features are possible candidates for inclusion in the product. Product managers leverage stakeholder input to write epics, epics are large user stories that need to be broken down into smaller pieces of work. After an epic is broken down into stories, the stories are prioritized and maintained in a backlog. The backlog is an aggregate of stories pending inclusion in an iteration.
Release planning, iteration planning and daily planning provide iteration teams with the product features that they will work on during iterations.
During release planning developers make estimates about the level of effort required for stories, define what stories will be included in each period of iteration (periods of iteration are known as ‘sprints’ when using an agile scrum methodology).
Aother work product of the planning phase and pre- develoment are test unit cases, these are small unit tests that are written and completed by a developer before beginning work help to increase the quality and accuracy of subsequent code.

Agile Process Stages

The agile process can be implemented in a variety of customized formats. A hallmark of most implementations is requirements gathering and creation of epics and their resulting stories. These become the cornerstone for release planning.
Iteration planning and the backlog go hand in hand as items are pulled from the backlog to be included in a specific iteration or sprint if using scrum methodology.
Estimation is an important part of always improving the iterative process. In the beginning agile estimates can be off the mark but with good practice of iteration retrospective techniques (see next paragraph for more on iteration retrospective) teams learn to estimate well in time.
As the iteration progresses you may hear the term ‘burndown’, this refers to the stories or tasks that have been accomplished so far in an iteration. Items completed and reflected in burndown reports should be demonstrable and shippable.

Agile Testing, Iteration

Testing is an important part of the agile process. Test driven development means that small unit tests are written and manually run by developers right before development.
Automated unit testing enables tests to be written and then performed by software programs designed to test and provide reporting on the results.
Development in agile is continuous, with shippable code being produced constantly. Testing throughout the process vs. just at the end of development, ensures that the iteration is maximized and errors, issues and bugs are found very early on.
At the end of an iteration there will be an interation review, this review is typically an informal demonstration of the working, shippable, code product accomplished during current iteration.
Another goal marker for each iteration is the iteration retrospective. During the iteration retrospective the entire iteration team inspects it’s process and reviews issues that arose during the iteration. Estimates are compared to actual burndown progress to determine the level of accuracy. every iteration attempts to increase estimate accuracy rates. The review is a time to openly determine what worked and what didn’t. The entire team commits to making changes to improve the next iteration.

Agile Methodologies

Agile implementations and methodologies come in many formats. Your organization or your customer’s may use a very traditional implementation or you may see a hybrid form of scrum being used. Whatever the method, the goal of agile methodlogy, a working, shippable product at each iteration, remains.
There are many sources of information to take your agile knowledge to the next level. Courses and certifications in the various aspects of agile are prolific. You can find more information on agile through the Agile Alliance.

Author: Carol Glennon