25 Jan Understanding Open Source Communities, through GitHub Activity (Part 2)

//TODO: Read Part 1. In the first part of this blog series, I explained how we decided to write a plugin for monitoring Github open source communities activity on Count.ly. There are more than 100 repos in the Restcomm GitHub organization, so there’s a lot we need to keep track of!

So, the decision was taken! The only trouble for me was… Count.ly is written in Javascript… And it’s been more than ten years since I’d touched JS code… Now, anyone who lives in JS-land knows ten years is more like two millennia, with the kind of pace things are moving over there, but, hey! Let’s save that a rant for another time.

” I mean, come on, did `toString()` really have to be `JSON.stringify()`”

Several WTFs later battling against my JS noobness, and after some generous help from the Count.ly devs on their Slack group (thanks folks! <3 ), I finally found myself receiving GitHub webhook events in Count.ly. For this, I had to rely on another open source project,  express.js middleware.

Integrating the express.js middleware, wasn’t easy either, and it brought about a further fair-amount-of WTFs, as I had to get acquainted with express.js. Don’t get me wrong– it might have its use cases, but I really wished I could have spared myself the hassle, seeing as I’ll probably never (ever!) use it again…

Anyway, with that, I was now in a position where I could map incoming Github Webhook Events to the Count.ly Custom Events, through their REST API. This meant that I could now see, in Count.ly:

• branch or tag creation / deletion
• forks of a project
• issue creation / updates
• issue comments
• label updates on github issues
• pull request creation / updates
• pull request reviews
• pull request review comments
• push
• watch / star

Critically, this opens up the door for me to correlate these events with other actions performed by Restcomm community members, since each webhook event includes the full event sender information in its payload.

For all these events, we have some visualisations available out of the box such as:

• date histogram
• date histogram + segmentation over 1 metric (varies per event type)
• comparison of different events on same date histogram

 

Or when you build your own Dashboards:

Future Improvements

No State through Custom Events

What I am missing up to now is basically some way of maintaining “state” on Count.ly, through its custom events.

For example, we can’t map a GitHub Webhook event that concerns a specific PR to other events about the same PR (and likewise for issues, etc.). This means I can’t yet keep track of which PR or issue was in what state (open or closed, etc.). I just know that I’ve received an “open” event, a “close” event, and so on.

However, I would really like to build a dashboard with:

• total open vs. closed issues (over time)
• total open vs. merged vs. closed PRs  (over time)
• total stars / i.e. people who watch our repos (over time)
• total forks (over time)

Now, don’t get me wrong, it’s certainly possible to achieve this with Count.ly. Through the plugin mechanism, I am offered access to the underlying Mongo DB, where I can store my own data (in a my own set of collections), then write a corresponding front-end for my plugin. The plugin  would retrieve this data back from the database and render the visualisation accordingly.

Drilling Into Custom Events

A second limitation is that I can’t currently drill down as much as I would have liked into these custom events. For example, when someone stars one of the Restcomm projects, I can see that event in the charts, but I would also like to be able to see more information about that particular event in the charts.

Count.ly now expects a flat structure in its `segmentation` field, and there isn’t a straightforward mapping between all GitHub Webhook event fields as top-level `segmentation` attributes. In other words, it makes little sense to segment the events by GitHub username, just because I want to see who performed the event.

Not Enough Segmentation

Even though the `segmentation` field included in Count.ly Custom Events is a good start to immediately begin visualising and comparing between different events, I would also like to be able to combine more than one segmentation criteria (at the moment, I can only choose one).

Conclusion

All in all, correlating the activity over on GitHub with activity on our own websites, is something our product and sales teams are literally drooling over, so shout out to the Count.ly team for their superb support in building this plugin. It is now available as a Restcomm open source project, and will hopefully find its way in the official Count.ly plugins list soon enough. As always, we are open to Pull Requests and would welcome contributors in either this or any of our other open source telecom software.