People always ask "why this repo" and never ask "how is this repo", so I created an app that finds how happy a repository is.
TLDR; The app runs a sentiment analysis engine on your repo and finds how happy it is. Check repostatus
How?
So how exactly do you find the sentiment of a non living thing? Well, even I had that thought in my mind. Any repository is made up of people that contribute to that repo, people that interact in the repo's comments.
So, if we are able to run a sentiment analysis engine on the interactions of the people that are contributing to that repo, we might get somewhere?
repostatus extracts three important part of the repo (by using GitHub's API):
the commit messages
the comments on the issues
the comments on PR's
Once, we have these three things, we can combine them, filter out the unnecessary data and run our engine on it.
Tech
The backend is written in Python (FastAPI) and the frontend is written in Vue
First things first, the sentiment analysis engine used by repostatus is the textblob library. It is very easy to use and works great.
So now that we have the engine at our ease, what's next.
Backend
My goto tech stack is Python so no wonder I went with that for the API.
I used FastAPI for the backend. Off late, I have started liking FastAPI more and more and it was an obvious no brainer to go with it for the backend. It's ease of use with the efficiency is just awesome. If you haven't checked it out, do that, I'm sure you'll love it if you're a Python developer.
Services
Services that the API will offer are:
Internal API for the webapp
Public API
Badge API (Yep, you can use repostatus badges on your README).
I wanted to provide a Public API so that people would be able to use it for their own fun projects. The API is capable of working with both private and public repo's. The details for that can be found here
The badge is another thing that I thought would be a nice little addition. This badge works similar to how the travis build badges work or any badge. You can simply use the URL to embed it into your repositories README.
I love using VueJS. It was obvious that I would use that to build the frontend. Now for the frontend I wanted to make sure that it doesn't restrict the user too much.
Thus, repostatus works with both private and public repos. For private repos, GitHub's OAuth is used which gives us access to that particular repo and then we run the engine over the repo.
One issue that I faced while implementing the OAuth was that I wanted to make the process seamless. If you go the the app now and select on the OAuth option, you will see the process is pretty neat.
Here's what it does:
Opens a new window and asks the user to give access
User gives access and GitHub redirects the user to my sites callback endpoint.
Window closes and the app shows all the users repos.
The above steps makes it look real seamless. However, the hard part for me was to figure out how do I know when the OAuth is done and then show the window.
Seamless OAuth
So in order to make it seamless, I implemented the following flow:
User clicks on OAuth button, new window is opened and the app keeps waiting for it to close.
In the new window, the user is redirected to the callback URL which returns a nice HTML page that shows the user that the window will close in 5 secs. After 5 seconds the window closes and the app knows that the OAuth is done.
The app then tries to find the repo's of that user and accordingly shows the user all the repos.
I know, it's not much. I have to say, though, I really liked implementing this one little feature and making it so seamless. I'm not even kidding, I just kept on doing OAuth on repeat after implementing it, for a while.
Badge
An example of the badge can be seen below.
Isn't it cool?! It supports options like style of the badge where for-the-badge can be used. It changes the color of the badge based on the happiness status of the repo.
How is happiness exactly calculated
As I mentioned earlier, the happiness of any repo depends on certain parts of the repo. Thus, once the commit messages, issue comments and the PR's comments are extracted, they are run through a filter.
Filtering the data
This step makes sure that the data is cleared off of any unreadable content, like an image that the user might have posted in the comments. Or some code inside a code block that the user might have added in an issue report.
Running the engine
Once the data is cleared off all the unreadable content, it is passed to the textblob library that runs the engine on the data.
Now, this library returns a float score. This score is between -1 and +1 where +1 indicates happy and -1 indicates sad.
Thus, when the engine is run on the comments, let's say we get a score of 0.8, this means, based on the comments, the repo is not that happy but it's more happier as compared to being sad. So repostatus considers that based on the comments the repo is happy.
We do the above process on other aspects of the repo too, the commit messages etc.
Once, all the individual scores are available, they are added up and an average is calculated. This average, mathematically, is also between -1 and +1. This is the overall happiness status of the repo.
Based on this score, it is decided what color is to be assigned to the repo.
Caching
Since the engine takes a pretty hefty amount of memory, the score of any repo is cached for 15 days.
The badges are cached for 24 hours and only after that they are updated.
This caching was necessary in order to make sure the performance of the API was not effected.
Backend for repostatus. Repostatus lets you calculate the happiness status of your repository.
What we do?
We consider various parts of the repo like commit messages, comments on issues, pulls etc and run a sentiment analysis engine on the data in order to find out the happiens status.
Setup
You'll need to setup an environ variable named GITHUB_TOKEN that will contain an access token. In order to get the token, follow this article and accordingly save it to the environment.